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

In this series of blog posts, adapted from a recently published paper, we sought to demonstrate how layered business and technical architectures can leverage modular component design practices to establish new approaches for capability acquisition that are more effective for the Department of Defense (DoD) than existing system of systems (SoS) strategies. The aim of these posts is to help the DoD establish an acquisition environment that is more efficient and capable of delivering higher quality, with far greater innovation, in a fraction of the time.

Our first post proposed a layered business and technical architecture model to help the DoD leverage modular component design practices that will establish more effective approaches for capability acquisition. Our second post explored this model in detail. Our third post examined key change drivers and organizational structures associated with our proposed model of acquisition. We also examined the impacts associated with the implementation and organizational structure of our proposed acquisition model. Our fourth post examined the technical architecture for our proposed acquisition model. In this fifth and final post in the series, we examine the impacts associated with our proposed new acquisition implementation and organizational structure and provide an overview of our recommendations.

Impacts of Modular Open System Architectures in DoD Acquisition

Our new acquisition architecture is predicated on separating the concerns associated with building new capabilities--Research and Engineering (R&E)--from those associated with a product-line architecture landing-pad, support tools, and shared services delivered to the platforms that would host them--Acquisition and Sustainment (A&S). Figure 1 depicts the impacts of adopting this new acquisition architecture.

Figure 1: Resourcing and Acquisition Alignment

1. The R&E organizations would focus on delivering cross-platform, reusable component capabilities in product lines that have unique attributes and value, such as sensors, communications, weapons, combat management, information operations, and command & control. Those organizations establish requirements for a shared system architecture and work together to integrate products.
2. Likewise, the A&S arm collects the R&E infrastructure requirements and creates a common environment that provides a secure, real-time, safety-critical, and cyber-secure environment, including build tools, automated test capability, data architectures, connector models, training environments, and integration frameworks. The Platform Acquisition arm would focus on designing, building, and sustaining the platform, as well as specific requirements for installation and non-warfighting system integration.
3. Program executive officers (PEOs) have started examining modularized capabilities packed as micro-services (e.g., within containers) that can be deployed as severable, self-healing units of performance, such that new products or services can be delivered independently. To ensure success, however, system and software architectures must support the loose coupling of those modules. This pairing enables the extraction and replacement of functionality by new capabilities deployed in an environment that is widely available and practiced in the marketplace. The resulting product set is composed of elements that can be changed with low friction and risk since they are designed as loosely coupled--but highly cohesive--capabilities that are more reliable, self-healing, and can be integrated quickly with known impacts to existing products and services.

While these preliminary actions by a bold few are laudable, the business dynamics of today's DoD marketplace are currently stacked against wide adoption by all programs of record, regardless of size or maturity. Creating a level playing field for a wider array of providers is antithetical to the incentives of the existing prime contractor environment. For the past three decades, many programs embraced a vertical and horizontal integration of their capability providers while the ecosystem for Defense contracts has splintered into a few very large companies, many small firms, and a hollowing out of medium-sized businesses addressing defense needs.

Further exacerbating problems with the existing prime contractor environment, the standard practices for the managing government's rights to intellectual property has been weak or, at best, haphazard. These practices are particularly problematic for architectural information and enforcement of modular open systems practices. This situation has resulted in winner-take-all vendor lock environments where the government has made the majority of the investment in the environment, but has few alternatives for incorporating innovation.

To remedy this stratification, the government needs to establish ownership of software and system architectures, while encouraging innovation and diversity. The supporting elements of the acquisition arena should be refactored to support this model, as summarized below:

• Adopt cross-program deployment environments by PEOs and PMs and use government managed architectures to facilitate modular product deployment across multiple programs.
• Ensure accessibility to the development and deployment tool chain must be readily and affordably available to any qualified and competent developer.
• Use a standardize and nuanced intellectual property strategy across portfolios by establishing two regimes: (1) open and available architectures that are widely adopted and malleable foundation and data to many entities (government, academia, and industry - big and small) and (2) an application environment that can tolerate a wider array of open, closed, proprietary, government-owned, or government-accessible products.
• Perform portfolio management and decompose functions into modules that can be deployed in loosely coupled functional elements, such as by using micro-services. This type of architecture requires strong government-guided architectural leadership. It would include applying (vice developing) widely accessible technical reference frameworks, as well as including the establishment of infrastructure consolidation (i.e., considerations for hardware, networking, and storage). Programs also need to adopt a data architecture that is practiced by a broad community to ensure information interoperability.
• Establish the business and contracting environment where both traditional and non-traditional vendors can participate in crafting open architectures as a community, but be encouraged to invest in capability that is modular and loosely couple (and hence replaceable). This enables the government to deliver innovation rapidly but avoid the business and technology risks inherent in vendor-locked vertically- or horizontally-integrated solutions.

From the inception this transformation, the DoD test and evaluation (T&E) and certification communities must help establish architectural constraints early in the process (e.g., pre-solicitation phase) to ensure the products are designed properly. These communities must also stay involved to track that those equities are preserved throughout the development process. Testers and certifiers (e.g., certifications associated with things like weapon safety, combat capability, flight safety, etc.) should also be a part of establishing a way to check that the deployed product is production-ready. Tester involvement ensures the integration, test, and certification activities validate that the development team has created a highly reliable and critical bug-free product.

One evolving practice that is gaining wide acceptance for reducing risk in product integration is the use of digital twin environments. These environments provide a venue to validate that all in-lab testing of deployable products reflects the installed configuration when the capability is shipped for installation. Only then will delivery and installation testing be performed in days instead of weeks (or longer), with the resulting capability suite certified for full use.

Product support management takes on a new characteristic. Products that are software-reliant or cyber-physical never encounter a classic sustainment period. Instead, they reach a level of maturity in the productization of the design and then enter a continuous evolutionary engineering and upgrade phase that lasts until disposal.

