# Patent

## Title
Specifying integration points of a system-of-systems

## Abstract

In accordance with certain embodiments of the present disclosure, specifying integration points of a system-of-systems includes identifying an integration point that associates interfaces of system components. The integration point is characterized according to the identification to generate a set of attributes describing the interfaces. The integration point is specified according to the set of attributes.

## Background
RELATED APPLICATIONS
This application claims priority to U.S. Provisional Patent Application Ser. No. 61/092,670 entitled “DESCRIPTION OF INTEGRATION POINTS OF A SYSTEM-OF-SYSTEMS,” which was filed on Aug. 28, 2008. U.S. Provisional Patent Application Ser. No. 61/092,670 is hereby incorporated by reference.


TECHNICAL FIELD
This invention relates generally to the field of system architecture and more specifically to specifying integration points of a system-of-systems.
BACKGROUND
Developing an architecture of a system involves defining the relationships of the system. Designing the system extends the architecture by developing models of the structure and operation of the system. During the architecture and design phases, interfaces among components of the system may be developed.
SUMMARY OF THE DISCLOSURE
In accordance with the present invention, disadvantages and problems associated with previous techniques for transitioning from system architecture to design in the development of a system may be reduced or eliminated.
In accordance with certain embodiments of the present disclosure, specifying integration points of a system-of-systems includes identifying an integration point that associates interfaces of system components. The integration point is characterized according to the identification to generate a set of attributes describing the interfaces. Requirements of the integration point are specified according to the set of attributes.
Certain embodiments of the invention may provide one or more technical advantages. A technical advantage of one embodiment may be that integration points may link system architecture and interface design. This may reduce duplication of effort and improve consistency of the results.
Certain embodiments of the invention may include none, some, or all of the above technical advantages. One or more other technical advantages may be readily apparent to one skilled in the art from the figures, descriptions, and claims included herein.



BRIEF DESCRIPTION OF THE DRAWINGS
For a more complete understanding of the present invention and its features and advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:
FIG. 1 illustrates one embodiment of a system for which integration points may be specified;
FIG. 2 illustrates an example of an integration point that couples system components;
FIG. 3 illustrates an example of an integration point manager that may be used for the system of FIG. 1;
FIG. 4 illustrates an example of a method for specifying integration points in a system;
FIG. 5 illustrates an example of an architecture diagram that may be used to display information about integration points;
FIG. 6 illustrates an example of a matrix that may be used to display information about integration points; and
FIG. 7 illustrates an example of interface maturity levels that may be used in the method of FIG. 4.



