Architecture Capability Framework: Scoring Your Own Practice

The architecture capability framework I worked with at a telco was not something I built. I inherited it, and it arrived as a TOGAF template: a tidy, generic scaffold of the things an architecture practice is supposed to be able to do. Develop architecture. Govern it. Manage stakeholders. All perfectly correct, and all pitched at a level of abstraction where nobody in the building could tell whether we were good at it or not.

The template only became usable once we layered TM Forum's Frameworx and eTOM catalog on top of it. That gave us capability names with actual telco meaning behind them, the kind that network operations, sales, and billing could each recognise as describing work they knew existed. The generic TOGAF scaffold told us what shape of thing to list. The industry catalog told us what to call the things. A capability model nobody argues about is a capability model nobody is using.

That distinction, between the scaffold and the content, is what this article is about. Not the Business Capability Model, which maps what the business does. This is the other one: the Architecture Capability Framework from TOGAF Part VII, which is the architecture practice's own operating model. What your function needs to be able to do, how mature each of those things is, and who staffs them.

The Hospital Ward

A hospital ward does not open by hiring good people and hoping. It opens with a roster of required specialties: surgery, radiology, pharmacy, ICU. Each one gets audited on whether it can actually operate, meaning the consultants are hired, the machines are on the floor, the protocols are written, and the patient records flow. Those audits are what a department head takes to the hospital board when asking for another nurse or another scanner, because "we feel stretched" moves nobody and "we cover three of four required rotas" moves budget.

Sitting above all of it are the hospital's credentialing and operating rules, which govern how any department is permitted to run at all. That layer is about what qualifies anyone to practise here.

Your capability model is the roster of specialties. Your maturity assessment is the departmental audit. TOGAF Part VII is the credentialing rulebook that says how any of it is allowed to operate.

What Goes In the Capability Model

TOGAF Part VII does not hand you one flat list. It hands you the same four architecture domains you use on client engagements, turned back on the practice itself:

Most capability models stop at the first box. Governance gets a line item, and the practice's own data, tooling, and hosting never get scored, which is how you end up with excellent decision records nobody can search and a wiki nobody trusts. TOGAF's 2025 Business Architecture update reframes the scoring dimensions as "people, processes, information, resources," which matters here: resources means budget and hosting, the Technology domain most models never reach. Kotusev's 2023 study in Information Systems Management found capability models are among the few EA artifacts broadly adopted in practice. Most of what the frameworks specify gets produced once and abandoned. These survive, a decent argument for reaching for one across all four domains, not just the one everyone remembers.

Where the maturity scores come from

Score each capability, from whichever domain it comes from, across people, process, technology, and data, the scheme Gartner published in October 2025 as the basis for evidence-based investment decisions. Gartner's own EA maturity model runs five levels, nonexistent through reactive, functioning, integrated, and ubiquitous, across eight practice dimensions including stakeholder support, team resources, governance, and metrics.

Five levels is one more than most people can score consistently. Use them anyway, but write the level descriptors down before anyone scores anything, because otherwise "functioning" means whatever the person holding the spreadsheet wants it to mean this quarter.

The Failure Mode Nobody Warns You About

Here is the part the framework documentation leaves out. I ran a maturity assessment expecting it to become an instrument that triggered investment. It did not. What it became was an exercise mainly useful for stakeholder buy-in, and for scoping the next steps as a target-capability list plus a gap analysis. Useful, genuinely. Just not the thing it was sold as.

I also tried the obvious follow-on, taking maturity scores to a CIO to negotiate headcount and budget. That was mostly theater. It stalled, and no decision was ever made off the back of it in either direction, which is the outcome nobody models for.

So scope the assessment for what it reliably delivers, alignment and a defensible target list, rather than for what the deck promises. An artifact that reliably does one thing well is worth more than an artifact that occasionally does three.

Building the Thing You Can Actually Defend

Most capability assessments that actually get used are built in a spreadsheet, one row per capability, one column per dimension, a heat map colouring the scores. That is not a shortcut version of the "real" method: TOGAF's own Business Capability Planning guidance names heat mapping as the technique. The dedicated EA platforms, LeanIX, Ardoq, BiZZdesign, render the same heat map over a capability hierarchy, just with a sales cycle and a login in front of it. A spreadsheet gets you the identical artifact in minutes, on a machine that already has one, Excel more often than not, since it is the one most architects have open already.

What follows builds that workbook in Excel, step by step. If you would rather start from the finished thing, the worked example is a downloadable template, the same four rows, formulas, and conditional formatting built below, plus a Level Descriptors sheet and a Read Me.

Step 1: Lay out one capability per domain

Open a blank spreadsheet, row 1 as headers, one row per capability below it. Pull at least one capability from each of the four domains, not four flavours of governance, so the sheet actually reflects the framework rather than the one domain everyone remembers. Keep names in your organisation's own vocabulary, sourced from an industry catalog where one exists, as TM Forum's Frameworx and eTOM do for telco, rather than inventing generic ones.

Capability (A)	Domain (B)	Target (C)	People (D)	Process (E)	Technology (F)	Data (G)
Architecture Governance	Business	3	2	2	1	1
Architecture Repository	Data	3	2	1	2	1
Decision Record Tooling	Application	2	1	1	1	0
Repository Hosting	Technology	2	1	0	1	0

Leave columns H and I for Current and Gap, filled by formula in Step 3. Levels run 0 to 4 on every dimension, matching the nonexistent-through-ubiquitous scale a maturity model like Gartner's uses. Enter names, domains, and targets first; scores come after the descriptors exist in Step 2.

