The tender document has already chosen the architecture: what procurement decides before the architect arrives

The architect is invited to the project kick-off. The contract is awarded and signed, the teams are in place. The scope is presented: three lots, three suppliers, a go-live date already announced to the executive committee, a fixed price per lot. They are asked to “ensure the coherence of the whole”.

Within days they discover that the boundary between lot 1 and lot 2 runs straight through the customer master. That the requirements were written as a list of features lifted from the current system, which means the chosen solution will have to reproduce rules whose rationale nobody remembers. That the fixed-price model makes every mid-project discovery expensive to absorb. And that the supplier was selected on a scoring grid where purchase price weighed heavily and integration capability weighed almost nothing.

None of these decisions was taken against them. They were taken without them, nine months earlier, in a document they never saw, written by competent people doing exactly their job: framing a need, securing a fair competition, protecting the organisation legally.

This is the ordinary situation, and it rests on a misunderstanding about sequence. A tender is not the administrative step that precedes architecture: it is the moment when a large part of the architecture is decided, by people who do not know they are deciding it, in a vocabulary that does not name it. What gets signed is not only a price and a scope. It is a set of design constraints, an allocation of responsibility between systems, and an invisible list of options that are now closed.

Why tendering escapes architecture

Three structural properties explain this, and they are better looked at than complained about.

The tender pack belongs to a different process. It has its own calendar, its own committees, its own vocabulary and its own legal obligations. It is prepared by procurement, legal, the sponsoring business unit, sometimes a client-side advisor. Nothing in that circuit contains a box marked “architectural consequences”, and nothing requires one to appear. Architecture is not excluded by decision: it is simply outside the scope of the form.

You have to write with the most precision at the moment you know the least. This is procurement’s own paradox. A tender demands contractual detail before any design work, and therefore before the questions that will drive the real cost have been examined: the state of the data to be migrated, the behaviour of existing interfaces, the gap between the rules on paper and the rules actually applied. The precision the contract requires does not match the knowledge available, and the gap is filled with what is at hand: a description of the current system.

Irreversibility changes nature at signature. Before, an option is a discussion. Afterwards, it has a price, an owner and a procedure. The architect who arrives later is no longer working on choices but on concessions: every correction becomes a change order, which is to say a subject on which the supplier has an interest in the original scope prevailing. That is not bad faith, it is the normal mechanics of a firm commitment.

The practical consequence is simple and requires no reorganisation: architecture has to be present at the drafting, not at the award. What remains is knowing what to look for.

The architectural decisions taken without being named

A tender pack contains at least five structuring decisions. None of them presents itself as one.

Splitting into lots draws the boundaries of the system. Lotting is done for good reasons: widening competition, avoiding dependence on a single supplier, keeping the market accessible to firms of different sizes. In public procurement, some of these rules are imposed outright. But a lot boundary never stays contractual: it becomes an integration boundary, and therefore an interface, an exchange contract, an operational break point and a zone of argument about responsibility on the day of an incident. Lotting that cuts through the middle of a business object — the customer on one side, their contract on the other, with no ruling on who owns the data — creates a permanent coexistence nobody designed. The question to ask is not “should we split this?” but “where is the integration cost of this cut lowest?”, and that question is an architectural exercise.

The form of the requirements decides the form of the bids. A requirement written as a list of features invites a bid that ticks boxes, and a comparison that turns on compliance tables rather than architectures. The costlier drift is subtler: when the requirement is written by describing how things work today — “the system must allow the same fields to be entered, in this order” — the organisation buys its own past at the price of something new. It funds the continuation of rules it has not re-examined, and turns habits into contractual obligations. Expressing requirements as capabilities and expected outcomes is not a matter of drafting elegance: it is what leaves the supplier free to propose a different way of doing things, and the organisation free to accept it.

The contracting model sets the tolerance for change. A fixed price on a stable, well-understood need is an excellent instrument. The same fixed price on an uncertain need produces a predictable effect: everything learned along the way becomes a change order, therefore a negotiation, therefore a conflict — and the supplier’s interest becomes delivering the literal scope rather than the useful outcome. More flexible arrangements move the difficulty without removing it: they assume a real internal steering capability, which means people available to arbitrate continuously. No model is superior. What matters is that the choice matches the level of uncertainty — and assessing that uncertainty is an architectural judgement, not a contracting preference.

The award criteria are the real specification. An unweighted requirement is not a requirement: it is a wish. Everything that genuinely matters afterwards — the quality of the interfaces, the documentation of the data model, the exit conditions, the ability to change configuration without the supplier — disappears if the scoring grid does not account for it. Conversely, a weighting dominated by purchase price mechanically selects the bids that push costs beyond the evaluated period. An organisation gets exactly what it weighted, and it always gets it.

The announced timeline eliminates options before any examination. A go-live date communicated before design is not a scheduling constraint: it is an architectural filter. It rules out from the start every trajectory that assumes a coexistence phase, a progressive data migration or a prior decoupling, and it makes the single cutover the default option — not because it was judged preferable, but because it is the only one that fits the stated deadline.

What belongs in the tender, and almost never is

