Fitness Functions

Protect the qualities that matter with automated checks, so the architecture can change safely.

An architecture principle encoded as an automated check in the pipeline holds without review meetings.

To an executive

Principles written in documents fade. Automated checks keep important qualities such as speed, security and cost protected while teams keep changing the product.

To an engineer

Turn architectural rules into automated checks in the pipeline or production, such as dependency rules, latency budgets and security policies. A failing check blocks the change.

The idea

In evolutionary computing, a fitness function measures how close a candidate solution is to the goal. Neal Ford, Rebecca Parsons and Patrick Kua borrowed the term in Building Evolutionary Architectures (2017): an architectural fitness function is any check that measures how well the system meets an architectural aim, such as a dependency rule, a latency budget or a security policy.

Fitness functions turn architecture principles from documents into executable guardrails. Most run in the delivery pipeline, like tests; some run continuously in production, like monitors.

Why it works

Principles on paper erode. A rule in a wiki is checked only when someone remembers. A rule in the pipeline is checked on every change.

Fast feedback is cheap feedback. A violation caught at commit time costs minutes to fix. The same violation found at a quarterly review may be built upon for months.

It frees architects from gatekeeping. When the important qualities are checked automatically, teams can change the system freely within them, and review time goes to the questions that need judgement.

Where it applies

Structural rules: layer and dependency direction, no cycles, module boundaries.
Operational qualities: latency and throughput budgets, resilience tests, health endpoints and logging standards.
Security and compliance: dependency vulnerability scans, policy-as-code, data-handling rules.
Evolving platforms, where many teams change the system at once and central review cannot keep up.

How to apply

Pick the few qualities that matter most for this system, with the stakeholders who care about them, and note where they trade off.
Make each one measurable with a concrete threshold: "the domain package imports nothing from infrastructure", "p99 under 300ms".
Automate the check in the pipeline or in production monitoring, and decide whether a failure blocks or warns.
Review the set regularly, retiring checks that no longer matter and adding ones for new risks.

Example scenario

A team agreed that the domain layer must never import infrastructure code, and wrote it into the architecture guidelines. Within weeks, a developer under pressure imported a database client into a domain class, and others followed the example.

The architect replaced the guideline with an automated dependency test in CI that failed the build on any such import. The rule held for years with no review meetings, and when the team later swapped its database, the domain layer needed no changes.

Questions to ask

Which architectural qualities do we most want to protect as the system changes?
How would we know, automatically and quickly, if one were violated?
Which review-board check could become a pipeline test instead?

When not to use it

Qualities that cannot be measured meaningfully, such as whether a design is easy to understand; these still need human review.
Very early prototypes, where the architecture is meant to change daily and guardrails would only slow learning.

How it misleads you

It is easy to measure what is easy rather than what matters, which turns fitness functions into a Goodhart's Law trap: teams optimise the check, not the quality. Too many blocking checks also make the pipeline slow and brittle, and teams start looking for ways around it. Keep the set small and tied to qualities people actually care about.