LAUREN C. WILLIAMS
The Army’s digital transformation in recent years has centered on improving networks, cloud computing, and data. Now, the service wants to rework how it handles software development—by centralizing and simplifying it so mission-critical programs are updated quickly.
But what does that mean for buying, developing, updating, and patching software?
Defense One sat down with Jennifer Swanson, the deputy assistant secretary of the Army for data, engineering and software, to learn more about the Army’s software development shift and what that means for program managers and industry.
What exactly does it mean to no longer put software in sustainment, and why is it significant?
Starting in October of this year, we will no longer transition any software to [Army Materiel Command] for sustainment. So, that's a done deal. The money associated with that will stay with the [program managers], and the responsibility to do whatever they need to do from a sustainment perspective will be theirs starting in October. We are not going to pull systems out that have already transitioned AMC for the most part. But things that are not there are not going there.
What does this change mean for program managers?
I think it depends what stage of life the system is in, what needs to be done, and if there's requirements to add more capability. For our newer systems, there will be no sustainment phase at all because it's not part of [continuous integration, continuous delivery, and continuous deployment]. The model for CI/CD [means] the traditional things that we do in sustainment—like fixing problems, cyber patching, that kind of stuff—that happens in releases along with additional capability…and you're putting out releases very frequently. You're doing all of the things that need to be done, whether it's adding capability or a cyber patch, in a single release.
For systems that are nearing the end of their life…and you don't really have a need for further capability, at that point, I think we will make a decision with the requirements community, with [Army Futures Command]. If there's more capability to be added, then we will look for different kinds of money to be able to do that. If not, then the PM will own the responsibility of doing whatever sustainment functions, like fixing and cyber patching, that they need to do.
Upgrading and developing software is not a new challenge for DOD. How will this be different?
What DOD has done for us is enabled us to do what we need to do to make this work. From a money perspective, and we are exploring this with DOD…we believe that because we have made the decision not to transition software to sustainment anymore, that we can actually use BA-07 RDT&E [funds] for software. BA-08 provided the ability to use RDT&E for operations and maintenance functions. But if we're not transitioning software to sustainment, we don’t need that anymore.
What else makes this shift different?
We have spent the better part of a year with a lot of senior leaders’ support [for] changing a lot of processes around software. Why has this failed in the past? Because I think it was viewed as something that the PM could just do—just be better, develop better software, write your contract better. But the requirements were not written to enable agile software development. The testers were not enabled to do agile testing. Everything was as it was, and then somehow it was supposed to just magically get better.
There has been a lot of effort, led by my office, with tremendous support from [top Army leaders]... that has allowed us to change some very key things. Number one, from a requirements perspective, and we've been working on this with [Army Futures Command] for the last nine months or so…we believe we'll be ready to start leveraging [software initial capabilities documents and capability needs statements] this month. That's really game changing, because instead of giving us a 200-page document, which is kind of how we've operated for a long time, it will be a short, pithy high-level “this is what we need” [document].
The other piece of the requirements process that is changing is that AFC is on board to partner with FORSCOM, let's say our operators, and we will have a team that will help us to refine that requirement in development sprints. We've never done that before. And that's how agile works, right? You need the people that know the requirements to be with you and development that can help you prioritize the backlog and refine the requirements as you go. And we've never done that before. I think that's pretty game changing.
How will simplifying requirements affect vendors?
We are already changing contracts in terms of how we're asking industry to deliver products. One big shift—and we did this with Enterprise Business Systems-Convergence, as a good example. EBS-C is a big business system that's swallowing up much of the legacy business systems—General Fund Enterprise Business System (GFEBS), Global Combat Support System – Army (GCSS-Army), Logistics Modernization Program (LMP), and AESIP Hub—are all being subsumed by EBS-C.
When we wrote the requirements … for EBS-C, we put a lot of gates in there that allow us to evaluate…with orals and demos, not just a written document. No more just written proposals. There will be parts in writing, obviously. But there will be a “show me” component, whether that's oral or that's a demo, will depend on the program. But there will be a “show me” component to proposals. And so that's something that vendors are seeing now much more out of our office.
The other thing is that we're not just evaluating the solution, we're evaluating the company's ability to be agile, because that's where we have stumbled in the past. So, you can show us a shiny solution and a demo. But if we give you new requirements, how fast can you turn those new requirements into a new release? And that's part of the EBS-C prototyping activities that are happening now. I think that's pretty significant because it's really sending the message to industry that it's just as important for you to have the right team and an understanding of agile software development and then CI/CD as it is for you to have a good solution.
Which projects or which programs are going to see this agile shift?
Software, heavy programs. All of them. The software-based programs that are going out with requirements are moving in this direction.
If you have a significant software development component, this is what we're doing. Now, if your software component is strictly buying commercial software, then it might be a little bit different. But this is really about software development and how much of that is there in your program.
What else is important about how the Army is thinking about software development?
Things are moving much, much faster. Software material release, for example, which used to be a pretty long process that required a whole bunch of documents and artifacts and a whole bunch of stuff, and was actually managed by AMC, because software was transitioning to sustainment. Starting in [FY]24, that will not happen anymore, either. The PEO will have responsibility for their own software material release and they will only need to provide the artifacts that are statutorily required. We've really slimmed down that process. Today…it takes months to get a software release. It should take a day or two.
Army interoperability certification testing, which every software program has to go through…has also been radically simplified. PEOs there also will have a lot more ownership of what they test and how they test it. And we’re moving, by the end of ‘24, towards a cloud-based AIC capability.
All of these things are things that take a very, very long time to do today. The theme is how do we simplify everything that we can to make it take as little time as possible.
What does industry need to know about that?
I think industry is going to need to get the right people on board that understand this kind of software development. I've talked to many of them and I think there is certainly a gap in our defense contractor[s] ability to hire and retain that talent. And I know that they're looking at how to fix that because they see that this is coming. The truth is that there's a gap because we, DOD, in the past, haven't really prioritized software; we've been okay with what they've been doing. So, why change? Well, this is happening.
Where do you see the state of Army software in the next six to 12 months?
We will start to see some of our programs that we were already able to influence, like EBS-C, starting to deliver, which will be very exciting because it will be much better than what we had before. But we will continue to learn, I have no doubt. We will take what we can, the successes from those programs, and capitalize on them. And things that didn't work like we thought, we'll adjust those.
A lot of the obstacles to CI/CD that I talked about, like requirements and test…will be fixed because we have a ton of momentum right now. We've already fixed a lot of them, so I think we'll continue to do that and I think those things will be codified.
We have draft contract language that our PMs have access to, for how to write RFPs the way we want to write them today. But that will continue to evolve.
From a contract perspective, we're getting a lot of help right now from Army Contracting Command at Aberdeen Proving Ground. We are gathering information that will be provided as guidance to PMs in very short order, in terms of what types of contracts should you use for software. We're working closely with Danielle Moyer and Meg Dake and her team to try to provide that guidance in terms of, OK, not firm fixed price, but what? What are the best ways that I can buy sprints? And how do I hold contractors accountable? Because that is a piece of it: if they don't deliver, how do I set this up so that I can make sure that I'm not paying you to do something and then paying you to fix it? So, there's a lot of activity and I think certainly in the next six to 12 months, we will have that figured out.
No comments:
Post a Comment