9.4 Architecture Maturity Models & Capability Assessments

9.4 Architecture Maturity Models & Capability Assessments

To systematically establish and transform an Enterprise Architecture (EA) capability, executive leadership and chief architects must accurately benchmark their organization's current operational state. Attempting to enforce advanced architecture governance or complex metamodels on an enterprise with an immature architecture practice inevitably results in governance friction, compliance failure, and organizational resistance. Architecture Capability Maturity Models (ACMM) provide a structured, quantitative benchmarking framework to assess current architectural maturity, define a realistic target maturity state, and formulate an actionable Capability Improvement Roadmap.

The maturity model the TOGAF Standard actually reproduces is the US Department of Commerce (DoC) Architecture Capability Maturity Model, Version 1.2 (December 2007). It applies the Capability Maturity Model idea — originally from the Software Engineering Institute at Carnegie Mellon — to enterprise architecture practices, governance bodies, and repository assets. Attributing the TOGAF ACMM directly to CMMI is a common but incorrect shorthand: TOGAF publishes the DoC model, not CMMI.

The DoC ACMM has three sections (the maturity model itself, the characteristics of operating-unit processes at each level, and the ACMM scorecard), six maturity levels, and nine architecture elements assessed at each level:

An organization is not "at Level 3" as a single verdict; it scores each of the nine elements separately and then derives a weighted mean, plus the percentage achieved at each level per element. That distinction matters in practice — a practice can be Level 4 on architecture process and Level 1 on business linkage, and the average will hide exactly the problem worth fixing.

---

Detailed Breakdown of the 6 ACMM Maturity Levels

The TOGAF ACMM defines six sequential levels of maturity, numbered Level 0 through Level 5. Each level represents an operational milestone characterized by specific operational behaviors, governance traits, and repository/tooling characteristics.

Level 0: None

• Operational Behavior: Complete absence of Enterprise Architecture awareness or formal architecture activities. Technical and business decisions are made in isolated silos based strictly on immediate, localized project needs.
• Governance Traits: Non-existent governance. No Architecture Board, no architecture principles, and no compliance reviews exist. Technical debt accumulates unmonitored.
• Software & Repository Characteristics: Disconnected systems, zero architectural documentation, and no shared repository or standardized building blocks.

Level 1: Initial

• Operational Behavior: Informal, tactical, and reactive architecture activities. Architecture efforts occur sporadically through heroic individual contributions on critical projects rather than established organizational processes.
• Governance Traits: Informal and uncoordinated governance. No enterprise-wide standards exist; governance is applied inconsistently and depend entirely on individual project managers or lead developers.
• Software & Repository Characteristics: Architectural artifacts consist of ad-hoc diagrams, local spreadsheets, and unstandardized design documents stored in fragmented file shares.

Level 2: Under Development

• Operational Behavior: The enterprise architecture capability is actively being established. Basic architecture processes are defined, and an initial EA core team is operational.
• Governance Traits: Early governance structures emerge. Basic architecture principles are drafted, and informal stage-gate reviews are conducted for high-visibility IT projects. Executive management acknowledges the need for EA.
• Software & Repository Characteristics: Centralized wikis or shared folders house initial baseline architecture descriptions. Early identification of candidate Architecture Building Blocks (ABBs) begins.

Level 3: Defined

• Operational Behavior: Explicit, standardized, enterprise-wide EA process is fully documented, published, and integrated into the organizational lifecycle (e.g., tailored TOGAF ADM).
• Governance Traits: An Architecture Board is formally chartered with explicit executive authority. Architecture compliance reviews are mandatory at project stage-gates, and formal dispensation procedures are operational.
• Software & Repository Characteristics: A central Architecture Repository is established containing the Architecture Metamodel, Standards Information Base (SIB), Governance Log, and reusable Architecture Building Blocks (ABBs).

Level 4: Managed

• Operational Behavior: The enterprise architecture process is quantitatively measured, managed, and controlled. Enterprise decision-making is driven by empirical architectural metrics, Key Performance Indicators (KPIs), and Service Level Agreements (SLAs).
• Governance Traits: Quantitative governance enforcement. The Architecture Board tracks quantitative metrics including architecture compliance pass rates, dispensation grant frequencies, and technical debt retirement metrics.
• Software & Repository Characteristics: Enterprise Architecture management software is integrated with Project Portfolio Management (PPM) and IT Service Management (ITSM) tooling. Automated tracking of ABB reuse percentages and repository telemetry is active.

Level 5: Measured

