EA capability, roles, and operating model

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.

This course distils G184's guidance into 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 ADMthat 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's guidance on leadership and staffing distinguishes between the chief architect role, domain architects, and the supporting skills in repository stewardship, stakeholder management, and governance facilitation. Module 55 covers the G198 Architecture 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 needs to 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. This course's working framework, drawing on G184, measures 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?). G203, the Architecture Maturity Models guide, provides the formal assessment framework for capability maturity.

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.

The Enterprise Architecture Capability and Governance document in C220 is the part of the TOGAF Standard that connects capability to board behaviour, compliance, and repository stewardship. Where G184 explains what the capability needs, the governance framework explains how governance keeps it functioning.

The standard defines architecture 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.

The standard 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.

A practical way to assess whether an enterprise architecture capability exists or is merely aspirational is to apply five diagnostic questions.

1. Sponsorship test. Can the architecture team name an executive who actively sponsors the capability, defends its funding, and connects architecture decisions to business outcomes?
2. 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?
3. 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?
4. 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"?
5. 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 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 ADMcovers 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).