NEWS AT SEI
This article was originally published in News at SEI on: April 1, 2005
Within the Department of Defense (DoD), government, and corporate worlds, large-scale systems of systems (SoS) are increasingly being put together in an unprecedented way. Establishing interoperability between the constituent systems is increasingly a key for an organization to meet its critical goals. However, as organizations envision transparent net-centric operations spanning a large number of systems, we have found that successfully achieving such a vision requires a fundamental shift in traditional ways of thinking about system development, acquisition, and management.
In a seminal contribution Mark Maier has argued that systems of systems have unique characteristics that make them fundamentally different from individual systems [Maier 96]. These are
- Operational independence of the systems: Each of the individual systems within an SoS has a life of its own and can function acceptably without necessarily interacting with other systems.
- Managerial independence: The individual systems within an SoS are controlled by different authorities.
- Evolutionary development: Each system within the SoS is developed and upgraded according to a different schedule.
- Emergent behavior: The behavior of the SoS as a whole is not embodied in any one of the systems within the SoS.
- Geographic distribution: The systems within the SoS are not necessarily co-located.
We have found that, consistent with this overall formulation, systems of systems display a global complexity that cannot be managed by hierarchical structures and central control. In fact, the application of traditional approaches to system and software development may result in the development of rigid stovepipes that are ill-suited to the needs of net-centric world of loosely coupled interoperating components.
Despite the critical need for understanding how to make systems interoperable within an SoS context, there has not yet been a guide for understanding what interoperability is, when it needs to be applied, and how to effectively achieve it. In fact, a common view is that interoperability equates to connectivity and applying the right standards. While standards are necessary, they are far from sufficient.
As we develop our understanding of some of these issues, we are creating a web-based Guide to Interoperability. This Guide, over a period of time, will attempt to fill that gap as an evolving, web-based document intended to assist those who are planning, constructing and maintaining interoperable systems of systems. The Guide provides an outline of the organization, technology, and engineering issues that need to be addressed to achieve effective interoperability. It captures best practice and points to promising approaches for construction of highly interoperable systems of systems. Currently, initial drafts exist for a relatively small number of topic areas. The rest of the areas will be filled in over time, and the current drafts will be updated as new information is assimilated.
The Guide has four sections: Introduction, Engineering Practices, Management Practices, and Technologies. This recognizes that the problem of interoperability requires that each of these areas needs to be addressed.
The current outline of the Guide is provided below, together with a brief summary of its content. Initial drafts currently exist for the underlined sections.
A. The SoS Interoperability Problem will outline the basic issues of interoperability within an SoS context, including emergent properties, independence of component systems, and independent evolution.
B. Characteristics of Interoperability will describe the characteristics of interoperability, such as ownership issues, semantic consistency, evolution, dynamism, data management, and communication.
C. Models of Interoperability outlines current models that have been proposed to understand interoperability, including levels of information systems interoperability (LISI), levels of conceptual interoperability model (LCIM), layers of coalition interoperability (LCI), and system of systems interoperability model (SOSI).
II. Engineering Practices
A. Establishing a Concept of Operations
B. Identifying Interoperability Requirements
C. Defining Architectures for Interoperability identifies the mechanisms used by architects to accommodate future change with minimal impact, such as specialized layering, high modularity, well-defined interfaces, standard interfaces, and common integration mechanisms. Architectures that have been used or proposed for achieving interoperability are discussed, including serviced-oriented architectures (SOAs), grid architectures, and component-based architectures.
D. Designing for Interoperability
E. Procuring Interoperable Components discusses approaches for procuring components for systems of systems, including COTS component evaluation and methods for legacy component reuse evaluation.
F. Integrating the SoS discusses mechanisms for achieving integration—including specialized architectures such as SOAs, databases integration, integration through published application programming interfaces (APIs), file sharing, and memory mechanisms and queuing—and outlines classic and updated approaches for dealing with architectural mismatches.
G. Testing Interoperability
H. Maintaining Interoperability
I. The Future of Engineering Processes for SoS
III. Management Practices
A. Building the Business Case for Interoperability outlines issues that motivate SoS interoperability, including faster response to market demands, better decision making, cheaper adoption of new strategies, and adaptive service-oriented networks.
B. Developing an Acquisition Strategy outlines a set of acquisition-related strategies that are being incorporated within the U.S. DoD to facilitate SoS acquisition and identifies groups that are addressing issues of interoperability such as the Open Systems Joint Task Force (OSJTFE), and World Wide Web Consortium (W3C).
C. Establishing a Software Development Lifecycle
E. Contract Management
F. Risk Management
G. Configuration and Change Management
H. Monitoring Progress
I. Planning for Sustainment
J. Managing the Organization
A. Technology Evaluation identifies approaches for technology evaluation, including COTS evaluation technologies, evolutionary testbeds, and a model problem approach for hands-on evaluation.
B. Technologies for Interoperability currently has subsections that summarize the basic concepts and approaches, state of the practice, and implications for systems of systems for each of the following:
a. Web Services
b. Component Frameworks
c. Model Driven Architecture (MDA)
d. Ontology Web Language for Services (OWL-S)
e. Open Grid Services Architecture (OGSA)
As a web-based document, the Guide will evolve over the next several years. The outline provides our initial view of the primary interoperability issues. This outline will be revised as we and the rest of the community gain additional experience.
We solicit your comments and involvement. Rather than waiting several years to present a more complete guide, we have decided to provide releases as a work in progress. New versions of the Guide will be released regularly to update and improve the information provided.
We encourage you to become part of this effort to improve the practice of building interoperable systems by providing feedback on these pages and by sharing your experiences and ideas. Please mail comments to the Integration of Software Intensive Systems (ISIS) Initiative at email@example.com. We will consider your comments in future updates and hope that it will begin to provide useful information over the near term.
1 Interoperability is the ability of a collection of communicating entities to share specified information and to operate on that information according to a shared operational semantics in order to achieve a specified purpose in a given context.
Maier, Mark, W. Architecting Principles for Systems-of-Systems. http://www.infoed.com/Open/PAPERS/systems.htm 1996.
About the Author
Dennis Smith is the lead for the SEI Integration of Software Intensive Systems Initiative. This initiative focuses on addressing issues of interoperability and integration in large-scale systems and systems of systems. Earlier, he was the technical lead in the effort for migrating legacy systems to product lines. In this role he developed the method Options Analysis for Reengineering (OARS) to support reuse decision-making. Smith has also been the project leader for the CASE environments project. This project examined the underlying issues of CASE integration, process support for environments and the adoption of technology. Smith has published a wide variety of articles and technical reports, and has given talks and keynotes at a number of conferences and workshops. He has an MA and PhD from Princeton University, and a BA from Columbia University.
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.