The Ship Beneath the Ship
Why Shared Digital Infrastructure Will Decide the Next Naval War
Walk around a modern frigate or destroyer and the obvious things catch your eye. The radar mast. The missile silos. The main gun. The flight deck. These are the visible symbols of naval power and, for more than a century, they have defined how we judge a warship’s capability.
Yet increasingly, none of them works alone.
Hidden beneath the steel is another ship. One made not of bulkheads, pipework and machinery, but of shared computing, secure networks, data and software. It is largely invisible to visitors, yet it may prove to be one of the most important parts of the ship.
The next revolution in naval warfare may not be a new missile or a more powerful radar. It may be the digital architecture that allows every system onboard to work together, adapt and continue fighting when parts of the ship have been damaged or disconnected.
The hardware increasingly provides the platform, the software delivers the capability.
Every generation has its revolution
Naval history can be viewed as a succession of technological revolutions.
Steam replaced sail.
Steel replaced wood.
Electricity replaced many hydraulic and mechanical control systems.
Missiles displaced guns as the principal long-range weapon.
Today we are experiencing another transition, but this one is different. A single piece of equipment does not define it. It concerns the way the entire ship is designed and how its combat power is generated.
Traditionally, every major capability onboard brought its own dedicated hardware. Navigation, communications, electro-optics, weapons control, electronic warfare and combat management required separate computers, networks and support equipment.
As new capabilities were added during a ship’s life, more cabinets, cables and proprietary processors followed. Each system came with its own supply chain, training requirements and upgrade cycle.
The result was often a collection of highly capable systems that worked alongside each other rather than as one integrated whole.
That model is beginning to change.
From equipment to infrastructure
The Royal Navy’s Shared Infrastructure programme represents a fundamental shift in naval engineering. Rather than every capability requiring its own dedicated computing hardware, multiple applications can be hosted on a common, secure digital backbone.
At its simplest, this brings together shared computing, resilient networks, data storage and common operator consoles. Applications remain separated where security and safety require it, but they no longer necessarily need a unique cabinet and processor of their own.
Shared Infrastructure is already used across several Royal Navy ship classes, from Offshore Patrol Vessels to the Queen Elizabeth-class carriers. It is being installed aboard the first Type 26 frigates, HMS Glasgow and HMS Cardiff. BAE Systems describes its origins as extending back to initial deployments in 2015.
The commercial comparison is tempting.
We no longer buy separate devices for music, photography, satellite navigation and communications. A smartphone delivers all of these through software running on shared hardware.
A warship is obviously more complex. Weapons safety, security classifications, real-time processing and the need to survive combat prevent any direct comparison with a consumer device. But the underlying direction is similar.
The hardware increasingly becomes a common platform upon which different capabilities are delivered.
That matters because it changes more than the equipment fit. It changes the relationship between the warship and time.
Combat at the speed of software
For much of the twentieth century, improving a warship meant altering the ship itself. Installing a new radar, weapon or command system could require new cabinets, fresh wiring, additional cooling and a lengthy dockyard period. Capability development moved at the pace of naval procurement, shipbuilding and major refit cycles.
Shared infrastructure begins to loosen that relationship.
Some improvements will still require new sensors, processors or weapons. A software update cannot create electrical power, generate cooling capacity or place another missile in the magazine.
But an increasing proportion of combat capability can evolve through software:
Sensor fusion.
Threat recognition.
Electronic-warfare libraries.
Communications.
Decision support.
Management of uncrewed systems.
Artificial intelligence.
This does not mean that untested code can be sent directly to a deployed warship. Naval software must be assured, integrated and certified, particularly when connected to weapons or navigation. It does mean that capability can potentially be improved far more rapidly than through a traditional refit.
The United States Navy is moving in the same direction. In 2024, USS Winston S. Churchill became the first ship using a fully virtualised Aegis combat system to intercept an air target with a missile. The US Navy described this as part of its effort to move from multiple segregated systems towards a single integrated combat system, supported by a common hardware and software development pipeline. US Naval Sea Systems Command
The significance is not simply technical.
Threats, tactics and algorithms can now change much faster than ships can be built. If a navy needs years to incorporate each improvement, it risks deploying vessels whose digital capabilities are already falling behind.
A software-defined warship does not eliminate the need for shipbuilding. It allows the ship to continue evolving after it has left the shipyard.
Fighting through degradation
The true test of shared infrastructure will not come during a demonstration. It will come after systems begin to fail.
Naval combat has always involved degradation. Sensors may be damaged. Communications disrupted. Power lost. Networks attacked. Compartments may become inaccessible.
The question is not whether every system survives. It is whether the ship retains enough capability to continue fighting. A well-designed shared architecture could allow applications to be moved between surviving computing resources, while alternative sensors and offboard sources continue contributing to the tactical picture.
If a radar is lost, electro-optical sensors, electronic-support measures, passive sonar, another ship, an aircraft or an uncrewed system may still provide useful information. Shared infrastructure can help bring those sources together and present them coherently to the command team.
But this resilience is not automatic.
Moving several capabilities onto common infrastructure can also create common points of failure. The loss of a network backbone, power supply, cooling system or critical software layer could affect several functions at once.
Physical separation still matters. Redundancy still matters. Damage control still matters. So do degraded operating modes that allow essential systems to function when the wider architecture is unavailable.
The ship will only fight through degradation if that requirement has been designed and tested into the architecture from the beginning.
Resilience must become a property of the whole ship, not merely a promise attached to individual systems.
AI joins the crew
Artificial intelligence fits naturally into this model.
One misconception surrounding military AI is that it will arrive as a separate black box, installed beside the existing combat system. In practice, AI is more likely to appear as a collection of services operating across the ship’s digital infrastructure.
One application might help classify sensor contacts. Another could monitor machinery data for signs of failure. Others might support route planning, intelligence analysis, logistics or the management of un-crewed systems.
Each application could draw upon different data while supporting different members of the crew. This reinforces an argument I have made before. The AI fleet is not one brain, and AI does not need to become the captain of the ship.
It can instead become part of the operations-room team, helping people process information, identify patterns and manage complexity without displacing human command. Shared infrastructure makes that possible. It allows AI to become pervasive without necessarily becoming dominant.
It could also provide controlled environments in which new applications are evaluated against representative data before being trusted with operational functions. The difficult work remains assurance: proving what the software can do, understanding how it can fail and deciding which decisions must remain firmly with people.
The hidden vulnerability
Every technological revolution creates new strengths and new dependencies.
As more capability moves onto shared digital infrastructure, protecting that infrastructure becomes a war-fighting task in its own right.
Cyber resilience can no longer be treated as an IT problem.
Power and cooling become combat functions.
Software assurance becomes as important as weapons assurance.
Configuration management affects operational readiness.
A warship could carry an excellent radar and a capable missile, yet fail to exploit either if its software configuration is wrong, its data is corrupted, or the architecture connecting them has been compromised.
Adversaries will understand this. They may not need to attack every sensor individually if they can disrupt the infrastructure that connects them.
There is also an industrial question.
If shared infrastructure depends upon proprietary interfaces controlled by a small number of suppliers, a navy may gain technical flexibility while losing commercial freedom. Software-defined capability can still become locked into long contracts, closed architectures and slow approval processes.
Open standards and modular designs can help, but “open” does not mean unrestricted. Safety-critical naval systems still require firm design authority, controlled interfaces and rigorous assurance.
The challenge is to create an architecture open enough to evolve, but controlled enough to trust in combat. That balance may prove just as important as the technology itself.
Designing the software-defined warship
For generations, naval architects have designed hulls around machinery spaces, magazines, sensors and accommodation.
Future designs will increasingly need to treat data architecture as another fundamental part of the ship.
That changes the design process.
Naval architects, marine engineers, combat-system specialists, cyber professionals and software developers can no longer work as a succession of separate disciplines. Decisions about power, cooling, compartmentation, network routes, redundancy and computing capacity will directly influence the ship’s ability to evolve and survive.
It also changes procurement.
There is little value in building a software-defined warship if every software change must pass through a process designed for replacing physical equipment. Continuous technological development requires continuous assurance, integration, training and operational feedback.
The Royal Navy has already begun using the phrase “at the speed of software” when describing its experimentation with scalable infrastructure and common architectures. The challenge will be turning that ambition into an enduring way of delivering frontline capability. Royal Navy, Trident Sprint
Shared Infrastructure is therefore not the destination. It is the foundation upon which the software-defined warship will be built.
The ship beneath the ship
The most powerful fleet of the future may not be the one carrying the greatest number of missiles or the most sophisticated radar.
It may be the fleet best able to connect its sensors and weapons, absorb new technology and continue operating when parts of that digital architecture are attacked or destroyed.
History remembers HMS Dreadnought because she reshaped battleship design. The defining innovation of the next generation may be much harder to photograph. It will lie beneath the steel, connecting sensors, weapons, people and autonomous systems into a fighting whole.
The next generation of warships will still be built from steel. Their weapons will remain physical, and their survival will still depend upon sound naval engineering and trained people. But increasingly, they will adapt, fight and recover through software.
The ship beneath the ship may ultimately prove to be the one that decides the battle.
Further reading
BAE Systems: Shared Infrastructure
A useful introduction to the Royal Navy’s shipborne hosting environment and how common computing supports multiple combat and mission systems.US Naval Sea Systems Command: Virtualized Combat System Completes Critical Navy First
Describes the successful missile engagement by USS Winston S. Churchill using a fully virtualised Aegis combat system.Royal Navy: Technology Demonstration Boosts Royal Navy’s Hybrid Transformation
Shows how the Royal Navy is experimenting with common architectures, scalable infrastructure and delivering capability “at the speed of software”.RUSI: Prototype Warfare in the Maritime Domain
Sidharth Kaushal and John Louth examine how modular, software-defined systems could support faster experimentation, operational feedback and selective scaling.
Richard, this is an exceptionally well-balanced treatment of the software-defined warship. The decisive shift is not simply from hardware to software, but from installed capability to the rate at which trusted combat effect can be generated, adapted, and restored under degradation.
Shared infrastructure creates extraordinary leverage, but it also creates synchronization debt: the same integration that multiplies capability can enlarge the blast radius of failure. The winning architecture will therefore be neither merely open nor continuously updateable. It must be partitioned, recoverable, and sovereign—able to shed damaged functions, reallocate surviving compute, and regenerate a minimum viable fighting system before the adversary can exploit the disruption.
The next naval battle may ultimately be decided not only by firepower or decision speed, but by recovery latency—which fleet can restore operational coherence first after its digital ship has been wounded. Superb work.