Skip to main content

Transcript: Gaining Decision Advantage: Modernizing Air Force Command and Control for Deterrence and Combat

Bryan Clark & Dan Patt

Following is the full transcript of the Hudson Institute event titled Gaining Decision Advantage: Modernizing Air Force Command and Control for Deterrence and Combat.

Disclaimer: This transcript is based off of a recorded video conference and periodic breaks in the stream have resulted in disruptions to the audio and transcribed text.

View PDF

Bryan Clark:
Welcome to the Hudson Institute. I’m Bryan Clark, senior fellow at the Institute and director of the Hudson Center for Defense Concepts and Technology. And I’m here today with Dan Patt, a senior fellow at the Institute and also with the Center for Defense Concepts and Technology. And we are honored to have with us today, Brigadier General, Jeff Valencia from the US Air Force. He is the team lead for the Air Force cross-functional team for advanced battle management systems and for commander control. Thank you very much for being here Brigadier General.

Jeffrey Valenzi:
Well, thank you.

Bryan Clark:
So, we’re here to talk about joint all domain command control, advanced metal management system, a lot of buzzwords and acronyms, and a lot of technical investments that are going towards those. But I think it’s important for us to step back and talk a little bit about why we’re even pursuing new approaches to command and control, why these new investments are necessary, why the DOD is so focused on trying to reevaluate how it does command and control. So, can you start out today just by talking about what is command and control and why is it important to be rethinking how we do it today?

Jeffrey Valenzi:
Well, first of all, thank you for having me and thanks for having this conversation with us. Briefly, just my role, so that it’s clear for everybody is while I lead the Department of the Air Force cross-functional team, my peer is Major General John Olson on behalf of the space force, and then in the acquisition community, Ms. Melissa Johnson, part of the Department of the Air Force, Rapid Capabilities office. The three of us collectively are the lead the ABMS, but we have very specific lenses. The lens of which I apply to ABMS is war fighting. And so, think in the classic sense of how the war fighter articulates the acquisition community, the requirement that we need for future. And then Ms. Melissa Johnson responsibility is then to integrate across the many acquisition entities to go and find those technologies.

Specifically to your question, it’s a fascinating question because it’s been asked many times and the answer is remarkably straightforward. Joint all domain command and control and the Department of the Air Force’s contribution, advanced battle management system is simply about combined arms. It’s a timeless goal of which we have had within the military. In fact, the first instantiation of JADC2 was in 1957, when the army came up with a Pentomic division, and it was the first time they realized that functional alignment wasn’t as effective as combined arms alignment. And then we saw this again in 1982 with air-land battle. And then we saw it in 2010 with air-sea battle. And then we saw the early instantiations of JADC2 and multi-domain command and control, which was General Goldfein, the chief of staff at the Air Force. When he identified multi-domain command and control, as one of his command big rocks, that’s evolved into joint all domain command and control.

What’s interesting is the goal to combine arms has not changed over each of those instantiations, but what’s more fascinating is the mechanics of how we’re going to do it has changed. And today is a different and distinguishable from the past. The Pentomic division, the army tried to solve this problem through an organizational redesign. Air-land battle, doctrine. Air-sea battle, weapons and platforms. JADC2, data. And so we find this data centricity in the same way we’ve seen historically the mechanisms to drive combined arms is the mechanism that we’re pursuing today, which is how do we use data to make better decisions to more effectively combine arms. And so I would just close it up there and say, if you think JADC2, think that it’s today’s effort to combine arms.

Dan Patt:
So, could we zoom in on that? There’s a lot of discussion about decision superiority and maybe how data will drive decision superiority. Can you give us an example when you say decisions, what kind of decisions are we talking about and how exactly is data going to enable those?

Jeffrey Valenzi:
Yes, super good question. Okay, so we right now today, in the Secretary of the Air Force, honorable Frank Kendall has been unapologetic that we are focused on China, China, China, and he is reflecting the Department of Defense’s emphasis as China as our pacing thread. China has spent an enormous amount of time studying the capabilities of the United States in order to do what we call an anti-denial strategy, which is to not allow our archers to get in the range of our arrows. Put in more specific terms. If I have a platform that I need to generate an effect on a target in order to achieve some national security objective, and that platform needs to be 10 miles away from the target to be effective, the Chinese have very effectively pushed us out to 11 miles. Well at 11 miles, my platform’s no longer effective.

So what we have to do is we then have to sequence our military operations to first go after those capabilities that are pushing my platform to 11 miles so that I can move it to 10 miles. How do I know when I can move it? How do I know if my military operation was effective to reduce their ability to hold at risk this platform so I can get it to 10 miles to achieve whatever the military objective is? The way in which we know is how we process and deliver data to a decision maker at the right time, because I may only have a fleeting opportunity to get that platform in and back out with some element of survivability, but yet be mission effective. That fleeting capability is going to be tied to whether I delivered the information to the decision maker, at the right time the decision maker can say, go and they’re right. That’s the decisions that we’re talking about, and they are as complex and as simplified as simply oftentimes it’s a yes, you can go or no, you can’t go.