DETAILED DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates one embodiment of a system 10 for which integration points may be specified. In certain embodiments, specifying integration points may include identifying an integration point associating interfaces of system components. The integration point is characterized according to the identification to generate a set of attributes describing the interfaces. Requirements of the integration point are specified according to the set of attributes.
In the illustrated embodiment, system 10 may represent any suitable system that includes system components that communicate with each other, or a system-of-systems. For example, system 10 may represent a border security system-of-systems. In the illustrated embodiment, system 10 includes a plurality of nodes. Examples of nodes include surveillance towers 12 (12a-12d), surveillance vehicles 14 (14a-14b), command posts 16 (16a-16b), a sector headquarters 18, a headquarters 20, existing towers 22 (22a-22b), or other suitable node. A node may be a physical collection of one or more entities that can communicate with other nodes via a communication link 24. Examples of communication links include a voice link 24a (for example, a very high frequency (VHF) tactical link), a data link 24b (for example, a cellular link) a microwave link 24c, an existing 24d, or other suitable link operable to communicate signals between nodes.
A node may operate as a host platform for system components that allow the node to communicate within the node or with other nodes. A system component may include any suitable equipment, for example, commercial off-the-shelf (COTS) equipment or custom equipment. In the example, surveillance towers 12 and surveillance vehicles 14 may each include a radar system as a system component, and sector headquarters 18 may include a track manager system as a system component that receives tracking data from the radar systems.
An integration point associates interfaces of system components to allow that system components to communicate (for example, exchange data). An integration point may describe the interfaces between system components. The interfaces may be between hardware to hardware, hardware to software, or software to software. An integration point may be used to generate interface specification requirements. Different combinations of system components may have different integration points.
In the example, the radar systems and the track manager system communicate through surveillance tower 12 and a surveillance vehicle 14. There are two integration points between the radar system and the track manager system: one integration point is between the surveillance tower 12 and the sector headquarters 18, and the other integration point is between surveillance vehicle 14 and sector headquarters 18. Integration points are described in more detail with reference to FIG. 2.
A glue code system allows system components to exchange information. Examples of glue code systems include adaptors and translators. Glue code systems may perform other suitable operations, for example, debug interface problems, support integration and test interface monitoring, allow for insertion of simulators, and/or minimize the impact of replacing a component system.
A component of system 10 may include an interface, logic, memory, and/or other suitable element. An interface receives input, sends output, processes the input and/or output, and/or performs other suitable operation. An interface may comprise hardware and/or software.
Logic performs the operations of the component, for example, executes instructions to generate output from input. Logic may include hardware, software, and/or other logic. Logic may be encoded in one or more tangible media and may perform operations when executed by a computer. Certain logic, such as a processor, may manage the operation of a component. Examples of a processor include one or more computers, one or more microprocessors, one or more applications, and/or other logic.
In particular embodiments, the operations of the embodiments may be performed by one or more computer readable media encoded with a computer program, software, computer executable instructions, and/or instructions capable of being executed by a computer. In particular embodiments, the operations of the embodiments may be performed by one or more computer readable media storing, embodied with, and/or encoded with a computer program and/or having a stored and/or an encoded computer program.
A memory stores information. A memory may comprise one or more tangible, computer-readable, and/or computer-executable storage medium. Examples of memory include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), database and/or network storage (for example, a server), and/or other computer-readable medium.
FIG. 2 illustrates an example of an integration point (IP) 60 that couples system components 30a-b. In the illustrated embodiment, system component 30 includes protocol layers 62 (62a-62e). Protocol layers 62 include a physical layer 62a, a data link layer 62b, a network layer 62c, a transport layer 62d, and an application layer 62e. 
Integration point 60 may operate to couple one or more protocol layers 62 between the system components 30. In the illustrated example, integration point 60 couples the application layers 62e and the transport layers 62d. In certain situations, a tracking system and a radar system may be separated over a network, so they may exchange data at the application and transport layers, while intervening nodes handle the lower protocol layers. Communication systems may exchange data at no higher than network layer 62c. System components 30 that are physically connected to each other may at least exchange data at the physical and data link layers 62a and 62b in addition to higher protocol layers.
FIG. 3 illustrates an example of an integration point manager 32 that may be used for system 10 of FIG. 1. In the example, integration point manager 32 includes an interface 40, logic 42, and a memory 44. Logic includes a processor 50 and applications 54. Examples of applications include an identifier 55, a characterizer 56, and a specifier 57. Memory 44 stores a requirement specification outline 58.
In certain embodiments, identifier 55 identifies an integration point. Identifiers 55 may identify an integration point by identifying features of the integration point that affect communication between system components. Examples of such features include the type of system components 30 (for example, COTS, custom, or other type such as in FIG. 1), the type of glue code system, the interconnection between system components 30, the system nodes in which the system components 30 are deployed, the protocol layers that are exchanging data, and the interfaces between system component 30.
Characterizer 56 characterizes the integration point according to the identified integration point to generate a set of attributes that describe the interfaces. An attribute may be relevant in determining the risk that the integration point poses to the successful operation of system 10. Accordingly, characterizer 56 may identify integration points that pose the greatest risk. Examples of attributes include the criticalness of data flows between system components 30, the maturity level of an interface, protocol, or system component, the data standards (for example, commercial, government, or proprietary standards) used at each layer, the node that hosts the system component 30, the integration point type (for example, internodal or intranodal), the protocol standards and technologies used at each protocol layer, and/or other suitable attribute.
Attributes may be generated according to any suitable feature of the integration point. In certain cases, a feature may indicate a function or environment of a node, so attributes compatible with the function of the node may be generated. For example, if the integration point 16 is associated with a mobile surveillance vehicle, the attributes may take into account the movement of the vehicle. As another example, if the integration point 16 is associated with a node subject to extreme environmental conditions, the attributes may take into account these conditions. In other cases, a feature may indicate the criticality of an integration point, so the attributes compatible with the criticality may be generated. For example, if the integration point is associated with critical data flows and/or lower maturity levels, the attributes may provide a higher priority.
Different types of attributes may be generated for different types of integration points, such as different combinations of system components. For example, a first set of attributes may be generated if the integration point associates a first system component deployed in a first type of node. A second set of attributes may be generated if the integration point associates the first system component deployed in a second type of node.
Specifier 57 specifies integration point according to the set of attributes. The specifier may specify the integration point by generating requirements specification according to a requirement specification outline 58. The requirements specification may describe features identified by identifier 55 and attributes generated by characterizer 56. For example, the requirements specification may report requirements for one or more protocol layers of the integration point
FIG. 4 illustrates an example of a method for specifying integration points in a system 10. In the method, diagrams 102 that include information about system 10 are displayed. Examples of techniques for displaying information associated with the integration points are described in more detail with reference to FIGS. 5 and 6. The diagrams may be updated as more information about system 10 is gathered.
The method starts at step 104, where integration points are identified. Information identifying the integration points of system 10 may be documented in any suitable manner. As an example, information may be entered into one or more worksheets. For example, information may be entered into a products, integration points, and critical data flows worksheets. The worksheets may be generated using any suitable software, such as MICROSOFT EXCEL
Examples of the worksheets are shown below. In certain embodiments, the product worksheet may be generated from the diagrams of FIG. 5.










