Posted on by Open Systems Architecturesin
By Donald Firesmith
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
This blog posting 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:
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.
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:
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.
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.
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 session notes from a SATURN 2015 discussion Open Systems Architectures: Progress and Challenges, please click here.