search menu icon-carat-right cmu-wordmark

Towards a New Model of Acquisition: Product-Line Architectures for the DoD - Second in a Series

This post was co-authored by Douglas Schmidt and William Scherlis.

It is widely recognized that the Department of Defense (DoD) needs to have a nimble response to nimble adversaries. However, the inflexibility of many DoD development and acquisition practices begets inflexible architectures that often slow progress and increase risk to operational forces. This rejection of modern development methods actually increases program risk and extends development timelines, effectively reducing the value of the DoD's acquisition portfolio. As a result, the current lack of capacity for breadth and pace of change impedes our ability to evolve capability quickly and robustly enough to meet new requirements in emerging technical and warfighting environments. The push to deliver artificial intelligence (AI)-based capabilities (and respond effectively to AI-based threats) increases both the urgency and importance of addressing the challenges.

This post is the second installment in a series examining how layered business and technical architectures can leverage modern modular component design practices to establish new approaches for capability acquisition. These architectures are more effective than existing system of systems (SoS) strategies. In this post, which was excerpted from a recently published paper, Capability Composition and Data Interoperability to Achieve More Effective Results than DoD System-of-Systems Strategies, we examine a new model of acquisition that applies a coherent set of methods to develop military mission capabilities as sets of composed modules. This kind of architectural approach is commonplace in mobile-device ecosystems, in big-data analytic frameworks, and in nearly all modern web applications. Admiral Jonathan W. Greenert also advocated for this approach in his essay Payloads over Platforms: Charting a New Course.

Our first post in this series examined emerging opportunities in modularity and open systems architectures. Subsequent posts will identify key change drivers, and technical and organization structures, associated with the new model of acquisition we propose for DoD software-reliant systems. We will also examine the impacts associated with the implementation and organizational structure of our proposed acquisition model.

Towards a More Nimble Response from the DoD

The DoD's current pattern of upgrading ships and aircraft applies a system-by-system, "rip-out and install" process. This pattern incurs long upgrade periods that reduce operational availability and make interoperability more challenging. Consequently, the DoD is hampered by its inability to respond nimbly to any situation.

A set of alternative approaches is being investigated, including prototyping, model-based systems engineering, and virtualization. All have their value, but a comprehensive approach is needed to bring these together into a strategy. For example, the DoD has often found it hard to "cross the chasm" when trying to transition research prototypes that are good enough to experiment with into robust production-ready products that suitable for wide-spread use and provide the quality, support, and training needed by operational systems. Likewise, designs built as prototypes are often fielded in a way that does not match the business needs of the organization (full support for maintenance, training, in-service robustness, etc.).

In general, the benefits of rapidly attempting new ideas and quickly declaring success or failure may be lost if they lack sound structure at the start. Without good architecture practices, these efforts may only provide a short-term salve on an urgent problem. Over the lifecycle, however, users and program offices may be exasperated with the long, slow slog needed to make the prototype production ready, with no overall improvement in capability.

The use of enterprise technical frameworks, with data architectures that support both interoperability and secure and safe use of evolving prototypes, can change the game for rapidly delivering innovative advantages to the DoD. The ability to choose an alternative capability, however, must be prudent. Sweeping large-scale change-out of functionality increases programmatic and operational risk, which motivates adoption of smaller, more easily replaced modules of functionality.

A different—more pragmatic—alignment of programmatic and technical architectures is therefore needed to deliver smaller capability improvements (along with associated hardware updates) that can be installed quickly and automatically tested as certified for use at the time of installation. This approach requires a new means to leverage commercial and open source investment in data center technologies as well as products built to take full advantage of new development tools, techniques, and certification approaches.

By applying this approach, the DoD will only pay for a unique military capability that can be delivered quickly and reliably, as shown in Figure 1. This figure shows a highly simplified automotive example of product line engineering and payload/platform management for flexible integration of functional capability. This framework highlights the breakdown of major automobile functional elements (such as power train, suspension, interior, etc.) into product line segments.

Graphic depicting a highly simplified automotive example of product line engineering.

Figure 1: The Renault-Nissan Common Module Framework.

The DoD also needs a new procurement and delivery strategy that values shared responsibility, improved warfighter capability, increased operational robustness, outstanding support, and continuous improvement. Ideally, this strategy should ensure that the resulting products are defect-free to the warfighter, tested early and often, certified for operational use when deployed, fully supported, highly reliable, and able to provide the required capability in the face of component failures for protracted periods of time. These are ambitious goals, but they should be front and center in driving software engineering strategy, analogous to the ambitious software engineering goals set by the Defense Innovation Board.

