ByIvo Krka

In Collaboration with Doug Bodner, Nenad Medvidovic, Barry Boehm, Jo Ann Lane, Bill Rouse, George Edwards, Nupul Kukreja, and Daniel Popescu

Annual Research ReviewCenter for Systems and Software Engineering

University of Southern CaliforniaMarch 7, 2012

Requirements and Architectures forSystem-of-Systems Integration

Problem Space

• Net-centric enterprises engage semi-autonomous business units, each with its own set of requirements

• These units often need to collaborate using their IT systems, involving integration or merging―Temporary vs. permanent integration―Horizontal vs. vertical integration―Data vs. control integration―Desired non-functional properties (e.g., scalability, reliability)

Desired Solution

• Decompose integration requirements into architectures

• Provide support for traceability

• Provide support for multiple stakeholders involved in net-centric integration

Candidate Netcentric

SoS Requirement

s

Candidate Netcentric

SoS Architectu

re

Decision Drivers:• Type• Orientation• Information access• Platforms and technology

Refinem

ent

Key Decisions:• Integration style• Buy/reuse/build• Adaptation and

extension mechanisms

Jail Information Management System

• Provides data consistency and availability at seven San Diego County detention centers

• Interoperates with multiple external systems (Regional Area Crisis Response SoS)

• Security, privacy, performance, reliability & availability requirements

• Reasons for selection―Availability of requirements and data―Diverse issues and challenges

(multiple systems, COTS, vertical and horizontal, transient and permanent integration, etc.)

Figure 6. JIMS Top Level System View (SV-1) – Internodal Node Interfaces.

San DiegoCentral Jail Node

Booking Jail SiteConfiguration

South Bay Detention Facility Node

Descanso Detention Facility Node

George Bailey Detention Facility Node

Las Colinas Detention Facility Node

Vista Detention Facility Node

Data Services Division (DSD) Node

Booking Jail SiteConfiguration

Booking Jail SiteConfiguration

Booking Jail SiteConfiguration

Non-Booking Jail Site Configuration

Non-Booking Jail Site Configuration

DSD SiteConfiguration EXTERNAL

CONNECTION

All internodal interfaces except the external connection are identical…

Figure 6. JIMS Top Level System View (SV-1) – Internodal Node Interfaces.

San DiegoCentral Jail Node

Booking Jail SiteConfiguration

South Bay Detention Facility Node

Descanso Detention Facility Node

George Bailey Detention Facility Node

Las Colinas Detention Facility Node

Vista Detention Facility Node

Data Services Division (DSD) Node

Booking Jail SiteConfiguration

Booking Jail SiteConfiguration

Booking Jail SiteConfiguration

Non-Booking Jail Site Configuration

Non-Booking Jail Site Configuration

DSD SiteConfiguration EXTERNAL

CONNECTION

All internodal interfaces except the external connection are identical…

Requirements to Architectures

• iCBSP―Proposed method for refining

integration requirements into an integration architecture

―Augmented version of CBSP method―Strong traceability from architecture

to requirements

• Process of use―Pre-step: filter requirements for

integration―Step 1: stakeholders rate importance

and feasibility―Step 2: architects rate architectural

relevance―Step 3: architects negotiate and

reconcile disagreements―Step 4: requirements rephrased and

traced to proto-architecture―Step 5: integration architectural

solution selected and applied to proto-architecture

• Effective requirements filtering

• Identified integration architecture elements―16 processing component elements―16 bus elements―11 data component elements

• Traceability from NL requirements to architectural elements―Over 100 traces in the final model

Experience With iCBSP

Deriving Architectures from Requirements using Social Networking

• iCBSP Characteristics―Human intensive with both non-

technical and technical stakeholder involvement

―Requirements filtered in each step and finally rewritten to be made more precise

―The stakeholders negotiate and reconcile their views of the importance/feasibility/architectural relevance of the individual requirements

• Winbook―Social networking tool originally

targeted for WinWin requirements negotiation

―Easy to use by different stakeholders―Filtering requirements based on

various criteria―Supports color-coding, tagging,

highlighting, commenting, etc.

iCBSP in Winbook

iCBSP in Winbook

Classifying and Selecting Integration Solutions With Integration Matrices

• A simple and straightforward knowledge capture method

• Alternative or recurring design decisions across the columns―Patterns, styles, data management solutions, COTS product combinations

• Desired system properties along the rows―Quality goals and NFPs, desired capabilities and features

• Cells capture compatibilities, conflicts, or other relationships―A concise symbol (+/-) or rank (1-10) with a link to a textual explanation

• Using an integration matrix―Quickly “drill down” on a small set of potentially beneficial design options―Identify potential issues and alternative solutions early in the process

Integration Styles and Properties

• Style guides the composition of elements into an architecture

• Multiple styles may be used in a system or SoS

• Different styles result in different system qualities

• Integration Style =o Connector Roles + Topology + Linkage

Mechanisms

―Connectorso Adaptor, arbitrator, distributor, etc.

―Topologieso Point-to-point, hub and spoke, shared

bus, etc.

―Linkageo Shared data, messaging, screen-

scraping, etc.

