美国基础设施背后的软件危机

We have a software crisis. There's just no time to wait. If you don't have that sense of urgency, we're not going to accomplish what we need to do.

You can build the most advanced equipment. You can produce it at the largest scale possible, but if you can't get it where it's needed, when it's needed, it doesn't exist. There's always been collective defense, but not necessarily collective logistics. Any one nation can't do it alone.

Whatever we're modernizing now, this is not going to be the last update. Software is never complete. Software is moving incredibly fast. The best type of war you fight is one that you don't have to fight at all. The probability is very high that the next few decades are going to be a bit more dynamic and uncertain than the last 2 decades were.

Phillip, I'd love to start things off with your story. On your ASI company page—and I quote—it says that 12 years ago you were frustrated by Germany's stagnant approach to national security and its economic degrowth mindset. Tell us about that moment in your life and why you came to America.

I grew up in Germany and spent some time in the U.K. After college, around 2011 or 2012, I had to figure out what I was going to do in my 20s. I knew I wanted to be in a fast-paced, demanding environment. But what I found in Europe was that most of my friends just wanted to party.

Germany had decided to pull out of nuclear energy and become fully dependent on cheap Russian gas. At the same time, the top 5% of my friends and social network glorified consulting and went into consulting. The government made it as hard as possible to build anything, from starting a company to accessing venture capital.

While all that was happening, as I observed and internalized it, I heard about Silicon Valley. I thought, “That sounds like an interesting place. It sounds like everyone is just obsessed with building and technology.” A friend of mine and I traveled to Palo Alto, stayed in a hacker house, and in many ways never went back.

For the first 3 years, I slept on bunk beds and ate frozen food from Trader Joe's. But it was the most exciting environment to be in. Everyone was building in that hacker house. Everyone was thinking about startups and technology.

Fast-forward, and I now probably spend nearly as much time, or even more time, in the U.S. than I did in Germany. Our second daughter was just born here in D.C. last week. In many ways, I lived the American dream. Everything that I did and everything that I learned could not have been built somewhere else, I would say. It was the ecosystem, the ethos, the energy, and the people that enabled that. I'm very grateful, but also determined that it was very much the right decision about where to go.

I love that. You actually started your career in the world of autonomy and autonomous vehicles. Can you talk about your career journey there and what brought you to ASI?

When K.D. Lucas and I started ASI, I would say we were the ultimate outsiders. We weren't pilots. We had not worked in defense before, and we weren't logisticians. We worked on autonomous driving.

This was around 2017 or 2018. Autonomous driving was very popular, very hot. While many liked that, we didn't. It felt overly crowded. We started this company with a simple question: What are other modes of transportation that require better software?

During the first 6 months of ASI, we went to operations centers and wanted to understand the state of software and technology, whether that was in maritime or air operations centers. To some extent, we expected or hoped to see science fiction. What we saw was the most ancient software possible.

That made it very obvious to start this company with a mission to enable the world's most critical operations and optimize the most valuable assets and infrastructure that we have as a country. That's how we got started.

Leo, I'd love to hear about you. I know that you recently retired as a 3-star general after serving as the director of logistics on the Joint Chiefs of Staff. What brought you to ASI?

I spent over 30 years of my career in the military, starting with air mobility operations and then spending the last 7 years really focused on logistics. After I retired, I got the advice to give yourself about 6 months to figure out what's next after doing something for that long.

I knew what I was passionate about: national security, logistics optimization-type things. I had a chance during those 6 months to meet different companies, see different technologies, and see a lot of things going on. But when I met Phillip and the team at ASI, there was something unique and compelling to me.

One thing was that while distribution platforms, planes, and ships are all quite important, it really comes down to the data: being able to access that data, optimize it, and figure out what we need to do. That was something I struggled with in the Department of Defense—being able to access the data, understand it, and really optimize the things we need to do now and in the future.

The combination of that piece being exciting and a startup being exciting—not just to support the military, but also the whole commercial sector, which is strategically important for both—was compelling to me.

Absolutely. Can you tell us a little bit more about your career prior to ASI?

I initially was going to be an engineer. I went to graduate school for industrial engineering and optimization-type things, including neural networks, 30-plus years ago, before we really had the processing power to do that. Then I quickly went into pilot training and flew mobility planes for many years.