Bryan Clark:
So, what’s interesting about that is it raises one of the big changes I guess we’ve seen over the last 30 years, is that back 30 years ago, we talked about net centric warfare. We talked about having operations managed at more or less theater level. And we executed some campaigns like that, Kosovo and elsewhere, where you could have senior leaders able to make those kinds of decisions. Where they could get information from the field, determined if the conditions were met to go execute the next step of the operation, and initiate those actions. Here against a China threat, that’s going to be much more dynamic and you’re facing a competitor that’s able to meet you tit for tat. So you’re having to essentially delegate a lot of that decision making further and further down the chain of command, which puts a lot of demands on the sort of command and control systems. So those decision makers have out in the field, which previously had only been resident in these headquarters organizations.

So is that part of what you’re also looking at is, I’ve got to know all the way up and down the chain of command to enable combined arms, empower each of those levels in a way that we maybe hadn’t before.

Jeffrey Valenzi:
Yes. So intelligently empower them and we’ve done the deep bench analytics to understand what that means. So, when I take… And I don’t think I have to oversell the fact that China’s a different threat than we’ve dealt with over the last several decades and the dynamics of that AOR create some different stresses. But what we did is we looked at the stresses of operating in Indo-PACOM and on our current command and control systems that are very mature, they have proven themselves very effective in the adversaries of which we have fought to today. We took the current design and ran it through some really rigorous exercising and modeling and found the point of capacity that it operated at. Then we took an innovative design that somewhat turned on its head who gets to do what. This idea of distributing decisions out to the edge.

So we did it in a very specific way. In this case, we call it the target engagement authority. This is a specific authority that has doctrinal implications, and we moved the design of the target engagement authority. What we found is the new design under the old concept of the type of atmosphere we fought was not the best design. Our current design was the best design. Interestingly though, when we scaled it, there was an obvious breaking point and our current C2 doctrine where this innovative design came out heads and shoulders above. So what we’re seeing is when we get specific, when we really are tied to, and we are unbounded by our current paradise, but we’re tied to the operational imperative, when we turn some of the things on their heads, the insights are overwhelming.

Dan Patt:
So, there’s been a lot of discussion about ABMS in the press in the last few years, and many observers remember early discussions related to JSTARS replacement. And then there was a set of on-ramps, which were very public. Can you tell us a little bit about how Air Force thinking has evolved over the time scale? What have you learned and how does that shaping future direction?

Jeffrey Valenzi:
Yeah. Okay so I’m going to ask you to look at ABMS in three time horizons and we are in the third time horizon. So the first time horizon was the recognition that the Joint STARS did not have the mission readiness rates and the capabilities that we needed against the adversary we were preparing to fight. And so it became the classic, how do I go ahead and build a new version of this capability? There was a fairly obvious epiphany that took place, which was even if I build a better version of the JSTARS, I’m not entirely sure that that’s going to meet the operational demands. This led us into what became phase two.

And this was phase two where the chief architect office in the acquisition authority, within the Department of the Air Force, they looked at this notion of can I engage industry in some innovative ways that allow us to take advantage of emerging technologies in ways of which we normally would not be exposed to? When we think of the classic acquisition process, it’s very cumbersome. It’s very bureaucratic. It’s very slow. We deliver solutions too late. They looked at how can we innovate in this sort of environment, really take it more akin to some industry brush practices and bringing it in. It was a proof of concept. And under Dr. Roper, it was a proof of concept. Can this innovative acquisition approach work? On-ramps in that particular case, were demonstration events to show an unconventional way to engage with industry, to find innovative solutions. That was on the drawing board. At the end of it, the collective answer was we think there’s a better way, there’s a there there, which transitioned to phase three.

This is when the CFT really entered the force. And we were told with the very clear charter, operationalize it. To date, some of the challenges that we had with some of the ABMS narrative is we talked about the widget before we talked about the war fighting. What we have done is turned that around. And what we do is we begin with the war fighting imperatives, understand the system we have, understand the system that we need, and then be very disciplined in this designed. Then there is a technological element to it for the widget. So that phase three is marked by putting the cross hairs on war fighting.

