In this week’s blog post on Mason GovCon’s acquisition playbook study, we discuss a recommendation for government to partition contract tasks alongside the modular open systems architecture. This business practice will help facilitate the goal of avoiding vendor lock, enabling competition, and accelerating the evolution of systems.
Read the Draft Playbook, May 13, 2021
Background
The 1940-1970s period was a time of change in acquisition philosophy. Traditionally, the military services focused on maturing components and integrating systems around them. The Air Force started taking a new approach in the 1950s, one that focused on total system performance and developing components to match. As historian Elliot Converse described, this “weapon systems” concept came to be represented by the view that “All of the elements in a system should be designed and developed from the beginning as an integrated whole.”
LJ Atwood, President of North American, articulated the benefits of the weapon systems concept in a 1959 congressional hearing:
- It creates the “most advanced systems possible” by designing around subsystems that are not yet fully developed.
- “For the first time a single organization – the prime contractor – is cognizant of the entire cost” and has the ability to directly interact with all subcontractors.
- While accelerated technology works “against standardization of parts,” single prime integrators have better control to select their own standards rather than accepting what the supplier base offers.
By the end of the 1950s, these aspects of weapon systems contracting had become the norm in the Air Force. Recognizing that subsystems usually lagged the airframe, the Navy Bureau of Aeronautics continued for a time to make key decisions on system development, review of contractor performance, and arbitrate disputes between the prime and its subcontractors. In the 1960s, contracting for a fully integrated system from a single prime contractor spread throughout Army and Navy acquisition, for example becoming official policy of Naval Weapons in 1966.
The return to modular components with global standards was relatively slow going in the 1970s and 1980s, but picked up in the 1990s and today there are dozens of open standards used in the military including the Army’s VICTORY standards, the Navy’s Future Airborne Capability Environment, and the Air Force’s Open Mission Systems/Universal Command and Control Interface. Yet there is still displeasure with the implementation, as indicated in the past few National Defense Authorization Acts seeking to “fully realize the intent” of the modular open systems mandate found in U.S. Code Title 10, Chapter 144B.
Recommendations
The third play in Mason GovCon’s draft acquisition playbook sought to revive some of the traditional business practices from the 1960s and before that enables the technical goal of modular open systems. This involves the government unpacking system requirements and modularizing the contract alongside the architecture. This is important because different elements of a system have different development cycle times.
Advances in material sciences and infrastructure move quite slowly, perhaps on the order of five to ten years or more. Aided by Moore’s law, electronics can cycle through new models every couple of years. Software is even faster, capable of deploying new updates potentially every day.
Perhaps surprisingly, we at the Center have not found explicit guidance advocating government to partition and manage contract tasks based on the modular system design. Instead, guidance expects government officials to identify requirements for standards in the Requests for Proposals (RFPs). The DoD’s Open System Architecture Contracting Guidebook for Program Managers spells out all the language and consideration for an RFP across 200 pages. This process not only limits competition, but reduces the speed of all system elements to the lowest common denominator.
Breaking apart system monoliths gets into the controversial idea of government “owning the technical baseline.” If the prime contractor isn’t the lead systems integrator, then the government must be. Yet it is possible for government to fulfill its responsibilities without literally owning anything. The 2015 Air Force Studies Board paper Owning the Technical Baseline did not recommend across the board use of government reference architecture or unlimited data rights. Instead, government requires sufficient insight and control over design agent choices.
There are many ways this “ownership” can manifest. Unfortunately, we have few specifics to share, but will offer three working ideas.
Do it Twice
If a program office is assembled to go after a major integrated system, then most likely government will have to rely on industry expertise. Correctly identifying all the correct standards and needs for government data rights ahead of the RFP creates a complex systems-of-systems problem. Experience has taught us, however, that complex systems are made from relatively more simple parts.
Thorough market intelligence should be turned into quick pilots and early integration efforts for important subsystems. This will help hone the technical baseline, but shouldn’t be viewed as draft or beta work. Rather, it provides clarity on which standards should be put onto the real RFPs that will result in larger development work.
Unless the program is an incremental upgrade, the technical baseline will not come fully formed. Even the father of the waterfall development strategy for software Winston Royce advocated doing it twice or else “one can expect up to a 100-percent overrun in schedule and/or costs.” Use defense and national labs, FFRDCs, and industry consultation to help navigate towards a baseline.
Get in the Middle
Perhaps the most important recommendation is that government contract directly with suppliers in areas that they (1) want to avoid vendor lock; and (2) have sufficient insight and technical expertise. Often, the government will have a prime contractor do the actual integration, but the prime should not have privilege of contract with all vendors. This reflects the pattern of contract management that dominated prior to the 1960s.
Certainly, DoD frequently provides Government Furnished Equipment (GFE). For example, nearly half of the DDG-51 system cost including mission systems is intermediated by the government but in close coordination with the prime. This modular business practice extends into the government, as the DDG-51 program manager must interface with other program offices delivering sensors and ordnance. Configuration management can become difficult, however, leading to the fear that GFE becomes either late or defective.
Even with current guidance, the government takes on a lot of design responsibility through its identification of standards and other open systems requirements in an RFP. Up to 80 or 90 percent of system costs are “pre-set” through the operational concepts, preliminary designs, and performance requirements made before the release of the development RFP. Making this responsibility more explicit by directly contracting with subsystems or software providers can improve flexibility.
Preference for Commercial
The Department of Defense perhaps had enough weight after World War II that it could drive technology and proliferate its own standards. In 1960, defense-related R&D was 50 percent larger than the R&D of the entire U.S. commercial sector. The following decades saw a dramatic swing. By 2019, the U.S. commercial sector outspent DoD eightfold. Defense-related R&D shrunk from 36 percent of the world’s total to just 3 percent. Much of the technology development, including the standards that will be proliferating, are outside the control of the Department of Defense.
If DoD wants to increase its buying power, it has to adopt commercial standards. In the 1990s and 2000s when DoD started taking modular open systems seriously again, it often ended up sponsoring standards where the only players were traditional contractors. As commercial industry accelerates, it will have increasing implications for defense.
Government should actively participate in commercial standards groups that have defense-relevant capabilities. For example, the Army sits on the Robotics Operating System board, contributes more than $1 million a year to its code base, and uses the framework for military applications across a number of programs. Only those behaviors that have no commercial equivalent should government references be invoked or new developments undertaken.
Conclusion
When an entire development effort is contracted to a single prime integrator, there is little need for the iterative requirements and continuous market research advocated in the first two plays of the Center’s playbook. The ability to insert new market opportunities into programs depends on the not just using a modular open systems approach, but choosing standards that will proliferate and making it attractive enough for third-party vendors to participate.
The very idea of modular open systems challenges the foundations of a program of record. Components and subsystems should be tradeable across program “stovepipes,” which also need integration into larger systems like command and control networks. Careful steps toward partitioning systems from a prime integrator should be viewed as an opportunity to take advantage of enterprise capabilities, improve data flows across the government, and reduce sole source situations.
Leave a Reply