Follow Us:

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

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, interoperability

MITRE SE Roles & Expectations: MITRE systems engineers (SEs) are expected to be able to identify and assess integration and interoperability (I&I) issues in the program 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 systems engineers 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 operational business needs of the customer. A critical first step in identifying and assessing I&I challenges is to understand the systems engineer's responsibilities in addressing integration and the complexities of the associated problems.

Systems Engineering Responsibilities

Systems engineers 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; and
• Business interactions crossing many different commands or operating center boundaries.

Common to all of 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, the systems engineer 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 systems engineers often rely on modern information technology (IT) to provide significant components for their systems. Due to the evolution of IT and the systems engineer'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

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

The technical area focuses on the system itself, usually without regard for people. There are physical, logical, and environmental aspects to consider. The systems engineer 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, the systems engineer needs to ensure signals are interpreted correctly, and that data exchanged at the interfaces conforms to a defined structure and intended semantics. Further, the systems engineer 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. Finally, the systems engineer 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.

The programmatic and social areas are dominated by the system stakeholders. Stakeholders include everyone who needs to be involved in the development of the system: owner, administrator, operator, etc. Each will have a different perspective on risk associated with the project, and often these risks are not technical. The systems engineer needs to listen to and consider all stakeholder views, while understanding 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, the systems engineer will have a major stake in working out informed decisions.

The systems engineer also 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. There are also enterprise processes that will affect the development and fielding of a system (e.g., the Department of Defense Information Assurance Certification and Accreditation Process). It is incumbent on the systems engineer to maintain awareness of enterprise standards and processes. For more information on this topic, see Standards Boards and Bodies in the Enterprise Engineering section of the Systems Engineering Guide.

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

Best Practices and Lessons Learned

Interfaces—live or die by them. Interfaces are where the systems engineer 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 the systems engineer is 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, the systems engineer 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 non-technical 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 posed by the component.

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 on this topic, see Systems Engineering Strategies for Uncertainty and Complexity in the Enterprise Engineering section of this Guide.

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 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 will be critical to the acceptance of a system. The more stakeholders involved, the greater the degree of difficulty will be.

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 they appear 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 systems engineer 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.

Summary

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 systems engineers. Well-defined interfaces help the process.

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.