TOGAF Architecture Capability Framework Explained

What is the TOGAF Architecture Capability Framework? (Quick Answer)

The TOGAF Architecture Capability Framework is the set of resources — people, processes, structures, and tools — that an organization needs to run a professional, effective Enterprise Architecture function. It is established during the Preliminary Phase of the ADM, before any architecture design work begins. A mature capability gives the EA team both the authority and the mechanisms to influence organizational decisions consistently.

After you've mapped your career and understood digital transformation, the next question is: "How does an organization build a professional Enterprise Architecture (EA) function?"

Enterprise Architecture is not something that just "happens." It requires a structured set of people, processes, and tools to be effective. This is what TOGAF calls an Architecture Capability.

In this post, we’ll explore the Architecture Capability Framework and how you can use it to build a mature, high-performing EA team.

What is an Architecture Capability?

Think of an "Architecture Capability" as the Enterprise Architecture Engine of the company. It’s what allows the organization to take a business strategy and turn it into a successful technical reality.

The Capability Framework is mostly handled in the Preliminary Phase of the ADM. This is where you set the "rules of the game" before you start designing anything.

The Four Pillars of the Capability Framework

To have a functioning EA capability, you need four things:

Structure: The organizational chart. Who is in the team? Who do they report to?
Process: The TOGAF ADM itself. How does the team actually do its work?
People: The skills and experience of the architects.
Tools: The software repository, standards, and repositories (the Architecture Repository).

The Architecture Board: The Governing Body

A mature EA capability needs an Architecture Board. This is the formal committee that oversees and governs all architectural activity.

The Board's Core Tasks

Approve Strategic Designs: Ensuring the company is moving in the right direction.
Grant Waivers: Deciding when a project can deviate from a technical standard (e.g., "for this specific emergency project, you can use MySQL instead of PostgreSQL").
Manage Compliance: Checking that building teams are actually following the approved designs.
Dispute Resolution: Resolving conflicts between different technical teams.

An EA team without an Architecture Board is just a group of advisors with no real authority.

Measuring Success: The Architecture Maturity Model

How do you know if your EA team is doing a good job? Many organizations use a Maturity Model (often based on CMMI).

The Five Levels of EA Maturity

Level 1: Initial: No formal architecture process. Decisions are made on a project-by-project basis.
Level 2: Under Development: Some basic standards exist, but the process is not consistently followed.
Level 3: Defined: A formal EA team exists, the TOGAF ADM is used, and a repository is in place.
Level 4: Managed: The EA team is measuring its own performance and ROI. Metrics are used to drive improvements.
Level 5: Optimizing: The EA capability is "self-healing." It continuously improves based on real-world feedback and changing business needs.

As an architect, your goal is to move your organization up at least one maturity level every 1-2 years.

Practical Steps to Build Your EA Capability

If you are starting from scratch (or close to it), here is a realistic sequence for building EA capability:

Secure executive sponsorship. Without a C-level champion (typically the CTO or CIO), an Architecture Board has no real authority. Before anything else, establish who will sponsor and protect the function.
Define your architecture principles. A small set of 5–10 well-formed principles gives every team a decision-making guide and signals that EA is open for business. See our architecture principles and governance guide for the exact structure.
Stand up a lightweight governance process. Start with a simple architecture review process — even a weekly 1-hour board meeting — before investing in complex tooling.
Establish the Architecture Repository. Even a well-structured SharePoint or Confluence site is better than no repository. See our Architecture Repository guide for what classes of content it should contain.
Measure and improve. Use the maturity model above to baseline where you are, set a target for 12 months, and review quarterly.

The official reference for the Architecture Capability Framework is available in the TOGAF standard published by The Open Group.

How This Fits Into the ADM

The Architecture Capability Framework is not a separate exercise from the ADM — it is the foundation that makes the ADM work. Here is how each capability pillar maps to the ADM structure:

Preliminary Phase is where the capability is established. Before Phase A begins, the Preliminary Phase defines the governance framework, the Architecture Principles, the team structure, and the scope of EA in the organisation. Every element of the Capability Framework is put in place here.

Phase A through D rely on the capability being operational. The Architecture Board reviews and approves the Statement of Architecture Work in Phase A. The repository captures all outputs from Phases B, C, and D. Principles established in the Preliminary Phase constrain design decisions in every domain.

