Quick Navigation
- Start here — the inspector who visits once a month
- What the review board actually governs
- The batch problem
- What makes a fitness function a fitness function
- Three tiers of automated governance
- What happens when a check fails
- What the board still does better
- Retiring the agenda, one item at a time
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Imagine a building inspector who visits a construction site once every two weeks. They arrive with a clipboard. The crew halts work. The inspector walks the site, approves some decisions, tables others for next time, and misses the decisions already buried behind drywall. The crew resumes. And the building keeps changing every day — wiring, load-bearing walls, plumbing routes — none of which the inspector sees.
The architecture review board is that inspector. It meets on a schedule. It reviews what is presented to it. And the architecture changes on every commit.
Batch review cannot govern continuous change. The fitness function is not a replacement for the architect — it is a replacement for the meeting that was mistaken for architecture governance.
Keep it in mind. Especially the second half of it — this module is not an argument against architects, and it is not an argument that boards are bad.
1. The inspector who visits once a month
The review board was designed for a world where architectural decisions were rare and expensive. Design happened up front, in a phase, and could reasonably be inspected in a meeting.
That world no longer exists. Decisions are made every day — every pull request, every dependency upgrade, every configuration change. The board cannot keep up, not because the board is incompetent, but because the cadence is wrong. A monthly mechanism governing a daily process will always be governing history.
flowchart LR
D1["Day 1\nDecisions"] --> D2["Day 2\nDecisions"]
D2 --> D3["Day 3\nDecisions"]
D3 --> D4["Day 4…30\nDecisions"]
D4 --> BOARD["🗓️ Review Board\nSees the fraction\nsomeone escalated"]
BOARD --> HIST["Governs what happened\nlast month"]
2. What the review board actually governs
Here is the uncomfortable part. The review board does not govern the architecture. It governs the presentation of the architecture.
A delivery team prepares a slide deck describing the architectural approach they have already chosen. They present it to a group of architects who have not seen the context before. The architects ask questions. Some are good. Some reflect constraints that existed five years ago and no longer apply. Some are about terminology — whether the team used the right name for a pattern.
The meeting runs long. The board asks for changes. The team says they will incorporate the feedback. Nobody checks whether the feedback was incorporated — because the next meeting has twelve new items on the agenda.
This is not governance. This is a scheduling problem that organisations have mistaken for governance.
Try it yourself — The agenda audit
Take the agenda from your last review meeting and fill this in per item.
| Item | Already implemented when it reached the board? | Meaningful discussion, or approved on the nod? | Was the feedback ever verified? |
|---|---|---|---|
If more than half the items were approved without meaningful discussion, your board is a documentation exercise, not a governance mechanism. Write down the percentage before moving on — you will need it in section 8.
3. The batch problem
Architecture review is a batch process applied to a continuous stream of decisions. Every pull request contains an architectural implication. Every dependency upgrade changes the coupling profile. Every configuration change alters the system properties.
The board sees a tiny fraction of these — the fraction somebody decided was important enough to escalate. The rest drift through ungoverned.
And because the board reviews decisions after implementation, the cost of changing direction is high. The board becomes a rubber stamp for decisions already committed, or a blocker that creates resentment. Neither outcome is governance.
The economics are worth stating plainly, because they are usually assumed to run the other way. A two-hour review meeting with twelve senior architects costs roughly the same as building and maintaining thirty fitness functions — for a year. Not per meeting. Per year. And thirty fitness functions governing the same architecture would catch more violations in an hour than the board catches in a quarter.
The board is not the cheaper option. It is the slower and more expensive one.
The review board tells you what happened last month. The fitness function tells you what just happened.
4. What makes a fitness function a fitness function
Architecture fitness functions have been in the literature for nearly a decade. Building Evolutionary Architectures (Ford, Parsons, Kua, 2017) introduced the term; ThoughtWorks built them into delivery pipeline guidance; case studies and cloud-vendor patterns followed. Every treatment gives the same playbook: define an architectural property, encode it as an automated check, run it continuously, catch drift before it compounds.
That work solved governance of architectural properties at the code level. It left one claim unmade: nobody argued that the board itself becomes optional. Fitness functions were treated as a supplement — better data for the board, lighter workloads. The board stayed. The meeting stayed. The slide deck stayed. The unfinished claim is this: when fitness functions cover every architectural invariant the board was checking, the board is no longer the governance mechanism for those invariants.
But not every automated check qualifies. A linter warns about formatting; a fitness function governs architectural properties. Three properties distinguish them.
1. It tests an architectural invariant. Something that must always be true for the system to keep its architectural integrity — not a code style preference, not a naming convention. Examples: the dependency direction between layers must never reverse; the public API surface must never introduce a breaking change without an ADR; circular dependencies must never exceed a defined threshold; p95 response time under defined load must never exceed the SLA. Each is a property that, if violated, changes the architecture.
2. It runs automatically. No human invokes it. No board approves its results. It runs on every relevant event — commit, pull request, deployment, or scheduled interval. It is passive when the architecture is compliant and escalates when the architecture drifts.
3. It is decoupled from implementation. This is the most important property and the most commonly violated. A check tied to a specific file name or package version is governing implementation details, not architecture. A check on a measurable property — coupling, cohesion, latency, availability, dependency direction — is governing architecture. The implementation can change. The property must hold.
flowchart TD
C["Candidate check"] --> Q1{"Tests an architectural\ninvariant?"}
Q1 -->|"No"| L["🧹 It is a linter\nUseful, not governance"]
Q1 -->|"Yes"| Q2{"Runs without a human\ninvoking it?"}
Q2 -->|"No"| M["🗓️ It is a meeting agenda item\nStill batched"]
Q2 -->|"Yes"| Q3{"Checks a property,\nnot a file or version?"}
Q3 -->|"No"| I["🔧 It governs implementation\nIt will break on refactor"]
Q3 -->|"Yes"| FF["✅ Fitness function"]
Try it yourself — The invariant test
Write down three rules your board repeatedly enforces. Run each through the three questions.
| Rule the board enforces | Invariant, or preference? | Could it run automatically? | Coupled to implementation? |
|---|---|---|---|
Any rule that passes all three is a candidate for automation. Any rule that fails the first question is one your board should stop spending time on regardless.
5. Three tiers of automated governance
A single fitness function is useful. A system of fitness functions is what changes the role of the board. The Architecture Fitness Function System (AFFS) organises checks into three tiers by cadence and by the kind of property each one protects.
flowchart TD
A["🏗️ Architecture Fitness Function System"]
A --> T1["Tier 1 — Structural\nEvery commit\nStatic properties"]
A --> T2["Tier 2 — Behavioural\nEvery deployment\nRuntime properties"]
A --> T3["Tier 3 — Strategic\nWeekly or monthly\nLong-term properties"]
Tier 1 — Structural. Runs on every commit, validating static properties: layering violations, dependency direction, cyclical dependency counts, module boundary scope, breaking changes to the public API surface. These checks run in seconds and catch the drift boards never see, because that drift accumulates one small violation at a time. One team bypasses a layer boundary in one pull request. Another adds a reverse dependency in the next. Neither decision alone would be escalated to a board. Both combined produce an architecture nobody designed.
Tier 2 — Behavioural. Runs on every deployment, or on a schedule against a running system, validating runtime properties: latency SLAs, error budget consumption, throughput capacity, availability targets, eventual-consistency windows. A system can have perfect layering and terrible runtime behaviour, which is precisely what structural analysis cannot detect. Tier 2 also catches drift that only manifests at runtime — a service that becomes slower because its internal design changed, or a dependency that degrades because an upstream team made a different architectural choice.
Tier 3 — Strategic. Runs weekly or monthly, validating long-term properties: technical debt density, architecture entropy, standards compliance across services, decision drift between recorded ADRs and the live system, and fitness function coverage itself. Tier 3 is the meta-governance layer: it checks whether the governance system is still working. If coverage of fitness functions is declining, that is a governance failure — detected automatically, rather than noticed a year later.
6. What happens when a check fails
The board would table the decision until next time. A fitness function does something different at each tier, and the difference is proportional to blast radius.
| Tier | On failure | Why this severity |
|---|---|---|
| Tier 1 — Structural | Commit blocked or flagged; the team resolves before merge. Intentional violations require an ADR explaining the decision, automatically linked to the violation. | Cheapest possible moment to correct; nothing is deployed yet |
| Tier 2 — Behavioural | Deployment blocked or rolled back. The result includes the metric, the threshold, and the delta. | Runtime violations affect users, so severity is higher |
| Tier 3 — Strategic | Alert to the architecture team. They review the trend and decide whether the threshold needs adjusting or the architecture needs intervention. | Strategic drift is not urgent, but it is important |
Notice what Tier 1 does with a deliberate violation. It does not forbid it. It requires that the reason be written down and attached to the evidence. The ADR does the work the board's minutes were supposed to do, at the moment the decision is actually made.
7. What the board still does better
This is the section to read twice, because the argument is easy to flatten into "boards are bad" and that is not the claim.
Fitness functions are not a complete replacement for human judgment. They replace the batch approval mechanism that human judgment was forced into. Three things still need a human in the loop, and automating them would be a mistake.
Strategic trade-off discussions. When two architectural properties conflict — security versus latency, consistency versus availability, speed versus modularity — a human must resolve the tension. Fitness functions surface the conflict. Architects decide. No threshold can arbitrate a genuine trade-off, because the answer depends on what the business is trying to do this year.
Exception evaluation. When a team needs to violate an invariant intentionally — for a business deadline, a technical constraint, a market opportunity — the decision requires judgment. The fitness function flags the violation. The ADR captures the rationale. The board evaluates whether the exception is warranted. The automation makes the exception visible; it does not decide whether it is right.
Governance system design. Someone must decide what the checks cover, what thresholds are acceptable, and when a check is too strict or too lenient. A fitness function automates enforcement. It does not automate the design of the governance system — and a badly designed set of checks is worse than none, because it is trusted.
The architect's job is to design governance. Not to sit in meetings.
Put differently: the board is the wrong instrument for repetitive invariant checking and the right instrument for judgment under conflict. The failure mode most organisations are in is not having a board — it is having a board whose agenda is ninety percent the first thing and ten percent the second.
8. Retiring the agenda, one item at a time
The migration is deliberately unglamorous. You do not cancel the board. You make individual agenda items unnecessary and remove them one at a time, with evidence.
flowchart LR
S1["Select the most\nrepetitive invariant\nthe board checks"] --> S2["Write a fitness function\nfor it. Run it\non every commit"]
S2 --> S3["Show the board\nthe result — the check\ncaught it this week"]
S3 --> S4["Remove that item\nfrom the agenda.\nThe function governs it"]
S4 --> S1
This week. Ask three questions. What percentage of items on the last agenda were approved without meaningful discussion — and were they already implemented by the time they reached the board? How many architectural decisions were made between the last meeting and today, and how many will the board ever see? If you removed the board tomorrow, would the architecture drift faster — or would drift simply become visible at a different cadence?
Next 30 days. Select the most repetitive invariant the board checks — the one where it always asks the same question and the team always gives the same answer. Write a fitness function for it, run it on every commit, and show the board the result: the function caught a violation this week; the board would have caught it next month. Then remove that item from the agenda.
3–6 months. Repeat the cycle. Within twelve weeks, three or four items have left the agenda; within twenty-four, the board focuses on exceptions, trends and strategic decisions. Implement all three tiers, and establish a governance coverage metric: what percentage of your invariants are enforced by automated checks?
Evidence from practice
A SaaS scale-up I worked with had a weekly architecture review board that met religiously — and the architecture kept drifting anyway. The board reviewed designs before they were built, approved them, and then had no insight into what actually got deployed. By the time drift was discovered in production, three teams had built on top of it.
We replaced the first review gate with automated fitness functions in the CI pipeline. The board stopped reviewing designs and started defining architectural invariants — rules the pipeline enforced continuously. Drift detection moved from weeks to minutes. The board's meeting frequency dropped from weekly to monthly, and the meetings shifted from approval ceremonies to strategic steering.
The board did not disappear. Its agenda changed.
Putting it all together
flowchart TD
DEC["Architectural decisions\nmade every day"] --> AUTO["Automated invariant checks\nTier 1 · Tier 2 · Tier 3"]
AUTO --> PASS["Compliant\nSilent. No meeting needed."]
AUTO --> VIOL["Violation detected\nBlocked, rolled back, or alerted"]
VIOL --> INT{"Intentional?"}
INT -->|"No"| FIX["Team fixes it\nat the point of change"]
INT -->|"Yes"| ADR["ADR captures rationale\nlinked to the evidence"]
ADR --> BOARD["🧠 Human judgment\nTrade-offs · Exceptions\nGovernance design"]
BOARD --> AUTO
The loop is the point. Automation enforces what is already decided; humans decide what should be enforced and adjudicate the cases automation deliberately cannot. The architecture governs itself. The architect governs the system that governs the architecture.
Cheat Sheet — All the key terms
| Term | What it is | Where it belongs |
|---|---|---|
| Architectural invariant | A property that must always hold for architectural integrity | Encoded as a check, not asked in a meeting |
| Fitness function | An automated check on an invariant, decoupled from implementation | The pipeline |
| Tier 1 — Structural | Layering, dependency direction, cycles, module scope, API surface | Every commit |
| Tier 2 — Behavioural | Latency, error budget, throughput, availability, consistency windows | Every deployment or schedule |
| Tier 3 — Strategic | Debt density, entropy, standards compliance, decision drift, coverage | Weekly or monthly |
| ADR | The record of a deliberate exception and its rationale | Attached to the violation it explains |
| Governance coverage | Share of invariants enforced by automated checks | Reported as a metric, not assumed |
| Strategic trade-off | Two architectural properties in genuine conflict | Human judgment — the board |
| Exception evaluation | Whether a deliberate violation is warranted | Human judgment — the board |
| Governance system design | What to check, at what threshold, at what cadence | Human judgment — the architect |
How to know if this landed
You will know this landed when someone proposes an agenda item and a colleague asks "could that be a check?" — and the room treats it as a reasonable question rather than an attack on the board. Participants can distinguish an invariant from a preference, name which tier a given check belongs to, and say without hesitation which three things they would never automate.
The clearest tell is the shape of the remaining meeting. If the board still exists but its agenda is trade-offs, exceptions and trends rather than approvals, the mechanism has changed even though the calendar entry has not.
Where this comes from
This module develops the argument in The Architecture Review Is Broken. Replace It with Fitness Functions., including its careful limits — the three things fitness functions do not replace.
Book a Workshop
Ready to turn your review board into a governance system?
or
1-day workshop includes an audit of your current review agenda against what is actually being governed, identification of the first three invariants you can automate, a three-tier design for your context, and a 60-day plan to replace your first review gate.