Products Worksheet
















Product



Product

Product
System
Classifi-
Product


ID
Product
Vendor
Type
cation
Deployments





C2I_Trk_
Track
AAA
Mission
COTS
Regional HQ,


Mgr
Manager

System

Sector HQ



Interface







Engine






LSS_Rdr
Radar
BBB
Mission
COTS
Surveillance Tower,





System

Mobile Surveillance







Vehicle


Rdr_Glue1
Radar
CCC
Mission
Custom
Surveillance Tower,



Adapter

System

Mobile Surveillance



SW



Vehicle


C2I_Trk_
C2I Track
DDD
Mission
Custom
Regional HQ,


Glue1
Manager

System

Sector HQ



Adapter







SW



















Interface Worksheet












End-to-

Spec


Product 


End

Needed
Product A
Product B
Integration


Interface
Interfaces
?
ID
ID
Points (SV-1)





C2 Track
C2 Track
Yes
C2I_Trk_
Rdr_Glue1
Surveillance 


Correlator-
Correlator

Glue1

Tower - Post


to-
Adapter -



Surveillance 


Radar
Radar



Tower - 



Adapter



Sector HQ







Mobile







Surveillance







Vehicle - Post







Mobile 







Surveillance







Vehicle -







Sector HQ



Radar -
Yes
LSS_Rdr
Rdr_Glue1
Surveillance 



Radar



Tower



Adapter



Mobile







Surveillance







Vehicle



















Data Flow Worksheet












Data 





Data Element
Element
Data

Security


ID
Name
Type
Description
Class





LSS_Rdr_Trk
Radar 
Mission
Track data
Un-



Track
Data
generated
classified





by the Radar.



Rdr_Adapt_Trk
Radar 
Mission
Track data received 
Un-



Adapter
Data
from the radar 
classified



Track

that is converted 






to standard






format and units.



Corr_Adapt_Trk
C2 Track
Mission
Track data received 
Un-



Correlator 
Data
from the radar adapter 
classified



Track

that is reformatted






to the C2 Track 






Correlator format





















Source Product
Destination



ID
Product ID
Applicable Integration Points







