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

• technical 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.

The SEI is helping the DoD craft its OSA strategy and an implementation plan to deliver better capabilities to warfighters within the 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

• 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, and
• Common data and domain capabilities, such as trackers, interoperable data models, and mission planners involving battle management (BM), control, and interaction with sensors and weapons in C4ISR systems, and
• External interfaces, such as across the global information grid (GIG) to external weapon systems, as well as information sources and users.

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 involve the separate development of each warfighter's capability (such as BM/C4I, sensors, weapons etc. ) in a vertically stove-piped manner that lacks crisply defined module boundaries. This approach is characterized by vertical integration and tight coupling from higher-level domain-specific capabilities down to hardware and system-level infrastructure capabilities.
  

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.

• Modular Architectures define some crisp boundaries within their stove pipes and began to transition away from top-down algorithmic decomposition to a more object-oriented and component-based decomposition. This approach is characterized by designs whose components are less externally coupled and more internally cohesive than the earlier generation of ad hoc architectures.
  
  Although ad hoc architectures have not been economically viable for many years, sequestration has renewed the interest of government and defense industry leadership in modular architectures. Ironically, interest in modular architectures for DoD combat systems began several decades ago, as acquisition programs began to define module boundaries more crisply within their stove-pipes to move away from top-down, algorithmic decomposition (which yields tightly coupled point solutions) to a more object-oriented decomposition (which emphasizes modular, loosely coupled components that can be understood and tested more readily in isolation and thus reused more effectively).
  
  In the early phases of DoD software development, developers tended to write software using function-oriented programming languages (such as FORTRAN, JOVIAL, and C) and algorithmic decomposition and structured design methods, which focus on optimizing computing performance. In the 1990s, developers began to adopt object-oriented programming languages (such as C++, Java, and Ada95) and object-oriented design methods, which focus more on optimizing developer productivity. This shift occurred, in part, due to advances in hardware and software technologies (such as faster processors and networks, larger storage capabilities, and better compilers). It also coincided with the defense cutbacks stemming from the breakup of the U.S.S.R. (the so-called "Peace Dividend") and the end of the first Gulf War, which motivated the defense industry to rethink the economics of their development models.
  
  For example, as component providers and system integrators recognized they couldn't pass along the costs of these complex systems to their government customers, they begin modularizing their stove-pipes. They deemed the myriad dependencies and accidental complexity of their traditional ad hoc architectures too costly in terms of development and sustainment effort. A drawback of the first generation of modular architectures, however, was that they were still largely stove-piped and lacked the ability to share components across different warfighting capabilities. For instance, a software module could not be initially targeted for a radar system and then subsequently reused in a launcher system.

• Modular Open Systems Architecture with Standard Key Interfaces (MOSA) stemmed from a well-defined public standard approach that was both a business and technical strategy for developing new systems or modernizing existing ones. This approach was characterized by designing systems with modular interfaces, designated key interfaces, and select open standards with the goal of providing acquisition programs a choice of vendors when a system needs to be updated.
  
  With the advent of the modular architecture approach described above, the DoD began to reap some benefits of module reuse, including easier testing and porting to new environments. The drawback of this approach, however, was that each module was still largely proprietary. While the end result was a more efficient architecture, it modules were too tightly coupled, which increased sustainment costs and encouraged vendor lock-in.
  
  To help overcome these limitations with earlier modularity approaches, MOSA was devised to make it easier for DoD acquisition programs to replace modules from one architecture with modules from another. The resulting architecture provided acquisition programs with a wider choice of vendors when a system underwent upgrades since developers could create a new module with the same interface as the one being replaced. The key difference between MOSA and earlier modularity approaches was that module were connected via standardized and openly published interfaces and integration models.

• Layered Architectures emerged as commercial off-the-shelf (COTS) software began to mature and DoD acquisition programs began to purchase them directly from vendors and use them to layer systems so that they were no longer entirely built by a single integrator, even in a modular way. This approach was characterized by a horizontal partitioning of a system's functionality according to a (sub) system-wide property, such that each group of functionality is clearly encapsulated and can evolve independently. The specific partitioning criteria can be defined along various dimensions, such as abstraction, granularity, competitive market size, hardware encapsulation, and rate of change.
  
  During the mid-1990s, as the MOSA approach was growing in popularity, the DoD also began to reconsider its stance on COTS hardware and software technologies, such as CPUs, storage devices, networking elements, programming languages, and operating systems. Prior to this point, the DoD had considered COTS to be incompatible in terms of safety, maturity, and dependability for mission-critical combat systems. The constraints and demands of the DoD environment had instead fostered a system in which contractors were building both vertically integrated systems and the underlying system infrastructure, such as programming languages, compilers, operating systems, networking protocols, and networking standards.
  
  As COTS technologies began to mature, however, DoD programs began to purchase them directly from vendors and use them to layer certain portions of their systems, particularly domain-independent infrastructure capabilities layer(s). Examples include COTS products based on open standards such as TCP/IP, POSIX, CORBA, DDS, and Web Services. Consequently, these infrastructure capabilities were no longer built by integrators, even in a modular way. One benefit of layered architectures is that, because of industry competition, DoD programs were using technologies that were much more current than those they were able to obtain through traditional, stove-piped systems. Likewise, commercial industry tends compete and innovate more rapidly than traditional defense contractors due to leveraged funding from a range of customers, including DoD, government, and enterprise/consumer users.

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.

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