Enterprise Architecture & Operating Model Pathway

How strategy becomes capability, work, accountability, and consequence

Organisations do not fail only because they lack strategy, technology, talent, or effort.

They often fail because the connections among purpose, capability, work, information, decision-making, cost, accountability, and consequence are weak.

Strategy articulates a vision.
Projects are based on different foundations.
Operations coexist with other factors.
Data has varying meanings depending on the context.
Processes often span areas that lack clear ownership.
Technology tends to automate confusion.
Dashboards display activity but fail to reveal capacity.

This pathway is designed for those seeking to understand the real workings of an organisation, beyond its organisational chart, strategy presentations, transformation plans, or system diagrams. It brings together elements such as Business Architecture, Enterprise Architecture, operating model design, capability modelling, value streams, business processes, data, systems, roles, costs, measures, governance, and decision rights to provide a unified view of the enterprise.

The central question is:

How does the organisation turn purpose and strategy into capabilities, work, decisions, information, and outcomes?

For more information, see:

Who this pathway is for

This pathway is designed for people working in:

Enterprise Architecture
Operating model design
Transformation and change
Process improvement
Data and information management
Digital and AI transformation
Product and service design
Strategy execution
Governance, risk, and assurance
Organisational design
Business improvement and capability development

It is also for executives and managers who sense that their organisation is busy, well-intentioned, heavily governed, and full of projects — but still strangely incoherent.

The Enterprise Architecture problem

Enterprise Architecture is often misunderstood.

It is not just diagramming.
It is not just process mapping.
It is not an IT function wearing a business hat.
It is not an organisation chart.
And it is not shelfware.

Enterprise Architecture, at its best, enables an organisation to grasp what capabilities are essential, how value is generated, where activities occur, which information is vital, who makes key decisions, what systems facilitate the work, what costs are involved, and where accountability resides. It offers a common structural perspective of the organisation. Without this understanding, implementing change turns into a form of guesswork.

Projects multiply.
Systems proliferate.
Processes drift.
Data fragments.
Responsibilities blur.
Costs are allocated but not understood.
Risks move quietly across boundaries.
People work hard, but the organisation struggles to act coherently.

The issue is not a lack of activity.

The issue is a lack of coherence within the organisation.

For more information, see:

Purpose, capability, and coherence

Purpose provides direction. Capability makes purpose actionable.

An organisation cannot deliver purpose through slogans, values statements, or strategy documents alone. It needs capabilities: stable, nameable abilities to perform work, create value, meet obligations, serve stakeholders, learn, adapt, and respond.

A Business Capability Model helps define what the organisation must be able to do.

It gives the organisation a language for discussing:

Investment
Ownership
Maturity
Performance
Risk
Cost
Technology support
Data needs
Process improvement
Transformation impact
Strategic alignment

Capability is the point where purpose translates into practical action. A capability model isn’t about the current organisation chart; instead, it defines the essential abilities the organisation must have, regardless of the current team, system, project, or manager in charge. This is why capability modelling is important.

It gives the organisation a stable map in a changing landscape.

For more information, see:

Operating model: where strategy becomes work

The operating model is where strategy stops being intention and becomes work.

The Adaptive Operating Model Cycle

This model shows the operating model as a living cycle, not a fixed target-state diagram.

The cycle sits inside Purpose & Ethics because operating model choices are never neutral. They shape work, accountability, trust, knowledge, risk, value, and consequence.

COM — Current Operating Model

The COM describes how the organisation actually works today. This includes formal structures, capabilities, processes, systems, roles, data, governance, and decision rights, as well as the lived reality: workarounds, tacit knowledge, informal networks, trust dependencies, decision delays, data ambiguity, and the brilliant people quietly patching the holes.

TOM Options — Target Operating Model options

A TOM is not “the future”. It is a possible future operating model. There may be several TOM options, each with different assumptions, trade-offs, risks, and consequences. These options should be tested against scenarios, Gemba evidence, stakeholder needs, ethical boundaries, and organisational capacity.

AC — Adaptive Capacity

Adaptive Capacity is the test of the operating model. Did the organisation become more capable of sensing reality, coordinating work, applying knowledge, making decisions, learning from consequences, and adapting coherently? Once a TOM option is implemented, it becomes the new COM, and the cycle continues.

Organisational Awareness Hub