LSS_Rdr
Rdr_Glue1
Surveillance Tower




Mobile Surveillance Vehicle


Rdr_Glue1
C2I_Trk_Glue1
Surveillance Tower - Post




Surveillance Tower - Sector HQ




Mobile Surveillance Vehicle - Post




Mobile Surveillance Vehicle -




Sector HQ


C2I_Trk_Glue1
C2I_Trk_Mgr
Regional HQ - Regional HQ




Sector HQ - Sector HQ









Integration points are characterized at step 108 according to the identified features to generate attributes that indicate which integration points pose the most risk during system development. The characterizations of the interfaces may be added to the worksheets as shown below.










Updated Products Worksheet













Application Layer












Product


Integrated

Applicable


Integration


at Appli-

Standards


Points
Integration

cation
Data
and Tech-


(SV-1)
Point Type
ITRL
Layer?
Format
nologies





Surveillance
Inter-Nodal
4
Yes
Commercial
JMS, XML


Tower-Post



Stnds and







Proprietary



Surveillance
Inter-Nodal
4
Yes
Commercial
JMS, XML


Tower - 



Stnds and



Sector HQ



Proprietary



Mobile
Inter-Nodal
4
Yes
Commercial
JMS, XML


Surveillance



Stnds and



Vehicle - 



Proprietary



Post







Mobile
Inter-Nodal
4
Yes
Commercial
JMS, XML


Surveillance



Stnds and



Vehicle -



Proprietary



Sector HQ







Surveillance
Intra-Nodal
7
Yes
Commercial
HTTP,


Tower



Stnds and
XML






Proprietary



Mobile
Intra-Nodal
7
Yes
Commercial
HTTP,


Surveillance



Stnds and
XML


Vehicle



Proprietary



















Updated Products Worksheet













Transport Layer












Product


Integrated

Applicable


Integration


at

Standards


Points
Integration

Transport
Data
and Tech-


(SV-1)
Point Type
ITRL
Layer?
Format
nologies





Surveillance
Inter-Nodal
4
Yes
Commercial
TCP, UDP


Tower -



Stnds



Post







Surveillance
Inter-Nodal
4
Yes
Commercial
TCP, UDP


Tower -



Stnds



Sector HQ







Mobile
Inter-Nodal
4
Yes
Commercial 
TCP, UDP


Surveillance 



Stnds



Vehicle -







Post







Mobile
Inter-Nodal
4
Yes
Commercial
TCP, UDP


Surveillance



Stnds



Vehicle -







Sector HQ







Surveillance
Intra-Nodal
7
Yes
Commercial
TCP, UDP


Tower



Stnds



Mobile
Intra-Nodal
7
Yes
Commercial
TCP, UDP


Surveillance



Stnds



Vehicle









The characterizations may be added to the data flow worksheets as shown below.

















Data








Distribution







Applicable
Scheme 
Delivery

Max

Freq


Integration Points
(src-to-dest)
Method
Priority
Latency
Periodicity
(Hz)







Surveillance Tower
One-to-One
Reliable
High
TBD
Aperiodic
N/A


Mobile Surveillance Vehicle
One-to-One
Reliable
High
TBD
Aperiodic
N/A


Surveillance Tower - Post
One-to-One
Reliable
High
TBD
Aperiodic
N/A


Surveillance Tower-
One-to-One
Reliable
High
TBD
Aperiodic
N/A


Sector HQ








Mobile Surveillance Vehicle-
One-to-One
Reliable
High
TBD
Aperiodic
N/A


Post








Mobile Surveillance Vehicle-
One-to-One
Reliable
High
TBD
Aperiodic
N/A


Sector HQ 








Regional HQ - Regional HQ
One-to-One
Reliable
High
TBD
Aperiodic 
N/A


Sector HQ - Sector HQ
One-to-One
Reliable
High
TBD
Aperiodic
N/A