Governance is the board and its decision log. Repository is where decisions and reference models are structured, TOGAF's Enterprise Continuum. Decision Record Tooling is whatever a reader actually opens to read or write one, a wiki, a docs-as-code repo, a dedicated ADR tool. Hosting is where that tool lives and who pays for it. Four owners, and a model that only ever scores the first row is measuring the board, not the practice.

Step 2: Write the level descriptors before scoring anything

This is the step people skip, and skipping it is why the numbers get argued about instead of acted on. Add a second sheet, one row per level, one column per capability, all four domains included, not just the governance one everyone writes descriptors for by habit.

Level  Architecture Governance         Repository Hosting
0      No forum reviews designs;       No documented owner; running on
       decisions made in delivery      someone's personal account.
       teams only.
1      Reviews happen when someone     Owned by a team, but access and
       escalates; no standing agenda.  renewal are undocumented.
2      A board meets on a schedule     Access, backup, and renewal are
       with a published decision log.  documented and owned.
3      Board decisions are referenced  Provisioned through the same
       in delivery gates and funding.  process as any other team's infra.
4      Teams self-assess against       Monitored and budgeted like any
       published standards.            production service.

Fill in one column per capability. It is dull, and it is the difference between a score and an opinion: whoever scores next quarter reads the sentence, not a number they have to remember the meaning of.

Step 3: Compute the current score and the gap with formulas

Back on the model sheet, column H averages the four dimensions, column I is the gap against target (column C). In H2:

=AVERAGE(D2:G2)

In I2:

=C2-H2

Fill both down the column. Add conditional formatting on D2:G2, a three-colour scale, red at 0 and green at 4: colour shows where you stand at a glance, the gap column shows how far to target, and neither needs a sentence of explanation to defend in a meeting.

Step 4: Sort worst-first and name the weakest dimension

Select the data range and sort descending by column I. The capabilities furthest from target rise to the top; on a first honest pass, Application and Technology rows often surface above Governance, because nobody scored them before. Add column J to flag the weakest dimension per row, all of them, not just the first one Excel happens to find:

=TEXTJOIN(", ", TRUE, IF(D2:G2=MIN(D2:G2), D$1:G$1, ""))

Enter it as an array formula (Ctrl+Shift+Enter on older Excel; current Excel spills automatically). A plain INDEX(MATCH(MIN(...))) returns only the first dimension tied for lowest, which understates the problem exactly when it matters most: a capability failing on two dimensions at once reads as a one-dimension fix if the formula only ever names one. Run it over the four rows above and three of them tie: Repository Hosting comes back "Process, Data," not process alone, it has no documented owner and nobody knows where the access records live. A single tidy answer would have sent you to fix half the actual problem.

Step 5: Scope brutally on the first pass

If you are standing a practice up from zero, do not build the enterprise version across all four domains at once. I have scoped a minimal one for a first-time setup: governance, plus one or two core capabilities, everything else deliberately deferred until the practice grew enough to need it. A new hospital opens with the departments it can staff, then adds specialties. Business Architecture usually goes first, since it's the domain stakeholders already recognise; Data, Application, and Technology follow once the practice's own tooling stops being informal.

Hide the rest rather than deleting them. A "Deferred" status column, set on every capability outside this year's scope, records that the gap is a choice, not an oversight. An aspiration scored at 0 with no deferred flag reads as a failing practice; the same 0 marked deferred reads as a decision.

Step 6: Version it and plug it into governance that already exists

Export the sheet to CSV after every assessment and commit it to a Git repository, even a personal one. A single assessment is a snapshot with no argument in it; two assessments six months apart, diffed, are a trend, the only thing that has ever persuaded a finance committee of anything.

The spreadsheet has no teeth of its own. It needs the Architecture Review Board to own it, put the reassessment on a standing agenda, and treat target levels as decisions rather than ambitions. Without that, you have a well-formatted file.

Two Capability Models, Two Jobs

	Business Capability Model	Architecture Capability Framework
Describes	What the business does	What the architecture practice can do
Owner	Business architecture	Head of architecture
TOGAF home	Business Architecture, Phase B	Part VII
Typical use	Investment and portfolio decisions	Staffing, governance design, maturity
Audience	Executives and product	The practice itself, and whoever funds it
Failure mode	Mapped once, never referenced	Assessed once, becomes shelfware

Both fail the same way, and the fix is the same too: give it an owner and a review cadence, or do not build it.

The Roster Is the Argument

The value of this artifact is in the conversation the scoring forces, where a room full of people who each assumed the practice did roughly the same set of things discovers, on the record, that it does not.

• Inherit the scaffold, source the content. TOGAF Part VII tells you the shape; an industry catalog gives you names your colleagues recognise.
• Score all four domains, not just Business Architecture. Data, Application, and Technology are capabilities too, and they're the ones nobody scores by habit.
• Write the descriptors before the scores. Otherwise you are averaging opinions with a straight face.
• Expect buy-in and a target list, not a budget decision.
• Defer capabilities out loud. Two you run beat eight you have listed.
• Version it, or it is a slide.

The hospital analogy runs out exactly where your judgement starts. No regulator is going to tell you which architecture capabilities you must staff, which means the list is yours to defend, and an undefended list is just a longer way of saying you would like more people.

So which capabilities does your practice claim on paper that nobody has actually run this year? And if your CIO asked tomorrow what a second architect would buy, could you point at a file, or would you be building the argument from scratch?