Swarming Software’s Defence Industrial Implications

Over the past four years, Europe’s – and more broadly the West's –defence industrial landscape has changed significantly. Established defence companies have expanded production capacity to meet demand from Ukraine and Western militaries, while also investing in emerging technologies and new ventures. The most striking change, however, has been the arrival of a new generation of defence companies. Businesses that did not exist a few years ago are now well known across the sector.

Ukraine's need for affordable, rapidly deployable capability has accelerated the use of lower-cost uncrewed systems for both intelligence collection and strike missions. It is therefore unsurprising that many of the more than 230 defence start-ups founded since 2022 have focused on developing drones (broadly defined) and the digital systems that enable them. Many of these companies supply products or components to Ukraine while continuing to invest in R&D of more complex systems that can combine large numbers of systems into so-called swarms – which have significant potential for combat effectiveness – for which they now await larger procurement opportunities across Europe.

As this ecosystem has developed, competing visions have emerged for how autonomous systems or swarms should be controlled and integrated. One approach tightly integrates hardware and software into a closed ecosystem. Another separates the software architecture from the hardware, allowing platforms and sensors from multiple manufacturers to operate together. As European governments, including the UK, move towards larger procurement programmes of these systems, this architectural choice could have long-lasting consequences. Which factors will guide this choice?

Integration and Interoperability Will Become Even More Important

Integration and interoperability will become increasingly important as autonomous systems are expected to operate across multiple domains and, perhaps, across allied forces. If this integration and interoperability is successful, it may be one of the key benefits of these systems in comparison to the existing set of capabilities.

The ability to integrate diverse capabilities into a coherent force will therefore become a key consideration when designing software architectures. Different sensors must be able to share information with software that can combine and interpret multiple data streams. Increasingly, AI performs this task by transforming raw sensor data into actionable information. The AI systems implemented must be able to process diverse forms of data quickly and reliably before securely passing relevant information to operators or other platforms.

In Ukraine, integration has become a battlefield reality: a variety of drones, munitions, and other platforms integrate into a heterogeneous series of networks and digital platforms that form the backbone of Ukrainian command-and-control/digital capabilities. For instance, the DELTA combat digital ecosystem has been described by the Ministry of Defence of Ukraine as ‘a unified source for data exchange, operating everywhere – from laptops and tablets to smartphones – [which] is used by commanders at all levels’.

As defence ministries in Europe and elsewhere move towards larger autonomous systems contracts, they are also, therefore, developing a clear vision for how such a digital backbone needs to look for their specific needs. They must decide how hardware manufacturers and software providers will connect to it, how new capabilities can be integrated over time, and how the overall architecture will evolve. The UK Ministry of Defence has already begun addressing this challenge through its Digital Targeting Web framework, which will form an important part of the digital underpinning of future integration.

Interoperability between allies presents an equally important challenge. NATO forces already exchange targeting information and routinely task one another's capabilities, and will probably seek to do so in swarming. But can this level of integration be extended to autonomous systems? Different algorithms may not always interpret information identically, raising questions about how autonomous systems from different nations should collaborate and resolve conflicting assessments.

Integration across domains and interoperability across allies imply more open architectures over tightly integrated proprietary ecosystems. While closed systems can optimise performance within a single family of platforms, they can make it more difficult to incorporate capabilities from other manufacturers or partner nations and, indeed, more costly to do so. By contrast, more open architectures can provide common interfaces through which a wider range of platforms, sensors and applications can be integrated, offering greater flexibility as technology evolves and coalition operations become increasingly important.

Multiplying Industrial Scale

Software architecture also has important implications for the resilience and scalability of the defence industrial base.

Military leaders envisage future forces built around a mix of highly sophisticated systems and larger numbers of lower-cost, attritable capabilities. Today’s swarming concepts typically involve the latter. These capabilities range from strike drones and loitering munitions (often described as disposable, reflecting their relatively low cost) to uncrewed aircraft, surface vessels, and underwater systems (often described as attritable due to their higher cost and greater survivability compared to disposable systems). Such systems are expected to be consumed at far greater rates than traditional high-end capabilities and therefore require production at much greater scale in the event of a war.

The difficulty is that peacetime demand for these systems remains limited. Most European militaries purchase only enough for training, and sometimes not even that. Manufacturers therefore struggle to sustain the production capacity, supply chains and skilled workforces required for large-scale production. This leaves Europe at risk of losing one of the principal advantages of lower-cost systems: the ability to generate affordable mass rapidly during conflict.

Yet, maintaining large amounts of unused production capacity is not the only solution. Many disposable or attritable systems are considerably less complex to manufacture than high-end weapon systems. They rely more heavily on commercially available components or require less specialised, cheaper production processes. Subject to the availability of raw materials and components, this makes it more feasible for manufacturers of other goods to move quickly towards production of, for example, drones, during a crisis. Economically, this appears more efficient than maintaining expensive idle capacity during peacetime. Through distributing production across a wider industrial base, companies that manufacture civilian technologies in peacetime could contribute components or complete systems during periods of mobilisation. Such an approach would allow governments to generate affordable mass more rapidly while avoiding the costs of permanently maintaining excess production capacity.