Integration point requirements are specified at step 110. The requirements may include the messaging structure, communication protocol, and performance requirements for each integration point. The requirements may be generated according to an outline 112. Below is an example of an outline of one way of presenting the requirements.
Requirements Specification Outline
1. Scope
1.1. Identification
1.2. System Overview
1.3. Document Overview
2. Referenced Documents
2.1. Customer Documents
2.2. Contractor Documents
2.3. Standards, Handbooks, Specifications
3. Requirements
3.1. System A deployed in Node X—System B deployed in Node Y Integration Point Interface Requirements

    
    
        3.1.1. Interface Identification and Diagrams
        3.1.2. Message Definitions
        
            3.1.2.1. System A to System B Messages
            3.1.2.2. System B to System A Messages
        
        
        3.1.3. System A to System B Requirements
        
            3.1.3.1. Interface Technology Requirements
            
                3.1.3.1.1. Application Layer
                3.1.3.1.2. Transport Layer
                3.1.3.1.3. Network Layer
                3.1.3.1.4. Data Link Layer
                3.1.3.1.5. Physical Layer
            
            
            3.1.3.2. Protocol Requirements
            3.1.3.3. Performance Requirements
        
        
        3.1.4. System B to System A Requirements
        
            3.1.4.1. Interface Technology Requirements
            
                3.1.4.1.1. Application Layer
                3.1.4.1.2. Transport Layer
                3.1.4.1.3. Network Layer
                3.1.4.1.4. Data Link Layer
                3.1.4.1.5. Physical Layer
            
            
            3.1.4.2. Protocol Requirements
            3.1.4.3. Performance Requirements
        
        
    
    


3.2. System A deployed in Node W—System B deployed in Node Z Integration Point Interface Requirements

    
    
        3.2.1. Interface Identification and Diagrams
    
    


In certain embodiments, requirements for one or more integration points may be specified. Any suitable factors may be considered to determine which integration points require specification. As an example, the maturity level may be used to determine which interfaces to select. Integration points with a low maturity level may be selected to be specified, while integration points with a high maturity level may not be selected. As another example, end users may specify integration points for which they would like to have requirement specifications. As another example, higher risk integration points may be selected. The selected integration points may be noted in the interface worksheet.
Interface specifications are reported at step 112. The method then terminates.
FIG. 5 illustrates an example diagram 210 that may be used to display information about integration points. In certain embodiments, one or more diagrams 210 may be created to illustrate how system components 30 exchange data at any suitable protocol layer, for example, at the application, network, and/or physical layer. For example, different diagrams may be used to describe data exchange at the application, network, and physical layers.
In certain embodiments, multiple diagrams 210 may be created for different levels. For example, a parent level diagram 210 may show internodal interfaces among nodes, and a node may have a child level diagram 210 that shows the intranodal interfaces of the node.
In the illustrated example, diagram 210 describes integration points that communicate at the application and transport layers. For each system component, diagram 210 identifies the system component, the glue code, and a component maturity level. For each interface, diagram 210 identifies the interface and interface maturity level.
FIG. 6 illustrates an example of a matrix 214 that may be used to display information about integration points. One or more matrices may be created for any suitable protocol layer, for example, application and network layer interfaces.
The matrix may have any constant format. In certain embodiments, system component identifiers may run along both axes. A cell that intersects two system components may be marked to indicate that the components exchange data. In certain embodiments, the matrix may indicate the direction of data flow. For example, the horizontal axis may represent data producers, and the vertical axis may represent data consumers. In the example, the radar glue code (RDR_Glue1) sends data to the track correlator glue code (C2I_Track_Glue1) through four different integration points. The track correlator glue code, however, does not send data to the radar glue code.
In certain embodiments, the system component, glue code, and nodes may be displayed. Intersecting cells represent a unique integration point and may be marked with their maturity levels. In the example, the maturity level for the sector headquarters—surveillance tower integration point is 7. In certain embodiments, each maturity level may be given a color identifying the maturity level.
FIG. 7 illustrates an example of maturity levels 216 that may be used at step 108 of the method of FIG. 4. System interfaces may be assigned an interface maturity level in order to identify potentially risky integration points. In the example, the metric for determining the maturity level is the Technology Readiness Level (TRL) (such as that developed by the U.S. Dept. of Defense), and the metric for determining the interface maturity level is the Interface Technology Readiness Level (ITRL)
The interfaces may be classified according to any suitable classification that has any suitable number of classes. In the illustrated example, interfaces may be classified as low maturity, medium maturity, or high maturity.
a. Low Maturity Interfaces:
ITRL ratings 1-3. In low maturity interfaces, the technology, protocols, and/or data formats may be non-standard or have never been used in a deployed system and are still considered experimental. Low maturity interfaces may be regarded as potentially high risk.
b. Medium Maturity Interfaces:
ITRL ratings 4-6. In medium maturity interfaces, the interface technology, protocols, and/or data formats have been proven to be successful outside of the lab, but may not have been used to interface particular system components of a system.
c. High Maturity Interfaces:
ITRL ratings 7-9. In high maturity interfaces, the technology, protocols, and/or data formats have been used to interface the particular types of system components (for example, the particular COTS product). The use may be in a demonstration version in a system, within a systems integration and/or test lab, or as deployed within a system.
For each integration point, maturity levels may be given to the interface technologies, protocols, and/or data formats used to exchange data at each protocol layer. In certain embodiments, a maturity level may be derived using a function applied to other maturity levels. For example, an overall maturity level for an integration point may be the minimum maturity level of the interface maturity level of the protocol layers of the interface. The maturity level assigned to an interface may evolve during the life of a program.
Modifications, additions, or omissions may be made to the systems (including apparatuses) described herein without departing from the scope of the invention. The components of the systems may be integrated or separated. Moreover, the operations of the systems may be performed by more, fewer, or other components. Additionally, operations of the systems may be performed using any suitable logic comprising software, hardware, and/or other logic. As used in this document, “each” refers to each member of a set or each member of a subset of a set.
Modifications, additions, or omissions may be made to the methods described herein without departing from the scope of the invention. The methods may include more, fewer, or other steps. Additionally, steps may be performed in any suitable order.

