Stage 7 summary. Running EA as a Capability

An enterprise architecture capability is the operating model that turns architecture from advice into decisions. The primary TOGAF source is G184, the Leader's Guide to Establishing and Evolving an EA Capability, which treats the capability as a business asset that must be designed, funded, staffed, governed, and continuously improved. This course distils that guidance into seven components. Sponsorship and leadership, governance structure, architecture method and process, content framework and repository, roles and skills, delivery interfaces, and measurement and continuous improvement. If any is absent, the capability is incomplete regardless of how talented the architects are.

The stage opens with the failure that makes the framework necessary. A regulated infrastructure company hired a competent chief architect in 2020 and declared the capability established. A year later nothing had fundamentally changed, because hiring supplies only the roles component. Five diagnostic tests reveal whether a capability is real. Can the team name an active executive sponsor, point to three decisions architecture materially changed in six months, let a new joiner find the target architecture and decision log within an hour, hear a delivery lead describe defined engagement points, and show that deviations surface as recorded exceptions rather than post-implementation audit findings.

TOGAF does not prescribe one placement for the team. Three patterns recur. A centralised model gives strong coherence but risks distance from delivery, a federated model puts domain architects inside business units with a light central function coordinating coherence, and an embedded model disperses architects entirely into delivery teams. Most large regulated enterprises use a federated model or a centralised one with deliberate delivery embedding, because the choice follows coordination needs, regulatory obligations, and the number of cross-domain boundaries that need attention.

The TOGAF Standard describes the Architecture Board as a cross-organisation body that oversees the implementation of the governance strategy and is responsible for the review and maintenance of the overall architecture. That is a coherence job, not a universal review job. The government agency in the opening story reviewed 247 items in a year and decided 11, because its charter promised to review and advise on all architecture matters, its decision rights were assumed rather than written down, and no triage separated board-level items from the rest. Delivery teams learned the board was a formality and routed around it.

The remedy is a three-level decision-rights structure. The board decides genuinely cross-enterprise questions, target-state and transition choices, material exceptions, cross-domain integration conflicts, release conditions with enterprise consequence, and principle interpretations that set precedent. The domain architect decides bounded domain questions with the board informed. The delivery team decides within published guardrails with no escalation at all. The practical test is predictability. If a delivery lead cannot predict whether a decision needs board review, the rights are not clear enough, and teams will either over-escalate or quietly diverge.

Composition and cadence keep the board decisive. It should represent business, technology, delivery, and architecture, stay small enough to decide, typically 6 to 10 members, and meet on a rhythm that protects decision time, with decision items taking the largest share of a structured agenda ahead of exception review, information items, and a forward look. London runs an 8-member board chaired by the chief architect, meeting fortnightly for 90 minutes with papers circulated 48 hours ahead, and its published decision log feeds the regulatory submissions a regulated utility must defend.

The Architecture Compliance chapter of the C220 EA Capability and Governance volume grades an implementation against the architecture specification on six levels, irrelevant, consistent, compliant, conformant, fully conformant, and non-conformant, so assessment never collapses into a binary pass or fail. Compliant means a faithful subset of the specification, conformant means everything specified plus extras, fully conformant means full correspondence, and non-conformant is reserved for specified features implemented out of line with the specification. The review itself runs as five moves, raise the request and confirm scope, prepare the evidence pack, hold the review, record findings, and decide and sign off, with the decision recorded in the repository.

Grading the letter is not enough. Rule compliance asks whether formal standards, controls, and obligations are met. Intent compliance asks whether the architecture's deeper purpose, interoperability, resilience, and future coherence, survives local compromises. The bank in the opening story had marked every project compliant while fourteen had deviated materially, because its checklist verified documents rather than intent. Conditional alignment is the governed middle ground, letting a change proceed temporarily because compensating controls, follow-on work, and review conditions are explicit and bounded.