Bryan Clark:
And so one of the things that it seems like are going to come out of the conceptual work that you’re doing, looking at how you’re going to have to fight is metrics for how well I need to be able to execute decisions? What kinds of information I need for those decisions? How does that information get from one place to another? All of that is stuff that I think we’ve in the past, we’ve sort of just accepted. We go build a command control system. It has a certain set of characteristics, and we just live with those instead of stepping back and saying, well, what would I really want the performance to be if I had a really good sense of who’s going to fight? Is that what you’re doing here is that you’re essentially mounting, not a requirements process in the traditional sense, but a requirements process in the sense that you are rapidly evaluating the characteristics needed for the kinds of decision making you need?

Jeffrey Valenzi:
That’s exactly right. We look at three types of measures. We look at how does the system perform? What are its vulnerabilities in its design? And then is it effective? Does it generate the outcome? By the way, that’s the hardest one. Really, really difficult on that one. Performance. So, we’ve narrowed it down to the things that we value. So, one of the things we value has to do with the performance of the system at scale, meaning how much volume can it manage? How much time does it take to complete a task within the overall processing, in order to execute a mission? We care about error rates. How often are we seeing either human induced or systems induced errors? We care about what we call epi-ellipses. This is where the process seems to be moving and then suddenly wraps on itself. And we’ve seen this in very, very often times, we see this.

We care about the proficiency of the performer. So how does the individual interacting with the system? Am I working with somebody who’s brand spanking new, or am I working with somebody who’s the ace of the base? And how can I detect the variance within the system? To transition of vulnerabilities. So, one of the things you mentioned earlier is a lot of the information that we require lives in some pretty exquisite processing centers here in the United States. And I think anybody logically can understand that information sitting in the United States isn’t information that’s changing the outcome of the fight. How do we take that information and move it out there? Sometimes it seems like to be a very obvious answer, which says, well, if you can do the processing there, then just do the processing closer to the war fighting.

Some of the information is extraordinarily processing intensive. It is a very heavy technological bill. To think I’m going to drop that into an F-22, or I’m going to drop that into a carrier strike group, that’s not always going to be the case. So, there’s a measured conversation to be had on what I need for the vulnerabilities to that data. But maybe what we’re finding is oftentimes our access to the data is simply because we don’t have enough pathways. What if I create multiple pathways? And so the vulnerability assessment that we’re starting to see is giving us some very specific understanding of what information do I want forward and what information do I just need redundant pathways.

Bryan Clark:
And this kind of gets to, when you talk about the system, the command-and-control system, which you’re talking about is a combination of a command and controller decision support system. That is something that helps you model simulations and figure out what the opportunities are and what tasks need to get done. And then a communication system, that’s going to be passing information back and forth.

Jeffrey Valenzi:
Exactly. Right.

Bryan Clark:
So, I think sometimes when people think command and control, they think radios.

Jeffrey Valenzi:
That’s right.

Bryan Clark:
But what you’re talking about here is a combination of a decision support system that can manipulate and process data at a certain pace. And then it’s also dependent upon a set of pipes that are carrying that data to and from it or to the next level down in the chain of command.

Jeffrey Valenzi:
So, we look at that through processes and physics. And in fact, when we came into the job and we were told, hey, operationalize it, we realized we didn’t really have any tools to describe what the C2 thing was. We worked really hard within the Department of the Air Force to develop some of those preliminary tools that help us to understand process and understand the physics, the actual moving of the [inaudible 00:16:03]. Really fascinating insights, we got from that. So, we ran this model, and we ran the model against just a single kill chain. So, kill chain means I have a target and I want to generate an effect on that target, and I want to have affirmation that I did generate that effect. So, when we looked at the single kill chain and we mapped it out, it was extraordinarily long. Now, in comparison to ages before it’s lightning fast, in comparison to what we believe we need to succeed it’s woefully under equipped.

So, then we do excursion analytics. And one of the excursion analytics we did was the magic data button, which mean data was infinitely available to anyone at any time, there was no access limitations. And we watched the change in the performance of the system. Interesting, we saw about 1/3 change in the performance of the systems. That was a 1/3 savings. In this case, we measured time. That was the performance measure we were looking at. 1/3 savings in time is nothing to scoff, nowhere close to our threshold. But nothing to scoff.

But here’s what became really counterintuitive to us. We ran it against a campaign. So, we said, what if the system’s under strain? So, it has multiple kill chains at its processing parallel, and it’s got kill chains that are stacking up in the queue. Now, how does the system perform? Excruciatingly poor. But what became more interesting was when we hit the magic data button, because we thought this is where we saw the savings. And where we saw 1/3 savings before we saw less than 10% savings under the campaign plan. To us that wasn’t the outcome we were expecting. And we had to stop and look at and think about it. So, we did what’s called a utility loading analysis, where’s the system burdened? Technology was not the problem. It was processes. And so what we learned in that is that when you break in something as complex as command and control, if you are not talking about the war fighting processes before you’re talking about the physics of movement of data, you’re not going to generate the outcomes you think you’re going to generate.

