Why can’t the government achieve interoperability?

Author: Guy Bewsher

28 Jan 2026

Let’s be honest, the history of government IT projects is not a good one. They are often late, overly complex, highly expensive, fail to deliver what the user needs, and are stove-piped. There are many and varied reasons for this, chief among them the desire by both customer and supplier to ring-fence a requirement to give it firm boundaries, which inevitably leads to solutions reminiscent of a goldfish bowl and the inevitable requirements creep as projects drag on.

Some in industry have taken a different course, and in doing so have built companies that are in the top five most valuable corporations on the planet. While you may or may not like their products, it is their business model that differs so markedly from the way government has operated.

The Bezos mandate

In 2002, Jeff Bezos issued his famed design mandate. Governments and government departments would do well to follow his example. His direction was admirably brief and was not open to interpretation:

  1. All teams will henceforth expose their data and functionality through service interfaces.

  2. Teams must communicate with each other through these interfaces.

  3. There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back doors whatsoever. The only communication allowed is via service interface calls over the network.

  4. It doesn’t matter what technology they use. HTTP, Corba, Pub/Sub, custom protocols – doesn’t matter.

  5. All service interfaces, without exception, must be designed from the ground up to be externalisable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

  6. Anyone who doesn’t do this will be fired.

128 words. Half as many as the Gettysburg Address and just as influential. How many data policies, data standards, and data strategies has the MOD, let alone the rest of government, had in the last 23 years?

A platform, not a collection of projects

What Bezos recognised almost a quarter of a century ago was that Amazon needed to be a platform in its own right. His edict instilled in the company a services-led approach, based on a service-oriented architecture. His threat to sack anyone who disobeyed helped drive a single company culture and eliminated special cases and private empires. Indeed, Bezos hired an enforcer, Rick Dalzell, to make sure they did not occur.

Dalzell’s presence, and the implementation of what we now call spiral development – try it, fail fast, iterate, try again – meant that those in charge, in our speak Senior Responsible Owners (SRO), were in fact Senior Accountable Leaders. Those in charge could not make ill-judged, short-term decisions, knowing that the ramifications would not be noticed until several SROs later. Rapid iteration exposes people to creating point solutions for a single use case.

Accessibility beats lock-in

The Bezos business model of owning the platform and allowing any third-party vendor to access it by exposing “the interface to developers in the outside world”, relies on strict adherence to joining rules through APIs.

By contrast, government policy is often to hand over the platform or core enablers to a Prime Contractor, who then locks down the solution to prevent accessibility by third parties.

Bezos’ genius was in creating accessibility. Amazon, and indeed Google and Apple, have little or no product to sell. Google even gives away its Android operating system for free. These companies could not have grown to be among the largest in the world if they tried to develop all the solutions in-house. They are among the most valuable precisely because they do not, generally, supply products, just services.

Interoperability is about data, not networks

Bezos was not so much interested in security. It is important, but not a major stumbling block, because in adopting a services approach, Amazon was implicitly focusing on data, and data interoperability, not on networks.

In traditional government solutions, security has been the opposing force to accessibility and the desire for open systems. If you focus on the data rather than the network, you can secure your platform and screen the data entering it. You do not have to bother with the other junk in the Open Systems Interconnection (OSI) model,] where malicious code might hide.

Legacy systems are not an excuse

By now, you are probably saying, “Great, but Apple was a greenfield site. The MOD alone has thousands of application goldfish bowls, the UK’s National Health Service (NHS), thousands more. We can’t replace the lot.”

And indeed, the history of massive Government IT procurements suggests that it would not be a good idea.

What you can do is add the APIs retrospectively. Those APIs need to do two things:

  • Label the data in the attached systems

  • Extract data, not schemas

In this way, you can migrate legacy, network-centric, isolated solutions to data-centric, interconnected and secure solutions, thus protecting previous investments. At the same time, government could, and should, adopt the Bezos approach across all IT procurements.

Platforms prevent stagnation

Bezos’ approach did not so much create an architecture as a platform onto which any number of apps could be added. Currently, the store has approximately 810,000 of them.

That means users can start small and grow over time, adding and replacing capabilities as requirements and solutions evolve. This prevents atrophy within a solution and helps prevent requirements creep. It also means the buyer does not need to try to future-proof a capability by second-guessing what may be needed in decades.

MOD is already proving the model

Fortunately for MOD, Dstl identified this approach and, using Nexor as its principal developer, created an API-based solution that takes data from legacy systems and allows it to be shared with any application across its platform, concentrating on data, not networks.

This solution was the core capability used recently by MOD to enable data sharing during its largest ever UXV interoperability trial. It allowed UK, US, Norwegian and NATO systems to share data at CWIX and REPMUS. 

Read more posts on

About the author

Guy Bewsher has been at the forefront of technological innovation, combining deep expertise with a forward-thinking approach. In 1996, he worked as a contractor for DERA, exploring the potential of synthetic environments; now known as AI; to streamline and enhance military decision-making processes. This research contributed to advancements like the Single Information Environment (SInfoE) MVP, driven by Dstl’s SIE and Comms and Nets programs. Through a series of four blogs, Guy will delve into the impact of AI on the battlespace and explain how the SInfoE is central to achieving the Integrated Force vision.

Guy Bewsher on Linkedin

Read more posts by Guy Bewsher