NEWS AT SEI
This article was originally published in News at SEI on: January 1, 2004
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 interoperability1.
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 workshops2, 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.
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:
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 Brooks3 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.
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.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.