The defense industry does not have an innovation problem. It has a speed of integration problem.
Artificial intelligence is moving into operational systems. Autonomous platforms are getting more common, capable and cheaper. Sensors are proliferating. Software is continuously changing what a platform can do years after it leaves the factory. Everything is network capable. Some of the most important capabilities reaching the field now come from companies that did not exist ten years ago, alongside traditional defense companies still building our most complex weapons systems.
That is the ecosystem we need. Now we have to make it work together.
Defense agencies that gain the most from AI and autonomy will not be the ones with the best algorithm, the best unmanned vehicle or the best sensor. It will be the ones that can put new capability into their formations faster than its adversary can.
Integration speed is a warfighting advantage. We must start treating it like one, which means we need to start measuring it.
Start the clock
Cost and schedule are tracked on every program across defense agencies. Integration time is tracked on almost none.
The new metric: how long does it take, from the day a useful capability is identified, until a formation can use it?
Not integrated into a lab. Used. By a unit, on its network, against its mission, with its data.
Consider a program I supported early in my career.
When the program was restructured, fielding was scheduled to begin two years out. It began five years out. Ten years in, and several billion dollars spent, the program had reached roughly twenty formations and was being fielded at a rate of about two brigades a year. Then the procurement was halted.
Two brigades a year. That was the clock speed of the program, set against a commercial networking industry that turned over its entire product capabilities several times in the same window.
What made it slow was integration. Operational test reporting found the same system had to be worked separately into one combat vehicle after another, and that some of those vehicles did not have the space or the power to take it. Every platform was its own project. Every project received the same capability at a new price.
That was not a failure of engineering. The people on that program, me included, built what was asked for, and an earlier version of it provided capabilities to the Warfighter. It was a failure of architecture. We designed a network as an end item instead of as something a formation could absorb, and then we were surprised that absorbing it took a decade.
If that number is measured in years, we will lose to technology that changes in months. If we can get it to weeks, the arithmetic of the fight changes: an adversary gets one adaptation cycle while we get six.
This is measurable today. It needs no new authority, no new program and no legislation. It needs the community to write down two dates.
The formation is the platform
For most of the industrial era we built military capability around platforms. Design a tank, an aircraft or a ship, then integrate everything the mission needs inside it, and by commercial standards, it becomes relatively static.
AI, autonomy and software broke that model. The formation is now the platform.
An unmanned aircraft detects something. AI characterizes it. The data crosses a network. Another system builds a targeting solution. A different platform acts on it. No single vendor owns that chain, and no single platform contains it. The capability lives in connections.
So open architecture cannot just mean publishing interface specifications. It has to mean introducing a new sensor, application, network or autonomous system without redesigning everything around it, quickly and repeatedly, using subject matter experts in each domain rather than a generalist dabbling across all of them.
Autonomous systems need a common language
The proliferation of collaborative autonomy across multiple functions and weapons systems makes this urgent. Future formations will operate systems from many manufacturers, with sensors, payloads and software that change constantly. Each one cannot arrive carrying its own integration project.
Imagine instead an autonomous system joining a formation and introducing itself: what it is, what it can do, what sensors it carries, what data it produces, how it can be tasked and how it communicates. The architecture translates that into the command-and-control and data environment the formation already uses.
That takes common protocols and genuinely open architectures. It also takes competition. Government agencies should be able to choose the best autonomy software, the best sensor, the best communications and the best vehicle without requiring them to come from the same company.
We already know it can go faster
Last summer an armored brigade ran an experiment with about twenty capability providers. Autonomy companies, sensor companies, networking companies. Most of them small and many of them new to the Army.
Instead of each one solving the integration problem on its own, they integrated once into a common data layer. One published an integration guide. A remote integration lab was open for roughly two months before the exercise. Vendors normalized their outputs into a common set of data standards, and that data was aggregated and pushed to the brigade’s picture, so the commander saw one view of everything on the field rather than a dozen separate ones.
More than a dozen of the twenty integrated successfully.
Now the second number. Of those same twenty, roughly three had completed the cyber authorization needed to get onto the Army network.
Those two numbers must be considered together, because they are the entire argument. Technical integration was not the hard part. It ran in weeks, against a published specification, in parallel across a dozen companies that had never worked together. The approval process ran in months, and most of the field never finished it.
We have spent years treating integration as an engineering problem. On that field, it was not.
Who has the right to integrate?
This is the question I would put at the center of every program review, and it is the one we discuss least. Integration rights are not a contracts detail. They determine whether the government can keep choosing capabilities or has to keep asking for them.
Questions to ask:
- Who owns the interfaces? If a new vendor needs a competitor’s permission to connect, that is not an open architecture.
- Who owns the data models? Undocumented schemas lock a formation in more tightly than any hardware ever did.
- Can the government direct a third party to integrate on its own architecture without renegotiating?
- If the incumbent will not move fast enough, what is the alternative, and how long does it take to exercise?
Programs should be measured not only by what their systems can do today, but by how easily they accept what comes next. Can we field a new application in weeks rather than years? Substitute a sensor? Add another manufacturer’s autonomous system? Run new AI on hardware already fielded? Re-task and reorganize systems across formations?
We cannot build a software-defined force on an acquisition model designed around hardware-defined platforms.
What I am asking for
America’s innovative defense technology ecosystem is a strategic advantage. Traditional defense companies, new entrants and commercial technology providers bring different strengths, and the country is better served when all three compete, and more importantly, cooperate. But an ecosystem only converts into overmatch at the point of integration, and integration is a discipline rather than a byproduct of being large. It should be done by whoever does it best, on architectures the government owns.
To acquisition community: measure integration time on every program and report it alongside cost and schedule. Make integration rights an evaluated requirement, not a clause someone finds later.
To industry, including my own company: publish interfaces, document data models and compete on capability instead of on lock-in. No company should have to become a vertically integrated prime to reach the warfighter.
To Congress: fund architectures and integration capacity, not only platforms and end items. Connective tissue rarely has a constituency, and it is where the advantage now lives.
To investors: the compounding returns in this market will belong to the companies that make other companies’ technology work together at speed.
We cannot predict which technology will prove decisive five or ten years from now, and we should stop trying. We can build formations that absorb whatever turns out to be decisive faster than the other side can.
Start the clock. Then shorten it.