What Architectural Governance Is Actually For

In many organisations, architectural governance is a gatekeeping function. Teams propose technical approaches, an architecture board reviews them, and the board approves or rejects. Teams experience this as a bottleneck. Architects experience it as a necessary control. Neither side is entirely wrong.

But this model misunderstands what governance is for. The purpose of architectural governance is not to review decisions - it is to create conditions in which teams make good decisions consistently, without requiring review for every choice.

Good governance means teams can move fast because they are operating within clear boundaries and with shared understanding. It means the decisions that do need review are identified clearly and reviewed efficiently. And it means that architectural patterns and standards improve over time through learning, not just through compliance.

The Spectrum from Centralised to Federated Governance

Architectural governance sits on a spectrum. Where your organisation should sit depends on your size, stage, and risk profile.

Centralised Architecture

A central architecture team or function makes and owns architectural decisions. Teams consume those decisions rather than making them. This model provides strong consistency but creates a bottleneck and often lacks the context of the teams doing the work.

Centralised architecture works reasonably well in small organisations, in domains with very high technical risk, and in early phases of architecture establishment. It breaks down as teams scale, as domains diversify, and as the pace of decision-making required exceeds what a central group can provide.

Federated Architecture

Decisions are distributed to the teams doing the work, with shared principles and standards providing consistency. A small central function - or distributed principal and staff engineers - provides guidance, reviews significant decisions, and maintains shared standards. Teams have genuine autonomy within defined boundaries.

Federated architecture scales better and produces decisions with better context. It requires more investment in shared standards, tooling for decision documentation, and the technical seniority to make good decisions at the team level.

Most mature engineering organisations land somewhere in the federated model, with the central function focused on significant cross-cutting concerns rather than routine decisions.

Architecture Decision Records

An Architecture Decision Record (ADR) is a short document that captures a significant architectural decision - the context, the options considered, the decision made, and the consequences.

ADRs serve several purposes:

Memory. In organisations without ADRs, architectural decisions live in the heads of whoever made them. When those people leave, the decision remains but the reasoning disappears. Future engineers change the decision without understanding why it was made, sometimes recreating the original problem.

Transparency. ADRs make decisions visible to the teams affected by them. Engineers can understand why the codebase looks the way it does rather than encountering unexplained constraints.

Review. Requiring teams to write an ADR for significant decisions creates a review moment without requiring a formal committee. Asynchronous review of an ADR is often faster and higher quality than a synchronous review meeting.

Evolution. When a decision needs to change, the new ADR links to the old one and explains what changed. The architectural history of the system becomes readable.

What Makes a Good ADR

A good ADR is short - typically one to two pages. It answers four questions: what is the context and problem? What options were considered? What decision was made? What are the consequences, including known trade-offs?

The section on options considered is critical. An ADR that only records the chosen option provides little value. An ADR that shows the alternatives considered and why they were rejected provides genuine insight.

ADR Process

Establish a lightweight ADR process: teams write ADRs for decisions that are significant, cross-cutting, or likely to be revisited. Significant means consequential for the system's evolution - choosing a database technology, adopting a new framework, establishing a data model pattern. Not every design choice needs an ADR.

Store ADRs in the repository alongside the code they describe. They should be as close to the code as possible and reviewed in pull requests. An ADR that lives in Confluence is an ADR nobody reads.

Tech Radar

A tech radar is a visualisation of an organisation's relationship with different technologies, frameworks, tools, and techniques. The radar is divided into four rings:

• Adopt - actively use this; it is proven and recommended
• Trial - worth pursuing; use it on a project with an understanding of how it will pan out
• Assess - worth exploring in a spike or research context
• Hold - proceed with caution; not recommended for new projects

The value of a tech radar is shared vocabulary and explicit positioning. When engineers ask "should we use technology X?" the radar provides an answer without requiring a review meeting. When a technology moves from Trial to Adopt, that signals a change in the organisation's stance that teams can act on.

Thoughtworks publishes a public tech radar quarterly that many organisations use as a starting point. Building your own, even if initially based on Thoughtworks', forces the conversations that produce shared understanding.

The radar should be reviewed and updated twice per year at minimum. A tech radar that is not maintained becomes a record of outdated thinking rather than a useful guide.

How to Run an Architecture Review That Adds Value

When a formal architecture review is necessary, the goal is a high-quality decision, not compliance theatre.

Reviews add value when they are:

Early. A review when a team is still in the design phase can influence the decision. A review when a team has already built something is a formality that creates resentment without improving outcomes.

Focused. The review should address specific concerns - security implications, cross-system impacts, alignment with shared principles - not relitigate every design choice. Define the scope of review before the meeting.

Prepared. The team presents an ADR, not a live Powerpoint. Reviewers read it asynchronously before the meeting. Meeting time is for questions and decisions, not presentation.

Fast. A review process with a two-week response time is a bottleneck that teams will learn to route around. Reviews should produce a decision in days, not weeks.

Consultative rather than gatekeeping. The best architecture reviews feel like a team getting experienced input, not a team defending their choices before a panel. The distinction is in the posture of the reviewers.

The Role of Principal and Staff Engineers

In federated governance models, principal and staff engineers carry significant governance responsibility. They are the people trusted to make significant architectural decisions within their domain, to identify decisions that need broader review, and to maintain architectural coherence across teams they do not directly manage.

Effective principal and staff engineers:

• Are trusted by both engineers and leadership, not just authority figures
• Write the ADRs themselves, not just approve others'
• Spend time in the codebases they are influencing, not just in meetings
• Make their reasoning visible so teams can learn from it
• Say yes more than no, and when they say no, explain why clearly

Common Failure Modes

Ivory Tower Architecture

Architects make decisions without adequate connection to the teams implementing them. Decisions look elegant on a whiteboard but fail in practice because they ignore constraints the implementation team lives with daily. The symptom is frequent "exceptions" to architectural standards, which are actually the system telling you the standards are wrong.

Governance by Committee

Decisions require approval from a group that meets infrequently and has broad membership. The committee becomes a bottleneck. Teams stop bringing decisions to it and instead make them informally. The governance becomes ceremonial.

Standards Proliferation

An accumulation of standards and architectural requirements over time that are never retired. Teams encounter a requirement that was created for a context that no longer exists and spend time satisfying it rather than delivering value. Architectural governance should include active curation and retirement of outdated standards.

Review as Retrospective Approval

Reviews happen after significant implementation decisions have been made. The review is an exercise in documenting what has already been decided rather than improving the decision. Build review into your development process at the point where decisions are actually made.

Good architectural governance is quiet. Teams make good decisions confidently because they know the boundaries and have support available when they need it. The noise of bad governance - escalations, exceptions, workarounds - is the signal that the system needs redesign.