SYDNEY J. FREEDBERG JR
Army Futures Command’s Software Factory operations taking place on March 22, 2021 in Austin, Texas. (U.S. Army Photo by Mr. Luke J. Allen)
WASHINGTON — After a sluggish start, the Army is slicing through self-imposed red tape so it can do faster software updates, which are essential to everything from payroll systems to cybersecurity to high-tech combat vehicles. The objective: remove a host of obstacles so the service can make widespread use of the streamlined Software Acquisition Pathway.
SWP was created in 2020 to bypass ponderous, industrial-age procurement processes so the Pentagon could roll out new software at the same pace as the private sector, in weeks or months instead of years.
“We are embracing the Software Pathway,” said Young Bang, principal deputy assistant secretary of the Army for acquisition. “We have the [legal] authorities to do that from Congress.”
But the legal foundation by itself is not enough, Bang emphasized in an exclusive interview with Breaking Defense. There are plenty of regulations, bureaucratic processes, and plain old bad habits in the way.
“There’s been institutional processes have been around for a long time for the DoD at large and the Army,” he said. “Until you fix all those, we can’t actually get to agile CICD [Continuous Integration, Continuous Deployment] releases every two-three weeks like Netflix.”
“We’re working on efforts to change that,” he said.
“There’s a lot of support within the Army and DoD to make that happen,” added Jennifer Swanson, deputy assistant secretary for data, engineering, & software, speaking to Breaking Defense alongside Bang. “I honestly believe by the end of next year, we’ll be in a much better place. We’ll have a lot more flexibility to do what industry does.”
For 3 Years, Slow Going
Right now, the service’s software stats aren’t that impressive. The number of Army programs using SWP has grown from one in 2020, when the pathway was first authorized, to nine — a dramatic increase but still less than 2 percent of the Army’s 540 programs. Of those nine, officials told Breaking Defense, four are so new they’re still in the planning phase and haven’t yet delivered any actual software to users.
Of the five programs that are delivering usable software, just two are delivering updated code more frequently than once a year. The Army didn’t provide more specific timelines, but that’s a long way from commercial-style release cycles measured in weeks.
Besides the nine Army SWP programs, the service has another seven programs using a separate but similar congressional authority, known as the Budget Authority 8 (BA-08) software pilot. These seven programs are all part of a larger Defense Cyber Operations (DCO) effort to shore up the service’s cybersecurity — an area where rapidly evolving threats and the ever-changing digital landscape of the internet make swift updates especially essential.
The DCO programs are technically traditional Major Capability Acquisitions, subject to an elaborate multi-phase process; but they’ve been given significant SWP-style flexibility, especially in the drafting of the formal requirements that their products must meet. So, while the Army didn’t provide specific metrics on how fast DCO code is being updated, Young extolled them as “a huge success story.”
There are also streamlined elements within other traditional software programs, such as IPPS-A, the service’s new Integrated Personnel & Pay System – Army rolled out in January. Planned upgrades, originally envisioned as one massive package, will be subdivided into smaller, more manageable “chunks” that can be developed, tested, and rolled out much faster, Bang said.
Nevertheless, all these streamlined software efforts added together still amount to a rounding error within the Army’s roughly $40 billion annual acquisition budget. Bang, Swanson, and their staffs are striving to make SWP and SWP-like programs a much bigger piece of how the Army does business.
While there are just nine SWP programs now, “that number is growing rapidly,” Swanson said. “Even this year, I honestly would expect it to close to double” as new programs ask to be on SWP from the beginning and existing programs ask to transition.
In the slightly longer term, “towards the latter part of ‘24, you’ll see the numbers drastically improve,” Bang told Breaking Defense. “You will see… a steady growth and then potentially an exponential growth.”
Several different reforms give Bang and Swanson cause for their optimism. One, which applies across the Defense Department, is DoD acquisition chief Bill LaPlante’s August 2022 edict [PDF] allowing “defense business systems” — such as payroll, contracting, or installation management — to use the Software Pathway. That significantly increased the number of programs eligible to escape the slow, traditional system into SWP.
Within the Army itself, they said, the service is working hard to streamline the requirements process. Traditionally, that takes years of horse-trading between bureaucracies to generate hundreds of pages of rigidly detailed specifications, which then can’t easily be changed as technology improves, threatens worsen, or users offer feedback. “A lot of times we develop software which we think is awesome, but people don’t adopt it or use it,” Bang said.
The Software Pathway, by contrast, allows programs to get underway with a much less detailed Initial Capabilities Document, setting broad-strokes requirements that can then be updated, expanded, and revised repeatedly throughout development. And, Swanson said, acquisition officials, Army Futures Command, and the service’s Training & Doctrine Command (TRADOC) are now “working very closely” together to develop templates and other guidance to give programs a clearer path through the new process.
‘Software Is Never Done’
Another major bottleneck is testing. Certainly, rigorous, realistic testing is important: Soldiers don’t want communications networks crashing mid-combat, any more than they want their guns to jam or tanks to throw a track. But traditional Pentagon testing is built around complex, lengthy events that run through every aspect of a system. That’s workable for hardware, which can’t change rapidly once it’s approved for fielding, but it’s out of sync with how software updates work best, which require lots of quick, incremental changes. Most commercial software companies manage this by automating much of their testing: They use software to test their software, with algorithms running new code through routine checks at superhuman speed.
“We’re working with ATEC so we [can] have automated testing,” Bang said, referring to the independent Army Test & Evaluation Command. “That’s a huge paradigm shift [and] they’re completely on board.” Instead of ATEC coming in at the end of a development cycle to manually retest the entire software package whenever any small change is made, they would instead get involved from the outset, access the outputs from the automated testing systems in near-real-time, and save their skilled human testers’ time for the most important checks.
Figuring out how all this will work in practice is complex and time consuming, Swanson cautioned. But, she said, “by the end of ’24, we will definitely have at least some of those software pathway systems that are able to automate testing.”
Another huge institutional change is how the Army handles what it calls “sustainment.” A traditional hardware program, like a truck or rifle, starts out in R&D, builds prototypes, goes through testing, and gets approved for fielding. Once fielded, the equipment may receive overhauls or upgrades from time to time, but day to day it’s “in sustainment” and not expected to change, so it simply needs to be maintained and kept in working order. These functions are considered so different the Army actually has separate organizations for them, with the program managers who developed a new technology at some point handing it over sustainment officials.
But that hand-off doesn’t work well for software, which requires constant updates to keep working properly. In effect, the “development” phase never stops, even after the software is fielded. So, starting in fiscal year 2024 (which begins Oct. 1, 2023), the Army will no longer move new software programs out of development into sustainment at all. Instead, authority of software programs — and the funding that comes with it — will stay with the same program management office that oversaw the initial R&D, allowing them to keep updating the code indefinitely.
“Software is never done,” Bang said. That’s actually a quote referencing the title of a landmark 2019 Defense Innovation Board study that warned Pentagon software programs moved far too slowly because “DoD still treats software much like hardware.”
In truth, though, the industrial-age development process doesn’t even work for hardware anymore, because physical machinery increasingly depends on software. Even civilian cars now rely on digital tools for routine maintenance diagnostics, while military vehicles incorporate high-tech sensors, targeting systems, and even automated anti-missile defenses.
But while the Software Pathway is built for flexibility, it’s not flexible enough that you can develop, say, a new tank or an aircraft carrier just using SWP. So, Bang and Swanson said, the Army is looking at splitting off the software portion of major weapons programs as a separate but intertwined acquisition, running rapid updates alongside the slower hardware development, with software and hardwnare using different processes.
The service is already trying this on a small scale with its Robotic Combat Vehicle experiment, where it has contracts with Qinetiq and Textron to build physical prototypes and a separate contract with Applied Intuition to build software development and testing tools.
In the longer term, Bang said, it might apply the split approach to the larger Optionally Manned Fighting Vehicle effort to replace the Reagan-era M2 Bradley armored troop carrier. Currently, multiple competitors are building rival prototypes, with each contender building a complete package of hardware and software. As OMFV matures, however, Bang said the service expects to split off an SWP to develop software in parallel to the hardware program.
“We’re looking at embedding multiple pathways within each other…because software is now embedded in all of our platforms,” Bang said. “As much as possible, we’re trying to separate hardware from software, and data from software.”
No comments:
Post a Comment