• Operational Behavior: Continuous process improvement driven by measurement. The EA capability functions as a proactive innovation engine, using quantitative feedback loops, return-on-investment analysis, and industry benchmarks to refine architectural processes ahead of market disruptions. (Note the name: the DoC ACMM's top level is Measured, not "Optimizing" as in the generic CMM ladder — a frequent distractor.)
• Governance Traits: Adaptive, automated governance. Governance policies dynamically adjust based on empirical performance data and automated policy enforcement mechanisms.
• Software & Repository Characteristics: Automated compliance checking embedded into Continuous Integration / Continuous Deployment (CI/CD) pipelines, real-time architecture repository analytics, and automated impact prediction modeling.

---

ACMM Level Summary & Comparison Matrix

---

Operational Transitions and Governance Challenges

Transitioning between ACMM maturity levels requires overcoming specific operational and cultural hurdles.

Transitioning from Level 1 (Initial) to Level 2 (Under Development)

• Primary Challenge: Moving away from individual heroic reliance to repeatable team structures.
• Key Actions: Executive leadership must charter an initial EA team during the Preliminary Phase, draft baseline architecture principles, and demonstrate quick-win value on high-priority projects.

Transitioning from Level 2 (Under Development) to Level 3 (Defined)

• Primary Challenge: Overcoming localized project resistance and standardizing processes enterprise-wide.
• Key Actions: Formally document the tailored TOGAF ADM process, charter the Architecture Board with executive sign-off authority, publish the Architecture Repository, and make stage-gate compliance reviews mandatory across all project portfolios.

Key Distinction: Qualitative Level 3 (Defined) vs. Quantitative Level 4 (Managed)

A critical focal point for enterprise architects and TOGAF exam candidates is the fundamental boundary between Level 3 and Level 4:

• Level 3 (Defined) is qualitative. The architecture process is standardized and documented, but evaluation of success relies on qualitative feedback and subjective compliance checks.
• Level 4 (Managed) is quantitative. The EA practice operates under statistical and empirical measurement. Key metrics tracked include:
  • ABB Reuse Rate: Percentage of project solutions built using pre-approved Architecture Building Blocks.
  • Compliance Pass Rate: Percentage of projects passing stage-gate reviews on first submission.
  • Dispensation Rate: Frequency and cost tracking of granted architectural dispensations and temporary waivers.
  • Technical Debt Reduction: Measured monetary reduction in legacy application maintenance costs achieved through architecture consolidation.

Transitioning from Level 4 (Managed) to Level 5 (Measured)

• Primary Challenge: Preventing governance rigidity and transforming EA into an engine of continuous innovation.
• Key Actions: Embed automated governance rules directly into modern delivery chains (such as DevSecOps pipelines), leverage machine-readable architecture definitions, and use predictive analytics to proactively evolve the Standards Information Base (SIB).

---

Architecture Capability Assessment Methodology

Conducting a formal capability assessment is essential during the Preliminary Phase (to establish baseline capability before launching major ADM cycles) and during Phase A / Phase H iterations (to measure maturity progression).

+-----------------------------------------------------------------------+
|                    1. Define Assessment Scope                         |
|         (Target Business Units, Domains, Operating Entities)          |
+-----------------------------------------------------------------------+
                                   |
                                   v
+-----------------------------------------------------------------------+
|                 2. Collect Data Across 6 Dimensions                   |
|       (Interviews, Artifact Audits, Surveys, Skill Assessments)       |
+-----------------------------------------------------------------------+
                                   |
                                   v
+-----------------------------------------------------------------------+
|                3. Score Current vs Target State (0-5)                 |
|       (Evaluate Gaps; Level 5 is NOT mandatory for all domains)       |
+-----------------------------------------------------------------------+
                                   |
                                   v
+-----------------------------------------------------------------------+
|            4. Formulate Capability Improvement Roadmap                |
|      (Prioritized Work Packages, EA Infrastructure Investments)       |
+-----------------------------------------------------------------------+

The 6 Key Evaluation Dimensions

TOGAF capability assessments evaluate maturity across six core dimensions:

1. Architecture Governance: Authority, charter clarity, board active involvement, and enforcement mechanisms.
2. Architecture Process: Rigor of ADM tailoring, phase integration, and alignment with Agile/PPM lifecycles.
3. Architecture Content & Repository: Sophistication of metamodels, ABB cataloging, SIB completeness, and repository accessibility.
4. Human Capital & Architecture Skills: Alignment with the TOGAF Architecture Skills Framework, competency levels, and continuous training programs.
5. Business Alignment & Value Realization: Integration with business strategy, capability mapping, and direct demonstration of ROI.
6. Software & Tooling Capability: Maturity of specialized EA modeling tools, repository automation, and enterprise software integration.

Data Collection & Scoring

Assessors collect data via structured stakeholder interviews, past project compliance audits, and architectural artifact evaluations. Each dimension is scored from 0.0 to 5.0. Target maturity states are established based on organizational needs—it is a major misconception that every enterprise should target Level 5 across all dimensions, as the cost of achieving Level 5 in non-critical domains often outweighs the strategic benefits.

---

Real-World Enterprise Maturity Scenario & Practical Exam Traps

Real-World Enterprise Scenario

A global retail bank operated at Level 2 (Under Development). Each business line (Retail Banking, Wealth Management, Mortgages) developed separate customer portals with redundant backend integrations. By conducting an ACMM capability assessment during the Preliminary Phase, chief architects identified a score of 1.8 in Architecture Governance and 2.1 in Content Repository. The bank formulated a Capability Improvement Roadmap to achieve Level 3 (Defined) within 12 months by establishing a unified Architecture Board, publishing a central API repository, and enforcing mandatory stage-gate reviews. Within 24 months, by tracking ABB reuse rates and compliance KPIs, they successfully transitioned to Level 4 (Managed), reducing integration project delivery times by 35%.

TOGAF Exam Traps & Key Takeaways

• Exam Trap 1: Target Level 5 Fallacy: TOGAF exam questions often ask whether an organization must always target Level 5 (Measured). The answer is NO. The target maturity level must be tailored to the enterprise's strategic goals, risk appetite, and cost-benefit trade-offs.
• Exam Trap 2: Conflating Process Maturity (ACMM) with Solution Quality: ACMM measures the maturity of the Enterprise Architecture capability and process, not the software quality of individual application codebases.
• Exam Trap 3: Level 3 vs Level 4 Distinction: Remember that Level 3 is Defined & Qualitative (documented processes, functional board), whereas Level 4 is Managed & Quantitative (empirical metrics, KPI tracking, dispensation metrics).