Business Architecture begins with a noble ambition:
Understand how the organisation works.
It then immediately draws 146 coloured boxes.
These boxes are called capabilities.
Nobody is entirely sure what some of them mean.
But they are arranged in three tasteful horizontal bands, so confidence rises.
At the top are strategic capabilities.
In the middle are core capabilities.
At the bottom are enabling capabilities, where Finance, HR and IT have been placed like plumbing.
Someone adds maturity scores.
Someone else adds heat-map colours.
A director sees a large red box marked Customer Management and asks:
“What exactly is wrong with Customer Management?”
Nobody can answer without opening another PowerPoint.
Business Architecture has begun.
1. The Capability Model Is Not the Business
This is the first and most persistent mistake.
A capability model describes what an organisation must be able to do.
That can be useful.
It is not, however, a description of how the organisation actually works.
Consider:
Customer Complaint Management
Lovely capability.
But who receives the complaint?
Who decides whether it is valid?
Which department owns compensation?
Where is the case recorded?
Which regulations apply?
What happens when Legal becomes involved?
How much does the process cost?
Which systems are used?
Where does the work queue sit?
Who can override the decision?
How long does resolution take?
Which suppliers participate?
What metric defines success?
The capability box answers none of this.
It sits there.
Blue.
Rounded corners.
Strategic.
This is not understanding.
It is taxonomy.
Taxonomy is useful.
So is a map of mammals.
But you would not use one to operate a dairy farm.
2. Capability Modelling Fails Because It Removes All the Interesting Things
The great attraction of capabilities is that they are supposed to be stable.
Organisations change.
Processes change.
Technology changes.
Org charts change.
But the fundamental capabilities remain.
Excellent.
Unfortunately, almost everything management actually wants to understand is contained in the unstable parts.
Why is this expensive?
Why are customers unhappy?
Why does this take six weeks?
Why do two departments do the same thing?
Why does nobody own this decision?
Why can we not automate it?
Why does changing one product require eleven systems?
Why does Finance reconcile the same data three times?
Why does the call centre employ 400 people?
Why do we lose customers at this point?
The answer is rarely:
“Our Level Three capability decomposition is insufficiently mature.”
The answer is usually somewhere in:
process,
organisation,
information,
systems,
decision rights,
controls,
incentives,
workload,
economics,
or historical stupidity.
Capabilities abstract these things away.
Then Business Architecture wonders why it cannot explain them.
3. Every Capability Map Eventually Looks the Same
A sufficiently generic capability model can describe almost any organisation.
Strategy Management.
Customer Management.
Product Management.
Financial Management.
People Management.
Risk Management.
Information Management.
Technology Management.
Operations Management.
Supplier Management.
Congratulations.
You have modelled:
a bank,
a university,
a pharmaceutical company,
a council,
a manufacturer,
and possibly a medium-sized criminal cartel.
The labels are correct.
They are also almost useless.
The more generic the model becomes, the more reusable it is.
The more reusable it becomes, the less it tells you about the organisation you were supposedly analysing.
This is known as architectural elegance.
4. The Argument About Nouns Begins
Business architects can spend extraordinary amounts of time debating whether something is a capability.
Is:
Campaign Management
a capability?
What about:
Marketing Campaign Management?
Or:
Market Engagement?
Perhaps:
Customer Acquisition?
Someone will announce the capability naming convention:
Verb-free.
Noun-based.
Business outcome focused.
Technology agnostic.
Someone else points out that Management appears forty-seven times.
A workshop follows.
Three senior architects spend ninety minutes discussing whether:
Workforce Planning
should be:
Workforce Management
or:
People Planning
Meanwhile the organisation cannot recruit nurses.
This is Business Architecture achieving semantic purity.
5. Then Comes the Hierarchy
Capabilities require levels.
Level 0.
Level 1.
Level 2.
Level 3.
Possibly Level 4 if the architect has recently purchased a large monitor.
At Level 1:
Manage Customers
At Level 2:
Manage Customer Relationships
At Level 3:
Manage Customer Contact
At Level 4:
Manage Customer Contact Preferences
At Level 5, someone realises they have reinvented a process model.
The rule is that capabilities describe what, not how.
Unfortunately, after enough decomposition, what develops a suspicious resemblance to how.
Nobody mentions this.
6. Maturity Heat Maps: Corporate Weather Forecasting
Once the capability model exists, somebody asks:
“Can we assess maturity?”
Of course.
Everything can be scored from one to five.
1 — Initial.
2 — Developing.
3 — Defined.
4 — Managed.
5 — Optimised.
These words have the comforting precision of astrology.
Workshops are held.
Capability owners are asked to rate themselves.
This produces fascinating results.
Departments seeking investment score themselves red.
Departments fearing intervention score themselves green.
Capabilities owned by powerful executives become strategically amber.
Capabilities nobody understands remain grey.
The final heat map appears scientific.
It has numbers.
It has colours.
It is therefore presented to the board.
The board asks:
“Why is Supplier Management a 2.7?”
Nobody knows.
But everyone agrees it should become 3.4 by 2028.
A transformation programme is born.
7. The Capability Owner Usually Owns Nothing
Business Architecture loves capability ownership.
Every capability should have an accountable owner.
Excellent principle.
Then reality arrives.
Take:
Order Fulfilment
Sales owns the customer.
Operations owns fulfilment.
Finance owns invoicing.
Supply Chain owns availability.
IT owns the systems.
Commercial owns the supplier contract.
Risk owns controls.
Nobody owns Order Fulfilment.
So somebody is nominated.
Perhaps the Operations Director.
They receive an email.
Congratulations. You are now Capability Owner for Order Fulfilment.
“What authority does that give me?”
None.
“Do I own the budget?”
No.
“The people?”
No.
“The systems?”
No.
“The process?”
Parts of it.
“Can I change anything?”
Subject to governance.
Capability ownership has been successfully established.
8. Capabilities Conceal Organisational Conflict
Organisations are political systems.
Not necessarily maliciously.
Different units have different incentives.
Sales wants revenue.
Operations wants stability.
Finance wants control.
Product wants speed.
Security wants fewer ways to be attacked.
Procurement wants contractual compliance.
Executives want all of these simultaneously by Q3.
A capability model suppresses these conflicts.
It draws:
Product Management
beside:
Sales Management
beside:
Service Delivery
as if these boxes peacefully coexist.
They do not.
They are fighting over:
priorities,
money,
people,
customers,
data,
and who gets blamed when delivery slips.
If you want to understand how a business works, model the tensions.
The boxes are not the interesting part.
The arrows between them are.
Especially the arrows nobody wants drawn.
9. Value Streams Were Supposed to Save Us
Eventually someone notices capability maps do not describe flow.
Enter:
Value Streams.
At last.
Something moves.
Customer Need → Engage → Select → Purchase → Fulfil → Support.
Beautiful.
Except the actual organisation works like this:
Customer asks salesperson.
Salesperson emails Operations.
Operations checks spreadsheet.
Spreadsheet disagrees with ERP.
ERP requires Finance approval.
Finance asks Sales for contract.
Contract is in SharePoint.
SharePoint permissions are broken.
Customer phones again.
Sales escalates.
Operations creates emergency order.
Finance rejects it because cost centre is wrong.
A manager approves an exception.
The order ships.
Nobody updates CRM.
Customer receives two invoices.
The official value stream remains:
Need → Fulfilment → Value
The customer has indeed experienced a journey.
Possibly through purgatory.
10. Processes Were Declared Too Detailed
Business Architecture often distances itself from process modelling.
“Processes are implementation detail.”
Sometimes.
But if the organisation wants to understand why work takes 42 days, process might be worth looking at.
The process people know:
where handoffs occur,
where queues form,
where decisions wait,
where exceptions multiply,
where rework happens,
and where somebody prints the electronic form before scanning it back into the system.
Business Architecture knows this sits within:
Case Management Capability
Both perspectives matter.
Only one tells you why everyone is miserable.
11. Organisation Charts Lie Differently
Surely we can understand the business through structure.
No.
The organisation chart shows reporting lines.
It does not show work.
A person may report to Finance while spending 70% of their time supporting Operations.
A central team may nominally own a service while regional offices maintain parallel shadow teams because they do not trust central delivery.
A transformation director may have 120 people on paper and no actual authority over any of them.
An executive assistant may have no formal decision rights and nevertheless control access to half the organisation.
The org chart is useful.
But it is a map of hierarchy.
Not power.
Not workflow.
Not influence.
Not dependency.
12. The Business Is Not Its Systems Either
IT departments frequently possess the most detailed maps in the company.
Applications.
Interfaces.
Databases.
Networks.
Servers.
Unfortunately, these maps describe technology rather than business behaviour.
The ERP may support:
Order Management,
Inventory,
Finance,
Procurement,
Planning,
and Reporting.
That does not mean those capabilities function well.
A single capability may span twelve applications.
A single application may support thirty capabilities.
This is why colouring capability boxes according to applications produces diagrams that resemble a quilt designed during a nervous breakdown.
13. The Real Business Lives in Work
If you want to understand an organisation, follow actual work.
Not policies.
Not strategy slides.
Not declared process.
Actual work.
Take one customer request.
Follow it.
Who receives it?
Where does it go?
Who touches it?
What information is added?
What information is missing?
Where does it wait?
Who makes decisions?
What systems are used?
What spreadsheets appear?
What approvals occur?
What happens when something goes wrong?
Who phones whom?
What does it cost?
What outcome emerges?
Do this repeatedly.
You will discover the business.
It may bear only partial resemblance to the target operating model.
This is normal.
So What Actually Works?
The answer is not to abolish capability modelling.
Capabilities are useful.
The mistake is pretending they are sufficient.
A serious understanding of an organisation requires several models connected together.
Not another gigantic framework.
A small number of views answering different questions.
14. Start With Outcomes
Before modelling capabilities, establish what the organisation exists to produce.
Revenue.
Health outcomes.
Manufactured products.
Successful claims.
Completed journeys.
Resolved cases.
Research.
Education.
Public safety.
Whatever actually matters.
Then define measurable outcomes.
Cost.
Time.
Quality.
Risk.
Customer result.
Volume.
Capacity.
Revenue.
Margin.
Error rate.
This gives architecture a reason to exist.
Without outcomes, capability modelling becomes corporate stamp collecting.
15. Model Value Creation End to End
Follow the major value streams.
Not generic ones.
Real ones.
For a manufacturer:
Customer Demand → Product Configuration → Planning → Procurement → Production → Quality → Delivery → Support.
For a council:
Citizen Need → Request → Eligibility → Assessment → Decision → Delivery → Review.
For a bank:
Customer Acquisition → Onboarding → Account Servicing → Transaction → Exception → Closure.
Do not stop at departmental boundaries.
The whole point is to cross them.
That is where most dysfunction lives.
16. Attach Capabilities to the Flow
Now capabilities become useful.
For each stage of a value stream ask:
What capabilities are required here?
This gives capabilities context.
Instead of:
Customer Management = maturity 2.6
you get:
Customer Identity Management is preventing digital onboarding because manual validation adds two days to 38% of applications.
Now you have architecture.
One is a coloured box.
The other is a problem worth solving.
17. Map the Operating Model
For each significant area, model:
People — who performs the work?
Process — how does work move?
Information — what information is created, consumed and authoritative?
Technology — what systems support it?
Decision rights — who can decide what?
Controls — what constrains the work?
Locations — where is the work performed?
Suppliers — what external parties participate?
Economics — what does it cost?
Now you can understand structure.
Not merely capability.
18. Model Decisions
This is enormously neglected.
Businesses are decision machines.
Approve loan.
Accept risk.
Set price.
Release product.
Prioritise work.
Escalate incident.
Hire employee.
Pay supplier.
Close case.
Ask:
Who makes the decision?
Using what information?
Under what authority?
Within what time?
What happens if they do not decide?
What decisions are automated?
Which require human judgement?
Which are escalated?
You will often discover that process delays are actually decision delays.
A case does not spend twelve days being processed.
It spends eleven days waiting for Susan to approve it.
This is useful information.
19. Model Information Flows
Follow information as carefully as work.
What is the authoritative source?
Where is it copied?
Who edits it?
Who reconciles it?
Where is it transformed?
Where does meaning change?
If five departments maintain five definitions of “customer,” no capability heat map will save you.
Many organisational problems that appear procedural are actually informational.
The business cannot act coherently because it does not share a coherent view of reality.
That is architecture.
20. Measure Queues and Handoffs
A business is full of queues.
Incoming cases.
Orders awaiting approval.
Projects awaiting finance.
Contracts awaiting legal review.
Incidents awaiting triage.
Data awaiting reconciliation.
Queues reveal capacity problems.
Handoffs reveal organisational friction.
Measure:
arrival rate,
processing time,
waiting time,
rework,
exceptions,
queue depth,
handoff count.
You do not need advanced mathematics to discover that a process requiring fourteen approvals will be slow.
Although advanced mathematics can make the PowerPoint more frightening.
21. Model Economics
Capability maps are strangely reluctant to discuss money.
Businesses are not.
For major flows understand:
cost per transaction,
cost per customer,
cost per product,
labour cost,
technology cost,
supplier cost,
failure cost,
rework cost,
cost of control.
Then transformation can focus on actual leverage.
A £4 million project to optimise a capability costing £300,000 annually may be architecturally elegant and economically deranged.
Business Architecture should occasionally mention this.
Finance will appreciate the novelty.
22. Model Variation
The average process rarely exists.
There is:
normal work,
priority work,
exception work,
regulatory work,
manual work,
international work,
legacy work,
VIP work,
and whatever Finance does at year end.
Architecture must understand variants.
Often 80% of cost is created by 20% of exceptional cases.
The official process describes the 80%.
The organisation spends its life dealing with the other 20%.
23. Observe Work Instead of Workshoping It
Workshops are useful.
But people describe what they believe happens.
Observation reveals what happens.
Sit with the service desk.
Sit with accounts payable.
Sit with planners.
Sit with nurses.
Sit with customer service.
Watch.
Ask:
“What are you doing now?”
“Why?”
“Where did that information come from?”
“What happens next?”
“What happens when this fails?”
“Why are you copying that into Excel?”
The spreadsheet is particularly important.
Spreadsheets are where organisations store truths their formal systems cannot accommodate.
They are the dark matter of enterprise architecture.
24. Find the Shadow Organisation
Every mature enterprise contains an unofficial organisation.
It consists of:
personal spreadsheets,
shared mailboxes,
informal phone calls,
Teams chats,
local databases,
manual reconciliations,
favours,
exceptions,
and people who know who to ask.
Do not dismiss this as poor governance.
It often exists because the formal structure does not work.
The shadow organisation is diagnostic.
It tells you where the official architecture is failing.
Study it before trying to kill it.
25. Map Causality, Not Just Structure
This is the important shift.
Traditional Business Architecture often says:
These things exist.
Better architecture asks:
What causes what?
Example:
Customer complaints are high.
Why?
Delivery dates are missed.
Why?
Production schedules change late.
Why?
Component availability is unreliable.
Why?
Supplier forecasts are poor.
Why?
Planning data is fragmented.
Why?
Three business units forecast independently.
Now you have a causal chain.
Improving Complaint Management Capability would not solve it.
Improving upstream planning might.
This is the difference between architecture and cataloguing.
26. Build a Business Knowledge Graph
If you want a genuinely useful enterprise model, stop treating architecture objects as isolated diagrams.
Represent relationships.
Capability:
supports Value Stream Stage.
Process:
realises Capability.
Organisation Unit:
performs Process.
Role:
makes Decision.
Application:
supports Process.
Data Object:
informs Decision.
Control:
constrains Process.
Supplier:
provides Service.
Metric:
measures Outcome.
Cost:
attaches to Activity.
Risk:
threatens Outcome.
Now the enterprise becomes queryable.
You can ask:
Which applications support customer onboarding?
Which processes rely on the retiring platform?
Which capabilities depend on Supplier X?
Which decisions require data from System Y?
Which value streams are affected if Site Z closes?
Which organisational units perform duplicated activities?
That is vastly more useful than staring at a Level Two capability map.
27. Keep the Capability Model Small
A useful capability model might contain:
50–150 meaningful capabilities.
Not 800.
When everything becomes a capability, nothing is a capability.
Use capability modelling to create a stable vocabulary.
Then stop decomposing.
The purpose is orientation.
Not molecular analysis.
28. Stop Scoring Everything
Do not maturity-score every capability because the spreadsheet has a column.
Assess capabilities when there is a question.
Where should we invest?
Where are risks concentrated?
What enables strategy?
Where are major cost drivers?
What constrains growth?
Use evidence.
Metrics.
Observed performance.
Technology condition.
Skills.
Process outcomes.
Do not ask managers:
“How mature do you feel your capability is from one to five?”
This is not architecture.
It is organisational astrology with Excel.
29. Model Change as Hypotheses
Transformation should say:
If we change X, we expect Y because Z.
Example:
If we automate eligibility validation, average case handling time should fall from 27 minutes to 18 minutes because staff currently spend nine minutes retrieving information from three systems.
Now measure it.
If nothing improves, the hypothesis was wrong.
Architecture learns.
This is vastly healthier than declaring:
Digital Case Management Capability uplift: Green.
30. Connect Strategy to Evidence
Strategy says:
Improve customer experience.
Business Architecture should translate:
Which customer outcomes?
Which journeys?
Which measurable pain points?
Which capabilities contribute?
Which processes create those outcomes?
Which systems constrain improvement?
What investment changes the causal chain?
That is genuine traceability.
Not:
Strategic Theme → Capability → Initiative.
Three boxes and an arrow may satisfy the framework.
They do not necessarily explain anything.
The Actual Model of the Business
If you genuinely want to understand how a business is structured and how it improves, think of it as seven interacting systems.
1. Value
What outcomes does the organisation produce, for whom, and why do they matter?
2. Work
What activities transform demand into those outcomes?
3. Organisation
Who performs the work, and where does authority sit?
4. Information
What facts, records and knowledge make the work possible?
5. Technology
What systems automate, constrain or enable the work?
6. Economics
What resources are consumed and where does value leak?
7. Governance
Who decides, who controls, who accepts risk and who is accountable?
Capabilities sit across these systems as a vocabulary describing what must be possible.
They are not the systems themselves.
That distinction matters enormously.
The Final Lament
The tragedy of Business Architecture is not that capability modelling is useless.
It is that capability modelling is seductive.
It produces something quickly.
It looks strategic.
It fits on a wall.
It can be coloured.
Executives can understand it in thirty seconds.
Consultancies can benchmark it.
Tools can store it.
Architects can argue about it indefinitely.
And none of this guarantees that anyone understands how the business actually works.
The business itself is messier.
It is people making decisions with incomplete information.
It is customers creating demand.
It is work moving through queues.
It is systems exchanging data.
It is budgets constraining choices.
It is suppliers failing.
It is controls slowing things down for good reasons and bad ones.
It is informal networks compensating for broken formal structures.
It is history embedded in process.
It is politics embedded in organisation.
It is economics embedded in technology.
And improvement happens when you understand those relationships well enough to change the right one.
So keep the capability map.
Hang it on the wall.
Use it as the index.
But when someone points at a large red box labelled:
Customer Management
and says:
“We need to improve this capability,”
do not immediately launch a £20 million transformation programme.
Ask:
“What exactly is happening to customers?”
Then follow the work.
Follow the decisions.
Follow the data.
Follow the money.
Follow the queues.
Follow the exceptions.
Follow the spreadsheets.
Eventually you will find the actual business.
It is usually nowhere near the capability map.
