As the architect for a large system, how would you derive a fitness-function suite from the system's architectural characteristics, and how do you govern it over time — including what to do when two fitness functions conflict?

## Step 1 — Derive characteristics from drivers, not from a checklist Architectural characteristics come from business goals, service-level objectives, regulatory obligations, operational realities, and team topology — never from a generic '-ilities' list. Practical sources: the domain's cost of downtime, the revenue sensitivity to latency, the audit regime, the growth curve, the number of teams that must ship independently. Two disciplines matter here: - **Keep the list short.** Seven or eight characteristics is already a lot; every one you add costs verification and constrains design. - **Force a priority order.** Characteristics conflict by nature, so an unordered list is not a decision. 'Availability > auditability > latency' is a decision; 'all of them are critical' is an abdication that will be resolved later, badly, by whoever is on call. ## Step 2 — Make each characteristic measurable A characteristic without a number is not enforceable. Convert: - 'The system should be fast' → 'p99 latency of `POST /checkout` ≤ 400 ms with 2,000 concurrent users on production-sized data.' - 'The system should be modular' → 'no cycles between modules; only `api` packages are exported; no module depends on more than N others.' - 'The system should be secure' → 'no dependency with a known critical CVE older than 7 days; every endpoint declares authorization; no secret literal in source.' - 'The system should be resilient' → 'with any single instance terminated, error rate stays below 0.1% and no order is lost.' Each statement needs a **threshold**, a **context** (load, data volume, environment), and a **measurement method**. ## Step 3 — Choose the mechanism and cadence For each measurable statement pick the cheapest sufficient mechanism, then classify it: - **Atomic + triggered** (dependency tests, scanners, lint gates): cheap, run on every commit. - **Holistic + triggered** (combined load + security scenario, resilience scenario): expensive, run nightly or pre-release. - **Atomic/holistic + continuous** (production monitors, synthetic transactions, always-on chaos): run in production with alerting and named owners. - **Manual** (legal/data-residency review, accessibility audit): scheduled, with an explicit checklist — a fallback, never the default. Budget the total: a suite whose pipeline cost pushes feedback past ~10 minutes for the fast stage will cause batching, which destroys incremental change — the very thing the suite exists to protect. ## Step 4 — Govern the suite like production code - **Traceability.** Every fitness function links to the architecture decision record it enforces, with rationale and owner. A rule nobody can justify will eventually be deleted under delivery pressure. - **Change control.** Weakening a threshold is an architectural decision, not a build fix; it goes through the same review as any production change and updates the ADR. - **Suppressions and baselines are metrics.** Track the count and the trend. A shrinking frozen baseline is healthy; a growing allow-list means the rule is decorative. - **Flakiness is fatal.** An unreliable fitness function teaches people that red means 'rerun'. Fix or delete it; there is no third option. - **Periodic review.** Revisit the suite when drivers change (new market, new regulation, 10× traffic, a reorg that changes team boundaries). Retire functions whose characteristic no longer matters; the suite should not only grow. - **Onboarding value.** The suite is executable documentation — new engineers learn the constraints from failure messages, which is why messages must explain *why*, not just *what*. ## Step 5 — Handling conflicts between fitness functions Conflict is the normal state, because characteristics trade off: - Security (encrypt everything, deep validation) vs performance/latency. - Strong consistency vs availability under partition. - Elasticity/dynamic scaling vs cost ceilings. - Fine-grained modularity/deployability vs end-to-end latency and operational overhead. - Auditability (retain everything) vs privacy/data-minimisation regulation. A disciplined resolution: 1. **Surface it explicitly** — ideally the conflict is discovered by a *holistic* fitness function rather than by an incident. 2. **Return to the priority order** agreed with the business. The higher-priority characteristic keeps its threshold. 3. **Renegotiate the loser's threshold consciously**, with the business owner, rather than quietly disabling the check. 'p99 rises from 200 ms to 320 ms because payload encryption is mandatory' is a recorded decision. 4. **Look for a design change that dissolves the conflict** before conceding — caching, session-level rather than per-request crypto, hardware acceleration, asynchrony, read models. 5. **Record it** in an ADR and update both functions so the suite stays truthful. 6. **Add a holistic function** covering the interaction so the trade-off stays verified as the system evolves. The anti-pattern is a fitness function that is 'temporarily' disabled or has its threshold relaxed by whoever hit it. At that point the suite stops describing the architecture and starts describing whatever the code happens to do — which is where the organisation was before it had fitness functions. ## Organisational dimension Fitness functions replace the architecture-review-board bottleneck with automated governance, letting teams move independently while the constraints hold. That only works if teams see the rules as *theirs*: co-author them with the teams, expose the suite's health as a first-class dashboard, and treat the architect's job as curating the suite rather than approving individual changes.