The Organisational Awareness Hub sits at the centre because it keeps the cycle grounded in reality. It monitors assumptions, weak signals, process friction, trust, workload stress, customer experience, data quality, decision delays, workarounds, unintended consequences, and changes in the external environment. It helps the organisation decide whether it needs a small tweak, a shift to another TOM option, or a new cycle of redesign.

Knowledge Base / Knowledge Operating System

The Knowledge Base provides the foundation for the cycle. It contains the shared explicit knowledge the organisation needs to understand itself: capabilities, value streams, business processes, data meanings, stakeholder perspectives, KPIs, systems, costs, risks, assumptions, and lessons learned. Without this foundation, operating model design becomes opinion, memory, and theatre. With it, the organisation can compare current reality, explore future options, and build Adaptive Capacity without losing coherence.

It explains how the organisation is arranged to deliver value, make decisions, use information, allocate resources, manage risk, and learn from consequences.

A useful operating model is not just a structure chart. It is not just a process map. It is not just a technology architecture. It is the organisation’s working logic.

It connects:

purpose and strategy
stakeholder expectations
capabilities
value streams
processes
people and roles
decision rights
information and data
systems and technology
governance
cost and performance measures
risk and compliance
learning and improvement

The operating model matters because strategy does not implement itself.

A strategy outlines the organisation’s goals, but the operating model determines its ability to achieve them. It illustrates how intent transforms into capability, how capability drives work, how work generates value, and how the resulting consequences inform ongoing learning.

This is where the operating model becomes visible.

Not in the diagram. In the strain.

When the operating model is weak, people compensate. They create informal workarounds. They rely on local knowledge. They negotiate across boundaries. They patch gaps with goodwill, experience, memory, spreadsheets, relationships, and judgement.

The organisation may still function, but it is being held together by effort rather than design.

That effort matters. It is often the reason the organisation survives.

But it also reveals fragility.

A weak operating model hides inside:

repeated handoffs
unclear decision rights
duplicated data
local spreadsheets
informal escalation paths
role confusion
process bypasses
unmanaged dependencies
hidden customer friction
brilliant people quietly patching the holes

It does not remove human judgement. It creates conditions where judgement can be used for learning, improvement, and adaptation rather than constant rescue.

A coherent operating model reduces that fragility. It gives people a shared way to understand:

What is the organisation trying to do?
What capabilities are needed?
How does value flow to stakeholders?
Where does work happen?
Who makes which decisions?
What information is required?
What systems support or distort the work?
Where do cost, risk, and accountability sit?
What consequences are being created?
What must be learned and improved?

This is why the operating model depends on a Knowledge Base or Knowledge Operating System.

The visible operating model changes over time. Markets shift. Customers change. Channels evolve. Technology changes. Regulations shift. Stakeholder expectations change. New target operating model options emerge.

But beneath that changing superstructure, the organisation needs a relatively stable foundation of shared knowledge: what it does, what it deals with, how value is delivered, how work is performed, how data is understood, how decisions are made, and how outcomes are measured.

Without that foundation, operating model design becomes theatre.

With it, the organisation can compare the Current Operating Model, explore Target Operating Model options, and build Adaptive Capacity without losing sight of purpose, ethics, work, capability, and consequence.

The operating model is therefore not a static diagram. It is a learning system.

It must remain connected to organisational awareness. It must be tested at Gemba. It must be corrected by evidence, experience, stakeholder feedback, operational friction, cost patterns, weak signals, and unintended consequences.

A good operating model is not merely designed and implemented.

It is maintained, challenged, corrected, and renewed.

That is where strategy becomes work — and where work teaches strategy what it still does not understand.

For more information, see:

Value streams: how value moves

Structure indicates where people are seated. Value streams illustrate how value flows through the organisation. A value stream outlines the complete sequence of activities that generate value for a stakeholder, crossing functions, systems, teams, and reporting lines. This is important because many organisational issues occur in the gaps between departments.

The customer does not see the organisation chart.
The citizen doesn’t see the funding model.
The supplier doesn’t see the project portfolio.
The employee doesn’t view the operating model as a diagram.

Instead, they all face handoffs, delays, rework, confusion, duplicate requests, missing information, unclear accountability, and the effects of fragmented design.

Value streams enable the organisation to identify where work crosses boundaries. They highlight where value is created, delayed, lost, protected, or damaged. Additionally, they help link strategy to work, work to process, process to systems, systems to data, and data to decisions.

Without value streams, organisations can optimise parts while weakening the whole.

For more information, see:

Business process: how work actually happens

Business Process Management gives detail to the movement of work.

It shows the activities, decisions, handoffs, rules, exceptions, controls, and variations that shape how work is performed.

