Editor’s Note: This is the final episode in a three-part series exploring the opportunities and challenges facing the Trump administration’s changes to how the Pentagon buys software. Part 1 is available here, and Part 2 is available here.
The new rules for buying software made mandatory by Defense Secretary Pete Hegseth’s March 6 memo are designed to strip away constraints on how the DOD and the military services contract with private sector companies, so that they can buy, integrate, and deploy innovative capabilities more quickly.
But critics warn that the Software Acquisition Pathway, by clearing the way for faster, more agile acquisition, also removes safeguards imposed to prevent waste and abuse. In smoothing the path for a new generation of innovative software companies to contract with DOD and “disrupt” the defense industrial base, these critics argue, DOD risks creating a new generation of complacent incumbents.
“The reason why this [software acquisition reform] push is so well-championed by private industry is because it’s a vehicle to move money quickly with very few strings attached,” one recently retired Air Force technology and acquisition leader told Air & Space Forces Magazine. “We have to be careful if we kill off those old kings, that we don’t just replace them with new kings.”
The retired officer, whose 20-year career included a stint as senior leadership at an Air Force technology accelerator, was granted anonymity because they fear retribution against themselves and their current employer for criticizing an administration policy initiative.
The software pathway, according to a guide produced by the Defense Acquisition University, frees software buyers from a series of constraints.
Normally, programs with an R&D budget of over $300 million or a total budget of over $1.8 billion are considered Major Defense Acquisition Programs. MDAPs are divided into phases and have to meet certain milestones and report them to Congress before they can move to the next phase.
Under the pathway, software programs are exempt from the MDAP process, according to the guide.
In return, pathway programs have to provide a minimum viable product—some capability to users in the field—within one year, a breakneck pace for military acquisition. They also have to commit to:
- Updates once per year or more.
- Using modern software practices like agile and DevSecOps.
- Automating their testing and compliance.
The pathway also frees software programs from the Joint Capabilities Integration and Development System (JCIDS), a process designed to vet requirements across the joint force.
“Instead of spending years writing detailed requirements and going through a rigid one-size-fits-all process,” a defense official told reporters at a background briefing on the Hegseth memo, “we can tap into the best tech available right now, prototype it fast and get it to the field quickly if it works.”
Another hailed the use of commercial solutions openings in the Replicator program, the Defense Innovation Unit-led effort to build cheap drones, saying they got three vendors on contract in just 110 days from issuing the original “problem statement” to industry.
“That is much faster than the traditional ways of putting out a solicitation and making those awards,” the official said.
The Relevance of Speed
Yet speed is a “dangerous” metric for software acquisition for a number of reasons, said the retired Air Force technology and acquisition leader.
“Speed is the metric where Silicon Valley measures its success: How fast can we get to market right? In the military it’s different. You can’t go out there with something that’s untested, where you think it’s going to work,” they said.
Moreover, speed as a metric “doesn’t tell you if anyone is actually using this stuff.” More useful metrics, they suggested, would be rates of user adoption and feedback about the user experience.
Ultimately, in the military context, they said, “the metric should be, does it work under fire? Does it have resilience under uncertainty? And if it does, then that’s a good candidate.”
Speed is also a potentially troublesome metric because it lessens focus on oversight, the retired acquisition leader said.
“Moving money and getting on contracts, I won’t lie about that: that’s hard to do, and getting on contract fast is important,” they acknowledged, adding that there are good people working hard in organizations like the Defense Innovation Unit.
But these faster mechanisms—often grouped under the term Other Transaction Authorities, or OTAs—can now be used for full-scale production contracts, not just for developing prototypes. “Hundreds of millions of dollars are going out that door,” the retired official said.
Maj. Gen. Luke C. G. Cropsey, who heads the Air Force Program Executive Office (PEO) for Command, Control, Communications, and Battle Management (C3BM), has said the service is already using the new authorities foot-stomped by the Hegseth March 6 memo—and he pushed back against the idea that the software pathway stripped away oversight.
“There’s still very much accountability associated with the expenditure of funds,” he said. “The contractor is accountable for delivering on the products.”
A senior defense official told reporters at a background briefing on the Hegseth memo that the ability to move from a prototype OTA contract to a production OTA contract is a “key enabler” for software acquisition, because it means an established weapons program can piggyback a prototype OTA by an innovation lab like DIU and issue a production contract for the technology that prototype has proven out.
“So, that’s a key element of these OTs is that you can prototype an OT and then a completely different organization can drop a production OT on top of that prototype OT,” the official said.
But that flexibility, combined with the low barriers to entry for a DOD marketplace like Tradewinds, the AI contracting clearinghouse run by the office of the Chief Data and Artificial Intelligence Officer (CDAO), could be dangerous, the retired acquisition specialist said.
The net effect, they said, is that companies with no history or demonstrated ability of delivering anything could get put on multimillion dollar, no-compete contracts at the complete discretion of the contracting officer on the basis of “a five-minute pitch video,” which is all it takes to enter the Tradewinds marketplace.
Defense officials told reporters at the background briefing on the Hegseth memo that they’re looking to combat that issue by requiring all OTAs and CSOs over $100 million to be approved by the undersecretary of defense for acquisition and sustainment.
‘Trilingual’ Expertise
Other critics are also concerned that the DOD workforce doesn’t have the skills they need to use the Software pathway.
Defense officials on the background briefing said they are moving to address the need for new skills from program managers and procurement officials.
One official said DIU, in partnership with the Defense Acquisition University, is running a training scheme called the Immersive Commercial Acquisition Program (ICAP). “We’re competitively select top performing contracting officers from across the Department of Defense to come and work with us at DIU and execute DIU service-aligned prototype projects. At the same time, they’re taking DAU courses, so they’re learning the textbook rules [and] regulations on Other Transaction Authority” contracts and other flexible acquisition tools, the official said.
Getting contracting officers into innovative programs is essential to spreading the knowledge of how to buy software better, said Cropsey: “You’ve got to build a pipeline that allows you to bring junior folks into these programs and actually get exposure earlier in their career to how to actually use and implement some of these [new acquisition] mechanisms,” he said.
But just training acquisition professionals to use new tools doesn’t necessarily equip them to buy software, explained Tate Nurkin, an Atlantic Council senior fellow and co-author of the recent report from its Commission on Software-Defined Warfare.
“We need people who are trilingual,” he told Air & Space Forces Magazine at the report launch. They need to understand and know how to use the new acquisition tools, but they also have to understand the needs of warfighters in the field. Above all, he said, “they need to speak software” to know which questions to ask of contract engineers writing the actual code, Nurkin said.
The challenge, said Dopkeen, is to develop “software literate” acquisition professionals. “You have to develop software people the same way you develop acquisition professionals. You have to take people and you need to put them in good software environments, practicing coding and learning how it done.”
“There isn’t really any substitute for working on a major software project, and preferably more than one, even in a relatively junior capacity” for learning which questions to ask as the manager of such a project, Dopkeen said.
But more important than any training was the issue of cultural change, she said.
“Data and software are kind of like the backroom at the Defense Department,” she said. “Everyone wants to do things that go ‘boom’ and data and software is an afterthought.”
Trying to get software right in DOD, Dopkeen said, “you always feel like you’re almost a virus that the Pentagon body is fighting against.”
To fix the problem requires overhauling the culture of the military services, she said, giving as an example the way pilots tend to get the top jobs in any Air force program.
The litmus test, she explained, for predicting the success of the new F-47 fighter, will be “If it has a software person as the program manager and a plane person, a pilot, as their product manager.”
Beyond Acquisition
Another big issue, Dopkeen said, is that acquisition is not the only problem with the way the military uses software. Indeed, she said, the way the DOD has traditionally treated software is “the opposite of what they should have been doing.”
In commercial enterprise like Google, she said, codebases are not just updated, they are constantly being rewritten, a process called refactoring. “With Google Calendar, for example, they will design that product and let the team work on it for a year and then they’ll tell them to go back and completely rewrite it, design it again with new code, knowing what they do now.”
At DOD, by contrast, the attitude is, “because it works and has been certified, this becomes Holy Code that can never be touched again. And then you build on that for a decade and you end up with spaghetti code that is just a huge mess. And you are left with a huge attack surface,” she said.
DOD Chief Software Officer Rob Vietmeyer recently called these legacy systems “a boat anchor,” a huge drag on the department’s innovation efforts.
And it’s not a problem that can be solved by just changing the way the military buys things, said the retired acquisition leader, because the root causes go way beyond the acquisition system.
“There’s not really any off-the-shelf software running on DOD networks,” the retired official explained. “Unless you’re an external application, hosted somewhere else, all the software is modified” to meet security and other special requirements for DOD networks. “And that creates a lot of technical debt, because you’re maintaining two different code baselines: One for DOD and one for everyone else.”
In addition, although the pathway mandates the use of agile software development practices, in reality, there were many restrictions on the tools developers can use on military networks.
“Operating on the military network is really where a lot of the blockers are. The restrictions, the approved tools that you can use, they suck…. That is the main driver on why they can’t push updates.”
They said the focus on acquisition is well-meaning but ultimately inadequate.
”If you want to move fast, then let’s streamline the process of building software, let’s approve the tools that developers need on these networks. … This is a hard problem to solve, but if you really want to solve it, then you need to look in the right places,” they said.