About 7 or 8 years ago, I had my first real foray into broader logistics. I was the director of logistics for U.S. Africa Command out of Stuttgart, Germany. That was also during the pandemic, when I was working with Department of Defense logistics and infrastructure, trying to move things around Africa. Just the size and scope—and then you add the pandemic—made it a significant challenge.

Then I went to Japan for a command assignment and came back to the Joint Staff as director for logistics, with Ukraine going on, support for Israel, and everything else. I realized the challenges with our defense industrial base and with what we have. One of the main efforts there was really that data and software piece, which we just weren't very good at. We were trying hard, but had a lot of catching up to do in the Department of Defense.

Makes a lot of sense. So you've been all over the world, and we're seeing these common core challenges everywhere you were. A lot of it is around data and software.

I'd love to kick off by first talking about the air domain. Obviously, ASI got its start in the aviation space, which is an area where we've seen a lot of challenges. On the one hand, we as consumers are told that flying is the safest mode of transport, and statistically, that's correct. On the other hand, we're seeing headlines every day about air traffic control shortages and staffing challenges. Can you help us paint a picture of the aviation industry and what the state of play is?

Yeah, absolutely. First of all, it is definitely, by far, still the safest domain and mode of transportation. But we're fundamentally looking at 3 different problems. The first one is staffing. There's a significant staffing shortage right now in the industry.

Why is that? You've seen a lot of retirements throughout the COVID pandemic. Training was not happening at the same speed during the COVID pandemic. In general, or more broadly beyond air traffic control, the industry might have also lost a little bit of the ability to attract the very best talent. We can talk more about what that also meant for software.

Then we equally have a software crisis. We've got legacy software that is faltering and falling apart. Whenever that happens, you have these massive outages that are incredibly consequential to the entire industry. Then you've got very outdated infrastructure.

What is not talked about enough is how these problems are all interconnected. Let me give you an example: staffing and software go hand in hand. If you have better software that is much more intuitive, you can train people much faster. Even more so, if you have software that is supporting the operator, that operator is a lot more productive. You're minimizing workload. If you don't have to do 10,000 clicks but just a few, or you have AI assisting you in your decision-making, you can be much more productive.

Even more, that is leading to second-order consequences. If you're increasing productivity, that means you can actually pay people more, right? And that means more people want to operate or work in the field. I think what's not considered enough is how staffing and infrastructure are fundamentally software problems.

You can't separate these 3 areas and look at them in an isolated way. Software is eating the world, and that is very much true for this domain. Internalizing that, as there's a mandate to modernize now and pull this sector and this industry forward, looking at it through the software lens is absolutely critical.

I think some of that is happening. It sounds like there are all of these challenges, but they're sort of being looked at in silos. People are trying to say there's a people problem here, an infrastructure problem here, and a technology problem here. But actually, these things are all connected. If we can modernize them, that's how we're going to be able to move faster.

Absolutely. And you're training a new generation, right? If you're training a 25-year-old air traffic controller, that individual grew up with an iPad, Snapchat, and so on. They're using Google Maps when they drive a car. The generation that has retired or is about to retire grew up with IBM green screens; they are familiar with how to use that technology, and they used it for the last 30 years.

But the new generation being trained now isn't familiar with those legacy tools. I think it's absolutely essential that software be modernized and brought up to speed with what people are used to using from a software-quality perspective.

I'd love to double-click on that. We're here at the American Dynamism Summit in Washington, D.C., and we're all grappling with the fact that there was a tragic accident here in our city just a couple of months ago: a commercial airline collided with a military helicopter.

Phillip, I believe you were at Reagan National Airport at the moment that happened. People assume that good safety records equate with good technology, but it sounds like we're actually dealing with a lot of legacy technology. Can you help us understand what that looks like today?

The way I would frame it is that it's very much a philosophy problem. The philosophy of what software should look like might be a bit broken. I think it boils down to 3 issues.

The first one is that software and compute are very much connected. What does that mean? If you have software systems that are deeply coupled with the compute power, it's very hard to modernize anything, specifically if you're dealing with an industry where you have facilities all over the country. You cannot just launch an update over the air and have all the software updated. That doesn't work.

You would literally have to go from facility to facility to update the software or patch things, if that is needed. Every single time, you're running a risk: Can the compute actually handle that new software update? The first part that really has to happen when we think about modernization is figuring out how to separate software and compute.

