Quick Navigation
- Start here — What governance is
- Architecture principles
- Governance models
- The governance lifecycle
- Escalation paths
- Lightweight governance
- Measuring effectiveness
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Architecture without governance is just advice. Teams can ignore it, contradict it, or drift away from it — and nobody notices until something breaks. I've seen organisations with thirty architecture principles on a wiki that nobody followed, because there was no mechanism that connected principles to actual decisions.
Architecture governance is the set of mechanisms that ensure architectural decisions are made consistently, applied correctly, and aligned with the organisation's principles and strategy. It's not bureaucracy — it's the system that makes architecture matter.
Governance without teeth is just guidance. Governance without empathy is just control. The goal is governance that enables speed by settling common questions once — and catches real risks before they become incidents.
Keep it in mind.
1. What governance is — And why "just write principles" isn't enough
Many organisations believe that writing architecture principles is governance. It's not. Principles without enforcement are aspirations. Governance is the mechanism that connects principles to actual decisions.
Without governance, architecture decisions are made inconsistently — one team follows the principles, another ignores them, a third doesn't know they exist. The result is a fragmented landscape with no shared direction.
The signs of absent governance:
- "We have principles but nobody follows them."
- "Every team chose a different database."
- "The architecture board meets but nothing changes."
- "Teams ship whatever they want — there's no review."
- "We keep finding out about decisions after they're made."
flowchart LR
PRIN["📐 Principles\nWhat we believe"] --> GOV["🏛️ Governance\nHow we enforce"]
GOV --> DEC["🎯 Decisions\nWhat actually happens"]
DEC --> OUT["📊 Outcomes\nWhat the system looks like"]
Governance covers four concerns. Consistency — are decisions made the same way across teams? Compliance — do decisions follow the agreed principles and guardrails? Alignment — do decisions support strategic intent? Communication — do affected parties know about decisions?
Without governance, you get inconsistent decisions, architecture drift, surprises in production, and rework. The cost is higher ops, slower delivery, and security gaps.
Governance is how architecture turns principles into practice — through review, enforcement, and feedback.
Try it yourself — The governance gap
How many of these are true in your organisation?
| Statement | True or False |
|---|---|
| "We have principles but nobody follows them" | |
| "Every team chose a different database" | |
| "Teams ship whatever they want — there's no review" | |
| "We keep finding out about decisions after they're made" |
If you checked two or more, you have a governance gap. Not a principles gap — a governance gap.
2. Architecture principles — How to write them so they actually guide decisions
Most architecture principles are vague statements like "we favour simplicity" or "we use open standards." These sound good but guide nothing — because they can justify any decision.
Good principles are specific enough to guide decisions and flexible enough to apply in different contexts. They connect values to rationale to implications.
A bad principle: "We prefer simplicity."
A good principle: "We prefer the simplest solution that meets the need because complexity increases cost of change. This means we choose monolith over microservices when a single team can own the system, and choose managed services over self-hosted when the capability is not a differentiator."
flowchart TD
BAD["❌ Bad Principle\n'We prefer simplicity'\nVague, unactionable"] --> IGNORED["Ignored\nCan justify anything"]
GOOD["✅ Good Principle\n'We prefer simplest solution...'\nValue + Rationale + Implication"] --> GUIDES["Guides Decisions\nSpecific, testable"]
The principle format: "We [value X] because [reason Y]. This means [implication Z]."
A well-curated principle set looks like this:
| # | Principle | Rationale | Implication |
|---|---|---|---|
| P-01 | API-first design | Contracts prevent rework | APIs designed and reviewed before implementation |
| P-02 | Data owned by domains | Shared databases create coupling | Each domain owns its data; access through APIs only |
| P-03 | Cloud-native by default | Cloud enables scale and speed | On-prem requires explicit exception |
| P-04 | Buy commodity, build differentiator | No value in rebuilding solved problems | Auth, logging, CI/CD = buy; core domain = build |
| P-05 | Automate everything repeatable | Manual processes are error-prone and slow | If it's done more than twice, automate it |
Good principles = value + rationale + implication — specific enough to guide, flexible enough to apply.
Try it yourself — The principle test
Take one of your organisation's principles. Run it through the test:
| Question | Your principle |
|---|---|
| Value — What do we prefer? | |
| Rationale — Why does it matter? | |
| Implication — What does this mean in practice? | |
| Can it justify any decision? | If yes, it's too vague |
If your principle can justify any decision, it guides none. Rewrite it.
3. Governance models — Centralised, federated, and hybrid
There's no single right way to govern architecture. A centralised model works for small organisations but creates bottlenecks at scale. A federated model works for large organisations but risks fragmentation.
The governance model must match the organisation's size, maturity, and culture. Most real organisations use a hybrid — centralised for cross-cutting concerns, federated for domain-specific decisions.
flowchart TD
GOV["🏛️ Governance Models"]
GOV --> CENT["🏢 Centralised\nOne body decides all\nConsistent but slow"]
GOV --> FED["🌐 Federated\nDomains decide locally\nFast but fragmented"]
GOV --> HYB["🔀 Hybrid\nCentral for cross-cutting\nFederated for domains"]
CENT --> BEST_CENT["Best for: small orgs\n<5 teams, single domain"]
FED --> BEST_FED["Best for: large orgs\nmature domains, strong culture"]
HYB --> BEST_HYB["Best for: most orgs\nscales with size and maturity"]
The hybrid model in practice: Central body (Architecture Board) governs cross-cutting standards, technology choices, guardrails, security. Domain architects govern domain-specific patterns, API designs, data models. Teams govern implementation details, internal structure, coding standards.
Centralise the cross-cutting, federate the domain-specific, delegate the implementation.
Try it yourself — The model fit
Which model fits your organisation right now?
| Question | Your answer |
|---|---|
| How many teams do you have? | |
| Do teams share a single domain or multiple domains? | |
| Is there a central architecture body? | |
| Do teams make their own technology choices? |
If you're under five teams, centralised works. Over five, you need hybrid. Over twenty, federated with central guardrails.
4. The governance lifecycle — How decisions enter, get reviewed, and are communicated
Governance isn't a one-time event — it's a continuous cycle. Decisions enter the system, get evaluated, get approved or rejected, get communicated, and eventually get revisited.
The governance lifecycle ensures no decision falls through the cracks, no review is skipped, and no communication is missed.
Enter — decision identified; ADR drafted. Review — evaluated against principles and standards. Approve — accepted and documented. Communicate — shared with affected parties. Monitor — compliance verified. Revisit — context changed? Update or deprecate.
flowchart LR
ENTER["📥 Enter\nDecision identified"] --> REVIEW["🔍 Review\nEvaluated against principles"]
REVIEW --> APPROVE["✅ Approve\nAccepted and documented"]
APPROVE --> COMM["📢 Communicate\nShared with affected parties"]
COMM --> MONITOR["📊 Monitor\nCompliance verified"]
MONITOR --> REVISIT["🔄 Revisit\nContext changed? Update or deprecate"]
REVISIT --> ENTER
The governance intake process starts with a threshold check: is this decision significant? If no, the team decides — no governance needed. If yes, draft an ADR and submit for review. Review effort should be appropriate — lightweight async review for small decisions, Architecture Board for strategic ones.
Governance lifecycle = enter → review → approve → communicate → monitor → revisit.
Try it yourself — The lifecycle check
Where do decisions currently fall through the cracks in your organisation?
| Stage | What happens now | What should happen |
|---|---|---|
| Enter | Decisions made in Slack, never documented | ADR drafted before implementation |
| Review | No review — teams decide independently | Lightweight review for significant decisions |
| Communicate | Nobody knows what other teams decided | Decision published to affected teams |
Pick one stage. What would it take to close the gap?
5. Escalation paths — What happens when teams push back
Governance decisions will be challenged. Teams will disagree with standards, resist reviews, or request exceptions. If there's no clear path for escalation, conflicts become political — resolved by power, not by principle.
Escalation paths define how disagreements are resolved — with clear stages, clear authorities, and clear timelines.
flowchart TD
TEAM["👥 Team Disagrees"] --> DISCUSS["💬 Discuss\nWith domain architect"]
DISCUSS --> RESOLVED{"Resolved?"}
RESOLVED -->|"Yes"| DONE["✅ Decision clarified"]
RESOLVED -->|"No"| ESCALATE_1["📐 Escalate to\nArchitecture Board"]
ESCALATE_1 --> REVIEW["🔍 Board Reviews"]
REVIEW --> DECISION["📋 Board Decides\nAccept exception or enforce"]
DECISION --> LOG["📝 Log Decision\nDocument rationale"]
The exception process is simple. Request — team submits exception with justification. Evaluate — reviewer assesses: is the standard genuinely unsuitable, or is this convenience? Decide — accept with conditions, deny, or propose alternative. Log — exception recorded with rationale and expiry conditions. Review — exceptions reviewed periodically; expired ones enforced.
Escalation paths = structured disagreement — conflicts resolved by process, not politics.
Try it yourself — The escalation test
If a team disagreed with an architecture standard today, what would happen?
| Question | Your answer |
|---|---|
| Who would they talk to first? | |
| If unresolved, where does it escalate? | |
| Who has the final say? | |
| Is the decision documented? |
If you can't answer all four, your escalation path doesn't exist. Conflicts are being resolved by politics.
6. Lightweight governance — How to govern without creating bureaucracy
The biggest risk of governance is becoming so heavy that teams route around it. If every decision requires a board meeting, teams stop asking — and governance becomes theatre.
Lightweight governance uses automation, defaults, and delegation to enforce standards without human bottlenecks.
flowchart TD
HEAVY["❌ Heavy Governance\nEvery decision needs approval\nWeeks of waiting\nTeams route around it"] --> THEATRE["Governance Theatre\nExists on paper\nIgnored in practice"]
LIGHT["✅ Lightweight Governance\nAutomation catches violations\nDefaults reduce decisions\nDelegation empowers teams"] --> REAL["Real Governance\nInfluences decisions\nEnables speed"]
The lightweight toolkit: Fitness functions — automated tests that verify architecture constraints in CI/CD. Defaults — sensible defaults that teams adopt without deciding. Delegation — most decisions made by teams, not the board. Linting and tooling — standards enforced by code, not meetings.
Governance automation levels range from manual (board review for everything) to guided (templates and checklists) to automated checks (CI/CD fitness functions) to self-service (platforms enforce standards). The goal is to move right.
Govern with automation and defaults — not meetings and approvals.
Try it yourself — The automation audit
What percentage of your governance is enforced by code versus by meeting?
| Mechanism | Current % | Target % |
|---|---|---|
| Board review | Should decrease | |
| Templates and checklists | ||
| CI/CD fitness functions | Should increase | |
| Platform-enforced standards | Should increase |
If over 50% of your governance requires a human meeting, you're too heavy.
7. Measuring governance effectiveness — How to know if it's working
Governance that's never measured can't improve. If you don't know whether governance is helping or hurting, you can't adjust.
Governance effectiveness is measured by its impact on outcomes — not by how many meetings are held or how many documents are reviewed.
flowchart TD
GOV["🏛️ Governance"] --> SPEED["⚡ Decision Speed\nHow fast do decisions get made?"]
GOV --> COMPLIANCE["✅ Compliance Rate\nAre decisions being followed?"]
GOV --> ADOPTION["📈 Adoption\nDo teams use the standards?"]
GOV --> RISK["🛡️ Risk Reduction\nFewer incidents, fewer surprises?"]
GOV --> SATISFACTION["😊 Team Satisfaction\nDo teams find governance helpful?"]
The governance health check:
| Metric | Healthy | Warning | Unhealthy |
|---|---|---|---|
| Decision turnaround | < 5 days | 5-15 days | > 15 days |
| Compliance rate | > 80% | 60-80% | < 60% |
| Exception rate | < 10% | 10-20% | > 20% |
| Team satisfaction | > 70% positive | 50-70% | < 50% |
| Architectural blockers per sprint | 0-1 | 2-4 | > 5 |
Measure governance by outcomes — speed, compliance, satisfaction — not by process activity.
Try it yourself — The governance scorecard
Rate your governance on each metric:
| Metric | Your score | Healthy, warning, or unhealthy? |
|---|---|---|
| Decision turnaround | ||
| Compliance rate | ||
| Exception rate | ||
| Team satisfaction |
Any "unhealthy" means your governance needs redesign. Start with the worst metric.
Putting it all together
Here's the complete picture in one diagram. This is the mental model worth internalising.
flowchart TD
PRIN["📐 Principles\nGuiding rules"] --> GOV["🏛️ Governance\nThe system that enforces"]
GOV --> MODEL["🔀 Model\nCentralised · Federated · Hybrid"]
GOV --> LIFECYCLE["🔄 Lifecycle\nEnter → Review → Approve\nCommunicate → Monitor → Revisit"]
GOV --> ESCALATE["🚨 Escalation\nStructured disagreement"]
GOV --> LIGHT["⚡ Lightweight\nAutomate, delegate, default"]
GOV --> MEASURE["📊 Measure\nSpeed · Compliance · Satisfaction"]
MODEL --> VALUE["✅ Value\nConsistent decisions\nAligned to strategy\nEnabling speed"]
LIFECYCLE --> VALUE
ESCALATE --> VALUE
LIGHT --> VALUE
MEASURE --> VALUE
The foundation:
Principles without governance are aspirations — governance is the system that turns principles into practice through review, enforcement, and feedback. Governance must be lightweight enough to be followed and strong enough to matter — automate what you can, delegate what you should, review what matters. Measure governance by outcomes — decision speed, compliance rate, team satisfaction — not by how many meetings are held. Good governance enables speed by settling common questions once. Bad governance creates bottlenecks that teams route around.
Cheat Sheet — All the key terms
| Concept | One-Line Memory | Key Action |
|---|---|---|
| Governance | The system that makes decisions stick | Review, enforce, communicate, measure |
| Principles | Value + rationale + implication | Write them so they guide, not just inspire |
| Centralised model | One body decides all | Good for small orgs, bottleneck at scale |
| Federated model | Domains decide locally | Good for large orgs, risk of fragmentation |
| Hybrid model | Central for cross-cutting, federated for domains | Best for most organisations |
| Governance lifecycle | Enter → review → approve → communicate → monitor → revisit | No decision falls through the cracks |
| Escalation paths | Structured disagreement | Resolved by process, not politics |
| Lightweight governance | Automate and delegate | Fitness functions, defaults, tooling |
| Measurement | Outcomes, not activity | Speed, compliance, satisfaction |
How to know if this landed
You'll know this has landed when someone stops treating governance as bureaucracy and starts treating it as the system that makes architecture matter. They can explain what governance is — and what it isn't. They have a set of architecture principles written in the value + rationale + implication format. They've defined a governance model matching their organisation. They have escalation paths — teams know how to challenge decisions. Governance is partly automated — fitness functions or tooling enforce key standards. And governance is measured — decision speed, compliance rate, and team satisfaction tracked.
What changes when the mental model clicks
I've run this session with teams who viewed architecture as "the department that says no." The gap at the start is usually not about understanding governance — it's about experiencing governance that enables rather than obstructs.
What changes after this session:
Teams stop viewing governance as bureaucracy and start viewing it as the system that settles common questions once so they can focus on what's novel. The governance scorecard — "how fast do decisions actually get made?" — is always the moment things click. People stop treating principles as aspirations and start treating them as the lens decisions are measured against. Their results get better. They stop routing around governance when the real problem was that governance was too heavy to follow.
The principles rewriting exercise tends to immediately change how teams think about their standards. They start noticing that "we prefer simplicity" can justify anything. Their principles get better. They stop writing vague statements when the real problem was that they never connected value to implication.
Book a Workshop
Ready to build governance that enables rather than obstructs?
or
1-day workshop includes governance assessment — where is your current governance on the spectrum, principles rewriting workshop — from vague to actionable, governance model design — centralised, federated, or hybrid for your context, governance lifecycle design — intake, review, approval, communication, monitoring, escalation path design — structured disagreement for your organisation, governance scorecard creation — measuring what matters, and governance model canvas + architecture principles register + escalation path template.