EA capability, roles, and operating model
This is the first of 6 EA Capability and Governance modules. Stage 7 asks how the enterprise sustains architecture as a real operating capability over time rather than treating it as a periodic consulting engagement or a documentation side-activity. The primary TOGAF source is G184 (Leader's Guide to Establishing and Evolving an EA Capability) supplemented by the Architecture Board and architecture contract guidance in C220 Part 5, and the capability assessment model from G249 (64 modules total, ~64 hours).
By the end of this module you will be able to:
- Explain why enterprise architecture capability is an operating choice rather than merely a team structure
- List the seven components of an EA capability identified in G184 and explain each one in plain language
- Describe the three operating-model patterns for architecture teams and explain when each fits
- Explain the G21I governance framework and how it connects capability to board, compliance, and repository behaviour
- Identify the difference between naming architects and establishing an architecture capability
- Design a first-pass operating model for the London Grid case that shows roles, forums, repository, and delivery interfaces working together
Real-world case · 2020
Chief architect hired. Capability not built. Nothing fundamentally changed.
A regulated infrastructure company hired a chief architect in 2020 and declared that it had established an enterprise architecture capability. The chief architect was experienced and competent.
Within a year, the executive team was quietly disappointed. The architect had produced several good documents and given useful advice in meetings, but nothing had fundamentally changed. Delivery teams still made boundary decisions without consulting architecture. The repository was a personal SharePoint folder. Governance forums existed but did not use architecture outputs to shape decisions.
The board commissioned an external review. The review concluded that the company had hired an architect but had not established a capability. There were no defined decision rights, no explicit delivery interfaces, no repository stewardship model, and no mechanism for architecture to shape transition decisions. The role existed. The operating model did not.
The problem was not the person. The problem was that hiring someone with the right title is not the same as building an operating capability. An enterprise architecture capability is real when it has roles, forums, repository ownership, delivery interfaces, and measurable decision impact.
If the enterprise hires someone with the right title but builds no operating model around them, does the architecture capability exist?
That story illustrates the gap between naming an architect and building a capability. This module explains what a workable EA operating model looks like, what G184 says about capability components, and how to tell whether a capability is real.
52.1 Why capability is broader than team design
Many organisations say they have an architecture capability when what they really have is a small set of people with architecture in their job titles. TOGAF's capability lens is broader. It asks how architecture work is sponsored, where the repository sits, which forums decide what, how delivery teams interact with architects, and how architecture remains useful over time.
G184, the Leader's Guide to Establishing and Evolving an EA Capability, is the primary TOGAF Series Guide for this topic. It treats architecture capability as a business asset that must be designed, funded, staffed, governed, and continuously improved. The guide is aimed at senior leaders who sponsor the capability, not just at the architects who execute it.
That perspective matters. If the only people who understand the architecture operating model are the architects themselves, the capability is fragile. It needs executive sponsorship, visible funding, and organisational interfaces that are documented well enough to survive personnel changes.
“An architecture capability requires governance, processes, skills, roles, and tools to function as a sustained enterprise service.”
The TOGAF Standard, 10th Edition - C220 Part 5, Enterprise Architecture Capability and Governance
The key word is sustained. A capability that depends entirely on one person or one project cycle is fragile, not established. G184 expands this into seven explicit components that together define what an architecture capability actually contains.
52.2 The seven components of an EA capability from G184
G184 identifies seven components that together constitute a working architecture capability. If any of these is absent, the capability is incomplete regardless of how talented the architects are.
1. Sponsorship and leadership
Someone at executive level must own the architecture capability as a business investment. Without executive sponsorship, architecture competes for time and attention with every other advisory function and usually loses. The sponsor ensures funding, protects the capability during budget cycles, and connects architecture decisions to business outcomes.
2. Governance structure
The enterprise needs predictable forums where architecture choices, exceptions, and transition decisions can be made or escalated. The Architecture Board is the standard TOGAF forum, but the governance structure also includes decision rights, escalation paths, and the relationship between architecture governance and wider corporate governance.
3. Architecture method and process
The team needs a defined way of working. In a TOGAF context, this means a tailored version of the ADM that fits the enterprise's size, pace, and risk profile. The method defines how architecture work starts, what artefacts are produced, how reviews happen, and how outputs flow into delivery.
4. Architecture content framework and repository
Architecture logic has to live somewhere durable enough to guide delivery, governance, and future change. The content framework defines the types of artefact the enterprise will produce and maintain. The repository provides stewardship, versioning, and access control. Without repository discipline, architecture knowledge decays into personal files and folk memory.
5. Roles and skills
Someone must hold the enterprise-wide view, someone must maintain domain-level architecture, and someone must keep delivery interfaces live and useful. G184 distinguishes between the chief architect role, domain architects, and the supporting skills in repository stewardship, stakeholder management, and governance facilitation. Module 55 covers the G18A skills framework in full.
6. Delivery interfaces
The capability has to touch product, programme, engineering, cyber, data, and operational teams in a way that changes decisions. If architecture produces views that delivery teams never use, the delivery interface is broken regardless of how good the views are. G184 emphasises that architecture must integrate with programme governance, solution design, and operational change processes.
7. Measurement and continuous improvement
A capability that cannot demonstrate its value will eventually lose its funding. G184 recommends measuring architecture impact through decision traceability (can the enterprise trace a delivery choice back to an architecture decision?), exception visibility (are deviations managed consciously?), and stakeholder satisfaction (do delivery teams and sponsors consider architecture useful?). G249 provides the formal assessment framework for capability maturity.
Common misconception
“Hiring a chief architect is the same as establishing an EA capability.”
G184 identifies seven components: sponsorship, governance, method, content and repository, roles and skills, delivery interfaces, and measurement. A chief architect without these operating elements is a label, not a capability. The opening story illustrates exactly this failure.
52.3 Three operating-model patterns
TOGAF does not prescribe one operating model for architecture teams. Different enterprise contexts produce different placement patterns. Three common patterns emerge from practice and from G184's guidance on organisational placement.
Centralised model
A single architecture team reports to a chief architect or CTO and provides architecture services across the enterprise. This model gives strong cross-domain coherence and a single repository. Its weakness is distance from delivery. If the central team becomes a documentation function that advises from a distance, delivery teams learn to route around it. Centralised models work best when combined with deliberate delivery embedding.
Federated model
Domain architects sit inside business units or delivery programmes and maintain local architecture discipline. A lightweight central function coordinates cross-domain coherence, repository standards, and principle stewardship. This model gives stronger delivery relevance but risks divergence if the central coordination is weak. Federated models work best when governance forums and repository standards are explicit enough to prevent silent drift.
Embedded model
Architects are fully embedded in delivery teams with no separate architecture function. Architecture discipline is maintained through shared principles, community of practice, and periodic cross-team alignment. This model is fastest for delivery but weakest for enterprise coherence. It works in smaller or less regulated enterprises where cross-domain interdependence is low.
Most large regulated enterprises use a federated model or a centralised model with deliberate delivery embedding. The choice is not abstract. It depends on the enterprise's coordination needs, regulatory obligations, delivery cadence, and the number of cross-domain boundaries that need architecture attention.
52.4 The G21I governance framework
G21I (Architecture Governance) is the TOGAF Series Guide that connects capability to board behaviour, compliance, and repository stewardship. Where G184 explains what the capability needs, G21I explains how governance keeps it functioning.
The G21I framework defines governance as the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level. That definition matters because it positions governance as an ongoing practice, not a one-time design activity.
G21I identifies several key governance responsibilities.
- Implementing architecture governance processes. This means the enterprise has a defined, repeatable process for reviewing architecture decisions and exceptions.
- Developing an architecture compliance strategy. This means the enterprise knows how it will check whether implementations conform to the architecture.
- Monitoring and reporting on architecture compliance. This means compliance is not just checked at gate reviews but tracked over time.
- Managing architecture contracts and agreements. This means delivery teams and architecture have explicit agreements about what will be delivered and how conformance will be verified.
- Managing dispensations and architecture debt. This means exceptions are visible, time-bounded, and reviewed rather than quietly accumulated.
The G21I framework connects directly to the Architecture Board (covered in Module 53), the compliance review process (Module 54), and the skills framework (Module 55). Together, these form the governance backbone of the EA capability.
“Architecture governance is the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level.”
The TOGAF Standard, 10th Edition - G21I, Architecture Governance
The phrase 'practice and orientation' signals that governance is cultural as well as procedural. An enterprise can have governance documentation without governance behaviour. Only the behaviour counts.
52.5 The test: is the capability real?
A practical way to assess whether an enterprise architecture capability exists or is merely aspirational is to apply five diagnostic questions.
- Sponsorship test. Can the architecture team name an executive who actively sponsors the capability, defends its funding, and connects architecture decisions to business outcomes?
- Decision test. Can the enterprise point to three decisions in the last six months where architecture materially changed the outcome, not just commented on it?
- Repository test. Can a new team member find the current target architecture, active principles, and recent decision log within one hour without asking someone verbally?
- Delivery interface test. Can a delivery lead describe when and how they engage with architecture during a typical programme, without the answer being "we send them our designs for comment"?
- Exception test. When a project deviates from the target architecture, is the deviation visible, recorded, and reviewed, or does it surface only during post-implementation audit?
If the answer to most of these questions is "no" or "unclear", the enterprise has architecture resources but not yet an architecture capability.
London Grid Distribution: designing the capability operating model
London Grid Distribution is a regulated electricity distributor undergoing a multi-year transformation that spans customer connections, network operations, data publication, cyber resilience, and regulatory compliance. That context demands a real architecture capability, not a one-person advisory function.
Applying the G184 framework to London produces the following operating model.
Sponsorship
The transformation director sponsors the architecture capability. The sponsor is responsible for protecting architecture funding within the ED3 business plan cycle, connecting architecture outputs to regulatory submissions, and ensuring the Architecture Board has sufficient executive authority to make binding decisions.
Governance
London operates an Architecture Board with explicit decision rights over target-state choices, transition approvals, major exceptions, and release conditions. The board meets fortnightly with a standing agenda and published decision log. Escalation paths connect to the investment committee and the executive leadership team.
Method
The tailored ADM covers preliminary framing, vision, business architecture, information and application architecture, technology architecture, migration planning, and governance. Each phase produces a defined minimum artefact set. The method integrates with the programme's sprint cadence through architecture runway reviews.
Repository
The London architecture repository is a versioned, searchable store containing principles, target-state definitions, domain models, decision logs, exception registers, and compliance records. Repository stewardship is assigned to a named role. The repository is accessible to delivery teams, not locked in an architecture team folder.
Roles
London's architecture team includes a chief architect who owns the enterprise-wide view and chairs the Architecture Board, domain architects for network, customer, data, and technology, and a repository steward. Domain architects spend at least 40% of their time embedded with delivery programmes rather than writing documents at a distance.
Delivery interfaces
Architecture connects to delivery through three defined touchpoints: architecture runway reviews at programme initiation, design review participation during solution elaboration, and release-condition sign-off at transition gates. Each touchpoint has a defined trigger, expected input, and decision output.
Measurement
London measures architecture impact through decision traceability (percentage of delivery decisions that reference an architecture artefact), exception visibility (percentage of deviations recorded and reviewed within 30 days), and stakeholder satisfaction (quarterly survey of delivery leads and executive sponsors).
An organisation has a chief architect, two enterprise architects, and no documented operating model. Delivery teams occasionally ask the architects for advice. Which G184 components are missing?
A federated architecture model has domain architects embedded in business units but no central coordination function. What is the most likely risk?
An architecture team produces high-quality target-state documents, but delivery teams rarely use them. Applying the G184 framework, which capability component is most likely weak?
Which of the following best describes the relationship between G184 and G21I?
Key takeaways
- An EA capability is defined by seven components from G184: sponsorship, governance, method, content and repository, roles, delivery interfaces, and measurement.
- Three operating-model patterns exist: centralised, federated, and embedded. Most large regulated enterprises use a federated or centralised model.
- The G21I governance framework connects capability to board behaviour, compliance, and repository stewardship.
- A capability proves itself through visible behaviour and decision impact, not through documentation volume.
- The five diagnostic tests (sponsorship, decision, repository, delivery interface, exception) can distinguish real capability from aspirational labelling.
Standards and sources cited in this module
The TOGAF Standard, 10th Edition (C220)
Part 5, Enterprise Architecture Capability and Governance
The core standard covering architecture capability, governance, and operating model guidance.
G184, Leader's Guide to Establishing and Evolving an EA Capability
Full guide
Primary guide defining the seven components of an architecture capability and leadership responsibilities.
Full guide
Governance framework connecting capability to board, compliance, and contract behaviour.
G249, Architecture Capability Assessment
Full guide
Formal assessment framework for evaluating architecture capability maturity.
ED3 Business Plan Guidance, Ofgem
Full guidance
Regulatory context for the London case, relevant to architecture sponsorship and funding justification.
You now understand EA capability as an operating model with seven defined components rather than a team label. The next question is how the Architecture Board should work, what decision rights need to be explicit, and how to design a board that is selective rather than universal. That is Module 53.
Module 52 of 64 · EA Capability and Governance