That's essential, because whatever we're modernizing now, this is not going to be the last update. Software is never complete. Software is moving incredibly fast. The separation of software and compute is absolutely essential.

The second part is that, historically, software in this domain has been built as if it were hardware, while the entire world is moving toward a direction where even the hardware companies build hardware as if it were software. In many ways, it's the inverse.

Whenever there's a modernization effort, whether this is with the government or on the commercial side in air operations, there's usually a need, a program is started, and it's being funded. The first thing that happens is that a 1,000-page document is written. Already, tens of millions of dollars are spent on just writing the documentation. No software has been built yet. Nothing has shipped. Nothing works yet. It's just the documentation.

Now we're already tens of millions of dollars into just documentation. Over the next 10 years, for hundreds of millions of dollars, software is being written from scratch for that particular problem area against those requirements. Then, 10 years later, all that is magically considered working and finished, and it's being rolled out.

Obviously, by that time it's already out of date and antiquated, because the state of technology has changed a lot over those 10 years. Then it's maintained for the next 20 years. We all know this: This is not how software is built, given how fast it's changing and how fast it's moving. I think that is the second area that needs to change.

The third one is that the companies that historically participated in the space can no longer attract the very best software engineers. The very best software engineers do not want to work in that ecosystem and with those structures. They want to build rapidly. They want to build close to the user. They don't want to be handed a list of 10,000 requirements and then just write code against that.

The combination of what all these things mean is that you are basically in a setup that does not produce the software that should be produced. If you wrap all of that into an acquisition framework that incentivizes those philosophies, you've got a really big problem at hand. That is where we are right now.

But I think things are about to change, and we may talk about this later. When I think about the Department of Defense, the way you describe that ecosystem and our challenge is exactly the same, especially in the logistics business within each service—the Army, Marine Corps, and Air Force—and within each subunit as you go down.

There are legacy systems that were programmed by great people decades ago, but they weren't designed to be able to connect. We spend so much time trying to put systems together ad hoc, when you really should be thinking forward and having that clean-sheet type of software that can be iterative.

There's just no time to wait. You have to move fast, and even moving fast, it still takes some time. But if you don't have that sense of urgency, we're not going to accomplish what we need to do.

And actually, on that point around urgency, we have to fix the status quo. It's exciting that this administration seems very committed to moving fast. I'd love your perspective on how fast we can solve some of these big challenges.

Yeah, I think things will only change if the momentum stays what it is right now. If there's a real urgency for change, I think President Trump and Secretary Duffy set the direction and the mandate.

I think the next step is for Congress to fund the modernization efforts at the FAA. I would argue that, in many ways, it's one of those areas where there's strong bipartisan support for this. It's very hard to argue why not to modernize air traffic control systems and why the U.S. should not have the very best software in that field. I think everyone agrees that it's the very best that we should have.

At the same time, it's important that guidelines are put in place for how to spend that money and how not to repeat the same mistakes from the past. We don't need to spend 10 years on custom development. If we can purchase software that already works in the private sector and is already commercially deployed, we can literally just purchase and use it as is, maybe making a few modifications.

That is a lot more efficient, allows for much faster modernization, and is also the safest because it's already proven. I think the next 2 steps here are making sure the resources are there. I think it's fair to say the FAA historically has not had, or most recently has not had, the resources it needs to modernize.

Then we need to make sure the structures are set up the right way so we're not repeating the same mistakes over again.

And when you say proven software, I'd love to understand what exactly you mean by that. How has ASI worked with the commercial sector and the DoD already to help provide some of these capabilities?

Absolutely. I'll give you some examples. When it comes to some of the modernization efforts that the FAA will pursue—for example, air traffic management—a lot of the software that is needed, a lot of the capabilities, we already have commercially deployed with the airlines.

In many ways, a lot of the airlines are advocating that they would love the FAA to use this type of software. That's a great example. Instead of building that capability from scratch for hundreds of millions of dollars—and that's historically been the idea, right?—why not use something that is already deployed and already used by some of the largest airlines in the country? Why not use that, because it already works?

The same has been true since we started working with the U.S. Air Force. The reason we were able to deploy within months and have seen our software being used in live operations was simply because it already worked in the commercial sector. It was already deployed there in a 24/7, 365-days-a-year type of fashion.