Phase G (Implementation Governance) is where the Architecture Board's authority is exercised most directly. Compliance reviews, waiver decisions, and architecture contract enforcement are all functions of the mature EA capability established in the Preliminary Phase.

Phase H (Architecture Change Management) depends on the Governance Log component of the Architecture Repository. Without a capability that maintained accurate records throughout the project, Phase H has no baseline from which to measure drift.

This means that investing in the Architecture Capability Framework is not bureaucratic overhead — it is what determines whether the ADM produces real-world outcomes or just internally consistent documents that nobody follows. Organisations that skip establishing the capability formally in the Preliminary Phase consistently find that their architecture work lacks authority and their deliverables go unimplemented.

The full specification of the Architecture Capability Framework, including the recommended maturity model and governance structures, is available in the TOGAF standard from The Open Group and elaborated in the TOGAF Series Guides.

Summary

Building an Enterprise Architecture capability is a marathon, not a sprint. It takes time to build the trust, the processes, and the tools needed to truly influence an organization. By using the Architecture Capability Framework, you can ensure your team is built on a solid foundation, with the authority and the skills to deliver real strategic value.

In our next post, we’ll see how this looks in the real world with: TOGAF Case Studies — FinTech, Healthcare & Retail.

This post is part of the TOGAF 9.2 Masterclass series. Don’t forget to check out our previous post on Digital Transformation with TOGAF — Agile EA.

Common Mistakes When Building an Architecture Capability

1. Starting with process before people Organisations frequently invest in architecture methodology and tooling before establishing who will do the architecture work. A documented ADM process with no trained architects to execute it produces nothing. Sequence the build correctly: identify and develop the people first, then establish the process, then select supporting tools.

2. Creating an ivory tower architecture function An architecture team that produces documents but has no visible connection to delivery programmes quickly loses organisational credibility. Architecture capability must demonstrate tangible value — decisions made, risks avoided, delivery enabled. Establish feedback loops between the architecture team and delivery teams, and report on architecture outcomes, not just activity (documents produced, reviews completed).

3. Scoping the Architecture Board too narrowly A board composed only of senior technologists misses business perspective on architectural trade-offs. The Architecture Board should include representatives from the business, security, risk, and finance functions in addition to technical architects. TOGAF's Architecture Governance guidance recommends a governance structure that reflects the full breadth of stakeholder interests.

4. Conflating architecture capability maturity with tool adoption Buying an enterprise architecture tool does not mean the organisation has architecture capability. Capability is measured by the quality of architectural decisions, the consistency of standards adoption, and the effectiveness of governance — not by the number of ArchiMate diagrams in a repository. Use the TOGAF Architecture Maturity Model to assess capability honestly before investing in tooling.

5. Not defining the architecture team's mandate formally Without a clear mandate from senior leadership, the architecture function cannot enforce standards or require project teams to engage with governance. The Architecture Charter (established in the Preliminary Phase) defines the scope, authority, and operating model of the architecture capability. Produce it early and get it formally approved.

Frequently Asked Questions

What is the TOGAF Architecture Capability Framework? The Architecture Capability Framework defines the structures, roles, skills, processes, and tools needed to establish and operate a mature enterprise architecture practice. It covers the Architecture Board, Architecture Compliance reviews, the Architecture Contract, Architecture Governance, and the skills and organisational models for the architecture team. It is the TOGAF answer to "how do we build an architecture function?" rather than "how do we do architecture?" The full framework is defined in Part VI of the TOGAF standard.

What is an Architecture Board in TOGAF? The Architecture Board is the governance body responsible for overseeing and reviewing the implementation of enterprise architecture. It approves architectural decisions that exceed the authority of individual project teams, adjudicates architecture compliance disputes, maintains architecture standards, and manages the Architecture Repository. Board composition, authority, and operating procedures are defined in the Architecture Governance framework established during the Preliminary Phase.

How does TOGAF define architecture maturity? TOGAF references several architecture maturity models, including the US Government's EAMMF (Enterprise Architecture Maturity Model Framework) and the Gartner EA Maturity Model. Common maturity levels progress from: no formal EA practice, through initial and developing stages (ad hoc architecture, some standards), to managed (defined process, Architecture Board in place), to optimised (architecture drives investment decisions, measured outcomes). The TOGAF standard's Architecture Governance section provides the detailed maturity assessment criteria.