Identify and Assess Integration and Interoperability (I&I) Challenges

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 [1]. 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" [2].

Keywords: integration, interoperability

MITRE SE Roles and Expectations: MITRE systems engineers (SEs) are expected to identify and assess integration and interoperability (I&I) issues in the programs they support and in 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.

Integration and Interoperability

Identification and assessment of I&I challenges are often system-dependent. Experience shows that integration and interoperability are two sides of the same coin, and SEs need to be concerned about both. Integration is typically addressed when a system is being developed—ensuring that the interfaces are well understood and documented and that the physical environment has been thoroughly addressed in the design and implementation. Interoperation is more about the role of the developed system—how the various components interact to meet the customer's operational business needs. A critical first step in identifying and assessing I&I challenges is to understand the SE's responsibilities in addressing integration and the complexities of the associated problems.

Systems Engineering Responsibilities

SEs should adopt the point of view that they own the I&I issues associated with their system, whether they are formally responsible for them or not. This includes all aspects of I&I: technical, programmatic, social, and business. The degree to which any one of these aspects dominates depends on the system being developed, the cultures and agendas of the stakeholder organizations, and the environments into which the system is expected to be deployed.

I&I can cover a broad range of issues, such as:

  • Electronic components being incorporated onto a motherboard
  • Computer subsystems and software forming a personal computer
  • Mechanical components being included in a vehicular drive train
  • Radio transceiver and antenna being installed in a vehicle or aircraft
  • Multiple computers and applications being built into a command center
  • Business interactions crossing many different commands or operating center boundaries.

Common to all these issues is the need to manage requirements for performance, size, weight, power, and cooling. Environmental constraints must also be considered. When software is a component, processing platforms, operating systems, and languages are all concerns from multiple perspectives, including intended use, future supportability, and modernization roadmaps.

I&I can take on a nested nature. In a worst-case scenario, SEs may have to worry about everything from the development of integrated circuits, to the collection of business processes spanning organizations, and everything in between. Fortunately, this extreme situation is rare, and SEs often rely on modern information technology (IT) to provide significant components for their systems. Due to the evolution of IT and the SE's relationship to it, along with the government's increasing focus on capability development, MITRE's role in I&I is moving from integration of components and subsystems to integration of systems, systems of systems, and enterprises.

Complexities of I&I

SEs can identify and assess I&I challenges in several interacting areas: technical, programmatic, social, and business.

  • Technical: The technical area focuses on the system itself, usually without regard for people. There are physical, logical, and environmental aspects to consider. SEs must ensure that physical subsystems fit together and interact properly. Items such as cabling or mechanical fit and finish at the interfaces must be verified. Logically, SEs needs to ensure that signals are interpreted correctly and that data exchanged at the interfaces conforms to a defined structure and intended semantics. SEs must understand how the system under consideration fits operationally into the enterprise in which it will exist and how the technical capabilities work in conjunction with other systems to meet mission needs. SEs may need to address how the system supports installation and the possibility of dual side-by-side operations with an existing system to support transition.
  • Programmatic and social: The system stakeholders dominate the programmatic and social areas. They include everyone who needs to be involved in the development of the system: owner, administrator, operator, etc. Each has a different perspective on risk associated with the project, and often these risks are not technical. SEs need to listen to and consider all stakeholder views, but understand that the goal is not to accommodate all stakeholder requests. This can be a driver in complexity of system development. Although juggling expectations, budgets, and schedules is a program manager's responsibility, SEs have a major stake in working out informed decisions.
  • Business: SEs must understand the business environment in which the program operates—funding, relationships and dependencies with other programs and organizations, business strategies, and motivations—so integration issues can be identified and understood in the context of this environment.

