The Pentagon’s acquisition chief vowed on Thursday that the Defense Department will get to work immediately on a sweeping revamp of DoD’s practices and policies for buying and building software.

After a year of study and under a directive from Congress, the Defense Innovation Board (DIB) drafted 26 separate recommendations to fix DoD software acquisition, including 10 “primary” recommendations. Members presented their findings at a public board meeting on Thursday.

At the meeting, Ellen Lord, the undersecretary of Defense for acquisition and sustainment, explicitly endorsed several of the DIB’s suggestions, including that the Pentagon needs entirely separate software acquisition pathways, distinct from its traditional hardware-centric rules.

She said her office had already begun rewriting DoD’s primary acquisition policy document, Instruction 5000.02, to achieve that end.

“We are going to have one process for hardware and one process for software, because truly I believe our future warfighting capability depends on hardware-enabled and software-defined systems,” Lord said. “We need to take those hardware platforms and continue to spiral in software to deliver more and more capability.”

Lord also backed a board recommendation that would establish an entirely new “color of money” in the Pentagon’s budget to account for the fact that software development is very different from building military machinery.

“If we look at the way we are structured to fund programs, it’s in a very serial, systematic fashion,” she said. “We can do that with hardware to a degree, but as you move from traditional waterfall software development to agile and DevOps, we need to be coding every day and testing every night.”

Specifically, the board said Congress should fund software development in a way that completely eliminates the existing distinctions in DoD’s budget between procurement, operations and maintenance, and research, development, test and evaluation.

Michael McQuade, one of the board members who led the software study, said it was one of several recommendations that flowed from a mantra the DIB adopted as a first principle: “Software is never done.”

“We need an appropriations category for the entire lifecycle of software, and it should be consistent with the pathway for execution we’re recommending: Automatic metrics, automatic development environments, DevSecOps approaches, without any separation into the various categories that we have in place,” he said. “A primary place to use that would be in the kinds of software where we know we will be delivering that kind of software forever … Not because we didn’t get it done, but because the threat environment will change or the operational environment will change. And we believe those should be programmed as a single kind of appropriation across the lifecycle.”

Several of the recommendations would require Congressional action, and Lord said she was hopeful that lawmakers would implement them as part of the upcoming 2020 Defense authorization bill.

DoD can revamp some practices now

But the Pentagon could begin work on many of them under its own authority. Some of the board’s other primary recommendations have to do with internal practices that are not heavily encumbered by existing law.

For instance, to shorten the time it takes to field new software, the DIB said DoD should conduct operational testing in tandem with its software development processes — ideally, automating those processes as well — instead of tacking scheduled operational test and evaluation events onto the tail-end of the development.

“But we need to be smart. The software I developed that runs on one kind of network may need different authorities to operate on another kind of network,” McQuade said. “So point number one is we need to try and figure out why the networks are different. Do they really need to be? But if the environments in which the software is being used [are similar], then we should have ATO reciprocity both across the service and from service-to-service.”

The DIB recommendations also include a strong emphasis on the department’s own IT and acquisition workforce. Board members said the department lacks a viable recruiting strategy for technical positions, and needs to make it a priority to train both its rank-and-file workforce and its acquisition leaders on how modern software development is done in commercial industry.

“There are lots of training programs out there,” said Richard Murray, another board member who helped lead the software study. “That might mean that I went out and I did a two-week boot camp on what it’s like to release software every night and have it go through a continuous integration, continuous deployment process, and I know what GitHub is, what Docker is. And if you are managing a program and somebody is throwing all those words around, it would really help if you could say, ‘Oh yeah.’ So we need to provide opportunities for people within the acquisition workforce to get that type of experience.”

The draft report also acknowledges that there are pockets of the Defense Department that are already succeeding in modernizing their software development processes and implementing agile methodologies. But board members say they’re doing so in spite of an unnecessarily complicated thicket of acquisition and budget processes.

“We make heroes out of people who are already finding a way to maneuver through the current system to do what we’re recommending,” McQuade said. “But we believe that that’s a waste of effort. The reason to have a defined pathway for software is precisely to recognize that software is different and you should not be spending your time finding a way through the system. You should use the easiest tool that’s available to you, the tool that has the least impedance against what you want to accomplish.”

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.