That middle ground is where waivers live. TOGAF's own term for the instrument is a dispensation, and a healthy one has six elements, a deviation description, the enterprise consequence, a business justification, compensating controls, an expiry condition, and governance approval, with the expiry condition the element most commonly missing. The Architecture Contract frames the whole exchange. C220 defines it as a joint agreement between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. It is established at the start of Phase G, reused by Phase H to judge later change, and adds most value at cross-team handoffs, with external delivery partners, and at regulated milestones.

G198, the Architecture Skills Framework, organises what an architecture function can do into seven competency categories, generic skills, business skills and methods, enterprise architecture skills, programme or project management skills, IT general knowledge, technical IT skills, and the legal environment, each assessed across four proficiency levels, background, awareness, knowledge, and expert. The Open Group superseded G198 in 2024 with G249, Architecture Roles and Skills, but the seven-category, four-level structure taught here comes from G198. The point is fit, not maximum scores. A chief architect needs depth in EA, business, and generic skills, while a domain architect needs depth in their domain, so the framework maps the gap between the skills the team has and the skills the enterprise needs.

G203, Architecture Maturity Models, assesses the function as a system, building on the Architecture Capability Maturity Model with levels running from Level 0, None, to Level 5, Measured, scored per dimension rather than as one blended number. A score only becomes useful when it survives three questions. What specific behaviour is weak, what consequence does that create, and what is the smallest intervention that would visibly improve it. The insurer in the opening story paid four months of fees for a Level 2 label that could not answer the CTO's test, what would we do differently tomorrow, which is the difference between diagnosis and decoration.

One risk stays invisible to every maturity score, concentration. A function can score Level 3 across the board and still be one resignation away from losing its repository knowledge, board facilitation, or sole delivery interface. Mapping G198 proficiency across the team exposes any category held at depth by a single person. For London the critical needs are OT/IT boundary expertise across SCADA and network automation, regulatory fluency in Ofgem obligations, stakeholder facilitation, and repository stewardship, each carrying a concentration risk if held in one head.

TOGAF is often blamed for bureaucracy the standard never asked for. Five implementation choices account for most of it, unclear decision rights, over-centralised review, artefact production without a decision purpose, fear-driven governance, and no tailoring discipline. The technology company in the opening story built 47 mandatory templates and taught its delivery teams to relabel projects as operational improvements to escape the process. None of that is the method. C220 Part 3 states that the ADM is intended to be used flexibly and tailored, so a rigid, heavyweight implementation is a local choice.

Deliberate tailoring uses four patterns drawn from C220 Part 3 and G20F, Enabling Enterprise Agility. Iteration and levels adjust the depth of an ADM pass, phase selection enters the method at the phase that matches the problem, artefact selection treats the content framework as a menu rather than a checklist, and governance scaling matches governance weight to decision consequence. The floor beneath all of it is five minimum viable controls that survive even the lightest implementation, a scope statement, active principles, a decision log, an exception register, and a lightweight review path. The four-question proportionality test checks the result, can the enterprise explain its decisions to a sceptical stakeholder, control material exceptions, hold a cross-domain picture delivery teams find useful, and answer a real question from the repository faster than asking a senior architect from memory.

G210, Applying the TOGAF ADM using Agile Sprints, shows the method running at delivery speed without dilution. An architecture runway keeps just-enough decisions ahead of the sprints, reviews align with sprint boundaries instead of a parallel calendar, and governance attaches to decision points rather than to every sprint output. London applies the same proportionality as three governance tiers, full weight for cross-domain, target-state, and regulatory decisions, lighter review for domain choices inside the approved target, and minimal governance for bounded operational change, so the right governance cost lands on the right decision.

The London governance repository organises the stage's machinery into seven sections, each answering a different governance question. Architecture principles hold the active set of 12 with rationale and implications. Target-state definitions hold the versioned target for each domain. The decision log records every significant decision with its rationale within 24 hours of each board meeting. The exception register holds active waivers with all six elements. Compliance records capture each milestone assessment and its conformance category. Architecture contracts hold the live agreements with delivery programmes. The board charter publishes composition, decision rights, and cadence. The operational test is the one from the tailoring module, a repository earns its name when it answers a real question faster than asking a senior architect from memory.

