Follow Us:

Develop and Evaluate Integration and Interoperability (I&I) Solution Strategies

Definitions: Integration is merging or combining two or more components or configuration items into a higher level system element, and ensuring that the logical and physical interfaces are satisfied and the integrated system satisfies its intended purpose [1]. Interoperability is the ability of two or more systems or components to exchange information and use the information that has been exchanged [2].

Keywords: integration, interfaces, interoperability, system(s)

MITRE SE Roles & Expectations: MITRE systems engineers (SEs) are expected to be able 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.

Background

Integration and interoperability co-exist with each other. To be successful at integrating two or more elements requires the elements to be interoperable. The elements must co-exist at both the physical and functional levels to be interoperable, and various communication or interface standards must be adhered to. 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 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: If two or more systems are capable of communicating and exchanging data, they 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 interpret the information exchanged meaningfully and accurately to 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, whether it is one used only by themselves or, preferably, a standard model that has been agreed on by a community, so additional interoperability with other systems in the community can be facilitated. 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 the systems engineer 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. (A number of articles cover subjects relevant to strategy formulation under the Acquisition Program Planning and Program Acquisition Strategy Formulation topics in the Acquisition Systems Engineering section of the Systems Engineering Guide.)

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?"

Importance of early and continuous operator involvement. 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) [3] 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 & Resources

1. Kossiakoff, Alexander and William Sweet, 2003, Systems Engineering:Principles and Practice, John Wiley & Sons, Hoboken, NJ.
2. Institute of Electrical and Electronics Engineers (IEEE), 1990, IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, New York, NY.
3. Next Generation Air Transportation System (NextGen) website, accessed May 24, 2010.