But process modelling becomes weak when it is disconnected from capability, value, data, cost, risk, and consequences.

A process map should not be just a picture of steps.

It should help people understand:

What work is being done?

Why it matters.
Which capability does it support?
Which value stream does it belong to?
What information it uses and creates.
What decisions are made?
Which systems are involved?
Where potential consequences and risk arise.
Where cost is incurred.
Where improvement is possible.
Where lived practice differs from official design.

Business process is where architecture meets reality.

It is also where many assumptions get exposed.

For more information, see:

Data, redundancy, meaning, and the Common Data Model

Organisations often say they have a data problem.

Usually, they do.

The same data may be held in multiple systems, spreadsheets, user databases, reports, extracts, and local workarounds. Each copy may be updated differently, governed differently, defined differently, and trusted differently.

This creates serious data integrity problems.

Which record is current?
Which source is authoritative?
Which version is used for reporting?
Which spreadsheet has become the real system?
Which local database is quietly running a critical process?
Which duplicate record is driving a decision?
How is redundant data managed?
More to the point, who is accountable for data integrity?

Redundancy is not just technical clutter and an IT problem. It is an organisational risk.

When the same data is copied across systems, spreadsheets, reports, extracts, and local databases, the organisation starts to lose confidence in what it knows, what is current, and what is actually true enough to support a decision.

Integrity becomes uncertain, accountability becomes blurred, and decisions may be made based on whichever version of the truth happens to be most convenient, available, or familiar.

The integrity of a business decision is only ever as good as the integrity of the data on which it is based.

Meaning also matters, but usually around boundaries, roles, and context.

Many everyday concepts have a reasonably common meaning across the organisation. In an insurance company, for example, most people would understand the policyholder as a customer.

The difficulty starts at the edges.

Is a broker a customer, a channel, a partner, or an intermediary?

Is the customer the person who pays, the person who benefits, the person who holds the policy, the person who sells your white-labelled policy as their own product, or the person the organisation ultimately serves?

These distinctions are not word games. They affect reporting, accountability, customer experience, compliance, product design, risk, and AI use.

A Common Data Model helps the organisation deal with both problems.

It helps reduce ambiguity by clarifying what the organisation deals with and how it relates to itself.

It also helps expose redundancy by identifying where the same business object is being represented multiple times across systems, spreadsheets, processes, and reports.

The CDM does not solve every data problem.

But it gives the organisation a shared structure for asking better questions:

What business object are we talking about?
Where is it held?
Which source is authoritative?
Where is it duplicated?
Who owns its meaning and quality?
How is it used in processes, reports, decisions, risk, and AI?
Where do the grey areas begin?

Without this discipline, the organisation may appear data-rich while being integrity-poor and meaning-fragile.

For more information, see:

📝 Common Data Model
📝 Data Ownership
📝 Stewardship
📝 Kanban Architecture
📝 Gemba
📝 Knowledge Operating System
📝 Shared Mental Models
📝 Sensemaking
📝AI, Human Collaboration & Dialogue Design
📝 Governance

Costs, activity, and consequence

A coherent operating model also needs to understand cost.

Not just budgets.
Not just cost centres.
Not just financial reports.

It needs to understand how work activities are planned and how the related tasks consume resources and create outcomes.

Activity Based Costing helps connect cost to activity, activity to process, process to capability, and capability to purpose.

This matters because many organisations make investment and reduction decisions without understanding the work they are affecting.

They cut a function without seeing the capability it sustains.
They automate a task without understanding the process it belongs to, the value stream it affects, or the full consequences it may create across the wider system.
They reduce headcount without seeing the tacit knowledge, informal networks, unseen support arrangements, quiet exception-handling, and judgement being removed.
They fund projects without understanding the capabilities being built, duplicated, degraded, or neglected.

Cost is not just a finance issue. It shows where the organisation is consuming effort, time, knowledge, systems, and management attention — and where unseen, unintended consequences are quietly eroding trust.

When cost is disconnected from capability, process, data, and value streams, leaders can cut numbers without understanding what they are actually cutting. They may remove the people, knowledge, coordination, controls, unseen support arrangements, and practical judgement that make the organisation work.

A business architecture that connects capability, activity, process, data, systems, cost, and consequence gives leaders a better basis for decision-making.

It makes the organisation harder to fool with superficial numbers.

For more information, see:

From shelfware to workwear

Enterprise Architecture and Business Architecture often fail when they become detached from the work they are meant to support.