Relevant Technology Trends

Development paradigms are constantly in motion. These paradigms advance on the basis of technical improvements in the ability to decouple implementation decisions to better support incremental development processes by separating features of capability, thus enabling higher levels of scale and capability without increasing uncertainty and risk. For example, service-oriented architecture (SOA) was a useful approach for a time, but the development methods and underlying technologies that made SOA attractive have evolved to the next step. In particular, containerization and micro-services are emerging development practices that facilitate more granular decision making and that have achieved broad adoption, as described below:

  • Containerization (also known as "operating-system-level virtualization") is an operating system feature in which the kernel supports the existence of multiple isolated user-space instances that enable the deployment and running of distributed applications without launching an entire virtual machine (VM) for each module. Containerization can be applied to convert many architecture design elements into interchangeable elements that better support modern iterative and incremental software development practices, such as DevOps.
  • Micro-services are a variant of the SOA architectural style that structures an application as a collection of loosely coupled fine-grained services connected via lightweight protocols. Modular capabilities implemented as micro-services more efficiently and safely manage data and can exploit the next generation of computing infrastructure, including multiple cores, cloud technology, storage evolutions, etc.

Containerization and micro-services also help reduce development risk and increase overall product robustness. Likewise, they can be combined with Agile and DevOps methodologies that development and quality assurance teams can use to focus on a capability as a new unit of functionality that works with other containers as a part of a capability architecture.

Requirements for a New DoD Acquisition Model

A new acquisition model for the DoD must address how the organization will evolve into a revamped set of business, organizational, contracting, technical, financial, and ultimately cultural behaviors. The core of this model involves transitioning from a collection of independently acquired systems into a highly interdependent ecosystem of rapidly delivered capability modules that integrate and interoperate as a foundational principle. This team-centric approach will require constant communication and collaboration across historically partisan divides. New practices will be needed to align stakeholders to new organizational identities and reward mechanisms.

Transforming from conventional DoD acquisition models to the model espoused here will only happen by having a clear-eyed future objective structure that emerges from a thoughtful progression from the current state. This model should start with an architectural approach that establishes and ensures the following properties:

  • loose coupling and independent development for components,
  • early and continuous production/evaluation
  • an orchestration of capabilities crafted to present a user experience that appears fully integrated

The remainder of this blog post explores the organizational implications of this model.

An Overarching Business Model

Both sides of the Goldwater-Nichols divide that separate capability acquisition from requirements ownership in the DoD should be reorganized on the principle that has guided dynamic markets. The automobile industry is an analogous example of the type of enterprise approach the DoD could emulate. The trend in that industry is to limit the number of different organizations that create similar value elements. Moreover, the automotive industry has evolved to use product line architectures (PLAs) to maximize flexibility and reuse of common elements.

A PLA is a design that has built-in flexibility to encompass all the different ways a product could be used. This approach is accomplished through configurable design features that are intentionally built to accommodate customizations that support specific customer use-cases. In this way, a PLA design can maximize reuse while also providing the variations that customers demand. The goal of applying PLAs in the automotive industry is to maximize the utility of a platform to serve multiple-vehicle products, providing greater flexibility and efficiency in offering products that meet customer needs.

Several industries that develop complex, safety-critical, and large-scale cyber-physical systems have adopted and improved upon the product line approach. Figure 1 above showed the breakdown of major automobile functional elements (such as power train, suspension, interior, etc.) into product line segments. Likewise, Figure 2 below shows the strategic trajectory of a major U.S. automotive manufacturer to reduce duplicative infrastructure and embrace product lines as a central organizing theme. This move to product lines promotes flexible and adaptable products while simultaneously improving efficiency.

Figure 2: General Motors Platform Reduction Strategy.

Figure 2: General Motors Platform Reduction Strategy.

Another market that needs to manage complexity, value reliability as well as provide change to customer needs is the manufacturing robot industry. Companies with product lines in this industry support specific classes of machines that can be configured for a near infinite field of manufacturing processes. They use common modules (controllers, user interfaces, digital process interoperability, selectable manipulators, etc.) to provide an integrated solution. In an odd twist of irony, the most popular and reliable manufacturing robot companies change their baselines relatively slowly while supporting manufacturing processes that facilitate client companies that respond to mass customization and a blistering array of user selections.