Now is a good time for the DoD and Services to consider new standards for architecting this environment, so it can support the warfighting community for several decades into the future. The type of change described above will likely imbue classic organizational resistances and text-book rejection responses to strategic change, which are natural human and organizational responses. Fortunately, the mechanisms of resistance to change are better understood now than ever before.

To minimize these affects, a coordinated rollout plan should be developed by the Military Services (Army, Navy, Air Force), with guidance from both USD(A&S) and USD(R&E), that encourages members of the organization to become involved in helping it achieve its shared objectives to establish and sustain an enabling environment to increase speed and decrease cost of delivering innovation to the warfighter. Likewise, a detailed communication plan should be developed that invites personnel in existing program offices and subordinate organizations to participate in developing how and where they fit as well as opportunities for growth. In times of uncertainty, people in these organizations will be primarily interested in how change will affect their profession and their lives.

Industry will be most interested in the impact to existing tasking and the opportunities that lie ahead. The role of the system integrator would be retooled into an overarching capability integrator, a system architect, and a hardware procurement agent. There is currently an integrator for every system and an overall platform integrator. These duplicative and overlapping roles are ripe for consolidation.

Implementing the types of change described in this series of blog posts on achieving modular open systems architectures requires the full commitment of all members of the acquisition community. Organizations improve the likelihood of successful transformation when all members can see their future in the implementation of the new model.

Summary of Recommendations

This section summarizes our recommendations to the DoD for achieving modular, open-system architectures along the following dimensions:

• Organizational/Cultural. The organizational problem that must be addressed involves crafting a new model of behavior that can achieve a dramatic reduction (at least 80 percent) in time to flow of capability to the DoD. The resulting environment will shift to a continuous capability delivery engine that is affordable, flexible, adaptable, effective and reliable. The organization must itself be rearchitected to separate the concerns of the payload capabilities from a supporting enterprise architecture and the host platforms such that managed capability improvements will deliver in smaller increments on rapid time scales (the speed of need).
  
  The Agile community developed the concept of the delivering capability in well-crafted increments under the auspices of the minimum viable product (to learn more about minimum viable product, check out this series of posts by our colleague, Bob Binder.). The MVP concept evolved in the context of comparative lightly integrated capabilities for use in environments that are not tightly coupled.
  
  For the DoD, however, mission viability means that capabilities must interact along with other functions in a safe and secure way that bring overwhelming combat power together. Products must therefore be delivered to the warfighter as minimum mission-viable products (MMVP). These changes will still be delivered in relatively small increments, but the degree of rigor for testing interoperability and safety certification must be viable for mission use. The cultural divisions between requirements, testing, and operations must be addressed to realize a future of wide-ranging modular capability change across the DoD portfolio.

• Business. Conventional federated system-of-systems business relationships currently employed by the services/agencies must evolve to a model of decoupled capabilities developed by a variety of firms that are experts in their craft. This business model is built on leveraging practices and components from the commercial marketplace, on valuing private investment, honoring the unique nature of small business, while also maintaining the government's fiduciary. Any capability that comes with restrictions on sharing internal design details must come with a certification that the design can be gracefully removed from the system and replaced with equivalent capability derived by a different organization.
  
  The overarching architecture on which all this capability will run should become a shared responsibility between industry, the standards community, and government, with appropriate mechanisms to ensure both initial buy-in and ongoing collaboration to evolve those frameworks. That open architecture will be co-developed in collaboration with the government by the stakeholder firms that coordinate the effort to ensure that capabilities can be replaced. Program managers should investigate other transaction authority (OTA) instruments as a preferred mechanism for establishing this environment.

• Technical. It all begins with a high-level strategic and enterprise approach that is led by services and supported by the highest levels of the DoD. This transformation is not achievable without the underpinnings of new technical and data architectures. Those underpinnings begin with an approach that is testable and verifiable to ensure the products being developed by industry and accepted by government comport to the overarching enterprise strategy. Fortunately, we have starting points. Several technical reference frameworks (TRFs) have been established and support a conformance model (e.g., OMS, Future Airborne Capability Environment [FACE], and VICTORY Compliance Test Suite). These TRFs have the support of forward-thinking government and industry teams that used cross-organizational collaboration and standards bodies/ consortium models to ensure voices are heard, but not to the exclusion of making progress towards a common goal (consensus-based).

Wrapping Up and Looking Ahead

In this series of blog posts, we described five architectures for improving the way DoD and military services buy and improve the speed and quality of warfighting capability. Our first post addressed recent developments in how software-intensive systems are produced, especially the use of DevSecOps methodologies with the strategic application of modularity and open architectures. We then built on this analysis and turned our attention in the second post to portfolio management and the application of product line architectures. In our third post, we explored the organizational architecture for these practices at the program level, to include contracting, intellectual property strategies and more concepts for portfolio management at the military service level. Our fourth post took a step back to examine the enabling technology platform architecture strategies necessary to bring this all about. Different technical problems demand technical architectures to support them, and we argued there should be the right number of reference frameworks to base this on--a total of three. With this fifth (and final) post, we provide an overarching construct, or architecture of architectures to be addressed at the larger DoD level to drive the strategy forward.

The nation is at a crossroads of performance. All program managers must accept that they are building software products and embrace proven methods to ensure success at rapidly delivering capability at the speed of need. We end where we started: the best available building blocks for software-intensive technologies are equally available us and our adversaries. Our military will only be able to prevail under any circumstances by embracing speed and modern methods to deliver exquisite modular capabilities that delight our users and put the fear of defeat in our adversaries.

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 all of the posts in our series on Achieving Modular Open System Architectures in DoD Acquisition.

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.