2 min read Business Architecture

Capability Maps don't win hearts. Decision advantage does.

Business Architecture doesn’t fail because stakeholders “don’t get capabilities.”

It fails when we try to sell the discipline, instead of landing the insight.

After 20+ years working across financial services, public sector and utilities, I’ve repeatedly seen the same adoption trap:

  • In many organisations, the word “capability” already means “people skills” (HR competency frameworks).
  • Business Architects then spend months trying to get stakeholders to unlearn that meaning.
  • Leaders, understandably, aren’t interested in terminology debates. They’re interested in decisions, outcomes, and delivery.

So we create a dilemma of our own making:

Capabilities are central to Business Architecture… but insisting on the language slows down acceptance.

Here’s the reframing that works.

Stop selling artefacts. Start selling decision advantage.

Most senior stakeholders will never ask for a “capability map”.
But they will ask for help with:

  • Which initiatives should we prioritise (and which are duplicating effort)?
  • What’s the best Target Operating Model option — and what does it change?
  • What will break if we change X (and who needs to be ready)?
  • How do we prove control, resilience, and auditability while transforming?

That’s Business Architecture. Just not marketed that way.

A practical playbook to make Business Architecture stick

1) Position Business Arch as a Decision Support Service

Define a short menu of “decisions we enable” with clear turnaround times:

  • Portfolio prioritisation & duplication elimination
  • TOM optioning with consequence scorecards
  • Change impact radars (what breaks / who’s impacted / what must change)
  • Governance inputs (accountabilities, decision rights, controls)

When BA becomes a decision accelerator, maturity follows.

2) Use stakeholder-native language, then translate internally

You don’t need to “win the word”. You need to win the outcome.

Externally, use terms leaders already trust:
 Business services. Customer journeys. Value streams. Operating model building blocks. Outcomes. Accountabilities.

Internally, maintain your discipline rigour with a translation layer.

3) Build adoption through 2–3 “signature plays”

Pick repeatable interventions that solve live, high-visibility problems:

  • Portfolio contention kill-shot
: Dependency map + “scorecard of consequences” + one recommendation
  • TOM optioning
: 2–3 options with RACI shifts, SLA impact, risk/control implications, and cost drivers
  • Change impact radar
: Services/journeys → roles → policies → data → tech → suppliers

Make these the brand of Business Arch  — not the taxonomy.

4) Embed into governance rather than asking for permission

Adoption accelerates when BA becomes part of the operating rhythm:

  • Investment forums
  • Design authorities
  • Service design boards
  • Resilience / control forums
  • Change governance

When Business Arch is “how decisions get made”, it stops being optional.

“But capabilities are central… what do we do without them?”

Here’s the truth: you can run a credible Business Arch practice without leading with capability language.

Three anchors work exceptionally well:

Option A: Build the knowledgebase around Business Services

A service catalogue is executive-friendly and measurable:

  • service owner, customers, channels
  • SLAs/KPIs, cost-to-serve drivers
  • key journeys/processes
  • key data/information
  • suppliers/partners
  • risks/controls/resilience mapping

Option B: Use Value Streams + Journeys

Perfect for transformation and benefit realisation:

  • end-to-end value delivery
  • journey variants and “moments that matter”
  • pain points + root causes
  • TOM options mapped to measurable improvements

Option C: Use Operating Model building blocks

Best for TOM, governance, and auditability:

  • outcomes & measures
  • decision rights & governance
  • accountabilities (RACI)
  • process/journey
  • data/info
  • technology
  • sourcing/locations
  • controls/resilience

Capabilities can still exist as an internal translation layer for your BA team.
But they don’t need to be the front door for stakeholder engagement.

The leadership message for a Head of Business Architecture

Stakeholders don’t need to learn Business Architecture.
They need BA to make decisions faster, more safely, and more cheaply.

So lead with:

decisions, outcomes, accountabilities, and measurable impact.

Let the discipline sit behind the scenes until the organisation asks for more.

If you’re leading a Business Architecture function, I’m curious:
 Where does your organisation get stuck — terminology, artefacts, or governance?

Share

Deepak Mohan