A tender cannot anticipate everything, and it would be dishonest to pretend otherwise. But a small number of clauses decide what the organisation will still be able to do in five years. They have one thing in common: they all concern the aftermath.

Data ownership, expressed as mechanisms rather than principles. Everybody signs that the data belongs to the client; that sentence protects nothing. What protects rests on four specifics: in what format the data can be returned, against what documented model, through what mechanism accessible without proprietary tooling, and how often that mechanism is actually exercised. An extraction never performed during the life of the contract will be discovered at the worst possible moment — the moment the relationship deteriorates.

Interfaces treated as contracts. Requiring “APIs” is not enough. A useful interface is specified, versioned, and comes with a compatibility rule and a notice period for breaking changes. The clause almost always missing is the one naming who bears the cost of adaptation when the supplier changes its interface for its own reasons. In its absence, the default answer is: the buyer, indefinitely.

Exit conditions, and proof that they work. Reversibility must describe what is returned, within what timeframe, at what price and with what support. Above all, it must be exercised at least once outside a crisis. A reversibility clause that has never been tested is not a guarantee, it is an intention drafted while both parties were still in agreement.

Non-functional requirements attached to the business capabilities they serve. Stated globally, they produce one of two failures: they vanish, or they are set at the most demanding level for the entire scope — and paid for at that level everywhere, including where nothing justifies it. Attaching each availability, recovery-time or retention requirement to the business capability concerned turns a declarative list into a set of fundable commitments.

Environments, test data and access to logs. This looks too operational to belong in a tender. Yet it decides the ability to run serious acceptance testing, to prepare a data migration and to diagnose a production incident without depending on the supplier for every question. What the contract does not provide for will be billed case by case, or politely declined.

The change regime after go-live. A contract that describes construction in fine detail and says nothing about what follows leaves the organisation without leverage over the phase where it will spend most of the lifecycle. It should state how a change request is assessed, what it costs, who decides, and what the organisation may modify itself without the supplier’s involvement. That last clause matters more than any other to its future autonomy.

Evaluating a bid on what it makes possible

Bid evaluation is the second moment when architecture is decided without being named. Comparing compliance tables tells you how good the bidders are at filling in tables. Three questions tell you more.

What does this bid make difficult later? Every solution closes doors; the point is not to avoid that but to know which ones. A bid that assumes the organisation adopts the product’s data model is not disqualified by that fact — it may well be the right choice — but it must be evaluated in full knowledge of what it implies for exchanges, extraction and future change.

Where do the dependencies sit? Look for the places where knowledge becomes inaccessible: configuration expressed in a proprietary language, business logic buried in undocumented scripts, a data model only the supplier can read. A technical dependency can be worked around; a knowledge dependency is paid for every year.

What happens if this product changes strategy? A vendor can be acquired, a product line discontinued, a licensing model revised. The question is not to predict these events but to know what they would cost — which amounts to assessing the exit clause on its practical feasibility rather than its wording.

One practice improves evaluation more than any scoring grid: asking bidders to work a concrete case rather than declare compliance. Describe the interface they would have to build with a named existing system, explain how they would migrate a real and imperfect dataset, say what they would do with a contradictory business rule. The differences between bidders appear immediately, and they concern what will actually matter.

It is worth staying clear-eyed about the limits of the exercise. A contract does not produce good architecture; it makes consequences visible at the moment of choice that would otherwise surface two years later. That is a modest and considerable function: most expensive decisions are not contested decisions, they are decisions taken without anyone seeing what they committed to.

What architecture must hold

Architecture’s role in a tender is not to write the pack, nor to supervise procurement. It is to make explicit the architectural decisions already sitting inside it.

That means being there at the drafting rather than at the award, which is less a question of reporting lines than of timing: as soon as scope and lotting are under discussion, the window is open; at publication, it is shut.

Producing a short architecture note that accompanies the tender — system boundaries, business objects concerned, the system of record for each, expected interfaces, non-negotiable constraints. A few pages saying what is not up for negotiation beat a technical dossier nobody will read.

Having the lotting examined against its integration cost, with the question framed in procurement’s own terms: each lot boundary is an interface to specify, fund and operate, and that weighs against the expected benefit of wider competition.

Taking part in the weighting of the criteria, which is the most effective and most neglected lever available. An architectural requirement absent from the scoring grid does not exist, however well it was drafted elsewhere.

And recording these trade-offs as architectural decisions, with their alternatives and their reasons. The chosen split, the contracting model and the weighting will all be questioned in three years, when their effects show up; it helps if the answer does not depend on the memory of whoever was in the room.

The last window where options are free

A tender is the last moment when architectural options cost nothing. As long as the pack is unpublished, moving a boundary, rewording a requirement or changing a weighting takes a conversation. After signature, the same change has a price, a lead time and a balance of power.

Which is why the question to ask before publishing is not only “have we expressed everything?”. It is “what does this document make impossible?” — and if nobody around the table can answer, the architectural decision has certainly been taken, but no one saw it happen.

You never buy only a solution. You buy a set of dependencies, a boundary between what you will be able to do alone and what you will have to ask for, and an exit cost that will one day be the real measure of the freedom you kept.