Dan Patt:
The war fighting problem first and the technology problem second.

Jeffrey Valenzi:
That’s right.

Dan Patt:
So fascinating. So, there is a very strong, popular conception of what Air Force command and control looks like. People imagine an AOC, and there’s a set of people there doing task related to command and control. There’s a system, an AOC weapon system, there’s an airborne battle manager somewhere. As you work through the war fighting side of this, how do you see that evolving over time? What happens to command? What happens to control? When you talk about multi-pathing with communication, how does this change this? What does it mean to move something forward? Where are the people in the picture and the decisions? How do you see this evolving?

Jeffrey Valenzi:
Super complicated question. Thanks for that, Dan. It became unanswerable for us initially, because we looked at the tools that we had available in order to understand what command and control is because you have to start as some brass tacks to get there. And what we realized pretty quickly was our doctrine was insufficient to describe what command and control was. Now, there’s a variety of reasons that we got there. But what we had to do was we realized that we needed a more disciplined approach. And if we weren’t extraordinarily disciplined in our understanding of what we were trying to create, it was very difficult to one, defend the resources, but two understand the operational outcome that you thought you were going to generate off this thing called decision advantage.

So, we broke it down into functions and we used a functional analysis model or a functional decomposition model. It’s an industry best practice that is found in model-based systems engineering. And it’s used oftentimes in many complex systems to understand them. We had not applied that discipline in any measure to command and control.

Dan Patt:
Can you give us just an example of what is one of the underlying functions in command and control?

Jeffrey Valenzi:
Happy to. Okay, so when you decompose it, what you end up decomposing it is into 13 sub-functions. These are 13 sub-functions that begin with the simplicity of what’s my job? And it ends with the simplicity, did I do my job? Now, what we realized very quickly is those 13 sub-functions were agnostic of domain. They were agnostic of organization. They were agnostic of doctrine. They were agnostic of theater. In fact, they’re agnostic of time. They’re just 13 functions: The air component, the maritime component, and every other component uses the same 13 functions.

The next thing that we learned when we start to break these 13 functions apart is it’s not linear. I do step one; I do step 13. It’s actually in the just looking at it on two dimensions. It looks chaotic. Looking at it through a system engineering lens, it’s extraordinarily disciplined. To get more specific. One of the things that we oftentimes expect battle managers to do is what we call match effectors. So, a match effector simply says, before I can generate a course of action, list of possible courses of actions, I need to understand what is my commander asking me to do? Remember everything begins and ends with the commander. I need to look at what is the outcome of the nature of the target that I have. And then what are the list of the tools I have available to me? And it’s a really pretty simple tabular lookup. What’s the best? The best that I have that’s going to give me the most likely outcome to match my commander’s intent. So, when you look at this match effector’s function and you break it into its parts. You do a third-tier decomposition of it. There are actually five sub-elements within how you do this match effector.

What becomes fascinating is this is a case where we came across, that we do this very manpower intensive. And when we looked at it in a very specific way, and this gets a little bit to the man, like where’s this happening and who does it? We learned that machines actually do it better. This one sub-element of the decision-making process, there are software solutions that are out there today that actually they’re really good at table lookup.

The other thing that this gave us the ability to do was build what we call kind of the common engine, which means that under the hood of every battle management node, every command-and-control node is the exact same mechanics, but they can be specialized in how they work within a particular component, how they work within a particular domain, how they work within a particular AOR. This means that ABMS is not defining the design of the next AOC or the next mock or the next MDTF. That is for commanders to optimize how they are going to array those functions.

Here’s what I’ll tell them. I’ll tell them what design is likely to generate the better outcome. So where you put target engagement authority matters, and I’m going to show you the numbers. And I’m going to show them to you in a discipline and a repeatable way. This also really helps us to start having the conversation about, well, what tools should we be given the people? One of the… I’m going to go back to one of the scar tissues in phase two of ABMS. So in phase two, it was oftentimes used tongue in cheek that you can do battle management from an iPad in Starbucks. Stop it. No. It is far more complex than that. It led to a second one, which is, well, just write AI. AI can do battle management. No, we are not designing the man out of the system. In fact, we’re very specifically designing elements within this decision-making process that only an experienced battle manager can do.

For example, when you develop courses of actions and we have a lot of people who come to us and say, hey, I can develop. I have this co-generator, course of action generator. By the way, we haven’t found one. A lot build that way, we haven’t found one. But they develop all these courses of actions. What if none of them are working? If our system is designed that it only allows the system to generate the options and you select A or B and neither A or B are working, then what? So, what we had to build into the system is the power of intuition and experience, which gives the operator ultimately the opportunity to use the system in innovative ways that might otherwise allude the design of the system. That’s a little longer answer, but it’s a really complicated question.

