Architecture
Maturity Models

The strategic guide for using maturity models well — recognising that the team's deliberate selection of one model rather than a composite of many, the honest current-state assessment grounded in evidence rather than aspiration, the explicit target-state choice with rationale rather than a default of "everyone should reach level 5," the trajectory-over-snapshot interpretation that values rate-of-improvement above absolute score, the per-team calibration that prevents inter-team comparison from becoming theatre, and the assessment cadence that lets each cycle inform the next rather than producing identical numbers year after year are what determine whether maturity assessments drive real capability development that the organisation can feel in its delivery outcomes or whether they degrade into compliance rituals that produce ascending numbers on slides while the underlying engineering practice stagnates.

The strategic guide to the catalogue of architecture-relevant maturity models — recognising that the team's awareness of the published landscape rather than reflexive adoption of the first model encountered, the explicit understanding that each model has a *scope* (delivery process, security, DevOps, cloud-native, AI) it covers well and other scopes it does not, the recognition that level structures vary fundamentally across models so cross-model score comparison is meaningless, the appreciation that some models are organisational-altitude and others are system-altitude and they answer different questions, and the awareness that modern architecture practice typically uses two or three models in parallel for different purposes rather than one model for everything are what determine whether the team's choice of maturity instrument matches the question being asked or whether the team mismeasures the wrong dimension because the chosen model was the only one anyone had heard of.