In many organisations, architecture governance comes down to a single body: a board that meets every two or three weeks, reviews submissions, and issues an opinion. The intent is sound — ensure coherence, prevent structural decisions being made in isolation. But as the number of teams, products and platforms grows, that single body turns into a bottleneck. Submissions pile up, lead times stretch, and the teams that have to ship quickly learn to route around the mandatory checkpoint.

The paradox is unforgiving: the more governance tries to control everything, the less it actually controls. What it gains in theoretical completeness it loses in adherence. This article looks at how to escape that trap — not by removing governance, but by changing its nature: moving from an up-front control point to a framework that guides decisions as close as possible to where they are made.

The symptom: the board that says no

The pattern is familiar. A team needs a green light on a technical choice: a database, an integration pattern, an exception to a standard. It prepares a submission, gets on the agenda, waits its turn. Two weeks later, the board asks for more information. Two weeks after that, a conditional opinion. Meanwhile the project has fallen behind, or — more often — has pressed ahead anyway, ready to regularise the choice after the fact.

This produces three perverse effects. First, governance becomes a perceived brake rather than a help: the architect is the one who slows things down, not the one who sheds light. Second, it drives workarounds: decisions get made outside the body, and governance now sees only a fraction of what is actually happening. Third, it concentrates knowledge in a handful of people, creating a fragile dependency — when the board is unavailable, everything stops.

The root of the problem is not the principle of governance but its model: centralised control, exercised case by case, ahead of every decision. That model held when structural decisions were rare and far apart. It buckles under volume the moment an organisation starts shipping continuously.

Why centralised control does not scale

The difficulty is arithmetic before it is cultural. A central body has a fixed throughput: so many submissions per session. But the number of architecture decisions grows with the organisation — more teams, more products, more platforms, and now the rise of AI systems and data products multiplying the decision points. The gap between the flow of decisions to be made and the body’s capacity to absorb them keeps widening.

Faced with that gap, two spontaneous responses exist, and both fail. The first is to filter: only bring the board the “important” decisions. But who decides what is important before the review? You recreate a judgement ahead of the judgement. The second is to speed up the cadence of meetings. That pushes the wall back a few months without changing the nature of the problem.

The real way out lies elsewhere: stop handling each decision individually and start equipping the decision — giving teams the framework that lets them decide for themselves, correctly, without routing through a central point. This is the shift from governance by control to governance by framework.

From control to framework: guardrails

A guardrail does not stop you moving forward; it stops you leaving the road. Applied to architecture, the principle is simple: rather than reviewing each decision case by case, you define in advance the space within which teams are free to decide on their own, and you reserve explicit review only for the choices that fall outside that space.

In practice, this means making explicit three things that classical governance often leaves implicit:

  • Guiding principles. A small number of structural rules, clearly stated, that express what the organisation favours — reversibility of cloud choices, decoupling of services, contract-based interfaces, data classification. Not a hundred-page catalogue: a handful of principles anyone can cite.
  • Sensible defaults. For recurring decisions, a recommended option that you follow without having to justify it. Choosing the default requires no authorisation; departing from it is what triggers a discussion. This inverts the burden: the common case flows, the exception gets examined.
  • The exception zone. The boundary beyond which a decision must escalate: major financial commitment, sensitive data leaving a controlled perimeter, hard-to-reverse dependency on a vendor. The board does not disappear — it refocuses on the small number of decisions that genuinely warrant it.

The warning deserves to be stated plainly: a framework without guardrails is not autonomy, it is fragmentation. Delegating decisions without defining the limits produces not agility but silent drift — each team optimises locally, and overall coherence dissolves. A framework is not the absence of rules; it is a set of rules clear enough that you no longer need a referee on every play.

Decentralising the decision without losing the memory

Delegating decisions raises an immediate question: how do you keep track of what is decided, and why? Without an answer, decentralisation produces organisational amnesia — choices made locally, never recorded, that have to be reconstructed by archaeology six months later.

The instrument that answers this need is the recorded architecture decision (widely known by its acronym, the ADR — Architecture Decision Record). The principle is deliberately lightweight: each structural decision becomes a short, standardised note answering four questions.

  • Context. What situation forces a choice? What constraints bear on it?
  • Decision. What was decided, stated unambiguously?
  • Alternatives. Which options were set aside, and for what reasons?
  • Consequences. What the decision entails — the expected benefits, but also the constraints and the debt it creates.

