Department of Defense (DoD) program managers and associated acquisition professionals are increasingly called upon to steward the development of complex, software-reliant combat systems. In today's environment of expanded threats and constrained resources (e.g., sequestration), their focus is on minimizing the cost and schedule of combat-system acquisition, while simultaneously ensuring interoperability and innovation. A promising approach for meeting these challenging goals is Open Systems Architecture (OSA), which combines (1) technical practices designed to reduce the cycle time needed to acquire new systems and insert new technology into legacy systems and (2) business models for creating a more competitive marketplace and a more effective strategy for managing intellectual property rights in DoD acquisition programs. This blog posting expands upon our earlier coverage of how acquisition professionals and system integrators can apply 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.

Collapsing Stove-Pipes with Technical Reference Frameworks

DoD programs have struggled for decades to move away from stove-piped solutions towards common operating platform environments (COPEs). An earlier post in this series described the drawbacks of stove-piped solutions, which lock the DoD into a small number of system integrators, each devising proprietary point solutions that are expensive to develop and sustain over the lifecycle. Although stove-piped solutions have been problematic (and unsustainable) for years, the budget cuts occurring under sequestration have motivated the DoD to reinvigorate its focus on identifying alternative means to drive down costs, create more affordable acquisition choices, and improve acquisition program performance.

The recently released DoD Better Buying Power 2.0 policy initiative, which superseded Better Buying Power 1.0, is one such alternative. Critical to the success of the Better Buying Power initiatives is the focus on the OSA paradigm, which includes a continually evolving integrated business and technical program management strategy that employs modular design, publishes consensus-based standards for key interfaces, embraces transparency, invigorates enterprise innovation practices, and shares risk via systematic reuse of software/hardware capabilities and assets.

OSA technical practices--which are the focus of this blog posting--foster competition and innovation through published open interfaces, protocols, and data models; open standards; full-design disclosure; modular components; and intentionally-defined system structures and behaviors. Likewise, OSA business models--which will be the focus of later blog postings in this series--use open competition to expand the pool of defense contractors that can participate in DoD acquisition program contracts, thereby lowering costs and invigorating innovation.

The SEI is helping the DoD craft its OSA strategy and produce an implementation plan aimed at helping program managers deliver better capability to warfighters, given the fiscal constraints of sequestration. A working group has been established to help the DoD move away from stove-piped software development models to COPEs that embody OSA practices. As part of this effort, I am serving as co-lead of a task area on "published open interfaces and standards" that is seeking to avoid vendor lock-in, encourage competition, and spur innovation by defining a limited number of technical reference frameworks. These frameworks are integrated sets of competition-driven, modular components that provide reusable combat system architectures for families of related warfighting systems. Key tenets of technical reference frameworks include

• improving the quality and affordability of DoD combat systems via the use of modular, loosely coupled, and explicitly-articulated architectures that provide many shared capabilities to warfighter applications
  
  

Examples of these shared capabilities include data- and net-centricity, utility computing, situational awareness, and location awareness.

• fully disclosing requirements, architecture, and design specifications and development work products to program performers
  
  

The goal of full disclosure is to ensure that competitors and small businesses have sufficient information to implement drop-in replacements for key system modules.

• enabling systematic reuse of software and software artifacts, such as objects, components, services, data models, and associated metadata and deployment plans
  
  

In a well-honed systematic reuse process, each new project or product leverages time-proven architectures, designs and implementations, only adding new code that's specific to a particular application or service.

• mandating common components based on published open interfaces and standards supported by a range of open-source (access to source code) and closed-source (no access to source code) providers
  
  

Open interfaces and standards are essential to spur competition and avoid being locked in/by a specific technology and/or vendor.

• achieving interoperability between hardware and/or software applications and services via common protocols and data models
  
  

These common protocols and data models simplify data interchange and exchange between components from different suppliers or components implemented using different technologies.

• amortizing the effort needed to create conformance and regression test suites that help to automate the continuous verification, validation, optimization, and assurance of functional requirements and non-functional requirements

These automated test suites ensure that developers need not wait until final system integration to perform critical functional and quality-of-service evaluations, nor must they expend significant effort (re)creating these tests manually.

Limiting the number of these technical reference frameworks will increase interopera-bility and reuse opportunities, leading to cost savings across the enterprise and across the lifecycle.

The challenge, of course, is to define guidance that helps program managers and associated acquisition professionals systematically apply technical reference framework tenets to address technical, management, and business perspectives in a balanced manner. This blog posting--together with others we have planned--describes how advances in DoD combat system architectures lay the groundwork for success with technical reference frameworks.

The Architectural Evolution of DoD Combat Systems

The technical reference framework approach described above has been applied with varying degrees of maturity and success to DoD combat systems over the past several decades. I, along with fellow SEI researcher Don Firesmith and Adam Porter from the University of Maryland's 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.

This diagram shows eight distinct stages along the evolutionary continuum of DoD combat systems. The ad hoc architectures in the columns on the left are highly stove-piped and exhibit little or no shared capabilities among various warfighter capabilities, such as communications, radars, launchers, etc. The increasingly advanced architectures on the right are intentionally designed to share many capabilities at different levels of abstraction in combat systems, including

• infrastructure capabilities, such as internetworking protocols, operating systems, and various layers of middleware services, such as identity managers, event disseminators, resource allocators, and deployment planners
• common data and domain capabilities, such as trackers, interoperable data models, and mission planners involving battle management, control, and interaction with sensors and weapons in C4ISR systems
• external interfaces over the global information grid (GIG) to external weapon systems, as well as sources and users of information

In practice, production combat systems vary in terms of their progression along the continuum shown in the figure above. This visualization simply provides a birds-eye view of the design space of DoD combat systems with respect to architectural evolution.

What's Ahead

This blog posting is the latest in an ongoing series that describes how the SEI is helping acquisition professionals and system integrators apply OSA principles and practices to acquire and sustain innovative warfighting capabilities at lower cost and higher quality. Upcoming postings in this series will describe the other stages of DoD combat system architectural evolution shown in the diagram above. Subsequent posts will then explore a research effort to help one Navy program obtain accurate estimates of the cost savings and return on investment for both development and lifecycle of several product lines that were built using a common technical reference framework.

Additional Resources

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
https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=9255

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
https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=53252

To read the SEI technical report, The Business Case for Systems Engineering Study: Results of the Systems Engineering Effectiveness Survey, by Joseph Elm and Dennis Goldenson, please visit
https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=34061

To read the SEI technical report, Quantifying Uncertainty in Early Lifecycle Cost Estimation (QUELCE), by Robert Ferguson, Dennis Goldenson, James McCurley, Robert Stoddard, David Zubrow, and Debra Anderson, please visit https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=10039

To read the handbook, QUASAR: A Method for the Quality Assessment of Software-Intensive System Architectures, by Donald Firesmith, please visit https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=7767

To read the SEI technical report, Lessons Learned from a Large, Multi-Segment, Software-Intensive System, by John Foreman and Mary Ann Lapham, please visit https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=8985

To read the SEI technical report, Resource Allocation in Dynamic Environments, by Jeffrey Hansen, Scott Hissam, B. Craig Meyers, Gabriel Moreno, Daniel Plakosh, Joe Seibel, and Lutz Wrage, please visit
https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=28121

To read the SEI technical report, Incremental Development in Large-Scale Systems: Finding the Programmatic IEDs, by Charles (Bud) Hammons, please visit https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=8991