The problem: we're still buying software like it's the 1990’s
Across most industries, the way complex software systems are procured has evolved significantly. For air traffic management (ATM) systems, the approach hasn’t really changed.
Three decades ago, the commercial model for buying bespoke software (in any industry) looked a lot like buying hardware. The model was to define requirements up front, agree a fixed scope and price, accept delivery, and then move into maintenance. The software industry treated its products almost like physical goods; you bought something and maintained it until support wasn’t available anymore, and then you bought the next one.
Over time, much of the software sector moved towards subscription models, software-as-a-service (SaaS) and more agile development approaches. The commercial and delivery models evolved to reflect what software actually is: something that can and should keep evolving after you buy it.
ATM system procurement has been slower to make the same shift, partly because the agile/SaaS solutions have been harder to apply and harder to assure for safety-critical aviation. So, it’s perhaps not surprising that even when procurement processes are updated to enable more modern practices, suppliers still respond through traditional commercial models such as turnkey, big-bang or fixed-scope delivery - even though the technology and wider market have moved beyond it.
I've seen this first-hand recently, when we had to explain to a major vendor that our client wanted to stay on the vendor's supported software baseline rather than be frozen on a static branch. The reaction suggested that this was still unfamiliar ground. It showed how strongly the industry can still default to older delivery assumptions.
How other sectors have responded
Let's step outside ATM for a moment and look at how the rest of the world buys and delivers software.
Adobe used to sell you a boxed product. You bought Photoshop, used it until it felt dated, then bought the next version. Now it's a subscription-based service with regular access to updated tools, features and fixes. Users are no longer left waiting for the next upgrade cycle. The product evolves, and you evolve with it.
Microsoft 365 went through the same transition. Office used to be a box on a shelf - you bought Office 2007, lived with it for years, then bought Office 2013. Now it's a subscription that updates continuously. For many, that shift happened gradually and has become the norm.
These examples present a broader shift in how software is delivered to the end user. They represent a fundamental change in how the software industry operates, from selling static products to providing platforms that continue to develop over time. Now, I know what the immediate response may be: ‘This is consumer and enterprise software. The ATM sector is safety critical. It's different.’ Is it though? Let's look at what other safety-critical sectors are doing.
Tesla pushes over-the-air (OTA) software updates, including safety-critical functions, to vehicles that operate at motorway speeds. NHTSA, the US vehicle safety regulator, now formally recognises OTA updates as a valid recall mechanism. If regulators can accept continuous software updates in a safety-critical environment, the argument that an ATM system is too safety-critical to evolve post-delivery starts to look very thin.
Defence is probably the closest structural parallel to ATM with long-lived platforms, sovereign concerns, and rigorous safety and security requirements. The US Department of Defense concluded that traditional waterfall procurement was taking over 10 years to deliver software and created a dedicated Software Acquisition Pathway to move towards agile, continuous delivery. The UK MOD's Digital Strategy makes the same argument: platforms with 30-year lifecycles still need their software refreshed every 6 to 12 months. If defence has concluded that traditional software procurement models are no longer sufficient, that is clearly relevant for ATM systems as well.
The banking sector provides another useful comparison. It is not safety-critical in the aviation sense, but it is highly regulated, systemically important and extremely risk-averse. Yet banks have also had to move away from static technology models towards more modular platforms, continuous security patching, cloud-enabled services and regular software releases. They have done this carefully, with strong governance and assurance, but the direction of travel is the same. Industry after industry, including those operating under the most demanding safety and regulatory requirements, is moving away from static, fixed-scope delivery towards continuous evolution. ATM is not alone in facing these challenges, but the sector has been slower than many others to adapt procurement models to the way software now evolves.
The real challenge: bespoke vs. product baseline
Most ATM systems are still bespoke, or at least heavily customised with unique features, so a one-size-fits-all product isn’t viable today. The existing as-a-service models in most industries offer customers no bespoke functions and no real control over the product roadmap.
Air navigation service providers (ANSPs) have specific operational requirements, some of them bespoke, and that has major implications for how systems are procured and maintained.
When moving to a unified platform, maintaining bespoke features incurs technical costs. Imagine a bespoke version of Spotify that can import and play music in a format no one else uses. Every time Spotify pushes an update to the core platform, someone also has to make sure all those custom features still work. That is where much of the cost sits, not in the core platform update itself, but in maintaining the bespoke layer on top of it.
In ATM terms, a vendor releases a new flight data processing approach, but the ANSP has a heavily customised version of the flight data processing core. The vendor can update their product. But updating the ANSP's customisations on top of it? That's where the complexity, cost and risk really sit. It results in legacy components that require distinct knowledge to maintain and continue to integrate – the technical debt of maintaining a sub-optimal solution.
In many cases, technical debt now plays a bigger role in driving a system’s end of life than hardware obsolescence. The more bespoke you go, the more debt accumulates, and the harder it becomes to keep up with the product baseline.
The mobile phone analogy is useful here from an architectural perspective. The OEM builds the device hardware and the low-level drivers that allow the operating system to interact with it. The operating system, developed by platform providers such as Google or Apple, then sits above that hardware layer and below the user applications. This separation is what allows app developers to use camera, location, connectivity and processing capabilities without writing bespoke code for every phone model. If ATM systems could achieve a similar separation - a core product baseline with well-defined interfaces, and bespoke operational functions sitting above it rather than embedded deep within it - the continuous delivery model becomes far more achievable.
The sector is not there yet, but this is clearly the direction in which it is moving.
A new procurement philosophy: defining ‘future-proofed’ in practice
The question is how to address this within a public procurement context, particularly in an oligopoly market. We've been working on exactly this question with ANSPs recently, and here's what we've learnt.
Signal your intent
Make it clear from the outset that you're not looking for a business-as-usual solution. A well-designed request for information (RFI) and down-selection process helps here - it signals to the market that this procurement is different, and it filters out vendors who aren't willing or able to think beyond the traditional model.
Be bespoke, but know the limits
ANSPs will always have specific operational needs. But the further you push into bespoke territory, the more you need to ask ’how can we, as the purchaser, support the vendor in maintaining this?’ That might mean co-investment in local development centres, joint R&D arrangements, or shared implementation resources. Bespoke doesn't have to mean isolated, but it does require both sides to commit to making it sustainable.
Stay on the vendor's supported baseline
Don't let yourself get isolated on a static or frozen software branch. If the vendor moves on and you don't, you're building a legacy system from day one. Make this explicit in the procurement. Evaluate and score the strength of each supplier’s product roadmap and baseline evolution strategy.
Price what you know, with mechanisms to deal with unknowns
There are functional capabilities and feature evolutions that an ANSP can reasonably define today, so price those into the tender. We have clear global roadmaps that help define these. But don't try to price unknown future needs. That is rarely realistic in practice. Instead, set up contractual mechanisms - a development ‘pot’, rate cards, agreed governance - to handle future requirements as they emerge.
Write requirements in a way that enables continuous evolution
Move away from prescriptive, solution-driven specifications. Focus on outcomes and functional needs, allowing vendors to propose how their product baseline can meet those needs - and continue to evolve against them over time.
The underlying strategic objective is to enable the ANSP to operate a system that remains up to date, supportable and genuinely future-proofed throughout its lifecycle. In this context, ‘future-proofed’ replacement should be manageable and non-disruptive.
Systems will still reach end of life
Any system will eventually reach a point when keeping it ‘current’ costs more than migrating to something new. That's true of your phone, your car, and your ATM system. The question is whether the procurement model can push that point further out - and whether, when it does arrive, it's a planned strategic transition rather than a reactive response to an unsupportable platform.
With the right model, where the ANSP stays on the vendor's supported baseline, bespoke elements are managed through proper governance, and technical debt is actively minimised. You could sustain a well-maintained ATM platform for over the typical 15 years. Replacement should be driven by a strategic choice, rather than by obsolescence.
What does this mean for the market?
This has important implications for the structure of the supplier market, because if you change how ATM systems are procured and maintained, you fundamentally change the market dynamics around them.
The oligopoly problem
ATM system suppliers operate in an oligopoly. A handful of major system suppliers dominate the global market. That’s always been the case, but the shift towards continuous delivery changes the dynamic.
If ANSPs move towards deeper, longer-term vendor relationships to enable continuous system evolution, there is a risk of greater vendor lock-in. This means that procurement strategies should be designed to maintain competitive tension - through modular architectures, open interfaces, separation between the core product baseline and ANSP-specific functions and, where possible, multi-vendor approaches - even within what is essentially a long-term partnership. The objective is not to avoid long-term supplier relationships, which are often unavoidable in ATM, but to ensure those relationships remain contestable and do not become dependency by design.
This creates a difficult balance. Continuous evolution depends on a close collaborative vendor relationship, but the market still needs enough contestability to maintain competitive pressure.
From obsolescence-driven to strategy-driven replacement
Historically, the trigger for replacing an ATM system has been obsolescence. The hardware ages out, the software becomes unsupportable. In many cases, replacement becomes reactive and happens under considerable time and support pressure.
But if systems genuinely stay current through continuous delivery, the driver for change becomes strategic. Does this platform still align with my operational concept? Does a competitor’s offering unlock capabilities I can’t get here? Is there a better value proposition on the market?
Take the mobile phone market. What would it take for you to switch from iPhone to Android – away from an ecosystem with which you are comfortable? In most cases, people switch not because the phone has failed, but because another platform offers better value, features or fit. That is a fundamentally different basis for decision-making, and generally a more strategic one.
This changes the procurement cycle. Instead of a 15-year cliff edge followed by a reactive procurement, ANSPs move towards ongoing strategic assessment, with the genuine freedom to stay or switch.
The shift to service orientation
The move towards service-based, layered ATM architectures does not automatically turn system procurement into a managed service model. But it does create the technical conditions where the relationship between ANSP and vendor may become closer to an ongoing service relationship than a one-off system purchase. That’s a totally different commercial model. In effect, it brings service-based software models into a safety-critical environment.
That in turn raises important questions about safety, sovereignty, regulation, and how you maintain competition in a market that increasingly involves a set of long-term service relationships. In practice, this is likely to be a hybrid model rather than a conventional SaaS arrangement. ANSPs will still need strong control over safety-critical operations, assurance, resilience and data, while vendors provide more continuous software evolution and support.
None of this is easy, but the industry is at an inflection point. ANSPs that continue to rely on the older model are likely to repeat the cycle: decade-long procurements, static systems, obsolescence-driven replacements. Those that embrace continuous delivery, service orientation, and strategic vendor management will operate more current, more resilient systems, and will have far more control over their own future.
Other software-intensive sectors have already moved in this direction. ATM now has an opportunity to do the same in a way that reflects its own operational and regulatory context.
--------------------------------
Photo: DSNA