―Examples:o SOA = distributor, shared bus,

messagingo Federated DB = arbitrator, hub and

spoke, shared data

Integration Matrix

Integration styles vs. Properties

Topology Linkage Connector

Point-to-Point

Hub and Spoke

Shared Bus

Peer-to-Peer

Shared Data

Messaging Explicit invocation

Data Streaming

Adapter Translator Arbitrator Distributor

Interaction

Distributed o + + + o + + + o o + +Local o - + - + o + + o o o -Secure + - o +/- - o o o o o + -Data intensive + - - + + - o + o - + +Data formats incompatible

o + o - - + o o o + o o

Data consistency o + o - + o o - o o + oInteraction protocols incompatible

o + o - + o - o + o o o

Reliable + - + + - + + o o o + oReal time + - +/- - + - + + o o + oOne-to-many - + + + +/- + - + o o + +Many-to-one - + o +/- o + - o o o + +Always available + - o + - + o o o o + oPeriodically scheduled

+ o o - o o o o o o + o

System

Loose coupling - + + +/- - + - - + + + +Robustness - - + + - + +/- - o o + +Dynamically reconfigurable

- o + + o + + o + + + o

Scalable - - + + - + o o o o + +Caching - + + o + o - - o - + +Distributed transactions

- + + +/- + + + o o o + +

Obvious advantages and disadvantages

Hub becomes a bottleneckShared data

repositories are difficult to scale

Integration Matrix Application

Integration styles vs. Properties

Topology Linkage Connector

Point-to-Point

Hub and Spoke

Shared Bus Peer-to-Peer

Shared Data

Messaging Explicit invocation

Data Streaming

Adapter Translator Arbitrator Distributor

Distributed o + + + o + + + o o + +

Secure + - o +/- - o o o o o + -

Data intensive + - - + - - o + o - + +

Data consistency o + o - + o o - o o + o

Reliable + - + + - + + o o o + o

Real time + - +/- - + - + + o o + o

Robustness - - + + - + +/- - o o + +

Distributed transactions

- + + +/- + + + o o o + +

Positive (+) 4 3 4 4 3 4 4 3 0 0 8 4

Neutral (o) 2 0 2 0 1 2 3 3 8 7 0 3

Negative (-) 2 5 1 2 4 2 0 2 0 1 0 1

Positive / Negative (+/-)

0 0 1 2 0 0 1 0 0 0 0 0Integration-specific properties

of interest

Summary of outcomes

Decision Support Example

Integration styles vs. Properties

Topology Linkage Connector

Point-to-Point

Hub and Spoke

Shared Bus Peer-to-Peer

Shared Data

Messaging Explicit invocation

Data Streaming

Adapter Translator Arbitrator Distributor

Distributed o + + + o + + + o o + +

Secure + - o +/- - o o o o o + -

Data intensive + - - + - - o + o - + +

Data consistency o + o - + o o - o o + o

Reliable + - + + - + + o o o + o

Real time + - +/- - + - + + o o + o

Robustness - - + + - + +/- - o o + +

Distributed transactions

- + + +/- + + + o o o + +

Positive (+) 4 3 4 4 3 4 4 3 0 0 8 4

Neutral (o) 2 0 2 0 1 2 3 3 8 7 0 3

Negative (-) 2 5 1 2 4 2 0 2 0 1 0 1

Positive / Negative (+/-)

0 0 1 2 0 0 1 0 0 0 0 0Adapters and translators are not needed as the interfaces

are homogenous

Decision Support Example

Integration styles vs. Properties

Topology Linkage Connector

Point-to-Point

Hub and Spoke

Shared Bus Peer-to-Peer

Shared Data

Messaging Explicit invocation

Data Streaming

Adapter Translator Arbitrator Distributor

Distributed o + + + o + + + o o + +

Secure + - o +/- - o o o o o + -

Data intensive + - - + - - o + o - + +

Data consistency o + o - + o o - o o + o

Reliable + - + + - + + o o o + o

Real time + - +/- - + - + + o o + o

Robustness - - + + - + +/- - o o + +

Distributed transactions

- + + +/- + + + o o o + +

Positive (+) 4 3 4 4 3 4 4 3 0 0 8 4

Neutral (o) 2 0 2 0 1 2 3 3 8 7 0 3

Negative (-) 2 5 1 2 4 2 0 2 0 1 0 1

Positive / Negative (+/-)

0 0 1 2 0 0 1 0 0 0 0 0Peer-to-peer has pronounced data

consistency problems relevant for the given system

Combination of a peer-to-peer solution and a shared bus solution can circumvent

such issues

Proof-of-Concept Wiki Implementation

• Knowledge capture and management via wiki format (e.g., rationales)

• Platform for feedback on usefulness of proof-of-concept tool, plus relevance of row and column headings

Future Work

• Winbook-based multi-stakeholder requirements negotiation

• Devise configurability of integration matrix

• Further methodology enhancements―Buy/reuse/build―Incorporate technical restrictions and limitations when identifying

architectural solutions―Detection of possible mismatches with proposed guidelines for specific

adapters/translators―Solution ranking based on prioritization of the desired properties