Pentagon officials, industry leaders lay out 3 secrets for speedier software

WASHINGTON — The war in Ukraine has underlined the importance of adaptability on the battlefield, with quick-thinking Ukrainians taking the initiative to innovate while the Russians remain mired in their own ponderous bureaucracy. But even as the US praises Ukrainian ingenuity, back in Washington the Pentagon still has plenty of its own red tape to get past — particularly, an industrial-age acquisition system ill-suited to a swift-moving world where even hardware programs depend on rapid software updates.

So, at the recent Nexus 23 conference in DC, DoD program managers and tech industry executives laid out best practices for faster acquisition. The keys to speed, they agreed:

1. Separate software development and testing from work on the much slower-moving work on hardware — potentially, by splitting off crucial software as a separate contract.
2. Design around modular open architectures, which let any vendor — not just a big prime contractor — plug-and-play new hardware components and software applications, as long as their tech complies with clearly defined common standards.
3. Bring industry engineers and military operators together in the field from the start, so each can learn from the other’s expertise as they experiment.

The goal is “to take our platforms and continually upgrade them and add additional sensing, additional capabilities…  better and faster than we have historically,” Dorothy Engelhardt, the Navy’s director for unmanned systems, told the Nexus conference. To make those updates easier, she added, “everybody is trying to figure out… how do I separate my autonomy from my platforms?”

On this front, the other services are keenly watching the Army’s Robotic Combat Vehicle program. RCV is using Other Transaction Authority contracts with one set of companies to build experimental unmanned vehicles — including the software required for them to function — and separate Software Acquisition Pathway (SWP) contracts with a different set of companies to build software development and testing tools.

“The Army has gone down the Software Acquisition Pathway for one of their programs [RCV], and that’s really exciting, because they’re going to learn all the lessons,” said Air Force Lt. Col. Tom Meagher, head of the service’s AFWERX Prime autonomy initiative, in an interview with Breaking Defense on the sidelines of the Nexus conference. “They’re taking an approach of developing the software on a Software Acquisition Pathway [in parallel to hardware contracts] and then trying to meld those together. It’ll be to be really important for the DoD to see how that works from an acquisition perspective, because that’s new.”

Neither he nor the Navy’s Engelhardt have seen a similarly structured program, Meagher told Breaking Defense. “If it’s successful, it could be very good,” he said.

The Army’s already trying to copy the split-software model, at least in part, for its flagship armored vehicle effort, the Optionally Manned Fighting Vehicle program. “RCV… led the way,” said Col. Jeffrey Jurand, the Army’s program manager for mounted combat systems. “OMFV is pursuing the same authorities right now. In fact, one of the things I’m here in DC to do is to brief the ASA(ALT) [Assistant Secretary of the Army for Acquisition, Logistics, & Technology] leadership on the process to get approval to enter the Software Pathway.”

“That does not mean developing all the software for the base platform” in the SWP contracts, he emphasized at the Nexus conference. “The primes still have to deliver a complete workable solution. We will develop in parallel, additive but not duplicative software base capabilities.”

Of course, when you have separate contracts for interdependent aspects of the same program, Jurand acknowledged, “anyone in this business is asking, how are you going to integrate?”

That’s where modular open architectures come in. “Open architecture… is the key enabler that allows an integrator that is not the prime” to work on a program, Jurand said. Instead of relying on a single, large prime contractor and their proprietary tech to pull everything together, “I will own the architecture,” he said. “I will be able to show it to you… so that we can upgrade at the pace of technology and really break our vendor lock with the primes.”

Modular open architecture also simplifies and speeds up safety testing, Jurand and Meagher agreed. That’s because modularity lets you keep the essential safety systems separate, unchanged, and reliable even as you experiment and do rapid updates on other subsystems. By contrast, in traditional designs, everything is so interdependent and intertwined that changing one feature might have unanticipated impacts on safety-critical components, requiring the military to test everything all over again.

“If you don’t have that separation between your autonomy stack and your safety functions, you will never get through independent test and evaluation,” Jurand said, “because…there’s no way to prove that [any] changes or upgrades to software you’ve done do not touch safety-critical vehicle management functions. We’ve seen that on the smaller robot side of the Army, and we’re addressing that trying to address that within the OMFV.”

“You have to have a separation,” Meagher told Breaking Defense. “That’s emerging as a best practice.”

If you have a modular open architecture and a contract structure that let you separate software from hardware, and different software modules from one another, it becomes much easier to work with a wide variety of innovative firms. And the closer the military and industry can work together, and the earlier in the development process, the better the results, experts at the Nexus conference agreed.

“Connect those companies and give them access to some operators,” Meagher told Breaking Defense. Industry engineers and software developers see how the military would really use their tech in the field, he said, while the military operators and requirements writers can learn what the latest technology can actually do, hands-on. “It opens up a world of different possibilities,” he said.

Often, however, that industry involvement comes too late in the development process. “We can’t do our best work unless we’re involved a lot earlier,” said Mandy Long, CEO of BigBear.ai.

All too often, she said, military officials spend years studying a problem in isolation from industry, then issue detailed requirements documents that try to prescribe how industry solves the problem. “I don’t need help with the ‘how,’” she told the Nexus conference. “My job, my organization’s job, is the how. That is what we do for a living. [We] understand the technology that is practical, that is possible.”

“Where we need more help… is actually understanding the problems that need to be solved and the outcomes that need to be delivered,” Long said. That’s where the engineers need to learn from the operators.

“A lot of times DoD knows intimately what the challenges all around are, what the problems are, and then at the same time [they] want to prescribe the solutions,” agreed Don Burnette, founder and CEO of Kodiak Robotics.  “We need a lot more flexibility.”

RELATED: Industry to Navy: We need steady demand signals, earlier involvement in requirements

“One of the things we’re learning about the Ukraine war is the need for flexibility, especially as it pertains to robotics,” he told the conference. “The environment is literally changing by the minute, by the hour.”

“I saw this play out,” added retired Navy Capt. Michael Brasseur, former commodore of an experimental unmanned systems unit in the Middle East, Task Force 59. “We were seeing software changes within hours or days, hardware changes within weeks or months. And that is enabled by a pace of iteration that, I would suggest, is rivaled only by what you see in Ukraine.”