Software developers could show the Pentagon how to end the “innovation theater.”


Congressional and defense officials have complained for decades that the Pentagon can’t put up something quick. With the digital revolution bringing new consumer products to market virtually every week, the US military must capture the attention of the US Secretary of Defense to quickly and at scale create a product such as: B. mine-resistant vehicles used in Iraq and Afghanistan. Today, when troops need new technology, they often buy it themselves.

The Pentagon’s failure to innovate is not due to a lack of effort. Hundreds of experiments are underway across the force to evaluate everything from unmanned systems to new ways of connecting disparate units. They are supported by dozens of software factories developing cloud-based delivery mechanisms that update system programs for new applications.

However, these efforts run the risk of becoming mere “innovation theatre”. As in the theatre, the new gadgets and tactics look good on stage and encourage creative thinking. But like theatre, these sometimes revolutionary combinations of hardware, software and people are fleeting. The use cases are heavily scripted and the systems involved are often one-off products that the government may not even own, that cannot be scaled and deployed across the force.

One of the hurdles preventing an experimental success from becoming a field system is testing and evaluation, or T&E. Just because a new piece of gear makes troops more effective in an experiment doesn’t mean it has the durability to last more than a few days, the interoperability to communicate with enough other systems to be useful, or the versatility to be useful in other situations. These are the questions program managers must answer when moving equipment from the lab to the field.

Traditionally, T&E is performed at the end of the development of a defense program. After years of analyzing requirements, evaluating alternatives, maturing technologies, and assembling systems, a new product is developmentally evaluated by the vendor and operationally evaluated by the government. Because they precede the deployment of the system, the T&E results do not reflect how they are used in the field and are only a snapshot of the system’s performance in limited environments.

Around 2008, software developers adopted a new approach to product development that addresses the limitations of traditional T&E – the development-operations or DevOps cycle. DevOps accelerates field deployment while maintaining quality through near-continuous automated instrumentation and testing. And unlike Pentagon T&E, DevOps continues after a new product is deployed and evaluates its effectiveness as the product’s use cases and environment evolve. Potential needs or opportunities that arise in the field are evaluated for security and utility and implemented in the next hardware or software update.

The DevOps model could be extended from information technology to defense systems using T&E. Rather than being the hurdle between development and operations, T&E would become the glue that integrates them and gives acquisition managers and executives confidence that a new program or employment concept is worth scaling or adapting. This approach would allow experiments and exercises to break out of the theater and become repeatable use cases.

Modernizing T&E to power Defense DevOps will require significant process and technology changes. Overall, the Department of Defense T&E firm needs to flatten and expand its efforts over the lifecycle of a program, as called for in the Director’s recent strategy for operational T&E. Rather than dedicating all of its resources to the testing milestone when a program is delivered, T&E needs to pay more attention to evaluating experiments and prototypes to help identify good ideas or rule out bad ones. After a system has gone into demonstration or operation, T&E would continue to evaluate its usefulness.

Supporting both development and operational evaluation requires the establishment of a digital infrastructure that can represent and evaluate a potential new system, which can be validated as the system undergoes development and operational testing. The resulting digital models could be used operationally to guide field commanders as they evaluate potential tactics or troop compositions and integrate the new system into common mission packages. While this approach may not be feasible for every program, it could be used for high-priority efforts such as the Air Force’s family of systems and Navy Next Generation Air Dominance.

The main obstacle to building a Pentagon version of DevOps is money. Today, operational and developmental T&E activities are mostly funded by the tested programs. Acquisition managers and executives have no incentive to invest in new testing infrastructure that would change their programs’ T&E plans. And T&E organizations can’t conserve funds for new tools or staff without distracting from ongoing testing.

Congress can help. By allocating some of the proposed increase in T&E funding to digital tools and systems alongside the physical outreach that has been the backbone of T&E, lawmakers could move from complaining about the slow acquisition to using the Fixing the DevOps cycle that gave us everything from distributed finance to the iPhone. In doing so, Congress could bring Pentagon innovations out of the theater and into practice.

Bryan Clark is a Senior Fellow at the Hudson Institute and director of the Hudson Center for Defense Concepts and Technology. Dan Patt is a Senior Fellow at the Hudson Institute.


Comments are closed.