Study guide
14.3 Architecture Maturity Models, Capability Assessment, and EA Performance Measures
TOGAF Enterprise Architecture Practitioner OGEA-103
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Mechanics & Foundation Overview
1.1 OGEA-103 Exam Structure, Gradient Scoring & Open-Book Strategy 1.2 The TOGAF Standard 10th Edition Structure & Core Concepts 1.3 Enterprise Architecture in Practice: Context, Scope, and Architecture Domains 1.4 The Context for Enterprise Architecture: Purpose, Capability, Security, and the Digital Enterprise
2 Chapter 2: Preliminary Phase & Establishing the EA Capability
2.1 Preliminary Phase Objectives, Inputs, and Activities 2.2 Scope of the Enterprise and Defining the Architecture Footprint 2.3 Establishing Architecture Governance, Frameworks, and Tools
3 Chapter 3: Architecture Vision & Stakeholder Management (Phase A)
3.1 Phase A Objectives, Request for Architecture Work, and Scope Definition 3.2 Stakeholder Management: Identification, Classification, the Power/Interest Grid, and the Stakeholder Map 3.3 Business Scenarios Technique for Problem Definition and Requirements Elicitation 3.4 Architecture Vision, Communications Plan, and Statement of Architecture Work Approval
4 Chapter 4: Business Architecture (Phase B)
4.1 Phase B Objectives, Steps, and Business Modeling Approaches 4.2 Business Capabilities, Capability Mapping, and Assessment 4.3 Value Streams, Value Stream Mapping, and Capability Cross-Mapping 4.4 Business Architecture Artifacts, Gap Analysis, and Architecture Definition Document Updates
5 Chapter 5: Information Systems Architectures — Data Architecture (Phase C)
5.1 Phase C Data Architecture Objectives, Approach, and Data Principles 5.2 Conceptual, Logical, and Physical Data Models and Data Management 5.3 Data Entity/Business Function Matrix, Data Architecture Gap Analysis, and Interoperability Requirements
6 Chapter 6: Information Systems Architectures — Application Architecture (Phase C)
6.1 Phase C Application Architecture Objectives, Approach, and Baseline vs. Target First 6.2 Application Portfolio Rationalization, Component Modeling, and Application Integration 6.3 Application/Organization Matrix, Application Gap Analysis, and Boundary Definitions
7 Chapter 7: Technology Architecture (Phase D)
7.1 Phase D Objectives, Cloud & Modern Platforms, and Technology Principles 7.2 Technology Standards, the Standards Library, Platform Services, and Infrastructure Modeling 7.3 Technology Gap Analysis, Non-Functional Requirements, and Reference Models
8 Chapter 8: Opportunities and Solutions (Phase E)
8.1 Phase E Objectives, Consolidated Gap Analysis, and Work Package Formulation 8.2 Architecture Building Blocks (ABBs) to Solution Building Blocks (SBBs) Transition 8.3 Transition Architectures, Incremental Delivery, and Dependency Analysis 8.4 Architecture Roadmap Development and Trade-Off Analysis 8.5 Business Transformation Readiness Assessment and Risk Management
9 Chapter 9: Migration Planning (Phase F)
9.1 Phase F Objectives, Stakeholder Collaboration, and Governance Alignment 9.2 Business Value Assessment, Cost-Benefit Analysis, and Risk/Feasibility Scoring 9.3 Implementation and Migration Plan Deliverable, Resource Allocation, and Transition Roadmaps
10 Chapter 10: Implementation Governance (Phase G)
10.1 Phase G Objectives, Implementation Governance Structure, and Project Architecture Hand-off 10.2 Architecture Contracts: Purpose, Types, Timing, and Stakeholder Commitments 10.3 Architecture Compliance Reviews: Conformance Levels, Process, Timing, and Checklists
11 Chapter 11: Architecture Change Management (Phase H) & Requirements Management
11.1 Phase H Objectives, Drivers of Architecture Change, and Value Monitoring 11.2 Change Classification: Simplification, Incremental, and Re-Architecting Changes 11.3 Ongoing Governance, Retirement of Solutions, and Maintenance vs. New ADM Cycle 11.4 Requirements Management: Central Role, Traceability, Mid-Phase Discovery, and Scope Conflict
12 Chapter 12: Architecture Governance, Boards, and Dispensations
12.1 Architecture Governance Framework, Organizational Roles, and RACI Matrix 12.2 Architecture Board Structure, Federation, Responsibilities, and Meeting Operations 12.3 Compliance Assessment, Dispensation Process, Expiration, and Remediation Tracking 12.4 Architecture Principles, the Decision Log, and Resolving Principle Conflicts
13 Chapter 13: Architecture Content Framework & Architecture Repository
13.1 The TOGAF Content Framework and Enterprise Metamodel 13.2 Deliverables, Artifacts (Catalogs, Matrices, Diagrams), and Building Blocks (ABBs vs SBBs) 13.3 Architectural Views, Viewpoints, Stakeholder Concerns, and ISO/IEC/IEEE 42010 13.4 The Enterprise Continuum and the TOGAF 10 Architecture Repository
14 Chapter 14: EA Capability, Tailoring, and Iteration
14.1 Tailoring the ADM: Enterprise Context, Process Weight, and Agile Integration 14.2 ADM Iteration Cycles, Levels, and Classes of Architecture Engagement 14.3 Architecture Maturity Models, Capability Assessment, and EA Performance Measures 14.4 Supporting the ADM Work: The TOGAF Library, Series Guides, Patterns, and Security
14.3 Architecture Maturity Models, Capability Assessment, and EA Performance Measures
Key Takeaways Explain This Topic AI
TOGAF builds capability assessment into the Preliminary Phase (a maturity target), Phase A (Evaluate capabilities), the Capability Assessment deliverable, the Governance Repository, and Phase H.
The US Department of Commerce ACMM has six levels: 0 None, 1 Initial, 2 Under Development, 3 Defined, 4 Managed, and 5 Measured.
The ACMM scores nine characteristics separately, including architecture process, business linkage, senior management involvement, IT security, and architecture governance.
Target maturity is set by business need, risk, and cost; the highest level is not automatically the goal.
The Governance Repository's Performance Measurement log captures metrics for the architecture function; outcome measures such as reuse and value realization matter more than activity counts.
Last updated: October 2026
14.3 Architecture Maturity Models, Capability Assessment, and EA Performance Measures
An Architecture Capability must itself be assessed and improved. The TOGAF Standard builds this in at several points:
The Preliminary Phase sets a capability maturity target .
Phase A's Evaluate capabilities step assesses the enterprise's capabilities, including its architecture capability.
The Capability Assessment deliverable records business, IT, and architecture capability.
The Governance Repository keeps capability assessments, including architecture maturity assessments, over time.
Phase H ensures that the EA Capability meets current requirements .
The detailed maturity model lives in the TOGAF Library's Architecture Maturity Models Series Guide. It is not part of the Fundamental Content, so expect it to support scenarios rather than be tested in depth.
Why Maturity Models Matter
TOGAF's guidance draws on the idea that organizations improve through recognizable stages, the Capability Maturity Model concept that originated at the Software Engineering Institute. Maturity models give an enterprise a way to:
Assess the current state of its architecture practice objectively.
Set a realistic target state and the steps to reach it.
Track progress and compare business units over time.
Maturity models also appear in Business Transformation Readiness Assessment , which presents each readiness factor as a maturity model with baseline, target, and intermediate levels (Section 8.5).
The Architecture Capability Maturity Model (ACMM)
The best-known model reproduced with TOGAF is the US Department of Commerce IT Architecture Capability Maturity Model (ACMM) . It has six levels , numbered from zero:
- Level Name Typical characteristics
- 0 None No architecture program
- 1 Initial Informal, ad hoc architecture processes; work depends on individual effort
- 2 Under Development The architecture process is being established; roles and some standards are emerging
- 3 Defined A documented architecture process is defined, communicated, and followed
- 4 Managed The process is part of the culture and is managed with quality metrics
- 5 Measured The process is continuously improved using quantitative feedback
The ACMM assesses nine architecture characteristics separately:
- Architecture process
- Architecture development
- Business linkage
- Senior management involvement
- Operating unit participation
- Architecture communication
- IT security
- Architecture governance
- IT investment and acquisition strategy
An ACMM scorecard records the level reached for each characteristic. An organization is rarely at one level across the board. A practice can be Level 4 on architecture process and Level 1 on business linkage, and averaging the scores hides exactly the weakness worth fixing.
Other Maturity Models
TOGAF's maturity guidance also refers to other capability maturity models, such as CMMI and models aimed at specific concerns. The general lesson is the same: choose a model that fits the enterprise's purpose, assess each characteristic, and set targets that reflect business need.
Setting a Realistic Target
The target maturity level is a business decision, not automatically the top level. A small or low-risk organization may gain most of the value from reaching Level 3 (Defined) on key characteristics. A heavily regulated enterprise may need Level 4 (Managed) on governance and security. Each step up costs effort in governance, tooling, skills, and change management, so set the target by weighing value against cost, and record it with its rationale in the Preliminary Phase.
Capability Uplift Lifecycle
Improving architecture maturity is itself a change effort that the ADM can manage, through an Architecture Capability iteration (Preliminary Phase and Phase A):
Baseline assessment : score each characteristic, for example with the ACMM scorecard, using interviews and evidence.
Target formulation : agree the target level per characteristic and the business reasons for it.
Gap analysis : identify the missing governance bodies, processes, skills, tools, and repository content.
Uplift roadmap : define work packages such as chartering the Architecture Board, defining principles, establishing the repository, and building skills, which the Architecture Skills Framework guide supports.
Execution and governance : deliver the work packages with sponsor oversight.
Periodic reassessment : repeat the assessment, record it in the Governance Repository, and revisit the target in Phase H.
Measuring the Architecture Function
TOGAF's Governance Repository includes Performance Measurement : the performance criteria defined in the architecture function's charter and the metrics for project governance, so performance can be measured and evaluated continuously. The specific metrics are the enterprise's choice. A balanced set usually combines:
Process and Governance Measures
Decision cycle time : the time from submitting an item to a governance decision.
Compliance rate : the share of projects passing compliance reviews without unapproved deviations.
Dispensation closure : the share of dispensations remediated by their expiry date.
Repository currency : the share of production systems with up-to-date architecture descriptions.
Outcome Measures
Reuse rate of approved building blocks.
Reduction in duplicate or legacy systems and the associated run costs.
Investment alignment : the share of change investment traced to capabilities on the target roadmap.
Value realization : actual benefits compared with those expected, as tracked by Phase H's value realization process.
Counting documents, diagrams, or meetings measures activity, not value. Executives respond to outcome measures.
Practitioner Scenario: Capability Uplift in a Healthcare Network
A healthcare network of 45 hospitals finds, after a failed regional integration, that hospitals have bought incompatible clinical systems and duplicate patient databases. The new chief architect runs an ACMM assessment in the Preliminary Phase:
Findings : architecture process and development score Level 1 (Initial) , with no formal board and no shared repository. Senior management involvement scores higher after the incident.
Target : given the regulated, safety-critical context, the board agrees on Level 4 (Managed) for architecture governance and IT security, and Level 3 (Defined) elsewhere, within 24 months.
Uplift : charter an Architecture Board co-chaired by clinical and IT leadership; define principles; establish a repository with the relevant industry reference models in the Reference Library; and track reuse of shared patient-data services and the retirement of duplicate systems.
Review : the assessment is repeated every six months, and results go to the Governance Repository and the executive sponsor.
Common Exam Traps
Using the wrong level names. The ACMM levels are 0 None, 1 Initial, 2 Under Development, 3 Defined, 4 Managed, and 5 Measured.
Assuming the top level is always the goal. Targets reflect business context, risk, and cost.
Scoring one overall level. Assess each characteristic; averages hide weak spots.
Treating assessment as one-off. Maturity is reassessed periodically and revisited in Phase H.
Relying on activity metrics. Show business outcomes, not document counts.