## Claims

1. A method comprising:
automatically identifying, using one or more processors, an integration point from one or more diagrams displaying a plurality of nodes each deploying a system component and being assigned to a node type indicating a function or an environment of the node, the plurality of nodes including a first node of a first node type and a second node of a second node type, the integration point associating a plurality of interfaces of a plurality of system components deployed by one or more nodes of the plurality of nodes;
characterizing, using one or more processors, the integration point based at least in part on the node types of the one or more nodes to generate a set of attributes describing the interfaces and compatible with the functions or environments of the one or more nodes, the characterizing including generating a first set of attributes based on determining that the integration point associates a first system component deployed in the first node, and generating a second set of attributes based on determining that the integration point associates a same system component as the first system component deployed in the second node; and
specifying, using one or more processors, the integration point according to the set of attributes including the first or second sets of attributes, the specifying including generating a requirement specification for the integration point to be presented to a user, the requirement specification including an identification of the integration point and at least one of a message structure, a communication protocol, or a performance requirement of the integration point.

2. The method of claim 1, wherein the identifying the integration point further comprising:
identifying one or more types of nodes deploying each system component associated by the integration point.

3. The method of claim 1, wherein the characterizing of the integration point further comprises:
characterizing the integration point to indicate a risk level of the integration point.

4. The method of claim 1, wherein the identifying of the integration point further comprises:
identifying each system component as a Commercial Off The Shelf (COTS) component or a custom component.

5. The method of claim 1, wherein the identifying of the integration point further comprises identifying one or more critical data flows, at least one critical data flow of the one or more critical data flows being associated with a lower maturity level, and wherein the characterizing of the integration point further comprises providing a higher priority to the at least one critical data flow.

6. The method of claim 1, wherein the characterizing of the integration point further comprises:
determining a maturity level for one or more protocols layers of the communication protocol.

7. The method of claim 1, wherein the characterizing of the integration point further comprises:
determining a maturity level for each interface of the plurality of interfaces.