Bryan Clark:
So, this idea of a functionally decomposing the tasks involved in conducting command and control, so it seems like that opens up. So, for one, the idea of instilling all of those into each of your control nodes gives you this opportunity for delegation essentially, and that’s in line with the Air Force doctrine of centralized command, decentralized control or distributed control, decentralized execution.
Jeffrey Valenzi:
Yes.

Bryan Clark:
And also, does it by decomposing those functions, does it mean that different parts, different nodes could do different functions so your command-and-control process could be distributed over multiple nodes simultaneously?

Jeffrey Valenzi:
Yes.

Bryan Clark:
So, it’s not. Because in the past, command and control was largely, you tell a unit that you want to complete a certain task as a commander and that unit, which is usually a multi-mission platform, or an organization just goes and figures out how to do it. But now, if you’re able to do this sort of very finely tuned, precise assessment of what the options are available and then direct some tasks, you can be very specific as to who should do what and you can distribute those amongst multiple units as opposed to having it just be delegated as an entire mission.

Jeffrey Valenzi:
Your question was more insightful than you made. Fully appreciate and here’s why. A military operation is a complex operation of combined arms [inaudible 00:26:11], JADC2, ABMS is about combined arms. And when you look at combined arms, a military operation is actually a family of mission elements. So, for instance, I’m going to put it into air terms because I can speak best there. In order for us to achieve a joint force commander’s desired outcome is I’m going to have to achieve some degree of air superiority for some period of time to give an increased probability of survivability. So, I might have to go after [inaudible 00:26:41] systems. I have to go to radars, communication nodes, a variety of things that I might have to do. That’s a mission. That’s part of this overall campaign. In that mission I have multiple roles. Generally speaking, I have three roles.

I have the battle manager who is helping to execute. Remember, battle manager’s not a bolt on capability, a battle manager’s an integral part of war fighting execution. I have a battle manager who’s in the mission executing. I have a battle manager who’s feeding the fight, vectoring the resources there. Particularly if the resources proven sufficient, they’re going to go find some more. I have a battle manager who’s managing the tanker flow. How am I going to assist?

So, I have all these different roles. Each role does the exact same 13 functions. They’re all the same. So, what it’s called is it’s called a performer model. And what we’re able to do is we’re able to decompose from operations to missions, to roles, to functions. And we now have done the functions. So, we have the functions pretty well programmed in, and now what I can do is I can work with the war fighting entity to say, how do you want to array the roles to achieve the variety of missions that you as a component are responsible for? Then as they disperse those roles, what goes with it is the information exchange requirements that becomes the underlining design element of this thing called this battle network.

And so that’s how we extract those out. This is why we’re agnostic. So for example, the maritime component may say, okay, that role, I want to live on this boat. Okay, I’m not emotional about it. They may say, I want this in the seventh fleet mock, I want this in the packed fleet mock, I want this in the AOC. I want this held way back here in the United States.

Bryan Clark:
But each of those nodes do those 13 functions and each of those nodes are going to be delegated authorities, I guess, as part of the process.

Jeffrey Valenzi:
That come with that role and the functions enable them to then execute that role.

Dan Patt:
So, if I could just pause here, in popular press, one of the big points of confusion about JADC2 has been what exactly is joint about this? Early on, obviously the Air Force took the lead with ABMS and really pointed out that it provides command and controls of service for the larger joint force. But I think the army rightly pointed out that there are many army problems, which for the army by itself, an AOC is a tool set that doesn’t well serve the army problem. So, if this is really combined arms and it’s really about bringing the best of the joint force to bear against our most pressing operational challenges, how do you see what the Air Force is doing, what other services are doing coming together jointly? I mean, does it get back down to that functional decomposition? How do you see that making headway?

Jeffrey Valenzi:
Okay, so first we had to ask ourselves that question, what is the joint problem? Because we oftentimes say, well, we’re trying to improve joint command and control. And so, we ask the question, well, what is joint command and control? And we went on a search for it, and we couldn’t find it. What we do find is very well-designed component command and control systems. So, we ran some tests on it and we looked at a single kill chain, single kill chain closed within a single component. This particular one, we looked at an error component, but that’s not the point. The point was, we looked at a single kill chain closed in the single component, and it was measured in a couple hours to close it. And it was not inconsistent with some of our other insights that we had.

We said, what if to achieve that commander’s intent we had to do a combined arms approach? And in this particular case, we said, what if we had to lean on the maritime component? So now what we did is we modeled it and tested it against an air component and a maritime component interacting with each other. And guess what? They don’t. That kill chain doubled. The time to close the exact same kill chain doubled. The reason it doubled is what we call these epi-ellipses, which is our processes moving and then every time we have to cross over with another organization, we end up having to revisit a portion of the process. What we then learned is – Oh – And people go, well, why don’t you trust each other? It’s not trust.

