The heart of the matter: the operating model is how the organisation delivers its value proposition day to day. It requires capabilities — the things the organisation must be able to do — which are delivered through value streams that flow value to customers. If the business model is the what, the operating model is the how.
At A Glance
Concept
Definition
Operating Model
How the organisation actually delivers its value proposition, day in, day out. Not an org chart, not a process map — the designed combination of both, and more.
Capabilities
What the organisation must be able to do, stated free of how, who, or where. The architect's pivot concept: stable while structures churn.
Value Streams
The end-to-end flows through which value actually reaches a customer, from trigger to delivered outcome.
How A Value Stream Crosses The Capability Map
A capability map is static — it shows what the organisation can do, grouped by domain. A value stream is dynamic — it shows how a specific piece of value actually flows from trigger to outcome, and it rarely stays inside one row of the map. The example below traces an access-granting value stream as it crosses from the customer domain into access and security capabilities, exactly the kind of cross-cutting flow a capability map alone will never show you.
The heavier-bordered boxes are the capabilities this value stream actually draws on. It starts in the customer domain, dips into access and security, and never touches fulfilment at all — exactly why value streams have to be mapped separately from the capability map, not read off it.
Breaking Down Each Concept
Each concept below sets out what it is, exactly what an architect needs to do to build or maintain it, the inputs it depends on, the outputs it must produce, and the mistake most likely to undermine it.
1. Operating Model
What it is: how the organisation actually delivers its value proposition day to day — the designed combination of structure, process, people, information, technology and location, not any one of them alone.
What you need to do:
Describe it as a whole, across all six design dimensions, rather than defaulting to the org chart. An operating model description that is really just a structure chart has described the organisation, not the operating model.
Anchor the description to the capabilities it delivers, not to today's departments — capabilities are what survive when the departments around them are reorganised.
Use a consistent template, such as an operating model canvas, so current and target states can genuinely be compared later.
Name an owner for the operating model as a whole. Without one, "the operating model" is a shared description nobody is accountable for keeping current.
Inputs: the capability map, the design dimensions as currently configured, and leadership's confirmation of who owns the model as a whole.
Outputs: a single, coherent description of how the organisation currently operates, ready to be assessed, targeted, and governed.
Watch for: describing the operating model once, at the start of a programme, and never updating it. The moment the description stops being maintained, it stops being trustworthy.
2. Capabilities
What it is: what the organisation must be able to do, defined independently of who does it, how, or where — the stable pivot architects anchor on while structures churn around it.
What you need to do:
Build the capability map top-down from the business model and strategy, not bottom-up from today's teams. A capability map built from the org chart just reproduces the org chart with different labels.
Name capabilities as abilities, not functions — "Identity & Access Management," not "the IAM team." That distinction is what makes the map survive a reorganisation.
Level the map consistently, typically two or three levels of decomposition, so it is detailed enough to assess and coarse enough to stay readable on one page.
Keep the map stable once agreed. It should change when the business model or strategy changes, not every time a project wants to reference something slightly differently.
Cross-check the map with capability owners and with security architecture, to confirm security-relevant capabilities — identity, data protection, detection, response — are named and levelled like any other capability, not left implicit.
Inputs: the business model, strategy, and existing process and organisational documentation as evidence of what capabilities already exist in some form.
Outputs: a levelled capability map that the capability assessment, current and target operating models, and gap analysis can all be built against.
Watch for: a capability map that quietly mirrors the current org chart. If every capability maps one-to-one onto a department, the abstraction has not actually happened.
3. Value Streams
What it is: the end-to-end flow through which value actually reaches a customer, from the trigger that starts it to the outcome that satisfies it — defined outside-in, not as an internal handoff chain.
What you need to do:
Start from the customer's trigger and the outcome they need, and work inward — not from the first internal process step that happens to run first.
Map every capability the value stream draws on as it crosses the organisation, including the handoffs between them. This is usually where the delay and the risk actually live.
Expect value streams to cross organisational and capability boundaries. A value stream that stays within one department has probably been drawn too narrowly.
Measure the value stream end-to-end, from trigger to outcome, not stage by stage. A value stream where every stage hits its local target and the overall flow is still slow has a measurement problem, not just a process problem.
Use value stream mapping alongside the capability map so both the static view — what we can do — and the dynamic view — how value actually flows — are visible together.
Inputs: the capability map, customer journey or trigger analysis, and end-to-end performance data where it exists.
Outputs: a mapped value stream showing the stages, the capabilities each stage draws on, and the handoffs between them, ready to be measured and improved.
Watch for: mapping the value stream as it is depicted in the process manual rather than as it actually runs. The real handoffs, delays and workarounds are exactly what a value stream map exists to expose.
Who, What, When, Where, Why
Who
COOs and operating model owners are accountable for the model as a whole. Capability owners and value stream owners are accountable for their piece. Enterprise and business architects build and maintain the capability map — and security architects need a named place on it, mapping security capabilities alongside business ones.
What
The core of the model itself: how the value proposition actually gets delivered, expressed as stable capabilities and the cross-cutting value streams that consume them.
When
Established once direction is set, then revisited at every planning cycle and whenever a value stream is redesigned. Capability maps are living artefacts, not one-off deliverables filed away after a programme closes.
Where
Capability maps sit at enterprise level, usually heat-mapped by maturity and importance across business units. Value streams cut across organisational boundaries end-to-end, which is exactly why they expose silo pain that an org chart hides.
Why
Capabilities are the stable pivot that survives reorganisation. Anchoring requirements — including security requirements — to capabilities rather than to today's org chart or technology stack keeps them relevant when the structure around them changes.
For Security Architects
Treat security as a set of capabilities on the same map, scored on the same two axes — maturity and importance — as every other capability, rather than as a parallel structure that only appears in a separate security architecture. Identity and access, threat detection, data protection, and response are capabilities the organisation needs exactly as much as any business capability, and they should compete for investment on the same terms. This is what stops security being "the function that says no" and makes it an integrated part of how value is actually delivered.