One of the things that the Department has an issue with is putting something out there really fast and really bad just because we need the capability, but we don’t take time to really think it through and operationalize it, or we don’t do an incremental capability where we build up the full capability over time. From a prototyping perspective, we are able to break things down into smaller chunks in order to build up a capability. That’s one of the things we’re really looking at from a software perspective. DevSecOps is an area where commercial industry is moving forward very fast, and have essentially done a cultural overhaul from the traditional waterfall methodology into DevSecOps methodology where you have the end user involved in the development process. We are looking at that very strongly.
One of the issues we have from a DoD perspective is that it has to be deterministic. Our acquisition system does not support a non-deterministic process where you don’t have the full vision of what the requirements are prior to letting a contract with industry. And commercial industry can do that, but DoD needs to know ‘what are they going to get, when they’re going to get it, and how much is it going to cost.’ That’s how our acquisition system is set up. So there’s a lot of overhaul that needs to be done on that.
The thing about getting acquisition and programs out there quickly, and correctly, is really focusing on looking at capabilities and then increasing those capabilities over time. That’s the way I’d like to see it. We have too much in-fighting between where the mission area is and whose going to be developing that capability for a specific use rather than a joint use.
That was Timothy S. Dare, Deputy Director for Developmental Test, Evaluation and Prototyping within the Office of the Under Secretary of Defense for Research, on the Defense & Aerospace podcast.
It’s good to hear people talking about the acquisition system in that way. Dare’s in USD(R&E), so no surprise. How about USD(A&S) and their efforts to revamp the acquisition system?
There’s a lot to like in the Adaptive Acquisition Framework, but I’m not sure it actually gets to the core issues Tim Dare is talking about with respect to the demand for determinism. It seems like a half measure — perhaps the best OSD could get under the circumstances. Programs still need complete determinism in terms of lifecycle costing, sustainment planning, IP strategy, some kind of fixed requirement, etc., but then they are expected to iterate and do DevSecOps. A recipe for Agile-Fall? I’ll be interested to see how it gets implemented.
One thing about the “in-fighting” about mission areas, and specific service use rather than joint use — You might think that “joint” warfighting at the Combatant Commands, alongside true DevSecOps where warfighters are brought into the development process, would lead to “joint” technical solutions. Right? So isn’t a cultural commitment to DevSecOps a precursor to the services developing joint capabilities?
Leave a Reply