We don’t distrust each other. When the maritime component comes to us and says, I need help striking this target. We don’t say, well, we’re going to have to do our own exploitation because we don’t believe you. No. It’s that the processes and how we affect decisions, and the outcomes are just different. So, it comes to this functional design. When you use a functionally based design, then wherever that decision has to be made, remember that role in the mission as part of the over operation, the information exchange is now knowable. And now what we can do is regardless of how a particular component erase it, what you create over it is a battle management network that is entirely agnostic. And I would offer probably the first instantiation of true joint command and control.

Bryan Clark:
So, in this functional decomposition, you can then identify, it’s like a standardized way of identifying what the needs are to make decisions, which is agnostic as to domain. So if you are the maritime node, you’re on the destroyer and you’re having to support decision making there. You’re doing those 13 functions. You have a set of requirements for the different characteristics associated with those functions. And it’s the same characteristics that would be associated with the same thing if it was on an air unit or an army unit, is that the idea? And that way, maybe there’s at least a standardized way of defining them. So the numbers may be different, but…

Jeffrey Valenzi:
…the information you value is probably different.

Bryan Clark:
So, you may have different priorities or different specific numbers, but since it’s the same 13 functions, we’ve got the same language to communicate that. And in that way ,you can talk about building a network that is able to share information between those because now you’re not talking past one another, you’re able to identify your information exchange requirements and meet those.

Jeffrey Valenzi:
Right. And so, to go to what we do with this, and it goes to the question, the second part of the question that you asked which is, how are we approaching this? The framework of the approach is not an Air Force framework. This was built under the impetus that General Brown generated when he told all the services to get together and present a way forward with JADC2 from a service perspective. This is not in competition with the JADC2 and with the joint staff J6 does. His question was very specific, I want to know what the services are doing? When we got into the room and started talking amongst my peers. What we realized is that we all have the same imperative. We all feel the sense of urgency. We all want to work together, but we just didn’t have a common framework to guide our efforts.

So, what we proposed was a common framework and the framework is simply this, four parts to it. Part one is we need to start with a common foundation. It’s just how we talk about command and control. It’s surprisingly or maybe not surprisingly a word used in the Air Force for distributed means something different in the Navy. Okay so we just got to align our lexicon a bit. And we needed to come up with some guiding principles and principles are our first filter to start sorting wheat from chaff. So, we came up with operational principles and we came up with technical principles.

Okay, second pillar is we need a model-based approach. There are a lot of models out there. Our advocacy has been to use the systems engineering discipline. And so, what we have done is we’ve gone and spent a lot of time with the maritime component in Indo-PACOM. And we are now driving in alignment in that second pillar which is, let’s just use the same model. And as we go through it and we test the model up against their systems, it helps us to teach and improve the model.
Third, we need a common contextualization of the problem we’re trying to solve. And this comes with our pacing threat is China. We have to extract a pacing scenario because this pacing scenario, we got to get out of big hand stuff. We got to get into war fighting language. We now have that. We did not have that two weeks ago. We have a single scenario that we are all unified and says, that’s the scenario that we’re going to define the problem. This allows us to do the fourth pillar, which is to develop a concept of battle management. Four things, foundation, disciplined approach, set the context and develop a concept. This is how we then inform the development of the TTPs and technologies that we’re going to generate the change.

Bryan Clark:
So, what this brings up is that it’s a very different approach to building command and control architectures than we originally envisioned with JADC2 which is more of a universalist approach that would work in all conditions under all circumstances. This is something that’s much more of a bottom up. We’re going to build this initially around a specific understanding of the situation you’re likely to find yourself in and the associated demands on decision making and communications.

Jeffrey Valenzi:
And the defensibility of where we’re going to invest our nation’s resources. So, Secretary Kendall likes to remind me all the time, what percentage of C2 modernization initiatives have ever succeeded? His number, seven. He’s like your track record Spaniard is awful. And so, when we stood up this team, one of the first things we did is everybody get into history books. Let’s go read about the programs that were successful, read about the programs that were bad. Let’s read about militaries who had to modernize interwar year period, which we are. Let’s read about militaries who had to modernize in war, which we are. And so what sort of lessons are we going to pull forward? So let me tell you probably the number one lesson that we are guided by is you have got to be defensible. You’ve got to be able to repeatedly explain and understand why you want to change a tactic, why you want to change the array of forces, why you want to bring a new technology, why you want to invest a dollar, and if you’re going to do it on PowerPoint and you’re going to do it with cute bumper stickers and cliches, you’re not going to survive. And the system’s going to fail.

