Measuring Architecture Characteristics: Three Methods and Fitness Functions for Governance

1. Why Measure Architecture Characteristics

After completing an Architecture Characteristics Worksheet, teams need to verify that the built system actually exhibits those characteristics. Measurement makes architecture health visible and drives the organization toward standard, unified definitions of architecture characteristics.

2. Three Measurement Methods

2.1 Operational Measurement

Characteristics such as performance and scalability map directly to runtime behavior, making them the easiest to measure—but also easy to measure incorrectly. For example, relying solely on average response time is insufficient because averages hide outliers. Teams must also track p99 response time to capture edge‑case anomalies. More mature teams build statistical models from historical data and trigger alerts when real‑time metrics deviate from the model.

2.2 Structural Measurement

Qualities like modularity and cohesion lack direct runtime manifestations yet determine architecture quality. No comprehensive, unified metrics exist, but some indicators and tools can assess key aspects. Cyclomatic Complexity measures code complexity; high values harm modularity and testability, though it cannot distinguish between inherent problem complexity and poor design.

2.3 Process Measurement

Some architecture characteristics relate to the development process. Agility, a composite characteristic, must be decomposed into measurable sub‑characteristics: testability, deployability, and maintainability. Deployability can be quantified with deployment success rate, deployment duration, and defects introduced by deployments.

3. Architecture Governance Lever: Fitness Functions

Extreme Programming gave rise to Continuous Integration, a concept that extends to architecture governance. In this context, automated tools serve as Fitness Functions —objective functions that evaluate how close an output is to its target. A well‑known Java framework for this is ArchUnit.

layeredArchitecture()
    .layer("Controller").definedBy("..controller..")
    .layer("Service").definedBy("..service..")
    .layer("Persistence").definedBy("..persistence..")

    .whereLayer("Controller").mayNotBeAccessedByAnyLayer()
    .whereLayer("Service").mayOnlyBeAccessedByLayers("Controller")
    .whereLayer("Persistence").mayOnlyBeAccessedByLayers("Service")

The example above defines a fitness function that enforces a layered architecture: controllers cannot be accessed by any layer, services may only be accessed by controllers, and persistence may only be accessed by services.

4. Summary

Measurement makes architecture health visible; fitness functions make architecture rules executable. 1. Fundamentals of Software Architecture 2nd Chapter 6 ↩︎