Here’s a bit from Gen. Hawk Carlisle (ret.) at a Hudson Institute event discussing JADC2/mission integration with Brian Clark and Dan Patt:
How you design, how you build these systems has to begin with — and everybody’s brought it up but we’ll say it one more time — we’re in a 60s era McNamara PPBE process, planning program budgeting execution, that is just absolutely unacceptable. The good news is in the Senate mark of the [FY]22 NDAA. They won’t want to change that system. The Department can’t do it we know that, and I’m not sure Congress can — you can hope they can but how do we do that to incentivize integration from the outset not after-the-fact when it gets fielded? Then, by the way, we need them to work together. How do we do that from the beginning?
We did some great things. Like Eric [Wesley] and I back in the days of the ROVER where an MQ-9 video went down to a soldier in the field — which was fantastic, it was a great integration of air and land power — but that was after-the-fact and it’s when we’re already engaged in Afghanistan. So why didn’t we design that in at the outset? I think that’s the key component of moving this forward.
Be sure to listen to the whole thing.
Carlisle argues that after-the-fact integration is a sign of failure in the requirements, budgeting, and acquisition system. In the case of a technology solution for directly feeding drone video footage to soldiers on the ground, it should have been designed from the start to support operational needs. Service-developed budgets, looking inward at their own domains, are a root cause of ROVER not being available from the start.
I find this argument to be steeped in hindsight bias. If ROVER wasn’t anticipated as a requirement back in the 1990s, then why should the next critical mission integration task be predicted by a new generation of people? The next critical need will almost certainly not be an enhanced real-time feed of drone footage.
In my mind, the lesson to draw from the ROVER example is that we should assume that our ability to predict future tech and requirements is imperfect and instead build in capabilities for on-demand mission integration. This should be even more obvious considering there never would have been an MQ-9 over Afghanistan in 2001 if it went by the requirements-led process. The Air Force had no requirements for UAVs until a functioning version was thrust upon them.
It’s actually quite impressive that soldiers started receiving drone footage within a year. Carlisle even said so. That after-the-fact integration should be considered a success. But it would have been even faster if DoD had regularized and funded the real-time mission integration task, as well as rapid acquisition of commercial technology.
By the way, here’s a little bit about ROVER:
The initial ROVER system, ROVER I, was developed in 2002 to allow ground forces to view video feeds from Predator UAVs or AC-130 gunships. The interface was so large it was carried in a Humvee, but it avoided the long delay of having to call a distant UAV controller and ask what the aircraft was seeing. By fall of 2004, the system’s size was reduced to that of a 5.4 kg (12 lb) device carried in a backpack. ROVER IV plans to include the capability to interface with a wide variety of aircraft and also allow interaction between ground controllers and close air support pilots.
In my view, much of the discourse on JADC2 seems to focus on identifying fixed standards/interfaces and designing a set of systems that will compose articulated kill chains. However, this limits the opportunities for new types of systems because they have to conform to the existing standards. General Hinote put it well on ABMS at a previous Hudson event: “We don’t know is what we’re going to buy in 2027. And if I was going to tell you, I could tell you I’d be 100 percent wrong about that because I don’t know exactly what the world looks like, especially what the commercial networking world looks like in 2027.”
The alternative approach is the federated model. Systems are developed as part of anticipated kills chains, and at times according to the engineer’s own requirements for interfaces, but the integration for warfighter use is the next stage of the delivery pipeline rather than baked in from the start. This requires dedicated funding mission integration cells that work closely with the combatant commands. They can use the suite of DARPA tools to translate data between the federated sensors and shooters at the point of need.
The federated approach is perhaps the most realistic based on the complexity of the systems and operations DoD as a whole must manage. It does not require exquisite prediction, as is often called for by proponents of JADC2 centralization.
One of the things for me is pushing the mission-command concept into acquisition. Carlisle mentioned as part of his discussion on command and control that it can’t be centralized:
One of the challenges is it can’t be centralized like it is today where you have the White House watching the takedown of Osama Bin Laden from the situation room because we know our adversaries are going to attack our ability to communicate. So what does it look like when you’re out there in mission-type orders and then you don’t have access to that to that communication network and you may have limited access to the data?
Similarly, in the JADC2 context it is our uncertainty about future states of technology (or future requirements for standards) that means DoD cannot centralize decision-making about weapon systems and how they are composed into force packages or kill chains. The federated model of acquisition works best because it is based on sound principles found in how markets, science, and warfighting works.
During the same Hudson event, Adm. Scott Swift (ret.) also argued against the federated approach to JADC2 and budget building:
One of the problems we face is that traditionally, we allowed the services to develop in a federated manner the capabilities that they need and then we integrate them at the point of need. The problem is that that will not suffice because we have to have a common framework for how we’re going to fight which should drive service budgets. Right now, service secretaries are not incentivized to budget in accordance with a common concept because the common concept hasn’t driven the budgeting process just yet.
To bring it home, I would just say that the whole point of PPBE was to create a joint warfighting concept which would then drive the requirements for service budgets which leads to weapon systems. Several generations of incredibly smart and dedicated people have largely failed in that effort to connect budgets to military plans. If they did not fail, then way are so many folks complaining about the poor state of acquisition and the force structure? The PPBE threw out the good in search of the perfect.
Of course, it is not our predecessors’ fault. Bad processes beat good people every time. The cognitive requirements for people to predict 5, 10, or 30+ years into the future what technology and CONOPS will be is simply beyond anyone. DoD must consciously design processes that embraces the inarticulate nature of the future, the dispersion of knowledge, and the idea that exchange is more important than allocation as a paradigm for economic activity.
Eric, in support (for a change!) of your main point, allow me to share this excellent paper from 8 years ago by my friend and colleague Prashant Patel: “Prepare to be Wrong”.
https://www.ida.org/research-and-publications/publications/all/p/pr/prepare-to-be-wrong-assessing-and-designing-for-adaptability-flexibility-and-responsiveness
Another piece of the “bad incentives” problem is that the perceived difficulty of starting a new major acquisition causes people to want to get every last ounce of performance out of the new platform from the beginning. That leads to platforms that (1) have the wrong set of capabilities for what we turn out to need, and (2) have no engineering design trade space remaining that would let you fix that quickly and cheaply, or perhaps at all. It isn’t an accident that all of our past flexibility successes started out as cargo aircraft or tactical vehicles — they had the SWAP headroom needed to add new capabilities later by trading away some payload. The opposite extreme is the F-22, which is exquisitely designed (hardware and software) to do one precise thing that we no longer need, at great cost — and that is almost impossible to alter because of the anti-modular designs.