The models may be correct.
The repository may be complete.
The diagrams may be elegant.
The principles may be approved.
The governance process may exist and be in operation.

But if the architecture is not understood, used, challenged, updated, and owned by the people doing the work, where the work is actually done and facing reality, it becomes shelfware.

It sits in a repository.
It appears in presentations.
It is referenced in governance forums.
It is dusted off during transformation programs.
But it does not shape everyday judgement, coordination, learning, or action.
That is not architecture in use.
That is architecture as artefact.
A living architecture must become workwear.
Architecture becomes workwear when it is coherent and practical enough to be worn at work by the people doing the work — helping them share meaning, coordinate action, improve practice, and innovate their world.

For more information, see:

Architecture belongs at Gemba.

Architecture should extend beyond strategy rooms, design authorities, project templates, or specialist tools. It must engage with reality at Gemba — the setting where work occurs, outcomes become evident, and assumptions are validated. At Gemba, the organisation determines if its architecture is truly effective.

Can people use the capability model to understand where work belongs?
Can they use the value stream to see how value moves?
Can they use the process model to improve handoffs?
Can they use the data model to clarify meaning?
Can they use the operating model to resolve confusion about roles, decisions, ownership, and accountability?
Can they use the architecture to explain why a change matters and what it affects?

If not, the architecture may be tidy, but it is not useful.

Gemba keeps architecture honest.

It exposes the gap between the model and the work.
It shows where the process is bypassed.
It shows where the data definition does not match lived practice.
It shows where the capability exists in name only.
It shows where the system design creates workarounds.
It shows where the operating model says one thing and the organisation does another.

This is not a failure. This is learning.

A living architecture should be corrected by reality.

The model should go to Gemba, meet the work, be challenged, and return stronger.

For more information, see:

Organisational ownership

Architects cannot solely own architecture. They can steward, model, maintain integrity, and help connect parts, but organisational ownership is essential.

Business leaders must own capabilities; process owners are responsible for how work is performed; data owners must oversee meaning, quality, and use; while product and service owners need to own value creation.
Managers should bridge the gap between operational reality and structural intent.
Teams need access to architecture to understand their work, improve coordination, identify issues, and make better decisions.

When architecture is only managed by the architecture team, it remains expert knowledge rather than an organisational asset.

When the organisation owns it, it becomes shared knowledge.

That is the shift from shelfware to workwear.

For more information, see:

Architecture as shared language

The real value of architecture is not the diagram. The real value is the shared language the diagram makes possible.

Architecture helps people ask better questions:

What capability is affected?
Where does this work sit?
Who owns the decision?
What information is needed?
What does this term mean?
Where does value flow?
Where does accountability break?
What process is actually being changed?
What risk is being shifted?
What consequence will this create?
What must we learn from what happens next?

These questions matter because organisations often fail through fragmentation.

Architecture is the discipline that helps reconnect the fragments.

It helps people see the organisation as a system of purpose, capability, work, information, technology, cost, decision-making, and consequence.

For more information, see:

AI makes architecture more important, not less.

AI does not replace the necessity for architecture; instead, it reveals whether an organisation has one. For effective use, AI requires a clear purpose, trustworthy knowledge, well-understood processes, governed data, accountable decision-making, and meaningful human oversight.

Without architecture, AI can accelerate confusion.

It can generate fluent outputs from weak knowledge.
It can automate poorly understood work.
It can hide accountability behind systems.
It can produce polished artefacts that nobody fully understands.
It can make broken processes move faster.

The question is not simply:

Where can we use AI?

The deeper question is:

How does AI change work, judgement, accountability, knowledge flow, and consequence?

That is an operating model question.

Business Architecture helps determine where AI belongs, what capabilities it supports, which processes it changes, which data it depends on, which decisions it influences, which risks it creates, and where human judgement must remain visible.

AI changes tasks.

Architecture must redesign the work.

For more information, see:

📝AI, Human Collaboration & Dialogue Design
📝 Kanban Architecture
📝 Common Data Model
📝 Data Ownership
📝 Business Process Management
📝 Operating Model
📝 Decision Rights
📝 Accountability
📝 Governance
📝 Tacit Withdrawal

Governance without bureaucracy

Governance is often seen as an obstacle. However, effective governance does not oppose adaptation. Instead, it facilitates safe, coherent, and responsible adaptation processes.

It clarifies:

Who can decide?
What principles apply?
What risks must be considered?
What evidence is needed?
What boundaries cannot be crossed?
What consequences matter?
When is escalation required?
How will learning occur?

Weak governance leads to costly improvisation.

Overburdened governance causes delays, theatrics, and avoidance.

Effective governance links decision-making to purpose, capability, risk, evidence, and consequence. It provides clarity for individuals. It safeguards the organisation from unintended fragmentation. It ensures adaptation is disciplined instead of chaotic.

For more information, see:

Line of sight

People need clarity on how their work connects to the organisation’s purpose. Without this understanding, work becomes just about completing tasks. Although people may be busy, they often don’t see how their efforts add value, facilitate learning, reduce risks, improve customer outcomes, build stakeholder trust, or support long-term sustainability. Business Architecture helps establish this connection sight.

It connects: Purpose → Strategy → Capability → Value Stream → Process → Activity → Data → System → Role → Cost → Measure → Outcome

This is not a reporting chain; it is a meaning chain.

It helps people see why their work matters and how changes in one part of the organisation influence others.

Line of sight turns architecture from abstraction into practical orientation.

For more information, see:

From project delivery to capability building

Projects bring about change, while capabilities ensure ongoing performance. However, many organisations mistake project completion for true organisational improvement.

A system goes live.
A process is redesigned.
A structure is announced.
A policy is approved.
A dashboard is launched.
A transformation milestone is closed.

But the deeper question remains:

What is the organisation now capable of doing that it could not do before?

Capability building requires more than delivery.

It requires people, knowledge, process, data, technology, relationships, governance, cost understanding, decision rights, and learning.

Business Architecture helps keep attention on the capability being built, not merely the initiative being delivered.

It asks:

What capability is this project strengthening?
What work will change?
What knowledge is needed?
What data must be trusted?
What systems are involved?
What roles are affected?
What cost or risk is shifting?
What consequence will this create?
What must be learned after implementation?

Without this discipline, organisations deliver projects while leaving their capability weak.

For more information, see:

The operating model as a learning system

A living operating model is not fixed.

It must learn.

As conditions evolve, the organisation needs to observe, understand, adapt, and enhance. This requires the operating model to stay aligned with organisational awareness and be validated through Gemba.

It must be informed by customer experience, employee experience, operational friction, risk events, weak signals, cost patterns, data issues, and unintended consequences.

A good operating model is not simply designed and implemented.

It is maintained, challenged, corrected, and renewed.

This is where Business Architecture connects to Organisational Learning.

The architecture provides structure.
Gemba provides reality.
Hansei provides reflection.
Dialogue provides sensemaking.
Governance provides disciplined choice.
Action provides the test.
Consequence provides the lesson.

For more information, see:

The pathway in practice

This pathway helps you move through the following questions:

What must the organisation be able to do?
Start with capabilities.
How is value created?
Use value streams to understand flow.
How does work actually happen?
Use the process to understand activity, handoffs, variation, and improvement.
What does the organisation mean by its key terms?
Use data modelling to clarify meaning.
What systems support or distort the work?
Connect technology to capability, process, and data.
Where are cost, risk, and accountability located?
Connect architecture to financial and governance reality.
Who owns the work, the decisions, and the consequences?
Clarify decision rights and operating accountabilities.
How is the architecture used at Gemba?
Test the model against lived reality.
How does the organisation learn from what happens next?
Connect architecture to reflection, adaptation, and improvement.

Closing reflection

Enterprise Architecture and Operating Model Design are not merely documentation disciplines.

They are coherent disciplines. They help the organisation understand itself well enough to change without breaking itself.

Architecture is not finished when the model is approved.

It is alive when the organisation can use it at Gemba to understand work, test assumptions, coordinate action, and learn from consequence.

The shift is simple.

From shelfware to workwear.

From expert artefact to shared knowledge.
From diagram to dialogue.
From structure to capability.
From strategy slide to lived work.
From fragmented activity to coherent action.

Suggested first steps

Start with:

Enterprise Architecture — Foundation of Shared Knowledge
How architecture becomes a shared organisational knowledge base rather than a specialist artefact.
Business Capability Model
How capabilities provide a stable map of what the organisation must be able to do.
Common Data Model
Why shared meaning matters for decisions, reporting, AI, and organisational coherence.
Line of Sight
How people connect their work to purpose, value, capability, and consequence.
Gemba
Why architecture must meet the place where work actually happens.
Mindset Our mindsets determine our behaviours and actions; both have consequences and outcomes. Use the right mindset to get the optimal outcome.