I think there are certain areas where dual use is a good idea, and there are certain areas where dual use is not a good idea. But when it comes to some of these industries where the private sector and the public sector have to collaborate very closely together, dual use is a phenomenally good idea.

Not just because it's more efficient, but it also enables more collaboration. When it comes to the national airspace system, it's a system managed by the government but used by the private sector, meaning the airlines.

At the risk of really bringing a Silicon Valley term to the table, there's a network effect here, right?

100%. You want everybody singing to the same tune, and if you have a platform where everyone has access to the same data, then everything can be more efficient.

Yep.

Maybe just adding from my experience in the Department of Defense aspect—and maybe people don't realize this—but day to day, the U.S. military uses commercial transport, whether it's trucking, rail, air, or sea. For any kind of contingency or disaster-type escalation, we would have to actually use more.

So it's really the same resources, the same need for collaboration, and the need to be able to work well together on the same systems and platforms.

Absolutely. That's such a great point, and it brings me to the next thing I wanted to double-click on: how ASI has been expanding into areas like logistics. Can you walk us through what exactly that looks like with the DoD? It feels like a black box for many folks. When we say “contested logistics,” what exactly does that mean?

Contested logistics is actually a military term. As with every military term, it has definitions and doctrine, and even secret stuff that we discuss. To understand the concept, most of us order things online. I'm sure you may have done that within the last week, if not within the last day or so. When you order something, you worry about the price and when it might get there, but most people have no concern about where it's built or the supply chain getting it there—unless it's going to be delayed, or you realize that there's some weather system affecting it.

On any given day, you have contested logistics. It's just that the consumer, and even the CEOs of some companies or senior four-star generals, may not think about logistics day to day because it hasn't been a problem in the past. The idea of contested logistics is that whether it's weather, maintenance, or other situations, you're going to have challenges. How do you understand that, predict it, and optimize it? That's what ASI, that type of software, is for.

From the military perspective, adversaries will look for your vulnerabilities, which would be in your supply chain and logistics. That's where, to be able to outdo them and maintain the ability to do what you need to do, you have to understand where your vulnerabilities might be, have resiliency in place, and be predictive so you can work around them.

Another thing is that when we in the military move an aircraft carrier or a group of soldiers somewhere, you make that decision, but people don't often think about the whole supply chain—the tail, I guess you'd call it—the food supply, munitions, and everything else needed to get them there and get them back. That's hugely important, because no matter what great weapon system you have, if you can't supply and sustain it and move it where you need to, it's not effective.

I really think logistics experts do think of it as a weapon system itself. It's your competitive advantage if you can leverage it. If you can't, and you don't see it, it becomes your greatest weakness and vulnerability. We want it to be your competitive advantage by providing this capability.

It's almost like electricity or water. You don't think about it working or not working until you flip the switch and your light doesn't come on, or you turn the faucet and the water doesn't run. It's really the backbone of everything.

We've seen that with the pandemic, with face masks or toilet paper and things like that. From the military perspective, I saw that with support to Ukraine, where there were munitions and things we were moving, and just the resources to do that—the supply chain needed to replenish those. As you start thinking through potential crises and other situations as things escalate, you'd want to be able to predict and understand that better. But again, just like oxygen, it's fine, and you don't notice it until you don't have it. Then it becomes a concern.

Phillip, what's your perspective?

To echo very much what Leonard shared, we talked about air traffic control and air operations before. It's the same there, right? You just assume things are working until they don't. That's why I think sometimes those sectors are a little harder to gather everyone's interest in or to make sure the funding is there.

It's very easy to spend money on the fancy weapon system, the autonomous drone, the new high-tech equipment, whatever it is, because it's physical and visible. But when it comes to the, quote-unquote, silent software that runs in the background, that enables all of this to work and allows the most advanced equipment to go where it's needed, when it's needed, I think that's sometimes too much of an afterthought.

Why has that been such an underserved topic? To your exact point, when we think about defense and some of these new capabilities, we're talking about autonomous drones, counter-UAS capabilities, and electronic warfare. We haven't been talking nearly enough about logistics, but we've just been through the pandemic. We've seen the disruption in our personal lives. Why do we still have this disconnect?

