The Army has seen enough from its testing of the Adaptive Acquisition Framework to know what its future looks like.

And that future is around six pathways that moves the services away from a one-size-fits all approach to buying and managing technology.

Margaret Boatner, the deputy assistant secretary of the Army for strategy and acquisition reform, said these six pathways outlined in the Defense Department’s released in 2020 have shown enough promise to force the service to change its approach to how it buys and develops software.

“I think two really key things about the software pathway. One, it eliminates a lot of bureaucracy and process that is typical of the traditional acquisition process. For example, we can operate totally outside of the traditional requirements process. There’s a lot less documentation and review requirements to start a program on the software pathway,” Boatner said on Ask the CIO. “But even more importantly, what it does do is it actually requires us to use modern software practices. It’s not an option. We have to use agile, DevSecOps, continuous integration, continuous delivery (CI/CD) and those types of things. We have to deliver capabilities within one year and annually thereafter. So really it’s forcing faster cycle times then what we employ traditionally when you look at our software systems.”

She added the Army typically released new features or capabilities every three to four years in traditional waterfall based programs. But now with the software pathway, it’s accelerated the release of new services to every 9-to-12 months, at the very most with a goal of releasing every six months or sooner.

While the Army is far from industry standards of releasing new capabilities every few weeks or even more quickly, she said these initial changes show real progress in changing the culture and outcomes.

“I do think it’s a sign that we have adapted and are adapting to more of these agile processes that are required by the software pathway. The Army has 14 programs on the pathway now, but we are actively in the process of transitioning more over including more of our traditional defense business systems because those are now allowed to transition and pivot over to the software pathway as well,” she said. “For any of our software intensive capabilities, we want to get on the software pathway because of all of these unique flexibilities and the fact that it forces us to align to some of these industry best practices.”

DoD’s Adaptive Acquisition Framework splits the acquisition approaches into six pathways:

• Major capability acquisition (the pathway that will handle most of the military’s traditional hardware procurements).
• Urgent capabilities.
• Software (including, in some cases, software that will be part of major weapons systems).
• Business systems.
• Services.
• Middle-tier acquisitions that use the recently-enacted “Section 804” authority for rapid fielding and rapid prototyping.

Under AAF, the objective is to flip the script: Start with a baseline of rules that only really matter for the pathway that best fits their program, and “tailor-in” whichever additional requirements and acquisition best practices fit the actual product or service they’re buying or building.

Reducing documentation requirements

Boatner said the AAF is changing the Army’s mindset in two main ways.

“First, it really allows us to tailor acquisition approaches. So moving away from the one size fits all approach, we now have the ability to choose between six different and distinct pathways based on the characteristics of our program,” she said. “We could choose one or we could choose multiple pathways depending on the needs of our program. It also emphasizes tailoring-in versus tailoring-out of other requirements. So instead of having to comply with 35 documentation and review requirements for everything we get to say, ‘hey, this document in this review requirement is appropriate based on the program.’ The second thing that it does really is empower our program managers. We can delegate decisions down as much as possible, including the choice of the pathway, including what documents review requirements. It’s really pushing down a lot of that decision making which helps to streamline the process.”

The expanded use of the AAF also is part of a broader effort across the Army to change the way it manages and buys software.

Secretary Christine Wormuth issued a new agile software policy detailing five changes to reform what she called the institutional processes of the Army.

Leo Garciga, the Army’s chief information officer, said recently the policy changes will help the service streamline its ability to build contracts based on agile and DevSecOps methodologies.

Boatner said these changes will not happen overnight, recognizing the Army has built up these habits and processes over the course of decades.

“We’ll do a full communication blitz, where we go to all of the program executive office shops and all of the contracting shops to make sure they understand the direction that we are moving in. We’re also trying to centralize expertise in a couple of places. Contracting, for example, is one way that we’re trying to centralize this expertise, such that contracts will flow through the same group of people who really can become very, very savvy in this, who are more skilled in in writing and executing contracts or agreements for software development efforts,” she said. “We’re trying to pool another group of experts that are going to help folks from the headquarters level as they do their software development efforts, more from the technical software development side. It’s really making sure we have the right expertise in the right place to actually execute a lot of these things, in addition to all of the communication and the roadshows that we, of course, plan to do.”

She added her office also will work with the larger cybersecurity and test and evaluation communities to ensure they understand how the AAF works and what it means for their specific areas.

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