Rebooting Capability Modelling: From Pretty Maps to Performance

Deepak Mohan

06 Nov 2025 — 4 min read

In Parts 1–2, we made a simple promise: architecture earns trust when it changes decisions this quarter. Business capabilities are the most widely misunderstood concepts within the business. And we business architects spend an inordinate amount of time generating the perfect business capability model for an organisation.

Here's my experience:

Capability models can help—but only when they're built for performance, ownership, and spend transparency, not for wall art.

In this article, I have shared my experience with capability maps. Specifically, when to model, how to make capabilities measurable, and how to use them to reduce duplicate spend—while dodging the "artificial consistency" trap.

When (and when not) to model capabilities

Model only when the model will drive a decision in ≤ 2 sprints.

If you can't name the decision, the owner, and the date, don't draw it yet.

Good reasons to model (do it):

Investment choices: build/buy/partner, platform vs. point solution.
Ownership clarity: who is accountable for performance & spend.
Risk & control design: where preventive/detective controls must live.
Rationalisation: decommission, consolidate, or reuse.
M&A or operating model change: What to integrate vs. federate.

Bad reasons to model (skip or defer):

"We've never had a complete map."
"A maturity assessment demands a big taxonomy."
"An auditor might ask someday."
"The tool needs it."

Rule of thumb: Start with the 2–3 capabilities your current initiative depends on. Model just deep enough to decide.

Making capabilities measurable (SLOs + cost/risk baselines)

A capability is functional only if it has targets and trade-offs. Give each priority capability a small "SLO card" you can review monthly.

Capability SLO Card

Capability: e.g., Customer Onboarding

Owner (single name): …

Customers/Segments: …

SLOs (targets):

Speed: Median time from application → active = ≤ 2 days
Quality: First-time-right rate ≥ 95%
Cost: OpEx per new customer ≤ £X
Risk & Controls: KYC coverage = 100%, QA fail ≤ 2%
Experience: CSAT ≥ 80 (simple cases)

Guardrails (anti-goals): Don't exceed abandonment > 5%; no manual workarounds for simple journeys.

Data Products feeding SLOs: Application feed (daily), KYC results (hourly), QA sample (weekly), CSAT (per release)

Review cadence: Monthly in Ops/Tech forum, quarterly with CFO/COO.

Cost & risk baselines (keep it simple)

Unit cost = total run cost / volume (last quarter).
Risk baseline = top 3 control objectives + current coverage % + incident count.
Resilience baseline = SLOs for availability, recovery (if the capability relies on platforms).

Make the SLO card the front page of the capability. All other details are behind it.

Use capabilities to cut duplicate spend and clarify ownership

Capabilities are the currency of ownership. Every priority capability should answer three questions:

Who owns the SLOs and the budget? (A single name. Not a committee.)
What are the supporting products/systems? (Map only those in the scope.)
Where is money duplicated? (Same outcome, multiple tech/processes/teams.)

Ownership Charter (one page)

Capability: Payments Execution
Business Owner: Head of Payments (accountable)
Tech Owner: Director, Payments Platforms (responsible)
SLOs: speed, cost, risk/resilience targets (from SLO card)
Decision Rights: build/buy/partner; onboarding standards; decommission gates
Shared Services Used: KYC, Fraud, Ledger
Funding Model: product chargeback; transparency of unit cost
Review: monthly performance; quarterly decommission plan progress

Publish these charters. Funding follows clarity.

Find duplicate spend (a fast method)

Create a Duplicate Spend Heatmap for one domain (e.g., onboarding, payments, claims):

Rows: priority capabilities

Columns: systems/apps / vendors / teams / locations

Cells: mark "X" where a cell contributes to the capability; add unit cost & volume where known.

Sort by capabilities with >1 system/team doing the same step. These are your quick wins:

Consolidate to the cheapest / most reliable path.
Productise shared services (e.g., IDV, address validation, notifications).
Set intake standards: anything new must consume the shared capability unless an exception is approved.

Decision pattern to use: Decommission/Consolidate

Decision owner, affected capabilities, option A/B/C (keep, consolidate, retire), 12-month savings, risk impact, migration cost, date to decide.

Avoiding "artificial consistency" traps

The trap: enforcing a beautiful, uniform taxonomy that ignores context—and ends up unused.

Anti-trap principles

Language of the business. Use the words teams use; capture synonyms if needed.
Scale depth to decision. Only decompose where a decision needs it.
Show the numbers. Every capability you draw should link to an SLO card or a £/risk number.
Don't centralise everything. Some capabilities must be local (e.g., specialist underwriting). Make the rule explicit: centralise when it reduces unit cost or risk without violating speed/experience SLOs.
Time-box harmonisation. 2 weeks to align names across tribes; after that, document variances and move on.

Smell tests

If two leaders can't agree on a capability name in 30 minutes, park the name—agree the SLOs and owner first.
If a model page has no metric, owner, or date, it's a decoration.

Examples

Too much theory, let's use the above in some examples:

A. Customer Onboarding (Banking)

Decision to make: Reduce cost-to-serve while improving speed.
SLOs: ≤ 2 days median, QA fails ≤ 2%, unit cost ≤ £X, KYC 100%.
Duplicate spend found: 3 separate ID verification vendors + 2 address checks.
Decision: Standardise on one IDV + central address service; retire others.
12-month impact: £1.4m vendor spend avoided, -25% onboarding time, +20 pts control coverage.

B. Claims FNOL (Insurance)

SLOs: 70% STP for simple claims; cycle time -20%; CSAT +15.
Duplicate spend: Two intake tools + manual emails.
Decision: Consolidate onto FNOL platform; make rules a shared service.
Impact: 3 systems retired; leakage -10%; Ops FTE redeployed.

C. Pricing & Offers (Retail/FS)

SLOs: Time-to-change ≤ 2 days; test coverage per release ≥ 80%; margin guardrails.
Decision: Build pricing as a capability with APIs and governance; stop embedding logic in channels.
Impact: One rules engine replaces six channel-specific copies, cutting change lead time from weeks to days.

Minimal artifacts that actually help

A. Capability SLO Card (front page, 1 per priority capability)

B. Ownership Charter (who decides, who pays, who runs)

C. Duplicate Spend Heatmap (1-page grid)

D. Decision Pack (2–3 options with numbers; date to decide)

Everything else is optional.

A Plan to reboot your capabilities

Phase 1:Focus:

Pick one domain (e.g., onboarding, payments, claims).
Create SLO cards for the top 3 capabilities.
Publish Ownership Charters.
Build the first Duplicate Spend Heatmap.
Take one Decommission/Consolidate decision to governance.
Suggested time for this phase: 30 days

Phase 2: Prove:

Track SLOs weekly; publish a "before/after" postcard.
Embed capability SLOs into product backlogs and OKRs.
Negotiate vendor consolidation and establish intake standards for reuse.
Suggested time for this phase: 30 days

Phase 3: Scale:

Extend to 3–5 more capabilities in the domain.
Template the artefacts; coach other teams to self-serve.
Add capability cost & risk baselines to portfolio reviews.
Suggested time: 30 days

So what next?

Pick one high-spend domain. Write three Capability SLO Cards and three Ownership Charters. Build a Duplicate Spend Heatmap. Bring a consolidation decision with numbers to governance in the next two weeks. Publish the before/after.

Capability modelling isn't about catalogues—it's about performance, ownership, and spend.

When you model with those three in mind, the maps stop being art and start paying for themselves.