I think it's human nature: wanting to go back to the status quo. You have all this stress, and you just want to take a deep breath and go back to what seems comfortable. We've been able to be comfortable for the last few decades because, fortunately, we haven't had a global war or that level of conflict. It takes pressure points like the pandemic to really see where the vulnerabilities are, and that's where there was a lot of investment taking place.

Then there's the human nature of easing back to the status quo. It's the same with air traffic control. You have great people working on that, but they deserve a much better software system—something from at least the 21st century. You hope it doesn't have to come to something where there's almost a crisis or something happens before that changes.

The other issue is that we've been accustomed over the last several decades to just-in-time logistics. It's been treated as a cost area: you're worried about reducing costs, and that's all well and good if there's nothing out there threatening the supply chain. But you realize that just-in-time isn't in time at all if you can't get that part or supply-chain need.

That's where I think the companies I talk to, and others, are realizing that their competitive advantage can be in understanding and building resilience into that supply-chain and logistics piece. Instead of thinking of it as a cost, it should be something that's their competitive advantage—something that provides profit, or, for the military, more deterrence and capability.

I want to go back to the dual-use topic. That's an area where we spend a lot of time. We think about companies that have an existing commercial capability that is doing great work in the commercial sector, and they can take that exact same capability to the DoD. Can you walk us through how ASI fits into that puzzle and some of the areas where you all are going to be able to lean in?

I think there are certain domains and capabilities where building something specific for one sector is absolutely the right way to go. Think of a new missile or an aircraft carrier. There's not much commercial applicability for that.

Logistics is one of those domains where I would argue it's the flagship example of where you want to have dual use. Why is that? Leonard has already alluded to it to some extent. From a defense perspective, a lot of the capacity resides in the private sector, on the commercial side. It goes way beyond the Civil Reserve Air Fleet. It's the same infrastructure that I use, the same ports, and so on.

Our adversaries are actually trying to deploy their software into allied ports. The Chinese are really good at making sure their software runs in ports. They're giving it away for free, and there's a reason why they do that.

From the other side, if you're providing mission-critical infrastructure like transportation, you want to make sure you're using military-grade software because the stakes are so high. You want these 2 sectors to be very close. Yes, there needs to be separation, but there's nothing better than actually running a very similar or the same software stack on both sides, so that these 2 sectors can communicate, collaborate, and share data when it's needed.

You don't want it to feel, in the moment of crisis, like, “Oh, shoot, now we need to understand what the software stack and the data structures look like on the other side so we can actually coordinate.” You don't want to figure that out when you're in the middle of a crisis. You want to have that done before, and that's very much what we're trying to do at ASI.

We want to make sure that the very best logistics software—the very best software to operate mission-critical operations—is deployed with the companies that are doing that in the private sector, as well as with the government, and then enable these 2 sectors to collaborate. In many ways, it's the truest form of dual use, because we're not only sharing technology; we're also enabling collaboration and communication between these 2 sectors.

I think then, to some extent, you can make the argument that you want to use a similar idea or mental model when it comes to collaboration between the US and its allies.

Specifically on the side of military logistics, contested logistics, it is always about the integration with our allied partners. How can we tap their infrastructure? How can we use some of the capacity that they have? How can that all be coordinated? There are times when you want to have more separation, and then there are times when you want to have tighter collaboration and more sharing. You need to have the infrastructure in place that allows for that.

In my previous job, I was a U.S. representative for the NATO Logistics Committee. Over the last few years in NATO, one of the changes—we can go into more detail, but basically, there has always been collective defense, but not necessarily collective logistics. Logistics was each nation's responsibility, but the realization is that any one nation can't do it alone. So this idea of collective logistics across NATO—which the U.S. is a member of—is all kind of common sense, but they finally put it into not only a common understanding, but also planning and other things to determine how best to utilize our collective logistics capabilities and plan for that in the future.

If we talk about modernizing logistics for the DoD, what exactly needs to change? Is this a policy issue? Is it a culture issue? Is it an experimentation issue? What do we need to fix here?

I think it's really about thinking very differently about software. When I say software in this case, I don't mean just legacy software, but I think also what we deployed in recent years. A lot of the modernization that happened over the last 5 to 10 years was just putting up new dashboards that are running in these operation centers on bigger TVs. But we haven't really deployed software to the warfighter, to the operator.