8. The method of claim 1, wherein the characterizing of the integration point further comprises:
characterizing a maturity level for each system component of the plurality of system components.

9. The method of claim 1, wherein the generating of the requirement specification comprises:
generating a separate report for one or more requirements for each of one or more protocol layers of the communication protocol.

10. One or more non-transitory computer readable storage media embodied with computer code, when executed by a computer, operable to:
automatically identify an integration point from one or more diagrams displaying a plurality of nodes each deploying a system component and being assigned to a node type indicating a function or an environment of the node, the plurality of nodes including a first node of a first node type and a second node of a second node type, the integration point associating a plurality of interfaces of a plurality of system components deployed by one or more nodes of the plurality of nodes;
characterize the integration point based at least in part on according to the node types of the one or more nodes to generate a set of attributes describing the interfaces and compatible with the functions or environments of the one or more nodes, the characterizing including generating a first set of attributes based on determining that the integration point associates a first system component deployed in the first node, and generating a second set of attributes based on determining that the integration point associates a same system component as the first system component deployed in the second node; and
specify the integration point according to the set of attributes including the first or second sets of attributes, the specifying including generating a requirement specification for the integration point to be presented to a user, the requirement specification including an identification of the integration point and at least one of a message structure, a communication protocol, or a performance requirement of the integration point.

11. The computer readable media of claim 10, wherein the computer code, when executed by the computer, is operable to:
identify one or more types of nodes deploying each system component associated by the integration point.

12. The computer readable media of claim 10, wherein the computer code, when executed by the computer, is operable to:
characterize the integration point to indicate a risk level of the integration point.

13. The computer readable media of claim 10, wherein the computer code, when executed by the computer, is operable to:
identify each system component as a Commercial Off The Shelf (COTS) component or a custom component.

14. The computer readable media of claim 10, wherein the computer code, when executed by the computer, is operable to:
identify one or more critical data flows, at least one critical data flow of the one or more critical data flows associated with a lower maturity level; and
provide a higher priority to the at least one critical data flow.

15. The computer readable media of claim 10, wherein the computer code, when executed by the computer, is operable to:
determine a maturity level for one or more protocols layers of the communication protocol.

16. The computer readable media of claim 10, wherein the computer code, when executed by the computer, is operable to:
determine a maturity level for each interface of the plurality of interfaces.

17. The computer readable media of claim 10, wherein the computer code, when executed by the computer, is operable to:
characterize a maturity level for each system component of the plurality of system components.

18. The computer readable media of claim 10, wherein the computer code, when executed by the computer, is operable to:
generate, as part of the requirement specification, a separate report for each of one or more protocol layers of the communication protocol.

19. An apparatus comprising:
memory to store information with respect to a system comprising a plurality of nodes each deploying a system component and being assigned to a node type indicating a function or an environment of the node; and
one or more processors to execute an integration point specifying module configured to:
display one or more diagrams comprising at least a portion of the plurality of nodes, the at least portion including a first node of a first node type and a second node of a second node type;
automatically identify an integration point from the one or more diagrams being displayed, the integration point associating a plurality of interfaces of a plurality of system components deployed by one or more nodes of the plurality of nodes;
characterize the integration point based at least in part on the node types of the one or more nodes to generate a set of attributes describing the interfaces and compatible with the functions or environments of the one or more nodes, the characterizing including generating a first set of attributes based on determining that the integration point associates a first system component deployed in the first node, and generating a second set of attributes based on determining that the integration point associates a same system component as the first system component deployed in the second node; and
specify the integration point according to the set of attributes including the first or second sets of attributes, the specifying including generating a requirement specification for the integration point to be presented to a user, the requirement specification including an identification of the integration point and at least one of a message structure, a communication protocol, or a performance requirement of the integration point.

20. The apparatus of claim 19, wherein the integration point specifying module is configured to:
calculate a maturity level of the integration point as a function of maturity levels each assigned to a corresponding one of the plurality of interfaces; and
determine whether to specify the integration point based on the maturity level of the integration point reaching a specified level.