By Donald Firesmith Principal Engineer
Software Solutions Division

Due to advances in hardware and software technologies, Department of Defense (DoD) systems today are highly capable and complex. However, they also face increasing scale, computation, and security challenges. Compounding these challenges, DoD systems were historically designed using stove-piped architectures that lock the Government into a small number of system integrators, each devising proprietary point solutions that are expensive to develop and sustain over the lifecycle. Although these stove-piped solutions have been problematic (and unsustainable) for years, the budget cuts occurring under sequestration are motivating the DoD to reinvigorate its focus on identifying alternative means to drive down costs, create more affordable acquisition choices, and improve acquisition program performance. A promising approach to meet these goals is Open Systems Architecture (OSA), which combines

• modular open development practices designed to reduce the cycle time needed to acquire new systems and insert new technology into legacy systems, and
• business models for creating a more competitive marketplace and a more effective strategy for managing intellectual property rights in DoD acquisition programs.

This blog post expands on earlier coverage of how acquisition professionals and system integrators can apply OSA practices to effectively decompose large monolithic business and technical architectures into manageable and modular solutions that can integrate innovation more rapidly and lower total ownership costs.

What is OSA and How Should It Be Applied?

By definition, an OSA is any system (or software) architecture that exhibits the following three beneficial characteristics:

1. It is modular, being decomposed into architectural components that are cohesive, loosely coupled with other components (and external systems), and encapsulate (hide) their implementations behind visible interfaces.
2. Its key interfaces between architectural components conform to open interface standards (that is, consensus based, widely used, and easily available to potential users).
3. Its key interfaces have been verified to conform to the associated open interface standards.

By mandating contractors to engineer OSA (e.g., via Better Buying Power 3.0), government acquisition organizations hope to achieve several benefits, two of the most important of which are to increase competition among developers of the architectural components and to avoid vendor lock when it comes to acquiring and updating these components. Given these benefits, government program offices may get the impression at first glance that all system architectures should be completely open. This impression is especially true when one considers the DoD policies (such as DoDI 5000.02) that require program offices to ensure defense contractors produce open system architectures.

One critical word in the definition of open system architectures, however, reveals this initial impression to be false. The definition does not state that all interfaces must conform to open interface standards, but rather only key interfaces must be open. Moreover, if one examines actual system architectures, one quickly learns that openness is not black and white but rather a matter of degree. Some interfaces are highly open (e.g., they conform to widely used international standards), some interfaces are relatively open (i.e., they conform to less-widely used, more application-domain-specific standards or widely used de facto standards), some interfaces are slightly open (e.g., they conform to product-line-specific conventions), and some interfaces are essentially closed (i.e., they are system-unique or conform to contractor-proprietary "standards").

Steps to Producing an OSA

Several steps required to produce an OSA are described below.

• Step 1: Decide how to modularize the system. The main OSA modularization approach typically decomposes the system into separately procurable architectural components to support competition, minimize vendor lock, and enable technology refresh. This approach is used to identify the key architectural components of the system that should be open, while the other parts potentially may be closed or partially open. The interfaces of these key components are then defined as the key interfaces that should conform to open interface standards.
• Step 2: Determine the associated open interface standards to use for key interfaces. When should an interface be identified as a key interface and, therefore, when should that interface be open? The answer is really a matter of cost-benefit analysis. While there are clearly benefits to being open, there are also associated costs and challenges. Mandating the use of an open interface standard may necessitate the replacement of an existing closed (e.g., proprietary) interface, training the developers to use the new interface standard, and lowered developer productivity until the new interface standard is mastered.
• Step 3: Verify conformance to the open interface standards. As mentioned earlier, an open interface must be verified (via testing or static analysis) to conform, both syntactically and semantically, to the associated open interface standard. It is also important to document and verify any implementation-defined portions of the standard.

In theory and if all things were equal, it would be good if all architectural components were modular and open. In practice, however, all things are not equal and other quality attributes (such as dependability, performance, robustness, safety, and security) may be more important than openness alone for some architectural components. Perfectly good reasons may therefore exist for why these components should not be open or at most partially open. For example, conforming to a specific open interface standard may decrease system performance or have negative security ramifications. In other words, when engineering a system architecture, the architects must weigh competing requirements (especially the non-functional quality attributes) against each other, and openness is only one such requirement to consider when making engineering and business trade-offs.

In summary, architects of OSA-based solutions should forego openness in those parts of the system and software architecture where the following conditions hold:

1. There are no strong reasons to make the architectural component separately procurable. For example, there is currently only a single vendor qualified, or the costs of transitioning away from a sole-source contract would be excessive or unaffordable given current or foreseen funding levels. Note that program managers and architects need to realize that short-term and long-term affordability may be quite different, and that an over-emphasis on short-term affordability may be a case of "penny wise and pound foolish."
2. There are overriding reasons to violate modularity or to modularize in a way that minimizes competition. For example, the existing poorly modularized architecture would cost too much or take too long to re-architect.
3. There are overriding reasons to use relatively closed interface standards, to use proprietary standards, or to use no standard at all. For example, no open interface standard exists, the open interface standards result in inadequate quality (e.g., performance, robustness, safety, or security), the open interfaces standards are too immature or not sufficiently specified, or the cost of replacing an existing proprietary interface exceeds the anticipated cost savings from making the interface more open.

When decisions are made to use closed or relatively unopen architectures, it is important to document the associated rationales and justifications. This documentation is invaluable when trade-offs and choices regarding openness must be revisited (e.g., due to rapid changes in technologies and the emphasis on obtaining needed capabilities by integrating independent systems into systems-of-systems).

Note that nothing in the above justifies ignoring openness, and it should not be misused as an excuse to engineer a closed system architecture. Program offices should ensure that integrators provide adequate justification for the relatively or completely closed parts of the system architecture and that they are not avoiding openness to avoid competition and ensure vendor lock.

Conclusion

Although an OSA will almost certainly result in important benefits (especially if openness is maintained through the development and lifecycle), both DoD policy and good system/software architecture engineering recognize that a 100-percent open system architecture is typically unachievable. Moreover, openness must be weighed against competing requirements to obtain the best architectural solution.

Additional Resources

To read the SEI Blog post The Importance of Automated Testing in Open Systems Architecture Initiatives, by Douglas C. Schmidt please click here.

To read the abstract and presentation materials from the SATURN 2015 discussion Open Systems Architectures: Progress and Challenges, please click here.