The synthesis module walks one decision end to end to prove the parts act as one system. A request to replace the connection-offer calculation engine is triaged against the decision rights matrix, reaches the board with a decision paper referencing principles by name, is conditionally approved subject to an architecture contract and a first-milestone compliance review, and the review's single non-conformance becomes a waiver with compensating controls and an expiry date. When internal audit later picked that decision at random, the decision log produced the board's rationale in four minutes and every other answer came from a different repository section, which is what an operating model looks like when it is real.

Two further disciplines complete the model. Release decisions in a regulated utility draw on three assurance streams, architecture, cyber, and operational, because each catches risks the others miss, and the board can attach conditions, delay, or escalate on any of them. And five behavioural tests distinguish real governance from decoration, the right forum decides the right question, repository artefacts feed board decisions, exceptions stay visible and time-bounded, release conditions reflect combined assurance, and delivery teams can describe their governance engagement without saying they avoid it.

Phase G, Implementation Governance, is where intent is defended while other people do the work. Its objective is to ensure implementation projects conform to the target architecture and to govern the Architecture Contract that covers implementation and deployment. It consumes three inputs as a working baseline. The Architecture Contract sets the standard, the Implementation and Migration Plan sets the sequence, and the Architecture Definition Document sets the target. Governance then runs continuously through the build, confirming scope with development, checking conformance, routing genuine deviations through the contract's waiver mechanism rather than around it, and recording every decision so it can be traced later.

Phase G's output is the Compliance Assessment, a recorded judgement of where a delivered solution conforms and where it deviates. The deployed-solution sign-off loop turns that judgement into a gate. A step deploys only when it conforms or its deviation has been formally accepted, otherwise it is sent back, corrected, and reassessed. The utility in the opening story had a board, a contract, and a plan, and still watched its build quietly become something else over eleven months, because nobody was consuming those documents during delivery. When a step is signed off, its Compliance Assessment passes to Phase H as the baseline for managing the live system.

Phase H, Architecture Change Management, is the eighth and final ADM phase and the feedback loop that keeps the target honest. Every change request is triaged into one of three categories that decide its ADM re-entry. A simplification change reduces cost or complexity and is handled through routine change governance. An incremental change adds value inside the current target and re-enters at a later phase such as migration planning. A re-architecting change moves what the enterprise is for and restarts the ADM from the Architecture Vision. The classification must be explicit and recorded, because eleven small changes can quietly amount to a re-architecting decision nobody named. Phase H also monitors value realisation, comparing the benefits the business case promised with the benefits delivered, and treats any shortfall as a fresh change signal.

An architecture function that cannot show its value in terms a board recognises will eventually be asked why it exists. The measurement discipline starts by separating activity from value. We reviewed forty designs is activity. Designs now reach release five weeks faster because teams reuse agreed patterns is value. The second distinction is between leading measures, which move early and predict an outcome, and lagging measures, which confirm it after the fact. A scorecard built only from lagging measures tells the board the truth too late to act on, and one built only from leading measures predicts value it can never confirm.

The working scorecard is small, four measures covering flow, coherence, resilience, and money. Change lead time and pattern reuse lead, risk reduction and cost avoidance lag. Each measure carries a plain definition, a baseline, a source, and a link to the investment case, and that last link is what turns a statistic into evidence, because every number on the page settles a promise the enterprise was funded against. A measure with no home in the investment case should be dropped, and a promise with no measure is not being kept visibly.

London's architecture function reports on a single page each board cycle. Design-to-release fell from 18 weeks to 7, pattern reuse rose from one in five new builds to three in five, open resilience gaps fell from nine to two, and three overlapping platforms became one retired platform. The narrative that carries the scorecard leads with the outcome, shows each movement from its baseline, anchors it to the committed money, and ends with a clear ask. Activity belongs at the back, if anywhere, because a board reads outcome, cost, and decision.

