Let me quickly break some things down. When we entered into the late Cold War and systems for the military especially the Air Force became complicated integrated systems of systems. We call it a fighter but what is it really it’s a stealth airplane with a complicated radar with a complicated weapon with a complicated mission computer all integrated together to act as one thing. All of that integration drove a lot of risk into programs slowed them down, which is what’s led us today to programs where we put the prime and we use that company — it’s kind of ironic we’re calling our programs prime programs but maybe there’s some sense in that irony — we drive the mandate to the prime that sub allocates it to companies that are providing subsystems and the prime had to integrate it all together so that we get that war winning capability at the operational edge.
It’s trendy in this building over here to talk badly about the primes, and say you know, ‘hey we’ve got a war winning Air Force today and they built it so let’s remember that,’ but it just doesn’t make sense to keep doing business that way we once didn’t do business that way we migrated to it because technology mandated at the time now we can migrate from it because technology has changed again. How do we create the new relationship we’ve got to adopt digital design practices so digital engineering, agile software development including containerization kubernetes that help us abstract code from the environment on which it runs which will allow a lot more software companies and AI companies to engage with the Air Force and Space Force and finally just use open standards like commercial industry does so that you can break up parts of the program.
Now what will that do for you a deep tech company in future? Well, you probably are not building the prime platform — you’re somewhere down in the subsystem. So in the past we would work vertically with you we would put the prime on contract and then money and tasking would trickle down to you. This new paradigm that’s digitally based we’re working horizontally you’ve got a direct relationship with the government to plug your deep tech in whether it is AI-driven or hardware-driven inside a government reference architecture that we control — effectively our digital modeling tools are the integrator. That’s not something we have to make us. That’s coming to us courtesy of commercial industries like automotive and you know formula one racing. I can go on [about] industries that have moved entirely digitally we’re just simply riding their coattails and learning their lessons.
What that will mean in defense is you having a direct relationship with us [the government]. You don’t have to master defense contracting and procurement. You don’t have to master integration. You simply have to master your technology, and we incorporate it in. What should that mean? It should mean that our platforms our systems become ecosystems of continual competition. If you can build a better application, a better component, a better hardware extension of our system, it should plug and play just like commercial technology does.
Why doesn’t it do that today it is that complicated integration it’s all of those layers down and down and down that don’t have the benefit of that digital technology today. That is a long answer and I apologize for it, but it’s really the answer for why it is so hard to plug and play in defense systems, why we don’t work with amazing agile deep tech companies today, and why we have hope that we can in future.
That was from a very interesting Ask Me Anything with Air Force acquisition chief Will Roper on Oct. 26, 2020, Deep Tech and Skyshots.
Of course I am completely aligned with Roper in this way. He’s walking the walk in terms of getting digital competency through the software factories, which is a critical enabler to successful execution of the vision: disaggregating systems, government owning the technical baseline, proceeding incrementally through modular contracting, and standing ready to move significant funds to when they are needed.
Redefining a Program of Record
Roper is really redefining what a program of record is. It isn’t a specific technical plan to field a major system that will be produced in quantity. Roper’s programs are really portfolios of modular projects or competitive projects. That’s certainly true of Advanced Battle Management System, which also builds on the software factories, but it’s also true of Next Generation Air Dominance. It seems the intention that the same NGAD budget line item will result in the digital-century series — a variety of aircraft and subsystems developed in the ecosystem.
Is that possible? Will the oversight complex allow that kind of portfolio management? Won’t each aircraft and subsystem project have to become it’s own budget line item, like an F-35, F-15, or F-18? When managing through iterations, speed, and keeping options open, that means there’s not an articulated life-cycle plan that can be measured against. It also obfuscates programmatic insight from Congress and even the higher levels of the DoD. It is for these reasons and more that ABMS and NGAD struggle to get the kinds of dollars traditional programs can secure more easily.
I think Roper is right and the oversight complex is wrong. I doubt he would frame it that way. At some point, for Roper’s programs to survive over the years and replicate, there has to be an oversight reckoning. Rather than fixing requirements for a decade and measuring cost and schedule growth to APB, the oversight agencies should review the history of the 1950s and before, which I would characterize as an insight and investigation approach. Let’s talk about accountability in the 21st century.
Where I disagree
One area I disagree with Roper is how he set up the discussion. He also said this in Steve Blank and crew’s Stanford class — That the DoD’s system worked well after World War II when it was building systems, but now they are systems of systems. I think he’s primarily thinking about software and electronics integration, but also physical attributes (“stealth”). But it’s hard not to say that the Polaris IRBM integrated onto a nuclear submarine was not a system of systems. And sure, there wasn’t any software, but for the time the computers and electronics were at the frontier.
Progress seemed faster at that time not because they had yet to bump up against “systems of systems” and software which was found in the 1970s/80s, but because the culture of management was different.
I think Roper is actually harkening back to an older way of weapons development. In the 1940s and 1950s, there were strong in-house offices that disaggregated systems and encouraged an ecosystem of interchangable components and subsystems. Letter contracts were pretty normal, there was ample competition in industry, and emphasis rested on speed.
All that changed when Robert McNamara took the helm and installed the Planning-Programming-Budgeting System — which continues to survive. Without this modern defense acquisition system, there’s a non-zero chance that the today’s DoD’s management would much more closely reflect commercial industry.
Leave a Reply