Requirements and Architectures for
System-of-Systems Integration
By
Ivo Krka
In Collaboration with Doug Bodner, Nenad Medvidovic, Barry Boehm, Jo Ann Lane,
Bill Rouse, George Edwards, Nupul Kukreja, and Daniel Popescu
Annual Research Review
Center for Systems and Software Engineering
University of Southern California
March 7, 2012
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
Candidate
Netcentric SoS
Requirements
Refinement
Decision Drivers:
Candidate
Netcentric SoS
Architecture
• Type
• Orientation
• Information access
• Platforms and technology
Key Decisions:
• Integration style
• Buy/reuse/build
• Adaptation and
extension mechanisms
• Provide support for traceability
• Provide support for multiple
stakeholders involved in net-centric
integration
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.)
Vista Detention
Facility Node
Booking Jail Site
Configuration
San Diego
Central Jail Node
Data Services Division
(DSD) Node
DSD Site
Configuration
Booking Jail Site
Configuration
EXTERNAL
CONNECTION
Non-Booking Jail
Site Configuration
Descanso Detention
Facility Node
Non-Booking Jail
Site Configuration
South Bay Detention
Facility Node
All internodal interfaces
except the external
connection are identical…
Booking Jail Site
Configuration
George Bailey Detention
Facility Node
Booking Jail Site
Configuration
Las Colinas Detention
Facility Node
Figure 6. JIMS Top Level System View (SV-1) – Internodal Node Interfaces.
Requirements to Architectures
• iCBSP
―Proposed method for refining
integration requirements into an
integration architecture
• Process of use
―Pre-step: filter requirements for
integration
―Augmented version of CBSP method
―Step 1: stakeholders rate importance
and feasibility
―Strong traceability from architecture
to requirements
―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
Experience With iCBSP
• 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
Deriving Architectures from Requirements
using Social Networking
• iCBSP Characteristics
• Winbook
―Human intensive with both nontechnical and technical stakeholder
involvement
―Social networking tool originally
targeted for WinWin requirements
negotiation
―Requirements filtered in each step
and finally rewritten to be made
more precise
―Easy to use by different stakeholders
―The stakeholders negotiate and
reconcile their views of the
importance/feasibility/architectural
relevance of the individual
requirements
―Supports color-coding, tagging,
highlighting, commenting, etc.
―Filtering requirements based on
various criteria
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
• Integration Style =
o Connector Roles + Topology + Linkage
Mechanisms
―Connectors
o Adaptor, arbitrator, distributor, etc.
• Multiple styles may be used in
a system or SoS
―Topologies
o Point-to-point, hub and spoke, shared
bus, etc.
―Linkage
• Different styles result in
different system qualities
o Shared data, messaging, screenscraping, etc.
―Examples:
o SOA = distributor, shared bus,
messaging
o Federated DB = arbitrator, hub and
spoke, shared data
Integration Matrix
System
Interaction
Integration
styles vs.
Properties
Distributed
Local
Secure
Data intensive
Data formats
incompatible
Data consistency
Interaction
protocols
incompatible
Reliable
Real time
One-to-many
Many-to-one
Always available
Periodically
scheduled
Loose coupling
Robustness
Dynamically
reconfigurable
Scalable
Caching
Distributed
transactions
Topology
Point-toPoint
Linkage
Hub and
Spoke
Shared
Bus
Peer-toPeer
Shared
Data
Connector
Messaging Explicit
Data
invocation Streaming
Adapter
Translator
Arbitrator
Distributor
o
o
+
+
o
+
+
+
+
o
o
+
+/+
-
o
+
+
-
+
o
o
+
+
+
o
o
o
+
+
o
+
o
o
o
o
o
o
o
o
o
+
+
o
+
+
o
+
+
o
o
o
+
+
o
o
-
+
+
o
o
o
-
o
o
+
o
o
+
o
o
o
+
+
+
+
+
+
o
+
+/+
o
o
o
+
+
+/+
-
+
+/o
o
+
+
+
+
o
+
+
o
o
o
+
+
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
+
+
+
+
+
+
o
o
+
+
o
o
-
+
o
+
+
+
+/+
+
o
+
+
+
+/+
+
+
o
-
+
+
+
+
+
+
o
+/-
+
+
+
o
+
o
+
+
+
+
Obvious
Hub becomes a
advantages
Shared and
data
bottleneck
disadvantages
repositories are
+
+
-difficult
o to scale
o
o
+
+
+
+
+
o
o
o
o
o
o
o
+
+
+
Integration Matrix Application
Integration
styles vs.
Properties
Topology
Point-toPoint
Linkage
Hub and
Spoke
Shared Bus Peer-toPeer
Shared
Data
Connector
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
0
IntegrationSummary of
specific properties
outcomes
of interest
Decision Support Example
Integration
styles vs.
Properties
Topology
Point-toPoint
Linkage
Hub and
Spoke
Shared Bus Peer-toPeer
Shared
Data
Connector
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
0
Adapters and translators are
not needed as the interfaces
are homogenous
Decision Support Example
Integration
styles vs.
Properties
Topology
Point-toPoint
Linkage
Hub and
Spoke
Shared Bus Peer-toPeer
Shared
Data
Connector
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
Combination
Peer-to-peer
peer-to0
0of ahas
0
peerpronounced
solution and
data
a shared
bus
consistency
solution can
problems
circumvent
relevant for
such
the issues
given system
0
0
1
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