David Yulovich puts it very well when he says the world is getting a lot spicier. It's much spicier now. What that means is that we actually need different software. When the world is stable, you can operate off near-real-time displays. That means the human operator is seeing problems as they happen, and then reacting to them.

But that's not necessarily the world we're living in. The world is a lot more uncertain now, and I think that means we need to have software that shows the operator what is about to happen in the operating domain. How do they need to adjust? I would say anticipation, in many ways, is a new high ground when it comes to software.

We have seen 3 evolutionary steps. The first evolution was that we had compute. In the 1970s and 1980s, we had workstations that were not connected. You input some data, and there was some optimization process or some form of processing happening, and then you had an output.

The next evolution was when all those workstations became connected—the internet. Now a lot more data became available online. The next step from there was, “Great, now we can extend that to the Internet of Things.” A lot more sensors became online, so the big challenge was, how do we fuse all that data? How do we make sure we have a great common operating picture?

That was very much the focus over the last 15 years or so: data fusion, displaying that data, and making it accessible, very often to these critical industries and the military. I think now we're at the very beginning of a new revolution, which is prediction machines. How do we actually build interfaces that predict what is about to happen?

What is the state of the operating domain? What is the state of our supply chain? What is the state of the assets we're operating—not just right now, but over the next hours, over the next days, over the next weeks? How can we forward-simulate that? That is an enormous advantage for an organization if you have that capability. Now we need to make sure we're rolling that out and embedding it in our operations.

Again, from an ASI perspective, we pioneered some of that work, very specifically in the air domain, but we need to do that more broadly now across all domains, across both sectors—private and public. Then I think the second part is that we need to enable much tighter collaboration between the 2 sectors.

We talked about that already a little bit, but the key issue is going to be, how do we get more capacity ASAP? Yes, we can think about how we build more ships and all of that, and there are clear needs for that, but all those things take time. At the same time, there is already a lot of capacity within the Western Hemisphere, between the U.S. and its partners and allies, as well as between the private and public sectors.

How do we enable collaboration and communication to make sure that capacity can be used effectively or efficiently? Lastly, I think it's important that these sectors are not just an afterthought. How do we make sure that these sectors get the funding, care, and attention—not just when things fall apart, because then it's too late, but how do we make sure we invest in these sectors proactively, before things fall apart?

On the last point about funding and prioritization, from a policy perspective, logistics is fundamental to everything we do, so we need to fund it and prioritize it. The other point—and this came from your air-traffic-controller explanation—is the skill set that it took in the past to become proficient with older systems.

I had a big challenge on the Joint Staff as a director for logistics in creating joint logisticians. In military terms, joint means you've got the Army, Air Force, Navy, and Marines, and each of those has its own perspective. If the Air Force wants to move something, they think about doing it by air; the Navy thinks about doing it by sea, for example, and maybe the Army thinks about doing it by ground.

First, you have to be an expert in that kind of logistics. Air logistics takes several years, if not a decade. Then you need opportunities to become a joint logistics expert, which means you have to understand all of those. That takes a lot of time, and we're challenged to do that. Not that we shouldn't strive to do it, but when you have AI decision-making tools that can enable individuals to make decisions and facilitate them—instead of taking 20 years to train someone to do this—you have software that you can be trained on and still learn from, but that can give you the option of multimodal decisions: whether something should be sent by ship or air, or what the best decision is.

I think that's really an accelerator for what we need to do. We still should train and try to achieve that, but in today's technology, we should be leveraging it instead of struggling to provide one person who can do everything. If that person isn't there, then you can't succeed.

It's like, if I'm a developer, I don't need to go out and buy a bunch of servers and rack and stack them in my garage. I can swipe my credit card with one of the cloud providers and focus on higher-level efforts—actually building the software. So it sounds like there's a similar opportunity here for acceleration.

Phillip, I'd love to ask you one more question because you started to touch on the intersection of AI and logistics. If we're doing all this right and we get in a time machine 10 years from now, what are some of the problems that we're going to be able to solve by getting that right?

One is that we will be able to do a lot more with the capacity we have available. That's one. Second, we will be able to harden our logistics networks in an uncertain world, or an uncertain state of the world.

No matter how some of these crises are going to pan out, I think the probability is very high that the next few decades are going to be a bit more dynamic and uncertain than the last 2 decades were. That means every form of supply chain, any piece of mission-critical infrastructure, will, in one form or shape, be disrupted.