The classic model from earlier in the stage has a structural weakness. When delivery is organised as temporary projects, no team owns a system for its whole life, so the central architecture function becomes the memory of record and the review queue every change waits in. London's connections systems lived that story, a minor form update queuing in the same lane as a network-critical data change. A product operating model changes the unit of ownership. A long-lived team owns a product for as long as it has users and keeps improving it, so knowledge and most decisions stay with a standing team instead of a temporary one.

Product teams raise a second question, whether every team must build its own identity, data access, deployment, and monitoring. A platform team exists to prevent that. It runs an internal platform, a curated set of shared capabilities offered as a self-service product whose users are the other teams. Self-service is the test that separates a real platform from a rebranded gatekeeper. If product teams must raise a ticket and wait, the platform has recreated the central bottleneck under a different name. In a regulated context the platform is also the safety mechanism, because teams inherit the enterprise's security and resilience posture by default.

Architecture changes shape inside this model. It becomes an enabling function, a small central team that publishes the guardrails, principles, standards, patterns, and the target architecture, and places architects inside product and platform teams rather than reviewing from a distance. Governance federates. The centre keeps the enterprise-level decisions that cannot be delegated, principles, standards, cross-team contracts, and anything with regulatory exposure, while product and platform teams decide locally inside the guardrails. London's connections product team now builds on the internal platform, and the centre keeps the data contract with the network model, so the queue shrank while the network stayed protected.

Architecture only changes an enterprise when a board backs it, so communicating upward is part of the job, not a soft extra. The TOGAF ADM treats it that way, producing a Communications Plan early and naming stakeholder management among the most important activities in a successful architecture effort. The stage's cautionary tale is London's own first attempt, a 40-slide roadmap that reached the funding ask on slide 37 and was deferred, not because the architecture was wrong but because the board never reached a point where it could say yes or no.

The fix is an ordering change. Architecture work is produced bottom-up, baselines, gaps, targets, transitions, and must be told top-down, the structure Barbara Minto set out in the Pyramid Principle. The one-slide architecture story carries the whole recommendation in four parts a board can take in at a glance. The situation states the fact that forces a decision now, the options name the genuine alternatives with honest trade-offs, the recommendation states the single option and the one reason it wins, and the risk names the residual exposure the board is accepting and who owns it. A case with no rejected options reads as a decision already made, and a case with no owned risk reads as a risk being hidden.

The rest of the skill is played before the room. Map each executive by power and interest, win the high-power, high-interest people individually before the meeting, and meet each concern on its own terms rather than overriding it, the finance director resisting a rebuild is protecting a budget line, so show the option costed inside the allowance. Told that way, London's phased three-year rebuild of the 11 kV control estate, framed against the RIIO-ED2 allowance from the first line, was approved in twenty minutes. The 40 slides survived unchanged as the appendix behind the one slide.

The stage's proof runs through London Grid Distribution's governance repository. Internal audit picked one board decision at random, the conditional approval of the new connection-offer calculation engine, and traced it end to end. The decision log produced the board's rationale in four minutes, the architecture contract showed the agreed conformance criteria, the compliance record showed the first-milestone review and its single non-conformance, and the exception register showed the resulting waiver with its compensating controls and an expiry date eleven weeks away. Every answer came from a different part of the operating model, board behaviour, compliance handling, repository stewardship, and assurance logic, and the walkthrough held because the parts acted as one system.

The regulated context sharpens every idea in the stage. The 8-member board's decision log feeds regulatory submissions, three governance tiers put the right governance cost on the right decision, Phase G Compliance Assessments double as evidence that delivery met commitments, the value scorecard settles promises in the business plan the function was funded against, the connections product team builds on an internal platform that carries the regulated guardrails by default, and the 11 kV recommendation passed once it was framed against the RIIO-ED2 allowance from the first line. Hold that thread. The scenario practice keeps returning to it, one decision at a time.