Meeting the Software Challenge: How the Air Force Is Embracing New Acquisition Rules

Editor’s Note: This is the first in a three-part series exploring the opportunities and challenges facing the Trump administration’s changes to how the Pentagon buys software.

When Defense Secretary Pete Hegseth addressed the Army War College last week, he mentioned changes to the way the military buys software alongside Golden Dome and the F-47 as key to his goal of “rebuilding the military.”

In a memo last month, Hegseth doubled-down on a new rule book for the way the U.S. military buys software. The memo mandates the use of the Software Acquisition Pathway, a five-year-old effort to reshape a military procurement process built for industrial age military hardware like tanks and ships, and fit it to buying modern software.

And Lt. Gen. Luke C.G. Cropsey, who heads the Air Force’s most consequential IT acquisition programs, says he’s already using the authorities that Hegseth foot-stomped in the memo to contract directly with commercial startups and bring cutting edge software into the huge, complex programs he manages.

The Software Acquisition Pathway was developed by a blue-ribbon commission and passed by Congress in 2019 to address concerns about huge delays and budget overruns in software-heavy acquisition programs like the F-35. But the pathway was a voluntary option prior to Hegseth’s memo and only a small number of programs are using it so far.

Hegseth’s memo says it should be the “preferred option” for all major software purchases going forward.

And the memo also mandates the use of new, much more flexible acquisition tools, which aim to short-circuit long-established rules about how the government spends taxpayer dollars, to help the military buy cutting edge technological capabilities more quickly.

Almost no one seems to think that the way the U.S. military currently buys software is effective. But while the Software Acquisition Pathway has existed for nearly five years now, government auditors have noted that it is rarely used by major weapons programs because of gaps in training and resources—suggesting Hegseth may face big challenges in his push to make it the default option.

Of 53 software-intensive major weapons programs looked at by the Government Accountability Office last year, only one reported it was using the pathway. And GAO Director of Contracting and National Security Acquisitions Shelby Oakley told Air & Space Magazine that program was no longer using the pathway.

“We would like to see more use of that pathway by these programs, but we’re just not seeing that at this point,” she said.

When program managers were asked why they weren’t using the then-optional software pathway, Oakley said, their response varied.

“Some said, ‘Oh, it’s not applicable to us,’ or, ‘The contractor is doing the software, we don’t have any insight,’ all sorts of things like that,” she said.

But one reason that stood out, she said, was resources. “Programs told us, and told [the office of the undersecretary of defense for acquisition and sustainment] that they felt like they didn’t have specialized people to do this, that they didn’t have the expertise,” she said. They ended up relying on contractor support. “In order to do these modern, agile developments, you need a program office and a program manager that have the skills to oversee these activities,” Oakley said.

There was a “disconnect” between the policy and the resources, she added. “It is a little bit unrealistic to think that folks will just magically know exactly how to do this and understand what this might look like for what they see as a more traditional weapons program effort.”

Lt. Gen. Luke Cropsey is responsible for developing the overarching architecture that can turn Combined Joint All-Domain Command and Control (CJADC2) from a concept into an operational reality. Mike Tsukamoto/staff

A New Way of Buying Software

Cropsey, who heads the Air Force Program Executive Office (PEO) for Command, Control, Computers, and Battle Management (C3/BM) told Air & Space Forces Magazine he was already using many of the authorities Hegseth is promoting as part of a drive to embrace software innovation. “What we’re doing with [Cloud-Based Command and Control] is exactly the direction the SecDef’s memo is pushing us,” Cropsey said.

CBC2 is the modern, cloud-based software replacement for the aging Battle Control System–Fixed—the Cold War-era system used to defend North American airspace by NORAD, the joint U.S.-Canadian air defense organization. Ground stations across North America monitor and track possible airspace intrusions, said Cropsey, and feed that data to NORAD HQ. “But the equipment that they’re using has been around for decades and decades and decades,” he said.

In the industrial age model of contracting, Cropsey said, the Air Force would award a contract for a new air defense system or a jet fighter to a single company which would produce it for decades, on the assumption that, with the resources of the United States behind it, it could outpace any technological competitors. But in the new innovation era, the service had to be ready to be a “fast follower,” adopting new technological advances, from wherever they spring, as quickly as possible.

“The paradigm is rapid, incremental, buys of emerging capabilities,” Cropsey said.

The capabilities he hopes to leverage in CBC2, he said, “grew out of a number of prototype collaborations that we have with folks like DIU” and other innovation shops.

The new authorities in the Software Acquisition Pathway and the novel contracting tools mandated in the Hegseth memo “allow us to contract directly with those non-traditional cutting edge software providers in the commercial market for the things that we needed,” Cropsey said.

Industry software teams participate in the Department of the Air Force’s Advanced Battle Management System Cross-Functional Team first software sprint experiment to examine software solutions for enhanced command and control in conjunction with the Shadow Operations Center – Nellis, at the Howard Hughes Operations, or H2O, facility in Las Vegas, Nevada, Sept. 9-13, 2024. U.S. Air Force photo

From Pathway to OTA

Traditionally, Cropsey explained, the way major weapons systems would seek to leverage a startup with exciting new capabilities would be as a subcontractor to a large defense prime, because the small, new company would not be able to meet the onerous requirements to qualify to bid on government contracts.

But the Hegseth memo directs all software programs use two alternative acquisition tools: Other Transaction Authority (OTAs) and Commercial Solutions Offerings (CSOs), which dispense with many of those requirements.

Cropsey said the CBC2 team used a different alternative acquisition tool, Small Business Innovation Research contracts (SBIRs) Phase III, to directly engage software vendors and bring them onto the program quickly.

“A Phase III basically allows anybody to come get you [the vendor] on contract as a sole source, very, very rapidly,” he said. “So we had a direct contractual relationship with them, not a typical prime to sub relationship that a lot of these different contracts have had historically.”

That meant the CBC2 team could use the startups to deal with issues or bugs as incremental capabilities were rolled out to users, while also developing the next generation of capabilities. “We could go in and very, very rapidly pivot those software providers to the things that were getting curated in that DevSecOps backlog and that pipeline,” he said.

These alternative acquisition tools make it easier to get vendors, especially non-traditional ones like the software startups working CBC2, on contract and working, Cropsey said.

“The drawback,” he said, “is you need contracting officers that understand the authorities associated with these contract vehicles, because they’re outside of the typical Defense Federal Acquisition Regulations that most contracting officers grow up doing. So it’s a different skill set.”

Writing and managing OTA contracts is taxing, and not just because they’re different from conventional procurement tools, said Oakley. They’re also less proscriptive and less structured, meaning it takes more work to create them.

Oakley compared drawing up an OTA contract to “creating it from scratch versus following the formula of a regular, DFAR-based contract.”

They can also be harder to manage, she added, and GAO had “raised some concerns about the ability to effectively oversee these OTAs and really structure them in a way that gets the government what it wants.”

Part 2 will probe the origins of the Software Acquisition Pathway as part of an acquisition reform movement in DOD. Part 3 will look at questions about the pathway and the flexible acquisition tools that accompany it.