What does "software-defined" actually mean?
The neo-primes say 'software-defined', but what does that mean in practice? I've captured some thoughts for what it could actually mean for how a warship is designed, built, operated and sustained.
Introduction
I spent over a decade working to ensure the Type 23 frigates operated by the Royal Navy could serve for double their design life, while being updated and upgraded so they remained able to deliver leading-edge capability. The complexity of that programme brought the integration of numerous updates, upgrades and modifications, each improving the vessel's ability to float, move and fight, alongside the work of making ageing ships a more palatable place to live and work for the women and men on board. All of this while addressing the extensive material degradation of years’ operating in harsh conditions. Do that for long enough and the case for modularity makes itself.
Modularity not only offers the ability to de-latch updates and upgrades programmatically; it enables the work to be de-coupled and delivered using very different planning and delivery processes, and different infrastructure. The next generation of warships being built to replace the Type 23s recognised that, with the introduction of mission bays and open architecture. But even that does not go as far as the concepts behind the new Hybrid Navy, which off-board sense, decide and effect from the monolithic hull altogether.
"Software-defined capability" is now commonplace in the defence industry. The emerging neo-primes use it frequently to argue for a different approach to delivering and enabling effect, seeking to disrupt the traditional primes with greater agility, greater modularity and a faster route into service. It is easy to see how that applies to a system that is inherently software-intensive, but how does it apply to building or supporting a warship?
I should say from the outset that this series is not an argument about whether the neo-primes will displace the traditional primes, or the other way round. Where approach they describe is useful, then the question that matters is how the whole industry adopts it, so that capability reaches the front line faster and the industrial base that delivers it is sustainable. That is the test I will keep coming back to throughout. Where I draw on my own experience, most of it on the support side of this industry, I say so, everything else is from the public record.
I recall trying to explain the concept on board a ship in refit to a mixed group of early-career apprentices and seasoned industrial technicians. We were standing in an empty compartment that had been stripped bare, with sections of the deck and bulkheads cut out to replace degraded structure. On a toolbox, and taped to the bulkhead, were drawings showing how a new system would be installed. The team saw the ship as something structural, like a building, so how can something structural, that floats and moves, be software-defined? I am fairly sure that my talking about the ship as an iPhone and its systems and equipment as the apps was a bit of a stretch…I’m not sure I convinced myself.
With the recent production awards in the US for medium uncrewed surface vessels, the acceleration towards a Hybrid Navy in the UK, and a largely legacy fleet being operated and sustained today, I thought I would revisit that discussion.
Where ‘software-defined’ comes from
Firstly, increased connectivity and agile methods to deliver capability are not new Early in my career the ambition was Cooperative Engagement Capability; that gave way to Open Architecture, and then to System of Systems, and ‘Smart Fitting’. Each was a different idea, but what they had in common was the difficulty of working out what the term meant in practice. ‘Software-defined’ is the latest in that line, although the difference this time is that the vocabulary is being set as much by the new entrants as by the customer, and that it arrives with the confidence of an industry that has already proven it elsewhere.
The phrase itself was coined well away from warships, with one of the places it appeared first being radio in the mid-1990s, where waveforms were set by software rather than circuitry.[1] The term then spread to networks and data centres until it reached most of us through our cars. A software-defined vehicle is one whose core functions are controlled, updated and improved through software rather than fixed hardware. The hardware and software are decoupled, where new features arrive over the air, and a hundred separate control units collapse into a handful of central computers. In modern cars today, some capabilities are sold as software after the car has left the factory.[2] That version of the software-defined vehicle is proven at scale, so nobody can dismiss it as 'hype', but it also holds a cautionary tale. The industry that proved it now reports a strong, hard-to-change mechanical culture, and its executives do not expect to have the software workforce they need until 2034. The industry that proved the idea built its software organisations before it had decided what they would own, and paid for it. I will come back to this at the end of this series.
What it seems to mean at sea
The best naval definition I have found is an argued piece, rather than doctrine, where two US naval officers describe warships as "computers on keels", with commercial compute, a standard software layer and upgrades delivered as code rather than refits. The one live example was seen in 2024 where the US Navy pushed software updates to its destroyers in the Red Sea while they were engaging missiles, without bringing them home.[3] That is a crewed warship with a modern combat system behaving the way a car does. Although it is a good description of one ship, it is not yet a description of a Fleet.
So rather than trying to define the word, it might be more helpful to describe the structural change instead. If the fighting capability moves into off-board systems and swappable payloads, the hull's remaining jobs are to float and to move. The hull becomes the platform and the capability becomes the apps. That is the iPhone analogy from the conversation in the ship compartment. ‘Software-defined’ at sea then means three things: capability that changes at the pace of software rather than of a refit; capability that is physically modular and can be swapped; and capability that increasingly leaves the hull altogether.
And the word is no longer confined to what fights. Anduril, which announced this month that it is to make submarine components in Maryland, describes the new yard as a "software-defined shipyard".[4] Support will ultimately need to follow, because when the maintainer is no longer on board, keeping the vessel floating and moving becomes a question of data, diagnosis and who does the maintenance. So there are at least three readings to test: software-defined capability, software-defined build, and software-defined support. This article is about the first. The series then dwells on build and support, because that is where the UK's choices are least examined. The pace at which capability itself can be adopted and updated is the thread underneath all three. The real test though is not whether the phrase sounds 'modern', but whether it changes how the work is actually done.
Float, Move, Fight is not a new idea
Modularity is not a new concept in naval design and operations. The Royal Danish Navy's StanFlex system dates from the early 1980s as standard modules in standard slots across nine ship classes, designed to enable a swap in about half an hour, though the public record is silent on how often they are actually swapped.[5] The MEKO class of vessels took a slightly different route, seeking to address build modularity rather than mission modules. Thirty-four MEKO 200 frigates serve eight navies, and three of those navies have fitted new missiles, radars and combat systems in mid-life.[6] The US Littoral Combat Ship set out to do both and fielded one of its three mission packages, although to my knowledge no serving LCS has ever swapped modules to change mission.[7] The lesson is not that modularity fails, rather that it works for what containerises well (such as mine countermeasures, survey, medical and communications), and less well for what is deeply coupled to the ship's power, command and data. So Float, Move and Fight have been separable on paper for forty years, but now the emphasis shifts to how Fight can leave the hull.
Where the UK is now
The Type 26 was designed from the outset with a flexible mission bay, able to take containers, boats and uncrewed vehicles, with its handling system contracted in 2018.[8] NavyPODS, the Royal Navy's containerised payload concept, dates from 2021, and its first module at sea is a medical one, trialled on HMS Protector this April. 20 PODs have been built so far,[9] and in May the Ministry of Defence said delivery timelines "remain subject to ongoing assessment".[10] There is no mission-system POD in the public record - so far it is the ‘hospital’ that has been modularised, and not yet the weapon.
The declared direction is clear. The First Sea Lord's principle is "uncrewed wherever possible; crewed only where necessary", and his picture of the North Atlantic is a Type 26 in company with two uncrewed escorts carrying sensors, weapons and decoys, the first being delivered within 2-years.[11] Industry has followed with concepts, from BAE Systems' uncrewed warship on an existing trimaran hull[12] to Navantia UK's LASV-75, uncrewed from the keel with eight container slots.[13]
Beyond the concept designs, the contracts so far are small. 20 modular vessels for the Surface Flotilla at about £600k each,[14] and a contractor-owned, contractor-operated sensing network for the Atlantic.[15] For now, concepts and tender notices run ahead of ships in the water.
What this changes
If the hull floats and moves and the capability lives elsewhere, then almost everything downstream changes.
Design, because the interfaces matter more than the platform.
Build, because a simpler hull should be faster to build, though the evidence for that is thinner than the announcements suggest.
Support, because, most of all, the maintainer who kept the ship fighting is no longer aboard. The dependencies shift too, as the many equipment suppliers behind each payload are suddenly on the critical path.
Buying, because you are buying a platform and a capability rather than a ship.
People, because the next apprentice in that compartment will spend a career in an industry that looks more like software than steel.
It also raises a fundamental question about survivability, and about how long a hull should 'live'. The Royal Navy's record is that ships either run far past their design life because the replacement is late, or are cut short by a spending review. The Type 23 was designed for an eighteen-year hull life and its survivors are past thirty.[16] The Vanguard class was designed for twenty-five years and will serve at least thirty-seven.[17] Albion and Bulwark were planned to 2033 and 2034 and went in March 2025.[18] If the fast-changing systems leave the hull, the thirty-year platform may no longer be the right assumption in either direction.
There is a quieter piece of economics underneath that. For decades the initial capital outlay meant residual value in the hulls at the end of their service life. The UK has historically disposed naval assets to other navies: three Type 23s went to Chile in 2005 for about $250m, at 12-15 years old.[19] That residual value depended on a ship being a durable, general-purpose asset that another navy would crew and run for another twenty years. If the next generation is either attritional or designed to different economics with more frequent recapitalisation for the same overall value, then the second-owner market thins out, and those navies will likely buy new vessels at the same price point. The second batch of five Type 26 frigates was contracted at £4.2bn, about £840m a ship before government-furnished equipment.[20] The US Navy's new medium uncrewed vessels are being bought at about $40m each.[21] That arithmetic is the real argument for autonomous mass: a great deal more presence at sea for the same money, without adding naval headcount. It is also why the question of how long a hull should live is not an academic one.
