Develop and Evaluate Integration and Interoperability (I&I) Solution Strategies
Definitions: Integration is the merging or combining of two or more components or configuration items into a higher level system element and ensuring that the logical and physical interfaces are satisfied and that the integrated system satisfies its intended purpose . Interoperability is "the capability to communicate, execute programs, or transfer data among various functional units" such that the user needs "little or no knowledge of the unique characteristics of those units" .
Keywords: integration, interfaces, interoperability, system(s)
MITRE SE Roles and Expectations: MITRE systems engineers (SEs) are expected to develop and evaluate integration and interoperability (I&I) solution strategies for the program they support and the enterprises of which their system is a part. They are expected to take a broad view of I&I, including technical, organizational, operational, and environmental issues and interactions across systems. In general, the MITRE SE "owns" the overall I&I problem space.
Integration and interoperability co-exist. To be successful at integrating two or more elements requires that the elements be interoperable. The elements must co-exist at both the physical and functional levels to be interoperable, and adherence to various communication or interface standards is required. These can be as simple as a 120-volt AC outlet or as complex as the Transmission Control Protocol and the Internet Protocol that control the exchange of information on a computer network.
As discussed in the companion article, Identify and Assess Integration and Interoperability (I&I) Challenges, to be successful, I&I must consider technical, programmatic, social, and business dimensions.
I&I of information technology (IT)–intensive systems is increasingly important as the concept "the network is the computer" becomes a reality. Almost all products in service today, from televisions to jet aircraft, are either wholly or partially controlled by computers, and therefore I&I strategies for IT-intensive systems require an understanding of two forms of interoperability:
- Syntactic Interoperability: Two or more systems that can communicate and exchange data are exhibiting syntactic interoperability. Specified data formats, communication protocols, and the like are fundamental. In general, Extensible Markup Language or Structured Query Language standards provide syntactic interoperability. Syntactical interoperability is required for any attempts of further interoperability.
- Semantic Interoperability: Beyond the ability of two or more computer systems to exchange information, semantic interoperability is the ability to automatically and meaningfully interpret the information exchanged and to accurately produce useful results as defined by the end users of both systems. To achieve semantic interoperability, both sides must agree to a common information exchange reference model—either one only they use or, preferably, a standard model that a community has agreed on—in order to facilitate additional interoperability with other systems in the community. Regardless, the content of the information exchange requests is unambiguously defined: what is sent is the same as what is understood.
So what does this mean for SEs in developing and evaluating I&I solution strategies? On the most basic level, it requires an understanding of what is needed to effectively integrate the elements of interest while providing a solution that will be interoperable. The detailed answer to this question should be based on the level of interoperability desired, which needs to be rooted in an assessment of operational needs. A key question is whether syntactic interoperability, semantic interoperability, or both are required. This is not necessarily a simple question to answer, but once it has been, the integration strategy can be developed.
I&I solution strategies must be scrutinized to ensure they satisfy program cost and schedule constraints. Other considerations, such as contract structure, implications to other systems (both the systems that directly interface to the system(s) impacted by the strategies and those that are indirectly impacted), probability of success, and risks must be factored into the evaluation. (Several articles cover subjects relevant to strategy formulation under the Acquisition Program Planning and Program Acquisition Strategy Formulation topics in the SEG's Acquisition Systems Engineering section.)
I&I solution strategies need to account for stakeholder agendas and objectives. This is often called the social or political dimension, and it includes actions to address potential issues or objections certain organizations or personalities may pose. One strategy is to socialize alternate solutions with supporting rationale for preferred options. In doing so, be sure especially to encourage or tease out stakeholder inputs in areas important to them as a way to facilitate their buy-in.
Business considerations should focus on plans and strategies of those stakeholders with the greatest equity in the system. Implications for future work programs, systems, and roadmaps should be part of the evaluation process. Naturally the operational users should figure prominently in this dimension, but don't forget the government's prime commercial contractors' interests or equities in the system. Factoring them into your business considerations can help shape the I&I strategy so it gives the government better leverage with the contractor.
Best Practices and Lessons Learned
Operational needs are key. The single most important consideration in assessing integration and/or interoperability solutions is to first understand the operational requirement for exchanging data. Ask yourself: "How much and what type of information is required to be exchanged for the system to perform its mission?"
Early and continuous operator involvement is important. Get users involved early and include them in the operational implications of the I&I solution strategies being considered. This is a continuous process, not a one-time activity.
Working groups that work. Establish an interoperability working group, including all stakeholders, early in the development cycle and meet regularly. There is no better way to ensure nothing "falls through the cracks" than to regularly meet with all stakeholders and discuss the specifics of integration and interoperability. Something as simple as a difference in nomenclature can result in opposite polarities on either end of a signal, with the result that interoperability doesn't happen.
Think broadly. Be sure you step back and consider the broad implications of candidate I&I solutions. Most systems no longer stand alone but are part of one or more systems of systems or enterprises. This makes developing a successful I&I solution strategy more difficult. The problems of integrating boards and boxes into a system are being joined and sometimes supplanted by integrating systems into enterprises with only the loosest of defined interfaces. This is of particular importance when an enterprise exists today and a much more sophisticated (i.e., complex) enterprise will replace it, gradually, over time. One example is the FAA/DoD Next Generation Air Transportation System (NextGen)  being developed to address the extreme growth in air traffic expected over the next two decades. Much of the responsibility, currently allocated to ground-based systems and air traffic controllers, will move to an airborne network and place more responsibility on cockpit personnel. I&I issues and their potential solutions need to be carefully addressed. These issues involve human cognition and decision-making dimensions, not just questions of enabling technologies.
Think incremental. Consider iterative or incremental steps to achieve the desired level of I&I.
Prototypes and experiments. Consider the use of prototyping and experimentation to understand the I&I environment, especially if the objectives are new or the solution is innovative in nature.
Bottom-up. Work integration issues from the lowest level upward. Do not assume that the "box will work" just because it did in another application, unless all integration aspects have been verified first. Make sure the integration strategy and subsequent verification are documented and agreed on by all involved. Don't arrive at the final test and hear "Well, that's not really what we meant..."
References and Resources
- Kossiakoff, A., W. Sweet, S. Seymour, and S. Biemer, 2011, Systems Engineering: Principles and Practice, 2nd Ed. Wiley-Interscience.
- ISO/IEC 2382-01, Information Technology Vocabulary, Fundamental Terms.
- Federal Aviation Administration, NextGen website, accessed July 29, 2015.