Making JADC2 Work

Show Notes

In this episode of From the Crows’ Nest, host Ken Miller revisits Joint All-Domain Command and Control (JADC2) and sits down with Bryan Clark and Dan Patt from the Hudson Institute to discuss their new report, “One Size Fits None: Overhauling JADC2 to Prioritize the Warfighter and Exploit Adversaries Weaknesses.” 

Ken, Bryan and Dan talk about the need to think differently about JADC2, an ambitious and potentially costly vision that may miss the mark when it comes to its primary customer – the warfighter. As technology changes at the tactical edge, the Defense Department must change the way it conducts business and implements potentially game-changing capabilities for the joint forces.

Creators & Guests

Host

Ken Miller

AOC Director of Advocacy & Outreach, Host of @AOCrows From the Crows' Nest Podcast

Producer

Laura Krebs

Editor

Reese Clutter

What is From the Crows' Nest?

This podcast features interviews, analysis, and discussions covering leading issues of the day related to electromagnetic spectrum operations (EMSO). Topics include current events and news worldwide, US Congress and the annual defense budget, and military news from the US and allied countries. We also bring you closer to Association of Old Crow events and provide a forum to dive deeper into policy issues impacting our community.

Ken Miller (00:09):
Welcome to From the Crows' Nest, a podcast on electromagnetic spectrum operations or EMSO. I'm your host, Ken Miller, director of advocacy and outreach for the Association of Old Crows. Thanks for listening. On this episode, we return to the topic of Joint All-Domain Command and Control or JADC2, and I'm pleased to have back with me on the show, Bryan Clark, from the Hudson Institute, and his colleague, Dan Patt, also from the Hudson Institute.
Ken Miller (00:33):
Bryan is a senior fellow and director of the Center for Defense Concepts and Technology. He is an expert in naval operations, electronic warfare, autonomous systems, military competitions, and war gaming. Dan is also a senior fellow with the Hudson Institute's Center for Defense Concepts and Technology. His experience is at the intersection of technology, business, and national security strategy. His work at Hudson focuses on the role of information and innovation and national security.
Ken Miller (00:58):
Bryan and Dan, it's great to have you on From the Crows' Nest.
Bryan Clark (01:00):
Yeah, Ken. Thanks for having us on. Obviously, we're big fans of the AOC and the podcast.
Ken Miller (01:06):
Both Bryan and Dan, you recently released a new report, entitled One-Size-Fits-None: Overhauling JADC2 to Prioritize the War Fighter and Exploit Adversaries' Weaknesses. Fantastic report as always. On From the Crows' Nest, we've talked about JADC2 on several different episodes trying to look at it from different perspectives. One of the things we typically walk away with is, "Great concept, but how do we do it?"
Ken Miller (01:34):
How do you actually get this into some sort of working effort? Your report basically addresses that. It seems that the basic concept or premise is that for JADC2 to be successful, we need to rethink the model we're using. Could you tell us a little bit about the report and what went into it and what were your thought process as you started out?
Bryan Clark (01:54):
The reason we started this project and wrote the study was largely because we were frustrated with the JADC2 approach of trying to boil the ocean, if you will. We're trying to solve all interoperability problems across the entire military, for all situations, in all phases of war. That's even how the JADC2 strategy describes their objective. It's a universalist approach to try to solve everything when it comes to connecting sensors, to shooters, to commanders to make decisions, which is very ambitious and probably not likely to result in success. And if it does result in success, it'll take decades and billions of dollars and we probably will find at the end, we didn't really solve the problem we intended to solve at the beginning. That was the fundamental problem that we saw with it.
Bryan Clark (02:41):
The reason we talk about this idea of thinking of it as a market place, or thinking differently about the framing of JADC2 is to try to focus it mostly on the customer. The customer of JADC2 is the combatant commander or the operational commander in the field. He or she needs these joint forces to be able to operate together and execute effects chains out in the field when you're actually fighting an enemy in some real combat situations. Those operational challenges that they're trying to solve, those should be the ones that the JADC2 effort focuses on. But instead, the JADC2 project is really designed around an industrial model where we're going to, back in the Pentagon, devise a set of standards and requirements that will result in eventually the force reflecting the kind of interoperability it needs to have. So that poor commander in the field will eventually be able to get a sensor that talks to a shooter and talks to a commander. Which... That industrial model just doesn't work anymore for DOD in the 21st century.
Bryan Clark (03:41):
I'll turn over Dan, to talk a little bit about what some of the implications of that are, the fact that we need to shift from an industrial model to maybe more of a customer oriented model.
Ken Miller (03:50):
Yeah, Dan, a lot of your work there has really carried over how we can apply some of what we know about the commercial sector and the marketplace into DOD and changing the way of business. Could you build on some of what Bryan said there?
Dan Patt (04:04):
Bryan teed up a pretty rich set of topics. I'll start though, and thanks for having me on. My inaugural appearance here, so appreciate that.
Ken Miller (04:14):
Your inaugural, but not your last. Just know what you're getting in for here.
Dan Patt (04:17):
Well, yeah, it's a little early to make that judgment, I think. Just wait till you hear my answers. On this topic, if we zoom out, the internet is this amazing thing that dominates the economy. It dominates our lives. If you look at the S&P 500, and you look at the companies at the top, all of these big, so-called tech companies are really internet companies that have found ways to capitalize on the tremendous value that can come out of this. And I think it's really natural for the military to see that and recognize that same set of trends and that same set of technology will very clearly be very important for military application. It's not exactly a new idea, but I do think it is richer.
Dan Patt (05:00):
As we see it transforming the economy and our lives, it's very clear that the time is right for this, but I think the danger comes when we try to just directly map that analogy. So there's this idea that in as much as there's internet and there's this internet of things where there's all these connected devices that kind of work together and help us out in our lives, that we can have the same thing on the military side. You can have this military internet of things, and it's going to kind of work the same way. And if you believe that, the right thing to do would be figure out, well, what's the right architecture? What are the common standards and how can we get people to adopt that so it all works together? It's really, really logical.
Dan Patt (05:39):
Why doesn't it work? Well at the bottom line, the reason that it doesn't work, you can actually tell by looking at the evolution of the internet itself. The internet, didn't start with some architectural design, trying to figure out how to get people to watch cute cat videos and run [danding 00:05:56] apps on it. It didn't start with that architectural design. It actually started around some really pretty simple use cases. There's this thing, it's called Gall's Law, and it states that all complex systems that work evolve from simpler systems that worked.
Dan Patt (06:11):
This actually shows up. Every commercial tech company that does these amazing things, they all start from really, really simple use cases. This is what investors tell companies to do. Start with a really simple use case. Defined cloud computing didn't start by trying to define cloud computing. It started by trying to run an online bookstore, and then they repurposed it. So you can come up with a lot of examples like that. But so the bottom line of that is, JADC2, or military internet of things efforts, shouldn't start by solving the generic problem. They need to start by focusing very specific military operational problems. So that is the first and number one principle.
Ken Miller (06:49):
And this is not something that do DOD is very well versed in doing. A lot of times when they come up with a new concept or even a new capability, they try to universalize and say, "Hey, we can do take this one thing and do everything we want across the force." And then once people start to think about how it impacts their lane, you start to see it crumble a little bit. So how do we make that transition then to... It's very counter to the way DOD is structured and organized, to start with very small, specific uses or examples that we can build upon and evolutionize over a period of time. You're basically asking DOD to turn over on its head. So how do you go about that? Good luck with that answer too.
Bryan Clark (07:32):
Yeah, appreciate it. Yeah. So how do you change DOD culturally to focus on the customers? So part of this is a technological evolution. So as, as Dan said, 50 years ago, even 30 years ago, we couldn't have done this. We couldn't have you focus first on the customer and the customer's problems, and then try to build a solution, then have it evolve out of that. Because the technologies didn't allow that level of tailored capability and customization at the edge. You kind of had to develop a system, a ship, an airplane, a radar, and then have that just basically built cookie cutter for the entire force, because we had sort of an industrial model and a mass model for the military. But you know, technology's changed now and you can customize things at the edge to a degree that you never could before.
Bryan Clark (08:20):
And that's true of internet enabled commercial technology and it's true of military technology as well. So today, the experiments that the services are doing as part of JADC2, Project Overmatch for the Navy, Project Convergence for the Army, ABMS or Advanced Battle Management System for the Air Force, they're all doing these kind of customized use cases at the edge. The whole reason they're doing these experiments is because they want to figure out, "How do I get these weapons to talk to these sensors, to talk to these command nodes and then get them to talk to each other throughout the entire operation?"
Bryan Clark (08:54):
That's exactly what we're talking about here. The challenge though, or the problem of those experiments today is they're focused on things the services are interested in connecting. If the service is running it, if the Navy's running Project Overmatch, they're looking to connect Navy things to further the Navy's goal of having a more relevant force. You could quickly fix that by focusing those experiments on problems the combatant commanders want to solve, as opposed to what the service wants to do.
Ken Miller (09:22):
You actually led into my next question, because a lot of times the first time that services are really working together in an operational sense is at the combatant commander level. So you have these service efforts. Is a there any attempt to take these types of, Project Overmatch and so forth, and apply them at a combatant commander level where you're now having all three, all the services bring in a certain amount of capability and designing that effort at the joint level, right off the bat instead of at the service level.
Bryan Clark (09:54):
Yeah. So as you noted, Goldwater-Nichols, which created our joint military, never created a way to integrate joint forces. So back when we developed Goldwater-Nichols, our integration was done mostly procedurally. So all we needed to do was train people in joint operations and then the people would do the integration. So when I went through JPME phase one and two, I learned how to operate as joint force. And that was all we needed. Well, now we do a lot of machine to machine communication and integration that's required. So you have to technically integrate the force in the field as well. And as you said, the services deploy forces to combatant commanders. The first time they see somebody from another service is when they arrive at the combatant commander's theater and now they're forced to work together. They have to work together more than on just the human terms of procedurally, but also in technical terms of machine to machine integration.
Bryan Clark (10:45):
So I think you could take these experiments that services are doing and push them out to the combatant commanders and say, "Okay, combatant commander, Indo Pacific command, you're now in charge of Project Overmatch and you're going to decide what experiments are going to... What things are going to be connected in these experiments, what operational problems you're going to solve, what effects chains that you need to create to help solve those operational problems."
Bryan Clark (11:09):
And have the combatant commanders drive that and give the combatant commanders some of the budget authority that allows them to execute those experiments. And I think we've already seen a symptom of how the combatant commanders want more of that responsibility in the Pacific deterrence initiative and the European deterrence initiative proposals that UCOM and INDOPACOM provided to the Congress. Where they said, "Here's the infrastructure I need to integrate forces in theater. So, the logistics training infrastructure, the defense systems and the communication infrastructure, so that I can actually put together joint force packages?" Because today there's no way to do that other than what the services provide.
Ken Miller (11:50):
Yeah.
Dan Patt (11:50):
Allow me to augment that. For me, as Bryan and I started looking at this problem and I guess we've been looking at this for a couple years now. It first became clear to me the role of technology, it's what Bryan said. Suddenly I have this technical aspect to integration. Not just planning an operation that we're in the same area at the same time, we've talked about our plans, we've rehearsed our plans. But now there's this technical integration. And that there is no way when I define the requirements of my acquisition programs to align up, to make sure that every mission system, every weapon system in the inventory works together. That's impossible. Once you realize that, it's a little stunning because you realize there's no way to make this happen. There's no structure, there's nobody responsible for this in the department.
Dan Patt (12:40):
But the flip side of that is, there's this tremendous opportunity. There's this tremendous opportunity for recombining our existing military capability or existing inventory around new operational concepts, new tactics, new kill chains that is really exciting. Because you, once you start thinking in these recombinatorial terms, there's a lot of really creative things that can happen. So this is a really tough problem, but if we can unlock this, we can really move the needle in the near term. I want to be clear this doesn't have to wait a couple decades. This is the kind of thing that we can make progress on the next couple of years.
Ken Miller (13:23):
In our previous episode of From the Crow's Nest, we were talking about Ukraine. And we talked about one of the hallmarks of U.S. forces and training is that we have decentralized command and decentralized execution versus what the Russian forces are typically applying, which is completely opposite, the centralized version. But with, you have this decentralized command and decentralized execution, but you have a very centralized bureaucracy driving the requirements, driving the program development. So how do you... Dan, you talked a little bit, you just talked about how there's a tremendous opportunity there and we can do that quickly. And I think if you look at the joint forces, we actually do have an ability to look at it differently than the way that our organization is structured. Who do you put in charge or how do you... What is that first step to open up that opportunity, to put someone there or put a group of people there that is responsible for taking charge of that opportunity in the right way, apart from the centralized bureaucracy?
Dan Patt (14:27):
Look, I think there are a number of ways that you could try to address this and Bryan will have some thoughts on this too. One particularly interesting idea came out of last year's NDAA, and is the concept of a mission manager. Everybody knows what program manager is. Section 871 defined a mission manager, which is somebody who looks after a particular operational problem or an operational outcome. And isn't trying to create a weapon system around that, but is trying to connect weapon systems and connect tactics and has presumably some amount of discretionary funding. And I think the legislation assigned the initial pilot to [inaudible 00:15:14], but it defined it as a generic construct. So, that's one way that you could do this without revisiting Goldwater-Nichols, without a major muscle movement is you could find... You know, you can't restructure the whole department like that, but there are probably a handful of things that are important enough. Assigning a mission manager might be a way to do it. I know Bryan's also been thinking about some other structural and incremental ways to address this.
Bryan Clark (15:38):
Yeah. So if we think about JADC2 being more about integrating the effects chains that combatant commanders actually need today. So instead of trying to solve all these problems from back in the Pentagon on or back with the services, try to solve what the combatant commanders need today, and then work out from there. You need to have an organization out there that's working for the combatant commander and identifying, "All right, well, what are our most important operational problems that we have to solve?" Whether it's an invasion of Taiwan or a blockade of Taiwan or an attack on the Secaucus, if you're INDOPACOM. You say, "Well, one of my operational problems is for example, how do I sustain air operations out of Kadena, in Okinawa?" You could say, "If I have that, it's going to enable me to be more effective and create more problems for the Chinese planning process, if I'm able to sustain some air operations from Kadena."
Bryan Clark (16:30):
No matter what the scenario is. "All right, well then given that operational problem or that opportunity, what are some effects chains I need to be able to execute in order to support or to address that operational problem?" Then you can have that build out from there. I think the organizational construct for identifying those challenges and kill chains or effects chains might be like a joint task force type organization. So we used to have, following the transformation effort of the early 2000s, standing joint task forces inside each of the combatant commands.
Bryan Clark (17:01):
And their job was to think about day to day, how to prepare for war with their opponents that are in that theater. That concept sort of fell apart over time because the services didn't want to support it. The combatant commanders didn't want to devote resources to it. So it kind of fell apart. But reinvigorating that concept and saying, "We need to have an organization that's thinking about the challenges and the effects chains the combatant commander needs to put in place," could be a way to have essentially a bottom up approach to implementing JADC2 instead of the top down approach that's being driven from the Pentagon today.
Ken Miller (17:35):
You basically, in your report, talk about making JADC2 a decision-centric approach versus what is a forecast-centric approach and being able to give the commanders a little bit more flexibility to pull in what they need to at any given time.
Bryan Clark (17:51):
Right. So today, how it works is the Indo Pacific commander, for example, is constrained in how many options he has or in the future she has, because of what the services provide in terms of force packages. Because if you're in into Pacific command, you can't mix and match with the services provided you because you have no infrastructure, no organization that's charged with it. You have no ability to recompose those forces. So you're stuck with what the services give you: a carrier strike group, a brigade combat team, Marine expeditionary unit. And you could do some adjustments at the edges, but you're kind of stuck with that force packaging, which means that if you're trying to develop courses of action, deal with operational problems, you're left with not too many ways to adapt your force.
Bryan Clark (18:31):
Which, you know, that's great for China's planning process because it means they kind of depend on you being able to operate a certain way, but it's not so good for our ability to get a decision making advantage over the Chinese. So if you want to deter China, we have to start thinking in terms of going beyond just fighting them out in a battle of fires and defense, an attrition battle, and instead think about how do we get a decision making advantage that gives them enough uncertainty that maybe they are dissuaded from conflict. Or once conflict starts, they seek an off ramp. You can kind of see an example of that today with Russia and Ukraine. Ukraine has presented enough different challenges to Russia that they were forced to back up and then take a different approach to the Ukrainian invasion. So that's the kind of challenge we'd want to impose on China, were it to think about aggression against one of its neighbors.
Ken Miller (19:19):
That's kind of, again, leading into my next question, was about two months into the conflict here with what's going on in Ukraine. What have we learned about how about the execution of what's going on over there? How's that either the sense of urgency or kind of the resolve to make these adjustments to prepare or to help us understand how to position our force in INDOPACOM region against another peer competitor? Have we learned anything that we're able to move quickly on?
Bryan Clark (19:47):
Yeah, so I think if you look at what the Ukrainians have done, they have adopted a very, what we would call decision-centric approach to their fight. So they didn't try to fight the Russians symmetrically, armor on armor, around Kyiv, for example. They chose to take their forces and recompose them in a way that was going to be able to give them an advantage, both in the fight, but more importantly, in the decision-making battle with the Russians. So instead of bringing out their armor, they had chose instead to use Starlink internet terminals, commercial satellite coverage, spotters, and Javelins, and stinger missiles to go after Russian multi-mission platforms, whether it's a tank or a helicopter or an airplane.
Bryan Clark (20:29):
And that was pretty effective because it created a uncertainty for Russian command and control, which faltered and eventually failed. And it gave the Ukrainians lots of options to be able to execute their counter offensives. So that shift from a kind of traditional planning approach to an optionality approach where they try to give their local commanders lots of ways to pursue the battle, really worked out well for the Ukrainians and kind of shows us how we might have to think about adapting our own ability to defend, if we were put in that same position against the Chinese.
Dan Patt (21:03):
Yeah. I think Bryan's right. I mean, Ukrainians have really, appear to have leveraged adaptation and surprise very, very effectively. And both of those things come out of models where you're delegating decision making. You're really pushing capability to the edge. Sometimes that's tactical innovation. Some really clever tactics emerging about, it's not just having Javelins, right? It's also how you use them. And, you know, they're figuring this out on the fly and some really clever tactics have appeared in the media about how these are employed at night, repurposing pieces of equipment, repurposing the sights and targeting systems from the Javelins to be able to better operate at night and being able to just keep imposing surprise on the Russians.
Dan Patt (21:58):
Even if the theater is different and the weapons are different, and the nature of the conflict is different, those parts of conflict are intrinsic. Those don't go away. And the question the U.S. should be asking is trying to figure out how we can engender that kind of adaptability and surprise at scale, given the technologies and theater and adversaries we're likely to face in the future.
Bryan Clark (22:21):
Yeah. And I'll add to that. So the JADC2 is intended to do this. So when you hear some of the early discussions about JADC2 too, is, any sense or any shooter, I want the force commanders locally to be able to combine any forces they have and make a kill chain, which is a great aspiration. That's the correct goal. I think the difficulty is if you're trying to do that from the Pentagon then you're trying to boil the ocean. You're trying to come up with, make every connection between every unit possible, instead of saying, "Well, I'm going to turn this over largely to my field commander, in this case, the combatant commanders to decide what they need to be able to combine. And they will try to maximize their options in the field. Let's start with that."
Bryan Clark (23:01):
And instead of trying to use the industrial model of pushing interoperability out to the edge, let's let the combatant commanders take advantage of the I ability they can create using modern tools. So Dan could talk more about this, but there's a lot of, you know, software driven tools available that could provide us interoperability that don't have to come from the Pentagon, but it could be instead put in place locally by the field commander or by the support infrastructure in the field.
Ken Miller (23:30):
How do we leverage some of the things that we can learn on interoperability from business sector into DOD?
Dan Patt (23:37):
I think it really revolves around this paradigm. There's this industrial paradigm that is compile and then compose. So compile means, in the software sense, it means, you know, you turn it into a binary executable form, but in general, it means you build something. And compose means you put it together with the other pieces you need to do it. And that is, that's the way we used to think about. I build an aircraft carrier and I build the aircraft that go on the aircraft carrier. I compile each of them, and then I compose them. I put them together. And in an industrial sense, that makes sense. And if I think about that context, it really makes me think about interoperability as a puzzle where I'm really focused on the interfaces for that puzzle and trying to define them very carefully at their requirements time.
Dan Patt (24:25):
The other way you could think about interoperability is the other way around. First, I compose, and then I compile. This is what you find in these complex commercial environments, these business systems and information systems. So what does that mean? That means I start looking at my military capabilities, like a pipeline, like a software delivery line. And first I set my configuration, what are the things that I need to be operating together? And then I compile them. First compose, and then compile. So that does include meaning the software, which means that I'm probably taking that configuration and I'm actually figuring out what do I need to make those pieces work together? And this is a paradigm that, you see all of the time. What are some examples of this? A modern abstracted operating system like Android is doing this.
Dan Patt (25:20):
Is, I've separated out these pieces and I'm able to set the configuration and then I compile and then they get the configuration. So you could imagine doing this also for military systems. Is all right, these are the systems I need operating together. Let's automatically generate the right network parameters, network participation groups, et cetera, in order for these to be able to operate. Get the protocols, freeze them. Basically admission planning. That's the kind of model, that more modern model of interoperability, just a shift in how you think about it, that you're likely to need to get the kind of dynamism we're talking about.
Bryan Clark (25:56):
So in the military sense, you could see putting together... You'd say, "Okay, well, I'm the combatant commander. The effects chain I need to put together is an F35 launching some kind of JASSM or LRASSM strike missile, but I'm going to need to be able to target that missile using a space development agency, lower thorbid sensor, and then I'm going to need to do battle damage assessment on that using a Reaper EOIR sensor. So this is my effects chain. I need all these things to work together, because they got to be able to talk to each other and be able to share data in real time. So instead of figuring all that out and trying to create all those interfaces through standards and requirements, back at the Pentagon, you say, "Combatant commander, I'm going to give you the software code writers and the money to be able to go write the code necessary, to make those things talk to each other in the field."
Bryan Clark (26:46):
And some examples of how we're doing that today is with these experiments that the services are doing. They have software factories, they have uniform members that are out there writing code so they can make a Thad air defense battery talk to a Patriot air defense battery through IBCS. They're having software code writers be able to connect a F35 to a DDG, a Navy destroyer. You've got these software factories that are using service members and government civilians to be able to do this, supported by contractors, but they're out in the field doing this as opposed to trying to do it as part of the acquisition process. Another example of this might be the Spectrum warfare wing in the Air Force does with STITCHES, which is a interoperability tool chain that writes software code in the field to be able to take data from one format and turn into another. Link16 to TTNT. CDL to TTNT. So try to write software code in the field that allows things to connect. And basically, do that in the field.
Ken Miller (27:44):
We have time for one more question and I apologize, because it's not an easy short answer for either of you. But you basically have five key recommendations because obviously this is a huge task, but you really break it down into five things that you think DOD can do today to really get the ball rolling in this new effort. So, wanted you to go kind of go through quickly, kind of talk about each of those five recommendations. I'll kind of let you split it up as you want, but we talked a little bit about some of them throughout the conversation this afternoon, but if you could go through and just kind of talk about what are some of the, what are the five steps that you've outlined that can get DOD on the right track to implementing this model?
Bryan Clark (28:21):
Well, I'll start. And then I'll turn over to Dan. So I think the first thing is going to be getting the joint staff out of the role of being in charge of JADC2, its implementation, because right now they're running it as the joint staff can, through setting requirements and standards. Which since the joint staff doesn't have any real authority means that this process is going to take a very long time to be eventually permeating throughout the entire military. So that's one of the reasons why JADC2 is going to take forever and cost a lot of money. Is that where the joint staff is leading it as a requirements process rather than having an organization lead it that can actually do joint integration.
Bryan Clark (29:00):
So let's get the joint staff out of the role of being in charge of JADC2 and instead focus them on working with the commanders to identify those key operational challenges and the effects chains that have to be developed. And then the combat commanders for their part need to focus on identifying their operational challenges and effects chains that need to be addressed in order to support their approaches to deterrence and their approaches to deal with the adversaries in their theater. And then I'll turn over to Dan because then we get into what the services are doing and then what do we need to do to build the infrastructure?
Dan Patt (29:33):
Look, I would say in our recommendations, there's some good news. So the good news is, it's good that the services are doing things are a little bit unique that provides resilience and diversity. That's a good thing, but what we're missing is actually making concrete progress on the problems that our combatant commanders face. Our real operational problems, bottom line, that's where we have to focus. That's where we have to think about connecting our systems, building new effects chains, building new capability. And the hard work begins by identifying what some of those key problems are and finding funding and somebody to run it.
Dan Patt (30:11):
And that could be slotted in under experimentation. It could be slotted in under mission management, but I think that's really the core of our idea. And what you'll soon find is, there's a real role for technology in thinking about those capabilities as part of a pipeline technology that supports that. Things like live virtual constructive simulation, things like a toolkit for interoperability that Bryan talked about and other supporting infrastructure. And I think that's exciting.
Bryan Clark (30:37):
So the, yeah, the services role needs to shift from thinking about their own equities and instead focus their experimentation on what the combatant commanders need. And then, to get to what Dan's saying about live virtual constructive training and some of these software tools, that's that horizontal infrastructure. That's that set of capabilities and software factories and people that has to be provided to the combatant commanders to allow them to do this integration of both the human and the technical dimensions of a joint force package.
Bryan Clark (31:07):
And those organizations are like the strategic capabilities office, which is doing mission management for the current pilot. It's like the JAIC, the joint AI center, which is supporting some of these toolkit development projects. It's like the Spectrum warfare wing that is producing STITCHES, the software factories that are supporting interoperability toolkits for the other services. So that horizontal infrastructure is necessary. So DOD needs to identify which of these, you know, DARPA, JAIC, et cetera, organizations are going to be charged with supporting the combatant commanders and doing joint integration in the field. The services need to fall in and support that with their experimentation efforts that increasingly need to be led by the combatant commanders.
Ken Miller (31:50):
Great. Well, thank you, Dan and Bryan for joining me here on From the Crow's Nest. That's all the time we have for this episode, but I do appreciate your time and I encourage all of our listeners to access the report. It can be found on Hudson org. It's a great read. And I think there's a lot of forward thinking recommendations and material in there. So thank you for taking time to join me here on From the Crow's Nest.
Bryan Clark (32:12):
Thanks Ken.
Dan Patt (32:13):
Thank you.
Ken Miller (32:14):
That will conclude this episode of From the Crow's Nest. I'd like to thank my guests, Bryan Clark and Dan Patt from the Hudson Institute. If you enjoy this podcast, please take a moment to rate us and comment wherever you download the podcast. I appreciate hearing from listeners and it always helps us to make improvements on the show and respond to listeners' interests. You can also visit our website at crows.org for more information on upcoming activities and programs, as well as our sister podcast, The History of Crows. Thank you for listening.