How to Architect for Competitive Tension (So You’re Never Stuck With One Supplier)

Procurement can only create competition if the architecture lets you leave. Four patterns that keep the option real, and one trap that quietly removes it

Patch cables running from a server rack to three network wall ports

On 1 October, PublicTechnology reported a written answer from a Cabinet Office minister, Baroness Twycross, saying the government “seeks to maintain competitive tension and to reduce dependency on any single supplier” by promoting a diverse technology estate. The same piece noted that a Competition and Markets Authority report on public cloud had found significant market power among the largest providers.

I’m not going to comment on the politics. But “competitive tension” is a phrase worth borrowing, because it describes something every large buyer wants and most fail to keep: the position of dealing with a supplier who knows you could leave.

That last part is the whole game. And it is mostly an architecture problem.

The problem in one sentence

Medium-sized and large organisations buying software and cloud services have too few suppliers and too little leverage over them.

You can write the most careful procurement framework in the world and it will still be toothless if the thing being bought is woven through everything you run. A tender only creates competition if a credible alternative exists on the day you issue it. Whether one does is decided years earlier, by engineers choosing how to build things.

Why this is an architecture problem

Procurement happens at a point in time. Lock-in accumulates continuously.

Each sprint, someone makes a sensible local choice: use the supplier’s queue because it’s right there, store the data in their format because it’s their default, write the business rule in their workflow tool because it’s quicker.

None of these is wrong on its own.

Together, three years later, they mean that “switching supplier” has stopped being a procurement decision and become a rewrite, with a price that dwarfs any saving the competition might produce.

The supplier knows this. Your negotiating position is exactly as strong as your cheapest credible exit, and the architecture sets the price of the exit.

So the useful question for an architect isn’t “which supplier?” It’s “what would it cost to leave, and do we know?” Here are four patterns that keep that number low.

Pattern 1: put an abstraction layer where your logic meets theirs

Don’t let your application code talk directly to a supplier’s API all over the codebase. Define a small interface in your own terms (store this document, send this message, authenticate this user) and put one adapter behind it that translates to the supplier.

The rule of thumb: the supplier’s name should appear in one place per capability. If you search the codebase for it and get hundreds of hits, you have a dependency rather than an integration.

Keep the interface boring and deliberately narrow. If you design it by copying every feature of the first supplier, you have just recreated their API with extra steps, and no second supplier will fit it. Design to what you need, then see how many suppliers can meet it.

Pattern 2: keep your data in open formats

Data outlives applications. It’s also the part that hurts most to move, because it’s the part with years of history in it.

Prefer formats that have more than one implementation and a public specification: standard SQL and CSV or Parquet exports, JSON with a documented schema, open document formats, standard identity protocols such as OpenID Connect and SAML. Be sceptical of anything where the only way to read your own data is through the supplier’s tool.

Then test the exit, rather than trusting the brochure. Run an export. Load it somewhere else. Check that the relationships, history and attachments survived. An export button that nobody has ever pressed is a hope, not a capability.

Pattern 3: don’t put core logic in proprietary managed services

This is the one that needs the most judgement, because managed services are often excellent and I’m not suggesting you build everything yourself.

The distinction I use is between commodity and core. Hosting, object storage, plain virtual machines and containers, standard databases: these are broadly interchangeable, and renting them from whoever is cheapest this year is sensible. But the rules that make your organisation what it is (eligibility, pricing, risk scoring, case routing) should live in code you own, running on infrastructure you could move.

A useful test is to ask whether an equivalent exists elsewhere that you could point the same code at. Containers on any cloud: yes. A proprietary low-code workflow with your eligibility rules drawn as boxes inside it: no. If the logic can only run on one supplier’s platform, then the supplier owns your business rules, whatever the contract says.

Pattern 4: write down your exit criteria before you sign

This is the cheapest of the four and almost nobody does it.

At the point of selection, when everyone is optimistic, write a short document answering: what would make us leave? What would leaving involve? How long would it take, and what would it cost? What data and what skills would we need to have to hand?

