Posted on by Software Architecturein
To deliver enhanced integrated warfighting capability at lower cost across the enterprise and over the lifecycle, the Department of Defense (DoD) must move away from stove-piped solutions and towards a limited number of technical reference frameworks based on reusable hardware and software components and services. There have been previous efforts in this direction, but in an era of sequestration and austerity, the DoD has reinvigorated its efforts to identify effective methods of creating more affordable acquisition choices and reducing the cycle time for initial acquisition and new technology insertion. This blog posting is part of an ongoing series on how acquisition professionals and system integrators can apply Open Systems Architecture (OSA)practices to decompose large monolithic business and technical designs into manageable, capability-oriented frameworks that can integrate innovation more rapidly and lower total ownership costs. The focus of this posting is on the evolution of DoD combat systems from ad hoc stovepipes to more modular and layered architectures.
Motivating the Need for Technical Reference Frameworks
DoD programs face a number of challenges in this era of increasing threats and constrained budgets. As nation state actors become more sophisticated, the nature of threats becomes asymmetric. It is therefore critically important that the DoD be able to respond quickly to risk with new technologies, while delivering enhanced integrated warfighting capability at lower cost. The DoD faces several challenges in achieving these goals. Chief among them is addressing the decades-long, stove-piped, ad hoc approach to developing software that results in vendor-locked legacy systems, each of which maintains its own proprietary software, computers, networks, and operating systems. A promising solution is OSA, which combines
The SEI is helping the DoD craft its OSA strategy and an implementation plan to deliver better capabilities to warfighters withinthe fiscal constraints of sequestration. A working group has been established to help the DoD move away from stove-piped software development models to Common Operating Platform Environments (COPEs) that embody OSA practices. As part of this effort, I am involved with a task area on "published open interfaces and standards" that aims to help program managers and other acquisition professionals avoid vendor lock-in, encourage competition, and spur innovation by defining a limited number of technical reference frameworks that breakdown traditional stove-piped solutions. These frameworks are integrated sets of competition-driven, modular components that provide reusable combat system architectures for families of related warfighting systems.
Despite substantial advances in technical reference frameworks during the past decade, widespread adoption of affordable and dependable OSA-based solutions has remained elusive. It is therefore important to look at past open-systems efforts across the DoD to understand what worked, what hasn't, and what can be done to make it more successful this time. To achieve this historical perspective, I--along with fellow SEI researcher Don Firesmith and Adam Porter from the University of Maryland Department of Computer Science--have been documenting the evolution of DoD combat systems with respect to their adoption of systematic reuse and the OSA paradigm described above, as shown in the following diagram.
The ad hoc architectures in the columns on the left are highly stove-piped, course-grained, and exhibit little or no shared capabilities that are critical to warfighter, including communications, radars, launchers, etc. The increasingly advanced architectures from left to right are intentionally designed to share more capabilities at finer levels of granularity in DoD systems, including
In practice, of course, production combat systems vary in terms of their progression along the continuum shown in the figure and descriptions above. This discussion is intended to provide a birds-eye view of the design space of DoD combat systems with respect to architectural evolution. The remainder of this posting describes the first four epochs in the diagram shown above. The remaining four epochs will be described in the next blog post in this series.
Ad hoc architectures are widely used in DoD legacy combat systems for various reasons. For example, the tight coupling between system components has historically been deemed essential for mission- and safety-critical DoD programs that need to extract maximum performance to meet stringent end-to-end quality attributes. The stove-piped nature of these ad hoc architectures has also often been perceived as risk prudent, since these architectures enable a single program office and system integrator to maintain tight control over every facet in the solution.
Despite their pervasive use historically, however, ad hoc architectures have become prohibitively expensive to develop and sustain over the software and system lifecycle. A key problem is the tight coupling common in ad hoc architectures, which typically locks the DoD into sole-source contracts that limit the benefits of open competition and impede innovations. These innovations include the ability to leverage commodity hardware and/or software platform advances, such as multi-core and distributed-core cloud computing environments, that would otherwise occur during periodic technical refresh insertion points.
Wrapping Up and Looking Ahead
Over the past several decades the advances in DoD combat system architectures presented above have had several beneficial effects. For example, modularity has helped integrators increase the flexibility of their proprietary solutions. Likewise, layering has increased the adoption of domain-independent COTS and open-standards infrastructure as the basis for many DoD combat systems. While these advances are a step in the right direction, they have not yet significantly reduced the development and sustainment costs of DoD combat systems. One reason for this limited impact on lifecycle costs is that these earlier architecture advances did not address key business model drivers, but instead focused on standardized infrastructures and codified architectures, which account for a relatively small portion of the total ownership costs of combat systems.
The next post in this series will describe the other four epochs of the architectural evolution of the DoD combat system shown in the diagram above. These epochs focus more on domain-specific architectural layers that address business and economic issues, as well as technical concerns. Subsequent posts in this series will explore a research effort to help one Navy program obtain accurate estimates of the cost savings and return on investment for both the development and lifecycle of several product lines built using a common technical reference framework.
To read the SEI technical report, A Framework for Evaluating Common Operating Environments: Piloting, Lessons Learned, and Opportunities, by Cecilia Albert and Steve Rosemergy, please visit
To read the SEI technical note, Isolating Patterns of Failure in Department of Defense Acquisition, by Lisa Brownsword, Cecilia Albert, David Carney, Patrick Place, Charles (Bud) Hammons, and John Hudak, please visit