Architecture Capability Framework

Section 1: Capability Framework Overview

The Architecture Capability Framework defines what an organisation needs to successfully operate an Enterprise Architecture function. It moves beyond process (the ADM) and content (the Content Framework) to address the organisational infrastructure required to sustain EA practice over time.

The framework has six core components:

• Architecture Board — the cross-organisational body that oversees EA governance
• Architecture Compliance — processes for ensuring projects adhere to approved architectures
• Architecture Contracts — formal agreements governing delivery and evolution of architectures
• Architecture Governance — the framework, policies, and processes for managing EA
• Architecture Maturity Models — tools to assess and improve EA capability
• Architecture Skills Framework — competency definitions for architecture roles

Section 2: Establishing an Architecture Practice

Before the ADM can be run effectively, the organisation must put in place the prerequisite conditions for EA success. This work begins in the Preliminary Phase and is governed by the Capability Framework.

Prerequisites for EA Success

• Visible executive sponsorship from a C-suite champion (typically CIO or CTO)
• A clear mandate defining the scope and authority of the EA function
• Budget and headcount allocated to the architecture team
• An agreed-upon architecture framework (TOGAF or tailored version)
• Tooling and repository infrastructure to store and share architecture artefacts
• Governance mechanisms, including an Architecture Board, established before the first ADM cycle

Architecture Team Structure

Organisational Positioning of EA

EA should ideally sit within or close to the office of the CIO/CTO to maintain authority across business units. A federated model — central EA team setting standards, domain teams applying them — is the most common pattern in large enterprises. The Architecture Board provides the cross-organisational governance overlay regardless of where EA sits structurally.

Section 3: Architecture Skills Framework

The Architecture Skills Framework provides a consistent vocabulary for describing, assessing, and developing the skills of architecture practitioners. It is organised into five skills categories and three proficiency levels.

Skills Categories

Proficiency Levels

• Level 1 — Awareness: Understands basic concepts; can participate in architecture activities under supervision; aware of TOGAF terminology
• Level 2 — Practitioner: Applies skills independently in typical situations; can produce standard architecture artefacts; has TOGAF Foundation (OGEA-101) or equivalent
• Level 3 — Expert: Leads architecture engagements; mentors others; shapes governance; contributes to standards; holds advanced certification (OGEA-103 or equivalent)

Skills Matrix Approach

A skills matrix maps each architecture role to each skill category at a required proficiency level. For example, a Domain Architect (Data) requires Level 3 in IT/Data skills, Level 2 in Architecture Specific skills, and Level 1 in Legal Environment. The matrix is used for recruitment, performance review, and training planning.

Section 4: Architecture Maturity Models

Maturity models allow an organisation to assess the current state of its EA capability and plan a structured improvement roadmap. TOGAF draws on CMMI-inspired five-level maturity progression.

Assessment and Improvement Roadmap

Assessment is typically performed via structured interviews, artefact reviews, and stakeholder surveys. Results are scored per maturity dimension (governance, processes, tools, skills, culture). The improvement roadmap identifies priority areas to advance one maturity level at a time, with specific actions, owners, and timescales per dimension.

Section 5: Architecture Roles

Section 6: Architecture Governance Structure

Architecture Board Composition and Charter

The Architecture Board is the primary governance body for enterprise architecture. A typical board includes: the Chief Architect (chair), senior representatives from each business domain, the CIO or delegate, and representatives from key technology domains. The board charter defines its mandate, meeting cadence, quorum requirements, and escalation paths.

Reporting Lines and Decision Authority

Section 7: Architecture Repository Management

The Architecture Repository stores all architecture artefacts produced during ADM cycles. Its governance is a key Capability Framework responsibility.

• Ownership: The Chief Architect owns the repository; the Architecture Analyst typically manages day-to-day maintenance and version control
• Tooling considerations: Repository tools range from simple document management systems to dedicated EA tools (e.g., Sparx EA, ABACUS, Alfabet). The tool should support the six repository classes: Architecture Metamodel, Architecture Landscape, Reference Library, Standards Information Base, Governance Log, Architecture Requirements Repository
• Governance: Changes to repository content follow a defined change-control process; artefacts are versioned; access controls restrict write permissions to authorised architects; the board approves major structural changes to the repository

Section 8: Certification and Training

TOGAF Certification Path

Continuing Education and Communities of Practice

• Continuing education: The Open Group recommends re-certification or continuing professional development (CPD) activity every three years to keep pace with framework evolution
• Communities of Practice (CoP): Internal architecture CoPs share lessons learned, debate standards, and mentor junior architects — a key mechanism for sustaining maturity at Levels 4–5
• Other certifications: TOGAF architects often complement their credential with ITIL (service management), Zachman, SABSA (security architecture), or cloud certifications (AWS, Azure) depending on domain focus

Practice Questions

Five exam-style questions covering this chapter. Click a question to reveal the answer and explanation.

Mark Chapter 15 as complete