Architecture governance in agile organisations

What architecture governance is for

Architecture governance is the set of practices by which an organisation makes sure its significant technical decisions are made well, are consistent with its goals and are actually followed. It answers four questions: who may make which decisions, how they should make them, what direction they should take, and how anyone knows whether the result conforms.

The purposes are practical. Governance aligns technology with strategy, so that fifty teams do not choose fifty ways to store customer data. It manages risk and compliance: data protection, security, accessibility and sector regulation all need evidence that rules are followed. It limits unnecessary diversity, because every additional database, language or messaging product needs skills, patching and on-call support. It protects qualities that no single team owns, such as end-to-end latency, security and cost. And it spreads learning, so that a lesson paid for by one team is not paid for again by the next.

Agile organisations feel a tension here. The Agile Manifesto's principle that the best architectures emerge from self-organising teams (Section 1.8) pulls towards autonomy; scale, regulation and shared infrastructure pull towards alignment. Henrik Kniberg's descriptions of Spotify's engineering culture popularised the phrase aligned autonomy for the goal: teams free to decide how, within a shared understanding of what and why. Governance is the machinery that makes that possible. Done badly, it becomes the slow approval process of Section 11.2; done well, teams barely notice it, because the right thing is also the easy thing.

Principles, standards, guardrails and gates

Governance uses four kinds of instrument, which differ in how much they constrain and when they act. Principles express durable direction and leave room for judgement. Standards are specific, mandatory choices (all services expose OpenTelemetry traces; all public APIs are described in OpenAPI). Guardrails keep teams within safe limits while they work, usually automatically and continuously. Gates stop work until someone approves it.

