Running architecture as a capability means deciding how it operates, who owns what, and which decisions get governed, so it strengthens delivery instead of slowing it.
TOGAF 10 Phases G and H, the architecture capability
The architecture capability is the way an enterprise organises, sustains, and governs its architecture work so that it actually shapes change rather than simply describing it. It is the operating side of the discipline: who does the work, what they own, which decisions are governed, and how all of that connects to strategy and delivery.
Why it matters is straightforward. Good models and roadmaps achieve nothing if no one decides between them, no one tracks whether delivery follows them, and no one can grant a sensible exception. A capability turns architecture from a set of documents into a function that the rest of the enterprise relies on and respects.
Governance also has a forward-facing job. Once an architecture is live, Phase H, Architecture Change Management, watches it for business and technology change, triages each request, and decides whether the change needs only simplification, a contained incremental update, or a full return to the architecture method. That decision is the feedback loop that keeps the target architecture honest, so governance is not only about approving today's work but about knowing when yesterday's architecture has to change.
The stage builds in order. It opens with the capability as an operating model, then narrows to the board and its decision rights, then to compliance, contracts, and waivers, then to the skills and maturity that sustain it, and finally to tailoring the method so the whole thing stays useful under real delivery pressure.
The stage builds up in this order. Read it straight through on the first pass, or jump to any concept.
Picture a retailer that announces an architecture team, gives it a manager and a few desks, and then waits for value to appear. An architecture capability is not that. It is an operating choice: a set of responsibilities, defined touchpoints with strategy and delivery, clear ownership of the repository, named review forums, and a deliberate decision about how much central coordination the enterprise actually wants. The capability is the machine, not the box on the chart.
The frequent error is to assume that standing up a team is the same as having a capability, so attention goes to headcount and reporting lines while the real questions stay unanswered. A more durable approach defines the capability by its interfaces, its owned outputs, and its measures of usefulness rather than by where it sits in the hierarchy. Ask what it hands off, to whom, and how anyone would know it was working; if those answers are vague, a team has been named but no capability has been built.
When a streaming firm asks its architecture board to sign off every screen design, the board becomes a queue, decisions slow to a crawl, and delivery teams quietly learn to route around it. An effective Architecture Board holds a narrow but meaningful remit instead: a short set of decision rights, a way to handle exceptions, a few genuinely important review points, and explicit criteria for when something must be escalated to it. Its authority comes from being selective and willing to decide, not from inspecting everything.
The tempting belief is that a board adds value by reviewing every design so that nothing slips through, but a board that reviews everything usually decides very little and teaches teams to avoid it. It is better to give the board a short list of decisions that are truly cross-enterprise, such as data authority or a major roadmap change, and delegate the rest to architects and teams under named escalation thresholds. The clearest sign of the wrong scope is a board pulled into routine local choices while the cross-enterprise questions stay unresolved.
At a bank with no disciplined route for deviation, teams swing between two bad habits: they ignore architecture guidance, or they treat any departure from it as a political crisis. Compliance assessment, architecture contracts, and waivers exist to replace both. Together they make a deviation visible, reasoned, time-bound where that helps, and traceable to the risk and the enterprise consequence it carries, so the conversation is about evidence rather than blame.
Many people equate good governance with a strict no-waiver rule, on the assumption that standards are safest when they are never broken. In practice a rigid ban pushes non-compliant decisions into the shadows, while having no compliance position at all lets the architecture drift. The managed middle path is to allow an exception through an explicit waiver that the right forum can see, with a reason stated against enterprise risk and an end date where appropriate. The aim is to be strict about visibility and reasoning, not strict for the sake of ceremony.
A compliance review is not a yes or no verdict either. The standard grades an implementation along a spectrum, from irrelevant and consistent, through compliant and conformant, to fully conformant, with non-conformant kept for a real breach. Placing a system on that scale is what makes the assessment objective rather than a matter of opinion, and it is the evidence that shows whether a waiver is genuinely needed or whether the gap can be accepted as it stands.
A hospital that declares it needs stronger architecture but never names the actual gaps has nothing to act on. Work on skills, roles, and maturity earns its place only when it reveals what the enterprise cannot yet do reliably, such as keeping the repository accurate or holding governance consistent, and ties each weakness to a concrete operating consequence. Done that way it becomes a diagnosis the organisation can use rather than a benchmarking ritual detached from how the place runs.
The trap is to treat the maturity score as the goal in itself, so reaching level three is logged as progress even though nothing has improved on the ground. A score on its own is close to useless; a gap is useful only when it points to the specific capability it limits and the risk that gap creates. Reporting each weakness with its operating consequence keeps the assessment honest and turns maturity language away from vanity and back toward something the enterprise can prioritise and fix.
A fast-growing scale-up that runs a lightweight architecture-decision-record practice keeps the method's value without the ceremony. The standard is designed to be tailored, and sensible tailoring preserves the parts that create value: a clear scope, explicit principles, traceable decisions, sensible artefacts, and controlled governance. Everything else is shaped to fit the enterprise's pace, risk, and size, so the rigour is kept while the weight is not.
The misreading is that tailoring simply means dropping steps to move faster, and that lighter is therefore always better. The word can hide two very different behaviours: smart simplification, or quiet erosion of the method. The test is whether the enterprise can still explain its architecture logic, track its key decisions, and control its exceptions with confidence. Tailor up to that line and the method stays useful; go past it and it has been over-stripped, leaving an organisation that can no longer say why it is changing or who may approve a departure.
Printable, fillable artefacts for putting this stage to work. Each cites its source, opens in the diagram workspace, and downloads as it stands.
An architecture change moves through submission, board review and decision. At each stage the green card is what carries it forward and the red card is what sends it to waiver, rework or rejection.
Phase G, Implementation Governance
A board mandate gives the architecture function its authority, and that authority flows down through the people, cadence, tooling and engagement that run it, all aimed at one maturity target each year.
ADM-wide
Five owned stages carry an LGD board decision from capture through assurance to a filed evidence pack, and each stage hands the next a specific artefact the regulator expects to see.
Phase G, Implementation Governance
Check what has landed. The practice set gives instant feedback as you go; the timed assessment mirrors a real sitting, with a pass record and a breakdown by domain.