For this model to succeed, however, the underlying software architecture must support it. Manufacturers will need access to the system architecture, standards and interfaces to quickly integrate their hardware and software into military command-and-control networks. And these networks will have to be used to and optimised for integrating a multitude of vendors, sensors and software applications. Architectural choices, therefore, become an enabler of industrial mobilisation as much as of operational effectiveness.

Open Architectures Could Benefit Local Defence Innovation

These architectural choices also carry wider consequences for national defence innovation ecosystems.

Separating hardware from the software that enables autonomy lowers barriers to entry for new defence companies. Instead of developing complete end-to-end systems, firms can specialise in producing high-quality platforms or sensors and the associated platform-specific software while relying on common software architectures to provide command, control and autonomy. This allows companies to focus their investments on areas where they have a competitive advantage, potentially improving hardware quality. An example of this is the partnership between Kraken Technology Group, which specialises in the building of autonomous surface vessels, and Auterion, a company that offers software for swarming.

Such an approach could also broaden participation in the defence sector, allowing more innovative firms to compete, and increasing the potential for defence investment to support regional economic growth.

Options for Procuring Autonomous Systems

The benefits outlined above – achieving interoperability, enabling industrial surge capacity and encouraging innovation – all depend on how governments structure software procurement.

One option is to contract software development to a commercial provider while requiring hardware manufacturers to integrate with that architecture. Companies such as Auterion and Shield AI already offer relatively mature solutions that can be deployed relatively quickly with limited adaptation. Many have also established relationships with hardware manufacturers and are accustomed to working with fast-moving defence start-ups.

One of the risks often associated with this approach is so-called vendor lock-in. Awarding a long-term contract to a single provider may reduce incentives for continued innovation while making government (which is the sole buyer of defence equipment) increasingly dependent on a single company to develop, maintain and expand the architecture. This risk, so the argument goes, becomes more pronounced as AI capabilities and third-party applications become more deeply integrated into the system over time.

The UK government has sought to mitigate the risk of vendor lock-in by contracting companies to develop combat management systems while retaining ownership of the resulting intellectual property. It also periodically opens existing contracts for a new round of competitive bidding, requiring the existing contractor to compete against new applicants to win the funding again. This can maintain competitive pressure and encouraging continued investment by suppliers. Another approach is for the government to completely own the development through funding public research institutes; one example is the Unmanned Maritime Autonomy Architecture and associated software, developed by Johns Hopkins University and the US Navy.

However, these approaches have limits. They place the burden of integrating complex systems on the government, requiring it to manage third-party applications and coordinate continuous development. But governments often lack the engineering expertise required for this and can be overwhelmed with the rapid development cycles required to keep enhancing a system as it encounters new challenges. Perhaps even more importantly, R&D spending is the easiest defence expenditure to cut politically – far more so than long-term commitments to personnel and maintenance spending.

Meanwhile, the significant demand across NATO countries and Ukraine, and the influx of capital that came with it, may have fixed some of the traditional market failures of defence. Companies are more confident and able to make investments into future products, as many markets are open to them, not just one, due to the high demand. The sprouting of defence start-ups across NATO demonstrates this development. As they invest, companies become strongly incentivised to continue innovating and ensuring their product or service is competitive in as many markets as possible. Indeed, letting industry own and develop a convincingly competitive system may even drive international adoption – Systematic’s SitaWare command-and-control software, widely adopted by NATO Allies, is an example of that. Thus, it may be more sensible for forces to make use of companies’ upfront investments, instead of paying for an expensive replication of this technology in order to own the IP. Instead, governments could set standards for software architecture that require companies to take a modular approach allowing different, specialised hardware from independent companies to plug into control systems. They could also implement regular re-competitions to incentivise continuous development.

Conclusion

The software architecture for autonomous systems will shape interoperability with allies, determine how rapidly industry can scale production during a crisis, and influence whether new defence companies can compete and grow.

Realising the operational and industrial benefits of multidomain swarming will therefore depend on not only the hardware governments procure, but also how they structure the relationship between software developers, platform manufacturers and the state. Whatever procurement model is ultimately chosen, these architectural decisions will require sustained strategic attention.

This commentary draws on a private roundtable on the operational and industrial dimensions of swarming as a decisive force, attended by government, military and industry stakeholders. The views expressed here are the author’s. AI-enabled copy-editing tools were used in the writing of this article.

© RUSI, 2026.

The views expressed in this Commentary are the authors', and do not represent those of RUSI or any other institution.

For terms of use, see Website Terms and Conditions of Use.

Have an idea for a Commentary you'd like to write for us? Send a short pitch to commentaries@rusi.org and we'll get back to you if it fits into our research interests. View full guidelines for contributors.