It doesn’t need to be long. A page is fine. It does three things. It forces the exit cost into the open while there’s still time to design it down. It gives you a basis for the contract (data return, notice periods, assistance on termination). And it gives whoever is in your seat in five years a map, rather than an archaeology project.

Review it annually. If the answer to “how long would leaving take?” has crept from months to years, that’s your early warning, and it’s much cheaper to hear it then than at renewal.

Measuring it: fitness functions for exit cost

A page of exit criteria goes stale unless something keeps checking it. Architectural fitness functions are automated or scheduled checks that tell you when the design is drifting away from a property you care about. Here, the property is how cheaply you could leave.

The headline metric is an estimate of developer time to switch away from each supplier, in person-weeks, for the capabilities that matter. Have the team re-estimate it each quarter and plot it. A number that only ever rises is the warning you wanted.

Cheaper checks sit underneath it:

None of these needs to be precise. They need to be tracked, cheap to run, and visible to the people making this month’s decisions.

Where this pays off

Here’s a generic example, not one based on any single client. An organisation runs a case-management system on a supplier’s platform. Early on, the team puts a thin layer between their own services and the platform’s API, exports data nightly to an open format in storage they control, and keeps their routing rules in their own code. They write a one-page exit note.

Four years on, the supplier proposes a large price rise at renewal. Because the alternatives are real, the buyer is able to scope a replacement properly: the data is already portable, the integration surface is one adapter, and the rules don’t need re-implementing. They don’t necessarily leave. They don’t have to. The credible option changes the conversation, and the renewal lands far closer to what they wanted to pay.

The organisation next door, with the same supplier and a platform full of embedded logic, gets the same letter and no leverage whatsoever. The technical difference between the two is smaller than you’d think. It was made in dozens of ordinary decisions long before anyone mentioned a tender.

Where it falls down: the nice-looking thing that locks you in

Every pattern above has a way of quietly failing, and it usually arrives wearing a benefit.

It’s the integrated feature that saves a fortnight of work and costs your portability. It’s the free tier of a proprietary service that becomes the thing everything depends on. It’s the “just this once” shortcut to a supplier-specific API from application code, because the abstraction layer is awkward and the deadline is Friday. It’s the discount tied to commit levels that is generous this year and a handcuff next.

Be especially wary of anything cheap because it ties into the rest of the supplier’s ecosystem. Bundling is the main lock-in mechanism, and it feels like a bargain at the time because it genuinely is one, for a while.

There’s a version of this that starts outside engineering. A product manager reads the supplier’s product manual, finds a feature that nearly does what the business wants, and says, “The supplier already does this, so we can just use that.” It sounds like thrift. It is also how your requirements quietly become the supplier’s feature list.

So make it a rule: a requirement is written in the organisation’s own terms (the outcome, the user, the rule) before anyone looks at what a supplier offers, and a supplier-specific feature can only be adopted through the abstraction layer, or with a recorded exit cost that someone senior has signed off. “The supplier has this” is a reason to investigate, not a reason to adopt.

The discipline isn’t refusing all of these. It’s pricing the exit cost into the decision, writing down that you’ve chosen to accept it, and making sure someone else will see it. Lock-in you chose knowingly is a trade-off. Lock-in you drifted into is a liability.

Perfect portability isn’t the goal either. It’s expensive, and most organisations that chase it end up with lowest-common-denominator systems that use nothing well. The aim is a credible exit at a cost you’ve measured and can live with.

Takeaways

For architects: treat exit cost as a quality attribute, alongside security and performance. Measure it, record it and review it.

For buyers and procurement teams: ask your technical colleagues how long leaving would take before the tender rather than during it. If they can’t answer, you don’t yet have competitive tension; you have a preference.

And for both: competition is something you maintain by design, not a thing you win once at contract signature. The leverage you’ll have in five years is being built, or quietly spent, in this month’s pull requests.

Source: PublicTechnology, “Minister cites need for competitive tension in government cloud and software landscape”, 1 October 2026, https://www.publictechnology.net/2026/10/01/business-and-industry/minister-cites-need-for-competitive-tension-in-government-cloud-and-software-landscape/ (accessed 11 October 2026).