Decision Architecture: a simple way to turn models into real decisions

Deepak Mohan

03 Nov 2025 — 3 min read

Thanks a lot for the great response on my previous article on Rebooting Business Architecture. In this article, I had suggested that for business architecture to succeed it must prove value fast - by helping leaders make better decisions, faster. Continuing on the same theme, in this article, I am suggesting the inclusion of Decision as a core component of business architecture. I am calling it Decision Architecture.

What is Decision Architecture?

It’s a short, living list of the important decisions your company makes again and again—who owns them, when they happen, what information is needed, what options to choose from, and how you’ll measure if the choice worked. Think of it as a clear route from strategy → decisions → delivery. It contains just five things:

Decision Inventory: a list of the top 30-50 recurring decisions.
Decision Canvas: a 1-page template to prepare each decision.
Decision Log: a simple list of what has been decided and why.
Decision Cadence: the calendar/meetings where decisions get made.
Decision Metrics: a few numbers that show the decisions helped.

Why it matters?

Faster decisions. Less waiting, fewer “let’s take this offline” moments.
Better choices. You always compare 2–3 real options with numbers.
Clear ownership. One named owner. Everyone knows the goal and the trade-offs.
Less rework. Past decisions become patterns you can reuse.

The Decision Canvas (copy this)

Goal (90 days): What must improve? (e.g., “Cut onboarding time by 20%.”)
Owner: One person accountable.
When: One-off / weekly / monthly / per release.
Inputs: Exact reports/data needed (and who provides them).
Options: 2–3 real choices with numbers for cost, time, risk, benefit.
Controls/Compliance: What changes and how we’ll show evidence.
Choice & Anti-goals: What we picked—and what we won’t do.
Metrics: The targets you’ll track for 30/90/180 days.

Below is what it looks:

Where to start? And How?

Rapid Inventory (interviews + artifacts)

Ask leaders and product teams: "Which decisions stall or gets reopened?
Harvest the last 5 months of meeting notes, approvals and exceptions.
Keep the top 30 by impact (money, risk, customer).

Create canvases for the top 10

Sit with each owner and fill the canvas.
Force real options and real numbers.
Name the data products needed for inputs and who guarantees freshness.

Wire the cadence

Place each decision on an existing forum (QBR, investment board, risk committee) or create a 30-minute slot in the product cadence.
Set a simple service level: "Architecture support in ≤ 5 working days.”

Embed & log

Make the first three decisions.
Publish the Decision Log: date, choice, rejected options, rationale, metrics.

What to include (and exclude) in your decision views

Include

One page per decision
2-3 options with cost/time/risk/benefit numbers
Only the slide of capability, value-stream and business information required to choose.

Exclude

"Complete' Enterprise maps
Open-ended "future state" stories
Single-option proposals.

What good looks like (some examples)

Reduce KYC Periodic Refresh Backlog

Owner: Head of Financial Crime Ops
Options: A) Hire 30 FTE (fast burn, low tech risk) B) Risk-tiering + data pre-fill + 3rd-party data (medium burn, higher permanence) C) Defer long-tail (waivers) + targeted automation (lowest cost, some risk)
Trade-offs: Cost, lead time, false-positive rate, audit findings
Choice: B
90-day Metrics: -40% backlog, ≤ 2% QA fails, +25 pts control coverage, £1.2m run-rate saved
Controls: KYC evidence stored with lineage; exception handling logged to case mgmt.

Claims FNOL Experience

Owner: Claims Director
Options: A) Portal refresh only B) Capability upgrade: intake, triage, rules, straight-through for simple claims C) Outsource intake to TPAs
Choice: B
90-day Metrics: +15 pts CSAT, -20% cycle time, -10% leakage, 70% STP for simple claims
Controls: Fraud checks preventive; audit trail embedded in workflow.

Core Platform Modernisation Path

Owner: CIO Platforms
Options: Re-platform, SaaS migrate, Strangler modernization
Decision metric: Duplicate spend avoided, release lead time, resilience SLOs, regulatory constraints
Outcome: Strangler pattern on top 6 capabilities first; prove with lead-time and resiliency deltas in 2 quarters.

How Decision Architecture impacts classic business architecture tools?

Capabilities → Capability SLOs (speed, quality, cost, risk targets with an owner)
Value streams → Decision points (where choices actually happen)
Business information → Data products (with a named owner and freshness SLA)
Roadmaps → Decision calendar (visible dates where choices are made)

Measuring success

Report monthly, publish at 30/90/180 days:

Decision lead time (median days)
Spend avoided / waste removed (£/$ and systems/processes retired)
Control coverage uplift (points)
Adoption (% squads/tribes using decision views)
Investment clarity (% initiatives with optioned business cases)

Starter pack: First typical decisions to map

Build/Buy/Partner for capability X
Decommission Y (system/process)
Platform onboarding standards
Data product ownership & SLA
Control design for regulatory change
Customer onboarding path by segment
Pricing change approval
Fraud/KYC rule changes
Cloud pattern selection
Self-service vs. assisted servicing scope
Outsource/automate/right-shore
Release cadence & change window exceptions
API productisation priority
Vendor rationalization per domain
Migration wave cut criteria
Remediation prioritization (risk-based)
KPI/KCI definition for new journeys
Feature toggle & A/B test gating
Data retention & privacy choices
Incident “fix forward vs. roll back”

Still not sure?

Pick one painful decision first. Build the canvas. Offer three options with numbers. Book the forum. Decide in 7 days. Publish the log. Share the results.

Decision architecture is small, fast, and public. It turns architecture from drawings into decisions.

If you have used this and has worked, please share your experience.