The value of this format is that it makes the decision visible, traceable and revisable without gathering anyone. The note lives where the teams work, next to the code or the models; it is dated, versioned, and leaves a durable trace of the reasoning followed. A decision is documented where it is made, not in a report no one reopens.

This shift changes the architect’s stance. It is no longer about rendering a verdict on each submission, but about defining the format, watching over the coherence of the whole, and stepping in on the decisions that truly commit the organisation. Governance moves from exhaustive review to reading the lines of force.

Automating assurance instead of multiplying reviews

Recording a decision does not guarantee it is honoured over time. A rule written into a standard and then forgotten across releases protects nothing. This is where an idea from evolutionary architecture, increasingly applied to governance, comes in: the fitness function.

A fitness function is an automated, objective, repeatable test that checks that an architectural property remains true as the system evolves. Where a human review notices a deviation after the fact, the fitness function flags it the moment it appears. The formula that best captures the complementarity: the recorded decision documents the choice, the fitness function assures it holds.

The examples are concrete, not theoretical:

  • Automatically verify that no component in a given layer calls directly into a layer it should not reach — adherence to a decoupling rule becomes a test, not an inspection.
  • Check that every exposed interface honours its published contract, and reject a change that would break compatibility.
  • Automatically surface any storage of sensitive data outside the authorised zones.

This logic, often gathered under the terms policy-as-code or architecture-as-code, turns architectural intent into an executable statement. The benefit is not to replace human judgement — it remains essential for non-trivial decisions — but to free that judgement from mechanical checks that had no business in a meeting. What a machine can verify, a meeting should not have to.

A federated operating model, not a single board

Together, these levers describe an operating model different from classical centralised governance. It is often called federated, or hybrid: a deliberately lean central architecture function that defines the principles, the guardrails and the format of decisions; and domain or product teams that decide within that framework, close to the ground.

The central function’s role then shifts from control to enablement. It spends less time judging submissions and more time equipping teams: providing solid defaults, maintaining the principles, running a community of architects who share their decisions and their reasons. Coherence no longer comes from a mandatory checkpoint but from a common framework and a shared culture.

This model demands a careful balance. Too much centralisation, and you fall back into the bottleneck. Too much decentralisation without guardrails, and you slide into fragmentation. The balance point is neither universal nor fixed: it depends on the maturity of the teams, the criticality of the systems, the sector. A regulated organisation does not set the dial in the same place as a young structure — and that dial moves as teams gain autonomy.

Governance that proves itself continuously

One dimension remains that board-based governance struggles to satisfy, and that becomes decisive in regulated environments: the ability to demonstrate that governance works, at any moment, and not merely to attest that it exists.

A board produces minutes. They prove that a body met and issued opinions. They do not prove that the decisions made are actually applied in production systems. Yet that is precisely the proof that regulators, auditors and executives increasingly ask for: not “do you have governance?” but “can you show, today, that your systems comply with the rules you set?”.

The model described here answers that demand better, because it leaves a continuous trace rather than a periodic one. Recorded decisions form a readable history of the why. Fitness functions provide, at all times, the proof of compliance. Together, they move governance from a periodic event — the meeting — to a continuously verifiable state. That is a change of nature: governance stops being something you organise and becomes something you can observe.

Guide without gating: a stance, not a tool

None of the above is about removing governance. The point is to redefine it: to move it from control exercised decision by decision to a framework that makes good decisions easy to take and bad ones hard to take without noticing. The board does not disappear; it refocuses on the small number of choices that truly commit the organisation, and stops being the mandatory gate for all the others.

This shift calls for a change of stance in the architect. Their value is no longer measured by the number of submissions they review, but by the quality of the framework they put in place: clear principles, solid defaults, well-recorded decisions, rules that can be checked without a meeting. Successful governance is the kind that becomes unobtrusive — the kind teams barely notice, because it was designed to carry them rather than to stop them.

That is exactly what guide without gating means: giving the organisation the freedom to decide fast, within limits sharp enough that it never has to slow down to stay coherent.