Mobile devices are another example where the hardware platform changes slowly (most people upgrade every few years) and the operating system updates come every few months. This opens up the application space to move quickly and respond to changing user needs and evolving capability. These open platforms invited many alternative suppliers to create innovations on top of the managed environment. Manufacturers that did not adjust to this change in business architecture (Nokia, Motorola, Blackberry, Microsoft, etc.) rapidly lost market share.

Evolution of closed platforms to open platforms.

Figure 3: Open Platforms for Mass Customization

To achieve the efficiencies experienced in other domains, many aspects of the DoD acquisition structure should be retooled. In particular, the organizational constructs in the Army, Navy, Air Force Services, and DoD-affiliated agencies (services/agencies) should be retooled from independent system deliverers into the following three distinct categories:

  • Platform Acquisition, which provides the outer shell and integration environment of the platform being acquired, such as an aircraft, ship, tank, etc.
  • Deployment Environment, which defines a set of software-intensive architecture frameworks
  • Capability Commodities, which provide flexible and adaptable capabilities that get added to or run on the enterprise architectures, and provided to platform integrators that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.
3195_towards-a-new-model-of-acquisition-product-line-architectures-for-the-dod-second-in-a-series_1

Figure 4: Business and Organizational Impacts for Modular Flexible Ships.

This framework for capability acquisition will require new programmatic approaches, tooling, and techniques to help the DoD acquisition structure manage loose coupling and independence of modular functional elements with ongoing integration. Software-intensive modules of fielded military products can be updated or replaced frequently and risk-prudently, so they can be thought of as more of a commodity.

The budget structure should also reflect this strategic approach and embrace a different lifecycle reality of continuous engineering to include early and often validation and verification by the test and evaluation (T&E) community, starting at a very early stage of the development process. The trade-off is that the testing associated with fielding will require far less time and cost as the risk of fielding has already been addressed. As such, the capabilities developed and deployed into the field can no longer be thought of as produced in their final state, but subject to regular maintenance or product improvement.

The military environment will be constantly evolving as a result of changes in the threat environment, cyber-vulnerability management, and the underlying COTS technology ecosystem changes. The products the acquisition community provides must therefore be upgraded continuously and fielded rapidly in quantity as modularized capabilities. Cyber-physical systems can be improved through both software and hardware changes. Although the DoD Acquisition Framework (DoD Instruction 5000.02) enables significant tailoring and flexibility, the vast majority of acquisitions still follow a classic spiral development model to achieve a production end-state and a corresponding near-elimination of research and development funding for capability improvement. This approach is particularly problematic in cyber-physical or software-reliant solutions for the following reasons:

  • The dynamic cyber threat environment requires constant vigilance for counter penetration and protection measures (even if no capability changes are required).
  • The COTS components used to build these systems (hardware, operating systems, tools, etc.) are all in motion, responding to various market pressures. The usable in-service life-span may therefore be much shorter than the longevity of the hardware (e.g., deprecation of software versions or termination of support for obsolete hardware baselines).
  • The deployment of new software functions is often an affordable way of improving warfighting performance and addressing evolving mission needs, long after the production run might otherwise be considered complete.

Looking Ahead

Implementing the recommendations discussed in this blog posting will establish a DoD acquisition environment that is more efficient and capable of delivering much higher quality, with far greater innovation, in a much shorter time frame. Future posts in this series will present key change drivers and technical and/or organization structures associated with the new model of acquisition we propose for the DoD, as well as the impacts associated with the implementation and organizational structure of our proposed acquisition model.

Additional Resources

This post was adapted from a recently published paper, Capability Composition and Data Interoperability to Achieve More Effective Results than DoD System-of-Systems Strategies, which examines a new model of acquisition that applies a coherent set of methods to develop military mission capabilities as sets of composed modules.

Read the first post in this series, Emerging Opportunities in Modularity and Open Systems Architectures.

Read an interview that Nick Guertin gave with Federal News Radio on how open systems are evolving to improve DoD buying power.

Read the SEI Blog Post by Don Firesmith Open Systems Architectures: When and Where to Be Closed.

CITE

Get updates on our latest work.

Each week, our researchers write about the latest in software engineering, cybersecurity and artificial intelligence. Sign up to get the latest post sent to your inbox the day it's published.

Subscribe Get our RSS feed