We are reminded almost daily that our national security rests on a foundation of software.
Every system the Department of Defense buys depends on code to function and each military service is establishing software factories to crank out tools that connect their systems, assess them, and help commanders decide how to use them. The importance of software was recently reinforced by Russia’s supply chain attack that breached more than 18,000 U.S. organizations, accessing, among other targets, Microsoft’s source code, Treasury files, and government public health data.
Nevertheless, despite their growing reliance on software, ships, aircraft, tanks, and weapons are predominantly composed of hardware. And unlike Apple or General Motors that sell a dozen or so different offerings, DoD acquisition officials purchase thousands of distinct hardware and software configurations every year. Because software and hardware are increasingly developed and fielded in different ways and on different timelines, the U.S. military needs to evolve its processes for buying integrated hardware/software products or risk losing the adaptability and decision superiority required to deter or defeat peer competitors.
Combining design and manufacture
The advent of mass production during the second industrial revolution separated design from manufacture. A General Motors engineer could devise a new car and its specifications, turning it over to a manufacturing team that developed repeatable steps for the assembly line. After incurring this one-time expense, the car could be produced at scale.
Software collapses the division between design and manufacture. Once a software program is designed through coding, it can be almost instantaneously manufactured through compiling. Freed from the costs and time to build software, programmers can engage in a continuous cycle of software development and redevelopment to improve performance or meet other customer requirements. With hardware, such frequent redesigns would exact a price in terms of the tooling and material needed to manufacture each new variation on the product.
Differences in the ways software and hardware are designed, manufactured, and distributed create challenges for acquiring modern defense systems. Hardware depends on defined specifications and is purchased as a finished product; software can be procured as an evolving product integrated with system hardware. DoD made remarkable progress during the last several years in updating its acquisition process to address these differences, inspired by the Defense Innovation Board’s work during the past two years under the leadership of Eric Schmidt.
Sustaining the reform momentum
Arguably the most important of these reforms was an effort by the Office of the Undersecretary of Defense (Acquisition and Sustainment) to launch a new appropriation category for software. Traditional defense appropriations are confined to distinct activities such as research and development, procurement, or operations and maintenance, which does not support a continuous delivery model in which the work of a programmer might pivot between design, production, and sustainment several times an hour. The new software appropriation addresses the fungible nature of software development by being applicable to any software-related activity. This appropriations category will likely be a major enabler for artificial intelligence as well, which needs constant updates to models and data even after a program is fielded.
The other prominent change was replacing DoD’s monolithic acquisition instruction with a framework that accommodates the breadth of capabilities the department acquires today. The Adaptive Acquisition Framework incorporates a new software pathway that supports continuous development and operations, or DevOps. Similar to the software-as-a-service business models used by companies like Salesforce to build customer relations management systems, this development approach could work for DoD applications for enterprise resource management or command and control.
The U.S. military’s software reforms, however, can only make a difference if they are used and survive. DoD and service acquisition officials may not aggressively employ the new software pathway or comptrollers may be unwilling to exploit the flexibility of software appropriations. And in its 2021 appropriations bill, the Senate recently suggested that the new software appropriation category might be a means to avoid accountability and circumvent financial controls.
In Congress’ defense, DoD should update its reporting mechanisms to build transparency and trust, including for software projects. Although program plans that forecast functionality milestones years out into the future do not make sense for a DevOps approach, software development projects could still set measurable objectives such as capability drops, active users, and implementation of planned features. Leaders need to treat software differently than industrial production but can still enforce accountability.
New operational concepts being advanced by the US military such as the Joint Warfighting Concept and Multi-Domain Operations rely on distributed forces using networking, maneuver, and interoperability to gain a decision-making advantage over opponents. Implementing these concepts against peer adversaries like China will require that DoD adopt new approaches that enable the US military to field a wider range of new capabilities faster. Unless Congress and DoD stay the course on their software reforms, US forces could lack the adaptability to effectively challenge China’s military.
Bryan Clark is a senior fellow at the Hudson Institute and Director of the Hudson Center for Defense Concepts and Technology.
Dan Patt is an adjunct fellow at the Hudson Institute.
