ISIS and the Goal of Interoperability

ISIS and the Goal of Interoperability
ED MORRIS

For the last several years, the COTS Spot column has addressed a number of topics important to the use of commercial off-the-shelf (COTS) products in software-intensive systems. Although the focus of the column was intentionally narrow, we recognized that selecting and incorporating COTS products was only one part of the challenge of building large software-intensive systems.

What was apparent from the outset was that large systems—even those with a COTS product at its foundation—incorporate many other types of software. This other software may include legacy-system code, code developed for organizational purposes (e.g., Federal non-developmental-item, or NDI, code), shareware, custom-built adaptation code that extends core COTS capabilities using vendor-provided hooks and languages, and custom code that provides unique capabilities. Constructing a system that integrates these various types of software into a cohesive solution is a daunting challenge.

Also apparent from the outset was the fact that no large-scale software system stands alone in today’s computing environment. Software systems are increasingly expected to use information from and provide information to other systems. For example, satellite ground-support software must interact with mission software; radar systems must share track information; and personnel systems must provide information to financial systems. This assembly of large software-intensive systems into still larger systems of systems has placed intense focus on integration to achieve interoperability¹.

To respond to a growing call to solve the wide range of integration problems evident when diverse systems are incorporated into systems of systems, the SEI has created a new Integration of Software Intensive Systems (ISIS) initiative. To reflect the transition to our new, broader focus, we have renamed the COTS Spot column Eye on Integration.

Part of the foundation of ISIS was established by the SEI’s Systems of Systems Interoperability (SOSI) project in 2003. In this project, we sought to understand the state of the practice for achieving interoperability among systems and to identify areas in which the SEI could help improve the practice.

The SOSI team held two workshops², interviewed several interoperability experts, and surveyed important literature on interoperability. The team identified both successes and failures. In general, interoperability is hard won and expensive. The SOSI team identified a wide range of problems.

New systems designed and constructed to interoperate with existing and other new systems fail to interoperate as expected. Reasons for the failures vary, but incomplete requirements, unexpected interactions, and unshared assumptions were common.
Planned interoperability among new systems is sometimes scaled back to maintain compatibility with older systems that cannot be upgraded without major rework.
Even strict specification of standards (e.g., Link-16) proved insufficient for achieving desired levels of interoperability, because organizations constructing “compliant” systems interpret specifications in different ways, thus creating different, and sometimes incompatible, variants.
Policies sometimes promote a single point of view at the expense of other points of view. For example, policies that enhance the levels of interoperability that can be achieved in one domain are sometimes generalized to additional domains, where they unduly constrain organizations or enforce unhelpful standards.
Funding and control structures within the DoD are not yet sufficient for providing the incentives necessary to achieve interoperability. For example, even though there is increased emphasis on the joint nature of many systems, funding for most programs still flows through service sponsors.
Tests constructed to verify interoperability sometimes fail to identify interoperability shortfalls. In other cases, systems are approved for release in spite of failing interoperability tests.
Even when interoperability is achieved by systems of systems, it is difficult to maintain as new versions of constituent systems are released. These new system versions sometimes break interoperability.

The SOSI project extracted the majority of its lessons from DoD sources. However, lest anyone think that the interoperability problem is limited to DoD systems, consider this commercial banking-industry scenario:

After deregulation of the banking industry, a commercial bank built new capabilities in investment management, insurance, and other areas through acquisition of other firms. The previously independent firms became divisions of the commercial bank and were treated as separate cost centers to encourage retention of staff and motivate high achievement. Following the consolidation cycle, the now larger institution recognized that in addition to diversifying into new market areas, it had acquired dozens of information systems that provided inconsistent, but in many cases duplicate, services. These systems ran on diverse platforms, used different databases, and had unique user-interface and communication requirements. To become more competitive, the institution would have to consolidate some systems and develop mechanisms for interoperation between others. Unfortunately, initiatives to identify a common architecture and shared data semantics for interoperability were disrupted due to several factors, including the diverse hardware and software technologies represented, and the differing demands of the managers of the various divisions. Division managers, who were encouraged to minimize cost and disruption to their existing computing infrastructure and systems, fought hard to avoid making the changes to achieve interoperability.

The banking example highlights several important features of the interoperability problem:

Interoperability problems increasingly involve many systems, and cannot be effectively solved by developing point-to-point solutions between pairs of systems. This is particularly the case for the next generation of systems of systems such as those being developed for e-commerce and for the DoD’s network-centric warfare.
Many situations that call for interoperability among systems are unknown at the time that the involved systems are specified. In this case, the value of interoperability among the banking systems was discovered long after the systems were in use. In general, no matter how carefully requirements for interoperable systems are identified, new opportunities for interaction among systems will emerge.
Individuals and organizations are motivated by many, often competing incentives that may be conflict with achieving interoperability goals. In the banking industry example, disruption to existing systems and costs associated with changes discouraged the compromises necessary for interoperability. In general, organizations are influenced by many incentives that discourage interoperability.

These and many other problems that occur in achieving interoperability are the result of the inherent complexity of managing and building systems of systems. As Fred Brooks³ pointed out more than 15 years ago, technical innovations intended to improve software engineering have not successfully solved the problems represented by this inherent complexity. We believe that such is still the case today, and building and maintaining interoperating systems is becoming an even more complex task.

The SEI is building on the SOSI project. Like SOSI, the SEI will focus on a full range of management, technical, and operational barriers to achieving and maintaining interoperability among complex systems. Keep your eye on Eye on Integration to track our progress.

About the Author

Ed Morris is a Senior Member of the Technical Staff at the Software Engineering Institute, assigned to the Integration of Software-Intensive Systems (ISIS) Initiative. He is currently investigating approaches to achieving technical interoperability between complex systems and programmatic interoperability between the organizations that build and maintain them. Previous activities involved improving processes and techniques for the evaluation and selection of COTS products, and the development of the COTS Usage Risk Evaluation (CURE) technology. Before coming to the SEI, Ed developed custom operating systems for embedded microprocessors along with support tools to predict and monitor the performance of real time systems.

1 For our purposes (at least for now) interoperability is defined as the ability to provide services to and accept services from other systems and to use the services to operate effectively together. Integration is the activity performed to achieve interoperability.

2 Proceedings from the first workshop can be found in the technical note CMU/SEI-2003-TN-016. A technical report detailing the complete SOSI findings is forthcoming.

3 In his classic article, “No Silver Bullet: Essence and Accidents of Software Engineering” (IEEE Computer, 20 (4), 10-19), Brooks suggested that factors such as complexity of systems, lack of conformity between organizations building them, changeability of expectations, and invisibility of details are essential characteristics of software that makes building software difficult.

The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.