Here’s the second: Don’t make it about the model. So today, a large percentage of our conversation is the model. The reason is because we are about to release that model to industry. By the way, we don’t want to keep it to ourselves. We got to give it to industry. We got to let industry help us to improve it. They’re a lot smarter than… We have really smart folks but they’re really, really good at this stuff. If we just stare at the model and all we do is tweak the model, then at the end of this you’re just going to end up with another model, which is why we have to operationalize it. This was the really important arrangement that we have with the Navy now. And the Marine Corps are fully aligned with the methodology.

And a week and a half we’re heading out to the UK, because the UK says we want in, as does Australia, as does Germany and as does Japan. And frankly, this methodology is going to only get stronger when we become more inclusive with our partners. And as General Brown, our chief of staff says to us is we need to be integrated by design. Don’t bolt them on afterwards, make them part of this solution development.

Dan Patt:
So, Secretary Kendall came in with a set of operational imperatives, said, in many of these resilient space, long range strike, counter-air capability, discussion of unmanned support. They all seem to depend on future battle management at some level, it seems to sort of cut across all of those. Can you tell me a little bit about what you’re doing this war fighting lens is intertwined with thought on the operational imperatives?

Jeffrey Valenzi:
You bet. So, every one of those imperatives, which are exactly that, an imperative. And as Secretary Kendall has made clear is if we don’t get these things right, he doesn’t imagine how we’re going to be able to defend our national security interests against China. So, when you look at every single one of those mission elements, whether it’s a counter-air, whether it’s a counter-surface, whether it is readiness, whatever the piece to it, every single one of them depend upon decisions. Every one of them. Which is an interesting element of what we designed.
So, when we look at the ability to use information to generate a better outcome, in most cases, that information has to be somewhat contextualized where it’s used. So for example, one of the principles… Go back to our operational principles. One of our operational principles is distribution, distributed control. So, distribution of battle management in the context of air domain command and control, it’s foundationally different than distribution of battle management in context of space domain command and control. Distribution is still distribution.

Building resiliency through distribution is still the principle we’re going after, but it’s design elements are different. What the OIs do is it takes those principles and allows us to specify them to those different mission elements. In other cases that you’re going to find is by enabling the movement of information, sometimes that information is not to a human, but it’s a machine to a machine. And so what ABMS has the job as a key enabling element across these operational imperatives. Understand how the systems have to interact with each other and how we can provide assured communication from machine to machine. And so, we have that duality in the lens that we look at, which is why ABMS is a single designated operational imperative, we actually spend conversations in every single one of those imperatives.

Bryan Clark:
So the use of model based system engineering is the basis for designing a command and control system. It seems like it’s got a lot of interesting externalities or benefits that come out of that. So for one, it seems like it opens up the possibility for innovation and creativity on the part of operators, which I think might be counterintuitive to folks that don’t think about command and control. But the idea that you’ve got a way of defining precisely what information needs to go from where and what decisions need to be made where, means that you can measure the impact of someone creating a new course of action that was not suggested to them by their decision support system. So an operator on the fly saying, well, maybe we should do this instead. Plugs that into the system. We can, and obviously in a simulated environment, see how that plays out and does that improve the performance and the outcome or not. But without that model-based systems engineering, it seems like you don’t have that precise way of evaluating the impact of that creativity and figuring out how to empower it.

Jeffrey Valenzi:
That’s right. So, the rigor of how we eventually say that we have a good understanding of a solution to solve a problem. The model-based system engineering becomes a foundation for it, but of itself, isn’t it. So, when we look at our model-based system engineering approach, which gives us the ability to describe the performer relationship, the information exchange requirements, it is then paired with some model simulation and analysis tools that help us to understand the potential delta. So, what we can do is I can now in a digital environment, I can throw ideas at it and then just play with the numbers.

When we get to something that we go, I think there’s a…we will then work across our partners into what we call the battle lab network. Our battle lab network is a network of laboratories that for the Air Force, our contributions is shadow operations center Nellis, which is out at Nellis Air Force base, part of our warfare center. But we plug in with the army’s JCAL out of Aberdeen. And so, as we grow this network out, what we then do is we take our anticipated outcomes and we put it into the lab with real operators, real tools, contrived scenarios. And then we go, did we get the outcome we expected? If it’s a yes and a yes, we got ourselves a solution that we’re going to go after.

Bryan Clark:
But it opens up the possibility in practice. If this is out in the field actually being used, that model based in systems engineering approach could also then help you define those sandbox if you will. So what’s the extent to which I will allow the operator to independently modify or develop their course of action within? What are the bounds of that? Because right now we don’t have that. It’s just sort of, if you’re going to exert mission command and do something on the fly, it’s totally on you, but you could maybe have a better way to help guide the operator in this case.

