The Army’s ready to turn its experience with its 11 software pathway pilots into policy.

The goal isn’t just to institutionalize the lessons learned from moving to an agile or DevSecOps approach and away from the long-dreaded waterfall methodology, but to transform the entire culture from requirements development and contracting to security to continuous delivery.

“We have a lot of successes that we’ve done well with the defensive cyber operations (DCO) pilot and working with our cyber colleagues about how do we work on processes. Technology is not the hard part, it’s the processes that enable us to get to releases faster,” said Young Bang, the principal deputy assistant secretary of the Army for acquisition, logistics and technology at the recent AUSA conference. “That set us on a journey beyond just going to agile and to get to continue integration, continuous delivery (CI/CD) and right now our focus is working with our colleagues like the CIO and Army Test and Evaluation to figure out how do we get rid of these institutional processes that really forced us back to more of an iterative process so we can get to CI/CD.”

To that end, Gabe Camarillo, the undersecretary of the Army, said new software development and contract policies are on tap for 2024.

Camarillo said these memos will “fundamentally reshape the landscape” when it comes to acquisition and developing software.

“There’s a couple of things that we’re looking at in that space. One of which is making sure that we formalized and standardize the way that we do those requirements for software development programs. Obviously going more to a CI/CD approach and a more generalized description [of what we want]. Another approach is changing the way we do test and evaluation for our software programs. There’s a lot of contractor vendor testing that we can utilize, and we can train our tests and evaluation workforce to utilize that without having to recreate it,” he said. “I think another one is contracting. That is where the rubber hits the road, and making sure that our contracting approaches are coherent, they involve personnel that are well trained in software development is critical to success. And then lastly, bringing software development expertise into the Army in a way that will enable us to be much smarter, more effective savvier consumers.”

Camarillo added too often the Army has programs or contracts that had been led without an understanding of what it is asking for in a real sophisticated way.

To address that shortcoming, the Army is looking at bringing in a team of experts that would red team or peer review many of the solicitations for complex software development.

“This will enable us to have a more informed approach moving forward,” he said. “We recognized we needed to move more toward CI/CDs, and more generic statements of need as opposed to the more prescriptive descriptions of requirements that would constrain our software development efforts. We did some changes there, leveraging the new authorities to enable us to tailor the acquisition process to do acquisition in a more CI/CD like approach. I think we have 11 programs that are currently utilizing it, and we’re looking for more.”

Jennifer Swanson, the deputy assistant secretary of the Army for data, engineering and software, said part of this change will be bringing on expertise from across the Army.

She said Army Futures Command is helping to write software development requirements in a different way to enable sprints of capabilities.

The test community will help improve how the Army accepts automated test data for credit.

“My team is writing playbooks and different things. We have an upscaling curriculum, because we’re trying to build the skills of our workforce,” Swanson said in an interview with Federal News Network. “I would say that the significant shift in RFPs is we are no longer just asking to give me a product. We are also asking and evaluating during source selection phase, how agile are you as a company? We’re going to use really hands-on evaluation techniques during source selection.”

Bang added Army acquisition is creating templates for contracting officers to develop performance work statements and how to schedule software deliverables and payment schedules.

Swanson said the enterprise business systems convergence initiative is one of the first programs the Army is applying this agile and DevSecOps approach to.

She said the solicitation made it clear to vendors that the Army would evaluate their product, but also how well they will adopt to changing requirements.

“We want to see how fast can you adapt that software to our new requirements, because that’s what we need?” Swanson said. “I think that’s a very significant shift. The other thing is, I don’t want something three years from now; I want it now. So we are requiring minimum viable products, which is part of agile software development. The frequency depends on the product, so we’re not going to say it has to be every three months or it has to be every week. But we aren’t going to settle for just one a year, for the most part.”

The Army’s chief information officer Leo Garciga also is involved in the software modernization effort. He recently signed out a new memo about software containers, laying out standards and requirements.

Bang said the next step is around the risk management framework and the moving toward a continuous authority to operate (CATO).

“It’s going to really help us deliver faster, and working with the Army Testing and Evaluation Command and the testing community to not necessarily go back and retest everything, but take a lot of the testing that we were actually automating in our process of development, and taking those and by exception, looking through and testing what they need to instead of, again, testing everything from soup to nuts,” he said.

Garciga, who also spoke at the AUSA panel, said his office is finalizing new application programming interface (API) guidance to help systems share data more easily.

Army’s 3-legged transformation stool

The move toward DevSecOps and agile development is a key piece to the Army’s digital transformation strategy.

Swanson said along with software modernization, the Army’s digital modernization strategy’s goals include achieving data centricity and digital engineering. She called the three initiatives the building blocks of long-term progress.

The Army expects to release a new digital engineering capability in the coming months.

Camarillo said the digital engineering effort is part of the Army’s continuous transformation goal.

“That means that we want to make sure we maximize our investment dollars to provide the best capabilities against the threat that continues to evolve very quickly and very rapidly. What else can help us more do that more effectively than a digital engineering capability that allows us to do everything from identifying tradeoffs in system requirements without the need for developing full of prototypes? The ability to represent a systems characteristics in a virtual environment to be able to understand what are the cost drivers, and assess it in a very sophisticated digital environment to understand what are the performance risks?” he said. “We’re a late adopter as the commercial sector is already there. That is how new cars are designed, developed and manufactured with a lot of these tools in place today. I think the Army has taken some steps in this direction. We have done this with the XM30 [infantry combat vehicle] program by having digital artifacts in digital engineering from all of the vendors in that particular program of record.”

Around achieving data centricity, the Army released three requests for information over the summer and is using that feedback to create a reference architecture that will be included as requirements in future programs.

“We’re partnered with the Army Combat Capabilities Development Command up at Aberdeen Proving Ground with the Command, Control, Communications, Computers, Cyber, Intelligence, Surveillance and Reconnaissance (CI5SR) Center, and we are working in their lab building an implementation of the reference architecture,” Swanson said. “We will validate it and we don’t want to put it out without knowing that 100% it works. That is going to turn into what we’re calling the innovation exchange, which is going to be a place where industry can come and determine is your box compliant. If not, what do you maybe have to tweak to make it compliant? What are some gaps that we have that you have products that we could use to fill the gaps? I think we’ve made a tremendous amount of progress in terms of data centricity in the past year.”

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