Finally, enterprise constraints must be addressed. The enterprise is typically concerned with broad-based interoperability, and it levies requirements on developers to help ease integration as the business environment evolves. These restrictions are usually expressed as technical standards to be employed in system development. Enterprise processes will also affect the development and fielding of a system (e.g., the Department of Defense Information Assurance Certification and Accreditation Process). It is incumbent on SEs to maintain awareness of enterprise standards and processes. For more information, see the Standards Boards and Bodies article in the SEG's Enterprise Engineering section.

SEs are also encouraged to read Develop and Evaluate Integration and Interoperability (I&I) Solution Strategies, the companion article to this one in the Systems Integration topic area.

Best Practices and Lessons Learned

Interfaces—live or die by them. Interfaces are where SEs can exert control, particularly in the technical area. Internal and external interfaces must be established and their configuration managed. Identify in detail as many interfaces as possible. External interfaces represent the boundary and scope of the system for which SEs are responsible. Interfaces among the stakeholders are equally important. Interfaces to the business process or operations also should not be forgotten.

Communication—essential for success. In addition to providing high-quality documentation and interface specifications that communicate how the system is intended to operate, SEs must also monitor dialog interfaces among the various stakeholders to ensure the program stays on track. Encouragement of open, factual communications among the stakeholders can be the lubrication that makes it all happen. This nontechnical skill is often overlooked.

Subsystems—use them wholesale if possible, but verify their appropriateness. Use of commercial off-the-shelf assemblies for both hardware and software systems is common. To ensure success, all subsystems should be qualified for performance and acceptance-tested commensurate with the risks that the component poses.

Problems in the technical area—plan for the unexpected. Realize and accept that system integration will not be flawless the first time. The more "moving parts" the system has, the bigger the challenge. Provide time in the schedule and funds in the budget to accommodate the occasional failure. Increased testing may also help minimize errors. Close attention to the deployment environment is also warranted. For more information, see the Systems Engineering Strategies for Uncertainty and Complexity article in the SEG's  Enterprise Engineering section.

Let risk drive your focus. Use risk identification and management strategies to help you decide the specific areas and techniques you will use to focus your work. For example, if the component or subsystem integration activities appear to be well managed by the contractor compared to some system or enterprise integration issue, focus your attention where it is needed and balance your tasks based on the severity of the risks. For details on risk identification and management strategies, see the Risk Management topic in the SEG's Acquisition Systems Engineering section.

Change—anticipate it. New things are not always welcomed by the people who are expected to use them. A rollout plan and training are critical to the acceptance of a system. The more stakeholders involved, the greater the degree of difficulty.

Unintended system usage—count on it. To accommodate the reality that a system will not be employed exactly as the original designers intended, build in as much flexibility as you can. This is especially true for IT-based systems, where adoption of popular standards at the external interfaces can pay dividends as the system and other systems evolve in their operational environment.

Recognize and address I&I gaps. This is critical, especially when it appears to be outside your area of responsibility. It is the age-old problem of doubles tennis—both players think it is the other's responsibility. System I&I is such a multi-faceted and complex area that there is always a risk that an issue or consideration has slipped through the cracks of the integration team. Each SE should take ownership to ensure that I&I occurs thoroughly and correctly across the team's span of influence, both vertically and horizontally.

Standards—a helpful nuisance. Standards-based interfaces are easy to enforce in theory. In reality, they mature over time, compete across standards organizations, and often do not exist for the specialized interfaces you need. Nevertheless, standards provide a meaningful starting place for interface definition, when they are available.


Integration is a difficult topic due to its many facets. Technical integration has its challenges, but the real difference between success and failure is in dealing with people. Time and energy spent on constructive stakeholder interactions is a good investment for SEs. Well-defined interfaces help the process.

References and Resources

  1. Kossiakoff, A., W. N. Sweet, S. J. Seymour, and S. M. Biemer, 2011, Systems Engineering Principles and Practice, 2nd Ed., Hoboken, N.J., John Wiley & Sons.
  2. ISO/IEC 2382-01, Information Technology Vocabulary, Fundamental Terms.


Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Contact the SEG Team