How do we have software that allows us to very quickly reroute things so that the impact of that uncertainty doesn't affect the warfighter or civilian infrastructure, because we have software systems in place that are able to balance that out and reroute things?

Again, I think the uncertainty will come obviously from geopolitical tensions, but equally from sanctions and also from a climate perspective. Increasingly volatile weather has huge implications for, for example, the National Airspace System and travel. How can we have logistics systems that are able to anticipate these challenges and then balance things out when needed, because we have that predictive capability?

I think no one really wants—no one I know wants—to fight a war. But we want to be able to prevent that. Phillip already alluded to this: no matter what ships, aircraft, and high-tech weapons you have, if you can't sustain them, you can't move them where they need to be, and the adversary knows that.

Or even if you can move them where they need to be, but you can't keep them sustained for any given amount of time, that doesn't provide deterrence. That's something fundamental that we maybe haven't had to think about as a nation for many decades. Having the ability to provide that deterrence based on understanding and fully taking advantage of our logistics capability allows us to be stronger.

Hopefully, if you fast-forward 10 years from now, I can't tell you everything that will happen in that time, but we will still be able to deter and make sure it's a free and open world because of that. If we don't have that capability, it makes anything we do from a national security perspective that much harder. I don't want it to be that much harder for our military men and women out there.

What are the risks if we don't get this right? If we don't modernize, what's at stake?

There should be a sense of urgency because there's no time. There's a book out there called The Hundred-Year Marathon by Michael Pillsbury. Just some of the background: the premise of the book is that adversaries like China have been looking at our vulnerabilities and supply chains for quite some time. In a marathon, even if Phillip's a much faster runner, if I start running today and he doesn't start until tomorrow, I probably will win. And this is where the sense of urgency is: to catch up with our risks.

Our risks lie in our ports, and our risks lie within our supply chain. You'll see news releases about hacking into water supply systems in places in Texas, and you wonder, why is that all happening? If you look at Sun Tzu's ancient strategy, the best type of war you fight is one that you don't have to fight at all. If we, as a nation, have been able to project power and do things from everywhere around the world, it's been great for the United States to do that. We have an amazing capability.

But in this age of contested logistics, with hypersonic missiles and cyber and space threats, our ability not just to operate abroad, but to be able to leave our own ports and move rail and everything uncontested, no longer exists. It probably hasn't existed for a few years or more. And so that's really where the risk is. That's why the risk of not really taking action—not drastically updating your system to the way that cutting-edge industry operates—is so great.

The Department of Defense built a logistics system 40 years ago and made minor, if any, updates to it. That's not the way we need to operate in the future.

So, also from a geography perspective, this stuff is so important, right? In many ways, the greatest asset for the U.S. is that you've got a massive ocean to the west. You've got a massive ocean to the east, right? It's actually very, very hard for any adversary to attack the U.S. on its homeland, given that we have the oceans, right? But at the same time, from a global power-projection perspective, we need to be able to overcome these vast distances over the oceans, and that requires logistics, right?

Our adversaries know that, and their strategies are very much like, okay, how do we target key logistics infrastructure, whether it's in the homeland or with allies and partners, to limit the U.S.'s capability to make sure the equipment can go where it's needed, when it's needed, right? And that requires software as much as physical infrastructure to allow us to maintain the ability to project power globally.

Some tangible examples: things have already happened. You look back to the Colonial Pipeline; for those here on the East Coast, you couldn't get gas for quite some time. You look at the Suez Canal back in 2021. You had a ship that was trying to parallel park and got stuck there for 6 days—just the billions of dollars of trade that were affected by that.

Those are things that had different reasons for happening, not nefarious actions in particular, but you could imagine the vulnerabilities that we have. You just can't stop if we're at some crisis. You're going to have to be able to overcome that. And that's why this predictive logistics capability, AI-enabled, is a way that we'd have to be able to look and think and come up with solutions.

So, I think that's so key. And then how do we understand the threat profile for every single node in the system, right? How do we understand the threats that might impact key infrastructure, right? We see a lot of undersea cables being attacked, right?

Every key node in the system is a vulnerability. How do we make sure we have the technology in place to detect any threats, no matter what form or shape they're coming in, and then how do we quickly counter that by relying on other nodes more than particular nodes that are impacted in their capacity and efficiency?