The modern consensus, though not a universal one, is to prefer guardrails over gates wherever a rule can be stated objectively, to keep gates for the few decisions where accountable human judgement is genuinely required, and to hold those gates early and time-boxed. A paved road (Netflix's term; Spotify calls it a golden path) complements both: when the supported way of building a service already includes approved images, logging, security scanning and deployment, most teams conform without being told, and governance effort can concentrate on deliberate departures. Section 10.7 covers the platforms that provide such roads.

Writing architecture principles

TOGAF, the Open Group's enterprise architecture framework (the TOGAF Standard, 10th Edition, 2022), gives a widely used template for principles with four parts. The name is short and memorable. The statement says the rule in one or two unambiguous sentences. The rationale explains the business benefit, in terms that a non-technical sponsor could accept. The implications say what the principle requires in practice: what must be done, what it costs and what it rules out. TOGAF also lists criteria for a good set of principles: understandable, robust (precise enough to decide difficult cases), complete, consistent and stable.

Two tests catch most weak principles. First, could a sensible organisation choose the opposite? "Systems should be secure" fails; nobody would choose insecurity. "Prefer buying to building for generic capabilities" passes, because some organisations rightly prefer to build. Second, does the principle change a real decision? If no one can name a choice it would settle, it is a slogan. Andrew Harmel-Law asks for a set that is neither too small to cover the key needs nor too large for teams to remember, sourced from the teams themselves and tied to business strategy, rather than general coding maxims or practices. Fewer, sharper principles are remembered and used; long lists are not.

Decentralised decision-making: the advice process

If decisions are no longer funnelled through a board, who makes them? Andrew Harmel-Law's article Scaling the Practice of Architecture, Conversationally (martinfowler.com, December 2021) proposed an answer borrowed from self-managing organisations: the advice process. Its single rule is that anyone may make an architectural decision, provided that before deciding they seek advice from everyone who will be meaningfully affected and from people with relevant expertise. The decision-taker must hear and record the advice but need not follow it; the aim is broad input, not consensus. Accountability stays with the person or team who decides, which is what makes the rule work: people who know they own the consequences seek advice seriously.

Harmel-Law describes four supporting elements. Decision records (ADRs, Section 4.5) are the thinking and recording tool, and include the advice received, from whom and when. An architecture advisory forum, typically weekly for about an hour and open to anyone, gives visibility to new spikes, proposed decisions and revisited ones; crucially, it offers advice but does not decide. Team-sourced architectural principles give shared direction. And an internal technology radar shows the organisation's current technology landscape and stance.

The advice process has failure modes worth knowing. Decision-takers may consult only the people likely to agree; a published list of who must be consulted for which kinds of decision (security for anything touching personal data, the platform team for new infrastructure) helps. Advice may be sought too late, after the code is written; making the proposed ADR the start of the work, not the end, helps. And some people find it uncomfortable at first that the forum does not decide. In regulated environments the process can coexist with a small number of formal gates, applied only where the law or the organisation's risk appetite demands them.

Technology radars

Thoughtworks has published its Technology Radar twice a year since 2010. Each edition places a hundred or so blips (techniques, tools, platforms, and languages and frameworks: the four quadrants) in rings that express a recommendation. Adopt means proven and recommended; Trial means worth pursuing on a project that can handle the risk; Assess means worth exploring to understand its effect; and the outermost ring, called Hold for most of the radar's history and Caution in its most recent editions, means proceed with care. Each blip has a short written rationale, which is the most valuable part.

Many organisations build their own radar, for themselves rather than the industry. Thoughtworks provides an open-source Build Your Own Radar tool that renders a radar from a spreadsheet or CSV file with the columns name, ring, quadrant, isNew and description. The value lies less in the picture than in the process: teams nominate blips, a small group with representatives from many teams discusses them, rings are assigned with a written reason, and the radar is refreshed every quarter or half-year. A Hold ring is a gentle but effective governance tool: it says "no new uses" without forbidding what already exists. A radar differs from an approved-technology list in being explicitly provisional and reasoned, and in recording what the organisation has learned, including its mistakes.

name,ring,quadrant,isNew,description
Debezium for outbox relay,Trial,Tools,TRUE,"Change data capture from the order database's write-ahead log to Kafka, replacing polling relays. Trial in ordering only; see ADR-0031. Owner: ordering team. Review: Q3."
Polling outbox relay,Hold,Techniques,FALSE,"Adds load and latency at peak; no new uses. Existing relays move when Debezium leaves Trial."

# ADR-0031: Use Debezium change data capture for the ordering outbox relay

Status: Accepted (2026-05-14)   Decision-taker: Priya N., ordering team
Context: The polling relay queries the outbox table every 500 ms. At 100 orders/s
it adds measurable database load and up to 1 s of event delay to dispatch.
Options: (1) tune polling; (2) Debezium CDC on the write-ahead log; (3) managed CDC
from the cloud provider.
Decision: Option 2, for the ordering service only, as a Trial on the radar.
Advice received:
- Platform team (2026-05-06): supports; will run Kafka Connect, needs runbook.
- Data team (2026-05-07): concern about replication slot growth if Connect stops;
  asks for an alert on slot lag. Accepted.
- Security (2026-05-08): CDC user must have replication rights only. Accepted.
- Advisory forum (2026-05-09): suggested option 3; rejected for portability (P3).
Consequences: lower load and delay; a new component to operate; slot-lag alert
and a fitness function on event delay (p99 under 2 s) added.
Review: after one quarter, or before any second service adopts it.

The role of enterprise architecture today

Enterprise architecture (Section 1.2) has had an uneasy reputation in agile organisations: central teams producing frameworks, standards and approval processes that delivery teams experienced as obstacles. The role has been changing. In organisations where it works well, enterprise architects curate the principles and the radar rather than dictating them, maintain the map of business capabilities and systems that no single team can see, make or facilitate the genuinely organisation-wide one-way-door decisions (identity, core data, cloud strategy, major vendors), run the advisory forum, and shape the platform and paved road with platform teams.

Gregor Hohpe's image of the architect who rides the elevator between the boardroom and the engine room (Section 11.7) describes the skill this needs: translating strategy into technical direction and technical constraints into business language. Practitioners still disagree about how much central authority is healthy. Some argue that a strong central function is essential in regulated, merger-heavy or highly integrated enterprises; others argue that most of its value can be delivered through platforms, principles and advice. The answer depends on the organisation's size, regulation and how much of its systems landscape is genuinely shared.

Compliance through automation

Whatever the organisational model, the cheapest compliance is automated. Fitness functions (Section 11.3) check architectural characteristics. Policy as code does the same for organisational rules: the rules are written in a machine-readable language, kept in version control, reviewed and tested like code, and evaluated automatically against infrastructure definitions, deployment manifests or API requests. Open Policy Agent, a graduated Cloud Native Computing Foundation project, is a widely used general-purpose engine with its own policy language, Rego; Conftest applies Rego policies to configuration files in a pipeline, and admission controllers such as OPA Gatekeeper or Kyverno enforce policies inside Kubernetes clusters.

Automated compliance has a further benefit that regulated organisations value highly: evidence. A pipeline log showing that every release passed the same checks is far stronger evidence for an auditor than a signed form, and it is produced at no extra cost.

package main

import rego.v1

# Guardrail: images must come from the organisation's scanned registry
deny contains msg if {
    input.kind == "Deployment"
    some c in input.spec.template.spec.containers
    not startswith(c.image, "registry.fooddelivery.example/")
    msg := sprintf("%s: image %s is not from the approved registry", [input.metadata.name, c.image])
}

# Guardrail: every container declares a memory limit
deny contains msg if {
    input.kind == "Deployment"
    some c in input.spec.template.spec.containers
    not c.resources.limits.memory
    msg := sprintf("%s: container %s has no memory limit", [input.metadata.name, c.name])
}

Balancing autonomy and alignment

The practical question is which decisions are governed how. A useful rule follows from Section 1.6: the more reversible and local a decision, the closer to the team it should be made; the more irreversible and widely felt, the more advice and, occasionally, approval it needs. The table sets out a typical allocation; each organisation tunes its own.

Governance should itself be measured. Useful signals are how long significant decisions take from proposal to acceptance, how many exceptions to standards are requested and granted, what share of services are on the paved road, how many Hold technologies are still spreading, and whether incidents trace back to decisions that skipped advice. If decisions are slow, governance is too heavy; if incidents keep tracing back to unconsulted decisions, it is too light.