The Building Inspector Who Only Visits Once a Month
Imagine a building inspector who visits a construction site once every two weeks.
They arrive with a clipboard and a checklist.
They walk the site. They look at what has been built. They ask questions about choices made in the days since their last visit.
The construction crew halts work for the inspection.
The inspector approves some decisions. Tables others for next time. Misses the decisions that were made and already buried behind drywall.
The crew resumes work.
And the building — the one being lived in, not the one being inspected — continues to change every day. Wiring gets upgraded. Load-bearing walls get moved. Plumbing routes change.
The inspector does not see any of those changes.
Because the inspector visits once a month.
And the building changes every day.
The architecture review board is that inspector.
It meets on a schedule.
It reviews what is presented to it.
It approves or rejects decisions that were already implemented.
And the architecture of the system — the one being built, not the one being reviewed — changes on every commit.
What the Review Board Actually Governs
The review board does not govern the architecture.
It governs the presentation of the architecture.
A delivery team prepares a slide deck. The deck describes the architectural approach they have already chosen. The team presents it to a group of architects who have not seen the context before.
The architects ask questions.
Some questions are good. Some reflect constraints that existed in the organisation five years ago but 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.
The Batch Problem
Architecture review is a batch process applied to a continuous stream of decisions.
Delivery teams make architectural decisions every day. Every pull request contains an architectural implication. Every dependency upgrade changes the coupling profile. Every configuration change alters the system properties.
The review board sees a tiny fraction of these decisions — the fraction that someone 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.
Fitness Functions Are the Mechanism That Fixes the Batch Problem
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. InfoQ published case studies. AWS documented patterns.
Every treatment tells the same playbook: define an architectural property, encode it as an automated check, run it continuously, catch drift before it compounds.
That work was necessary. It solved the problem of governing architectural properties at the code level.
It left one problem unsolved.
Nobody made the claim that the board itself becomes optional.
The literature treated fitness functions as a supplement — better data for the board, more informed decisions, 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 a governance mechanism. It is a historical artifact.
The economics prove it.
A two-hour Architecture Review Board meeting with twelve senior architects costs roughly the same as building and maintaining thirty fitness functions — for a year.
Not per meeting. Per year.
The board in that room reviewed ten items. Some got real discussion. Most got rubber-stamped. Three or four caught drift that had already been in production for weeks.
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.
A fitness function does not need a slide deck. It does not need a calendar invitation. It does not escalate to a board.
It runs on every commit, every build, every deployment.
The review board tells you what happened last month.
The fitness function tells you what just happened.
Three Properties That Make a Fitness Function Work
Not every automated check qualifies as a fitness function.
A linter warns about formatting. A fitness function governs architectural properties.
Three properties distinguish them.
1. Tests an Architectural Invariant
Something that must always be true for the system to maintain its architectural integrity.
Not a code style preference. Not a naming convention. An invariant.
Examples:
- The dependency direction between layers must never reverse
- The public API surface must never introduce a breaking change without an ADR
- The number of circular dependencies must never exceed a defined threshold
- The p95 response time under defined load must never exceed the SLA
Each of these is a property that, if violated, changes the architecture.
2. Runs Automatically
No human invokes it. No board approves its results.
It runs on every relevant event — commit, pull request, deployment, or scheduled interval.
The result is passive when the architecture is compliant.
It escalates when the architecture drifts.
3. Decoupled from Implementation
This is the most important property — and the most commonly violated.
A fitness function that checks for a specific file name or a specific package version is not governing architecture. It is governing implementation details.
A fitness function that checks for a measurable property — coupling, cohesion, latency, availability, dependency direction — is governing architecture.
The implementation can change.
The property must hold.
Architecture Fitness Function System: Three Tiers
A single fitness function is useful. A system of fitness functions replaces the review board.
The Architecture Fitness Function System (AFFS) organises checks into three tiers.
Tier 1: Structural Fitness Functions
Run on every commit.
Validate the static properties of the architecture.
What they check:
- Layering violations — does any module import from a layer it should not reach?
- Dependency direction — do dependencies flow in the intended direction?
- Cyclical dependencies — has the cycle count increased?
- Module boundaries — is any module exceeding its defined responsibility scope?
- Public API surface — has any public interface changed in a breaking way?
These checks run in seconds. They catch the architectural drift that review boards never see — because it accumulates one small violation at a time.
A team that bypasses the layer boundary in one pull request. Another team that adds a reverse dependency in the next. Neither decision individually would be escalated to a review board. Both decisions combined produce an architecture that nobody designed.
Tier 1 catches each violation when it happens — not when the architecture is already entangled.
Tier 2: Behavioural Fitness Functions
Run on every deployment or on a scheduled interval against a running system.
Validate the runtime properties of the architecture.
What they check:
- Latency SLAs — does the p95 response time stay within the defined envelope?
- Error rates — has the error budget been consumed beyond the threshold?
- Throughput capacity — does the system handle the defined load?
- Availability — is each service meeting its defined uptime target?
- Data consistency — are eventual consistency windows within the defined boundary?
Tier 2 catches problems that structural analysis cannot detect. A system can have perfect layering and terrible runtime behaviour.
It also detects architectural drift that manifests at runtime — a service that becomes slower because its internal design changed, or a dependency that degrades because the upstream team made a different architectural choice.
Tier 3: Strategic Fitness Functions
Run on a scheduled cadence — weekly or monthly.
Validate the long-term properties of the architecture.
What they check:
- Technical debt density — has the ratio of debt to new code exceeded the threshold?
- Architecture entropy — has the modularity score declined beyond the acceptable range?
- Standards compliance — does every service in the domain conform to the current architecture standard?
- Decision drift — do the recorded ADRs still match the live system?
- Fitness function coverage — has the percentage of architecture decisions covered by automated checks decreased?
Tier 3 is the meta-governance layer. It checks whether the governance system itself is still working. If the coverage of fitness functions is declining, that is a governance failure — detected and escalated automatically.
What Happens When a Fitness Function Fails
The review board would table the decision.
The fitness function does something different.
Tier 1 failure: The commit is blocked or flagged. The team must resolve the violation before the merge. If the violation is intentional, the team must produce an ADR that explains the decision and the rationale. The ADR is automatically linked to the violation.
Tier 2 failure: The deployment is blocked or the system is rolled back. Runtime violations are higher severity because they affect users. The fitness function result includes the metric, the threshold, and the delta. The team knows exactly what property was violated and by how much.
Tier 3 failure: An alert is sent to the architecture team. Strategic drift is not urgent. But it is important. The architecture team reviews the trend, identifies the pattern, and determines whether the governance threshold needs adjustment or the architecture needs intervention.
The Organisation That Replaced Its Review Board
A technology company with twelve delivery teams had an Architecture Review Board that met twice a month.
Each meeting had eight to twelve items. The average review time per item was twenty-two minutes. The board approved ninety-three percent of all submissions. The seven percent that were rejected were resubmitted and approved in the next cycle with minor changes.
The board consumed approximately forty person-hours per month in meetings alone — not counting preparation time, not counting context switching.
And the architecture of the system was drifting.
The board governed what it saw. It did not govern what it did not see.
The company implemented a three-tier fitness function system over ninety days. Structural checks on every commit. Behavioural checks on every deployment. Strategic checks on a weekly cadence.
Within thirty days, Tier 1 caught seventeen layering violations that had never been escalated to the board.
Within sixty days, Tier 2 caught a latency degradation that the monitoring system had flagged but nobody had connected to an architecture decision.
Within ninety days, the Architecture Review Board was reduced from a twice-monthly governance gate to a quarterly strategic review. The meetings that remained were not about approvals. They were about trends, exceptions, and strategic direction.
The monthly review board was not cancelled.
It became irrelevant.
Fitness functions did what the board was supposed to do — but continuously, automatically, and at the point where decisions are actually made.
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 a drift was discovered in production, three teams had built on top of it.
We replaced the first review gate with automated fitness functions deployed in the CI pipeline. The board stopped reviewing designs and started defining architectural invariants — rules that the pipeline enforced continuously. The 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 model we used is the Architecture Fitness Function System (AFFS) described in this post. It came from the same engagement documented here: Reducing Architecture Decision Time by 60%
What the Board Still Does Better
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.
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.
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.
Governance system design. Someone must decide what the fitness functions check, what thresholds are acceptable, when a check is too strict or too lenient. The fitness function automates the enforcement. It does not automate the design of the governance system itself.
The architect's job is to design governance.
Not to sit in meetings.
Action Plan
This Week
Ask three questions about your architecture review board:
What percentage of items on the last agenda were approved without meaningful discussion — and were those decisions already implemented by the time they reached the board?
How many architectural decisions were made in your organisation between the last review meeting and today — and how many of them will the board ever see?
If you removed the review board tomorrow, would the architecture drift faster — or would it simply become visible at a different cadence?
If the answer to the first question is more than fifty percent, your board is a documentation exercise, not a governance mechanism.
Next 30 Days
Select one architectural invariant that your review board regularly checks — the most repetitive one, the one where the board always asks the same question and the team always gives the same answer.
Write a fitness function that checks that invariant automatically. Run it on every commit.
Show the board the result: the fitness function caught a violation this week. The review board would have caught it next month.
Remove that item from the review board agenda. The fitness function governs it now.
3–6 Months
Repeat the cycle: select the next invariant, write the next fitness function, remove the next agenda item.
Within twelve weeks, three to four items have been removed from the board's agenda. Within twenty-four weeks, the board focuses only on exceptions, trends, and strategic decisions.
Within a year, the board is a strategic governance body — not a scheduling problem.
Implement all three AFFS tiers. Structural checks on every commit. Behavioural checks on every deployment. Strategic checks on a weekly cadence.
Establish a governance coverage metric: what percentage of your architectural invariants are enforced by automated checks?
Final Thought
The building inspector who visits once a month does not keep the building safe.
The building that has test points at every critical junction — and someone who reads them continuously — is the building that stays within its design parameters.
The architecture review board was designed for a world where architectural decisions were rare and expensive.
That world no longer exists.
Decisions are made every day. Every pull request. Every dependency upgrade. Every configuration change.
The review board cannot keep up.
Not because the board is incompetent.
Because 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.
The architecture governs itself.
The architect governs the system that governs the architecture.
Turn Your Architecture Review Board Into a Governance System
If your architecture review board meets every month and the architecture is still drifting…
if your delivery teams are making decisions that the board never sees…
or if your governance meetings feel like approval ceremonies rather than architectural steering —
the problem is not the board.
It is the mechanism.
In a focused 30-minute Architecture Governance Diagnostic, we will:
- Audit your current review board agenda against what is actually being governed
- Identify the first three architectural invariants you can automate with fitness functions
- Design the three-tier AFFS model for your organisation context
- Define a 60-day plan to replace your first review gate with continuous governance
→ Book an Architecture Governance Diagnostic
or
The architecture review is broken.
Replace it.