Jeffrey Valenzi:
So, what you’re describing is what we call battle management of battle management, which is how can we do that? So, if we create this network of nodes that has agility inherent within it, how do we then manage that agility? And this gives us the idea of how we can innovate within the system because we got to allow those innovations but then have the system adjust and learn from that. Same goes for when the system’s underperforming, if you’re a battle management node and you’re having a bad day or the adversary is denied you access and Dan and I are dependent upon you doing your job, we want to know that you can’t do your job anymore. And then we got to figure out who can do your job. So that gets into the age of digital twining and that is super complex. I am not nearly smart enough to describe it other than to say, ultimately, we could imagine ourselves in a place that sits on this network and actually monitors the performance of the network.

Dan Patt:
So you mentioned polishing the history, dusting off history books, reading up about this, focus on interwar period. When I think of an interwar period, I think about a time of vibrant operational concept development, experimentation with tactics. And I mean, history shows us force employment, how I’m using my forces is ultimately more important than what the systems themselves are. How do you see ABMS supporting or driving the Air Force to experimentation in operational concept, new ways of fighting?

Jeffrey Valenzi:
I don’t know if I would necessarily cast us in that large of an impact. Although, I do think that there’s a merit in the approach that we’re developing. I would love to see people catch on to this kind of disciplined approach. But interestingly, when you pull back the shades of history and you look at interwar innovation, more often than not major nations during interwar periods became very entrenched in their current paradigms. Probably the best illustration is the imaginal line. And where other nations that, and there’s very few by the way, that really truly innovate in… One of the best illustrations is the blitzkrieg. And so, you take those two in the same period of time, and two different nations approached them two different ways. In one, generated incredible outcome and the other was incredibly disappointed with the outcome.

Dan Patt:
And they each have tanks, radios and airplanes.

Jeffrey Valenzi:
But they had the same tools, and you can’t let the Brits off on this too, because they became very entrenched in the same period of time to maybe not necessarily recognize the full power that these new capabilities were delivering. When you look at interwar in modernization, it typically gets driven by business practices of the institution. And the business practices oftentimes become very protective of the current paradigms because a business practice is trying to manage risk on the institution. And it has political factors it has to take into consideration, has economic factors. I mean, there’s a lot of reasons why that system exists.

Secretary Kendall’s turning that on its head right now and his driving us with more of a wartime impetus. But see, here’s the thing in the wartime impetus is the wartime impetus becomes war fighting centric, not business practice centric, its war fighting centric. And that’s what we’re seeing in this shift, which is giving us this open field to start to innovate the ways in which we drive modernization initiatives.

Bryan Clark:
But I think Dan’s point, having a system like ABMS as you’re articulating it, allows you to start thinking through a lot of different options for force packaging and concepts of employment and matching up factors with different targets and looking at things outside of potentially the normal basket of kill chains that we would have executed. So, it seems like what you’re doing is you might be empowering a set of innovators operationally within the service to go and come up with new ideas that could be exploited in a future conflict. So, it’s providing that foundation it seems to be able to support that operational innovation.

Jeffrey Valenzi:
I would like to think, yes. So, one of the boundaries is we don’t trundle into designing new weapons, new platforms, new sensors.

Bryan Clark:
No, but different ways of combining what you have or composing what you have. It may be non-traditional combinations to say, well, this is something that an opponent may not expect. And therefore, it may have a surprising level of efficacy because they didn’t anticipate that. Well, I think that’s a great place to leave it because I think one of the biggest challenges, we’re facing today is a China threat that is increasingly appearing with a large military that’s technologically capable. And increasingly we’re going to have to rely on operational innovation to get our edge. And it sounds like what you’re doing with ABMS is going to help empower that and enable the best combination of forces in the future to be able to accomplish tasks. But thank you very much for being with us General Valenzia and sharing with us your thoughts on command and control and ABMS and JADC2.

Jeffrey Valenzi:
And I’ll echo the thanks back to you guys. And I’ll reiterate the fact that we’re not trying to do this alone. And so this sort of partnership, our partnership with industry is really important and how we bring all the minds together because we’re all focused on the same problem. And so thank you.

Bryan Clark:
Thank you.

Dan Patt:
Thank you.

Bryan Clark:
And thank you all for being here today from the Hudson Institute, have a great day.

View PDF

Related Articles

Beijing Threatens US Dominance in Space

Arthur Herman

Arthur Herman appears on NewsNation to discuss how NASA can compete with China's rapidly accelerating space program. ...

Watch Now

Here’s How the Two-Year-Old Abraham Accords Can Help Solve Today’s Biggest Challenges

Robert Greenway & Jacob Olidort

Today, Sept. 15, 2022, marks the second anniversary of the signing of the historic Abraham Accords agreements on the White House lawn. With war in Eur...

Continue Reading