Chapter 6 — Measuring and Governing Architecture Characteristics

Why it matters

A characteristic you can’t measure is a wish. This chapter makes them operational.

Core ideas

• Measurable definitions: many characteristics are vague (“agility,” “performance”). Give each an objective, testable definition (e.g., performance → p95 latency < 200ms; scalability → sustain N concurrent users).
• Types of measures: operational (performance, scalability, response time), structural (cyclomatic complexity, coupling metrics), and process (CI/CD cadence, test coverage relevance).
• Cyclomatic complexity as a structural measure; keep it in check.
• Governance and fitness functions: a fitness function is any mechanism that provides an objective integrity assessment of some architecture characteristic. Categories: atomic vs. holistic, triggered vs. continual, static vs. dynamic, automated vs. manual. Tools/techniques: ArchUnit (Java), NetArchTest (.NET), metrics gates, chaos engineering (holistic, e.g., Netflix’s Chaos Monkey), automated governance in the CI pipeline.
• The idea of evolutionary architecture: fitness functions let the architecture change safely over time without eroding its important characteristics (“architectural erosion” / the “bit rot” problem).

Trade-offs to argue

Automated governance costs effort to build and maintain, but manual governance doesn’t scale and rots. Choosing which characteristics to guard with fitness functions is itself a prioritization trade-off.

Terms to own

fitness function (all four axis pairs), cyclomatic complexity, governance, architectural erosion, ArchUnit/NetArchTest, chaos engineering.