Procurement writes architecture before an engineer opens the editor.
Public-sector technology procurement reliably delivers systems that are expensive, late and locked in. The engineers involved are no worse than anybody else; here at AxisOps we've worked alongside plenty of them. The structure selects for the outcome.
The mechanism¶
Procurement exists to transfer risk to a supplier. That's a reasonable goal, and it produces a predictable set of second-order effects:
- Large contracts favour large suppliers, because the compliance overhead of bidding is a fixed cost. A £40m framework excludes the ten-person firm that could do the work, and competence never enters into it.
- Risk transfer requires specification up front, which requires knowing the answer before the work begins. Everything learned during delivery becomes a variation, and variations are where the money goes.
- Exit is almost never specified, because whoever writes the contract is buying a system, not planning to leave it. The cost of leaving gets discovered later, by somebody else, usually in a hurry.
None of that is corruption. It's an incentive structure paying out on what it rewards.
The architectural consequence¶
A system procured this way has its architecture settled before an engineer is anywhere near it. If the contract names a vendor's platform, the architecture is that platform. If it specifies an outcome and transfers the risk, the supplier picks whatever minimises their risk, which is rarely what minimises your long-run cost.
So the technical decisions that matter most (data formats, interface boundaries, where state lives) get made implicitly, in a document written by people who would be surprised to hear they were making technical decisions at all. It's like signing off the floor plan before anybody has asked where the drains go.
What changes the outcome¶
Three things, none of them new, all of them structural rather than technical:
- Specify the exit, not just the entry. A requirement to export all data in a documented format, exercised annually as an acceptance test rather than promised in a clause. An untested export clause is worth nothing at all.
- Buy capability in increments small enough to cancel. The sunk-cost dynamic on a large programme is the single biggest driver of good money going after bad.
- Treat interfaces as the procured thing. Specify the boundaries and test them, and whatever sits behind one is replaceable; that's the only real protection against lock-in you can buy.
It is worth being concrete about the prize, because the critique above is familiar and the upside rarely gets described.
A council that specified interfaces rather than systems could buy its revenues and benefits processing from one supplier, swap it in four years for a better one and keep the data where it was. That is not a fantasy; it is how the payments industry works. The reason you can change bank without losing your transaction history is that somebody specified the boundary rather than the vendor. Applied to public services, the thing that becomes cheap is the second decade. Right now every programme pays twice: once to build, and once more in eight years to escape what was built. The escape is usually the larger number.
The smaller prize is more immediate and would change a lot of working lives. A specification that names formats and interfaces is one a ten-person firm can bid into. There are a great many such firms who could deliver a school admissions system or a licensing portal better and cheaper than a systems integrator, and they are excluded today by the cost of bidding rather than by capability. Lower that barrier and the public sector gets access to a supplier base it currently cannot reach, and those firms get to exist in towns where there is no other technology employer. That is industrial policy done by contract drafting, which is cheaper than industrial policy done by grant.
There is a resilience argument too. A service assembled from replaceable parts degrades when one part fails. A monolithic platform from a single supplier stops. Anybody who has watched a region's social care system go dark because one company had a bad weekend understands which of those they would rather own.
The framework is where the choice narrows, because it is presented as the solution to the problem it causes.
A framework agreement exists to save time: pre-qualify a set of suppliers, then call off against it without running a full procurement each time. Reasonable. What it does in practice is set the list of companies who are allowed to sell to government for the next several years. Its qualification criteria (turnover thresholds, insurance levels, reference contracts of comparable scale, security certifications priced per audit) are a filter on size rather than on competence. For any substantial lot the answer ends up being the same handful of integrators and, increasingly, the same three cloud providers underneath them.
The hyperscaler layer is the part that has changed and the part least discussed in the contract. A department can switch integrator and stay on the same cloud, which looks like competition and is not, because the dependency that would be expensive to unwind is the one nobody tendered for. Egress pricing, managed services with no equivalent elsewhere and identity systems that the whole estate now assumes: each is a decision made by an engineer under delivery pressure, and together they are a sovereign commitment made without a sovereign decision. The data is in the country, which is what the clause asked for. The dependency is not.
Where is the open, ownable version? It exists and it loses on procurement rather than on merit. Open-source infrastructure has no vendor to pre-qualify, no sales team to respond to a framework notice and no commercial entity to carry the liability the contract requires. So the better technical answer cannot bid, which is a structural defect in the buying process and not a judgement about the software. The fix is unexciting and known: buy the integration and the support as the contracted thing, specify the software as open and require the exit test annually.
Here at AxisOps this is the business we are in, so treat it as a declared interest and an argued position: we build infrastructure that the customer owns, can inspect and can rebuild without us. A system you can only operate while the supplier's invoices are being paid is not an asset on your balance sheet, whatever the accountants have written down.
Why it's on an engineering site¶
Because engineers keep trying to fix this downstream, with better architecture inside a contract whose shape already decided the outcome.
The leverage is upstream. An engineer who can read a procurement document and say "this clause means we won't be able to leave in eight years" is doing more valuable work than one optimising the thing that's going to be abandoned anyway. Learn to read a contract; it is the highest-leverage unglamorous skill in public-sector technology.