Capability Maps, Value Streams, and TOGAF
This module uses TOGAF as supporting context for digitalisation work. If you want the full TOGAF-led route from basics through governance, migration, and framework comparison, use the Enterprise Architecture course.
By the end of this module you will be able to:
- Distinguish between a capability, a process, and a function, and explain why capability mapping is the correct starting point for legacy system replacement
- Apply value stream mapping to identify waste and handoff delays in a digital delivery process
- Describe the TOGAF ADM phases A through H and explain the difference between Architecture Building Blocks and Solution Building Blocks
Real-world transformation · DWP · Universal Credit redesign
Before you can replace what you have, you need to understand what you actually do.
The Department for Work and Pensions (DWP) serves 22 million claimants and employs 90,000 staff across the United Kingdom. When it began redesigning Universal Credit from a legacy estate of more than 50 separate systems, the first question was not which system to replace first. The first question was: what does this organisation actually do?
DWP built a business capability map that separated what the organisation did (pay benefits, verify eligibility, manage claimant records, process appeals) from which system did it. A single capability might span 8 systems. A single system might support 6 capabilities. Until the capability map existed, the two questions were inseparable.
With the capability map in place, DWP could replace one system at a time without disrupting the others. The boundary of each replacement was drawn around a capability, not around a system. This module covers capability mapping, value stream analysis, and the TOGAF framework that provides the governance structure for transformations at this scale.
Before you can replace what you have, you need to understand what you actually do - and those are different questions.
With the learning outcomes established, this module begins by examining capabilities vs processes vs functions in depth.
10.1 Capabilities vs Processes vs Functions
Three terms are frequently used interchangeably in architecture discussions, but they describe fundamentally different things. Conflating them produces imprecise designs and misaligned investment decisions.
A capability is what an organisation can do, expressed at a level of abstraction that is independent of organisational structure and technology. "Pay benefits" is a capability. It does not describe how benefits are paid, which team pays them, or which system processes the payment. Capabilities are stable: they change rarely, typically only when the organisation's purpose changes.
A process is how a capability is performed, step by step, in the current operating model. "Receive claimant bank details, validate with banking gateway, generate payment instruction, post to BACS" is a process for the 'Pay benefits' capability. Processes change frequently as technology and operating models evolve.
A function is a grouping of people with related skills and responsibilities. The Finance function, the Technology function, the Operations function. Functions appear on org charts. The same capability may be executed across multiple functions simultaneously.
This distinction matters because legacy system replacement decisions should be driven by capability, not by function or process. DWP could not ask "which system should we replace first?" until it had separated the capability question from the process question. Once capabilities were identified and mapped to systems, the replacement sequence became visible.
A capability map asks: what must we be able to do? A process model asks: how do we currently do it? A target operating model asks: how should we do it in future? These are three separate questions that require separate answers before any investment decision is made.
Capabilities are distinct from processes and functions. Section 10.2 shows how to structure them into a business capability map and use that map to prioritise investment decisions.
10.2 Business Capability Mapping
A business capability map is a structured view of all the capabilities an organisation must possess to deliver its mission. Capabilities are typically organised into three tiers: strategic capabilities (direction and governance), core capabilities (the value-creating activities), and support capabilities (enabling activities that allow the core to function).
Each capability is assessed against two dimensions: business importance (how critical is this capability to the organisation's competitive position or mission?) and current performance (how well does the organisation currently perform this capability?). The resulting heat map identifies where investment is most urgent.
In 2019, NHS Digital used capability mapping as part of its transformation programme to identify which capabilities were poorly supported by existing systems. The process revealed that patient identity management spanned 11 separate systems, none of which had the same definition of a patient identifier. This was invisible in the process and system views alone.
The Open Group defines a business capability as "a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome." This definition emphasises outcome-focus: capabilities exist to produce results, not merely to describe activities.
“A capability is a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome.”
The Open Group, TOGAF 10th Edition - Business Capability Definition
This definition separates capability from process by centering on outcome rather than activity. A capability names a result an organisation must produce. The process describes how it is currently produced. The separation allows the architecture to change processes and systems without changing the capability definition, preserving stability in the planning framework while allowing the delivery mechanism to evolve.
Common misconception
“A capability map is an org chart.”
A capability map shows what an organisation does; an org chart shows who does it. The same capability is frequently distributed across multiple teams and departments. 'Manage customer identity' at DWP involved the Universal Credit team, the Debt Management team, and the Shared Services team simultaneously. An org chart would hide this overlap; a capability map reveals it and forces a governance decision about who owns the capability.
A capability map shows what the organisation must be able to do. Value stream mapping shows how work flows to deliver that capability - and where waste, delays, and handover failures slow it down. Section 10.3 covers VSM in practice.
10.3 Value Stream Mapping
Value stream mapping (VSM) is a lean analysis technique that maps the end-to-end flow of work required to deliver a specific value to a customer. Developed by Toyota and popularised in manufacturing by James Womack and Daniel Jones in their 1996 book Lean Thinking, VSM was adapted for software delivery by Karen Martin and Mike Osterling in Value Stream Mapping (2014).
A value stream map captures the current-state flow of a digital delivery process from customer request to value delivered. It records, for each step: process time (the time spent actively working on the item), wait time (the time the item sits waiting for the next step), and the percentage of items that complete the step correctly the first time (the percent complete and accurate, or %C&A).
The ratio of process time to total lead time is the efficiency ratio. In most large organisations, the efficiency ratio of software delivery is between 5% and 25%. The remaining 75% to 95% is wait time. A team that spends 8 hours developing a feature that then waits 3 weeks in a release queue has a 4.7% efficiency ratio for that feature.
In 2022, the UK Home Office published its value stream analysis for the Visa Application process, revealing that 67% of total lead time was waiting for manual identity verification decisions. The analysis directed automation investment at the specific step causing the most delay, rather than making general efficiency improvements across the board.
Capability maps and value stream maps are analysis tools. TOGAF provides the governance method that turns their findings into a sequenced architecture programme. Section 10.4 covers the TOGAF ADM phases and what each one produces.
10.4 TOGAF ADM Phases A through H
The Open Group Architecture Framework (TOGAF) is the most widely adopted enterprise architecture framework in the world, used by over 80% of Global 50 companies according to The Open Group. Its core method is the Architecture Development Method (ADM), a cyclical process for developing and governing enterprise architectures.
The ADM has 9 phases arranged in a cycle:
- Preliminary - establishes the organisation's architecture capability, governance, and tailoring of the framework.
- Phase A: Architecture Vision - defines scope, stakeholders, constraints, and the high-level target architecture.
- Phase B: Business Architecture - describes the baseline and target business architecture.
- Phase C: Information Systems Architecture - covers both data and application architectures.
- Phase D: Technology Architecture - maps the technology infrastructure needed to support the target architecture.
- Phase E: Opportunities and Solutions - identifies migration opportunities and consolidates work into an implementation roadmap.
- Phase F: Migration Planning - prioritises projects and finalises the migration plan.
- Phase G: Implementation Governance - provides architectural oversight during delivery.
- Phase H: Architecture Change Management - manages ongoing change to the architecture and monitors for triggers that would restart the ADM cycle.
A critical principle of TOGAF is that all phases can be tailored. An organisation does not need to execute every phase in full for every change. For a small cloud migration, Phases E and F may be the primary focus. For a major transformation, all phases apply. The ADM is a framework for structured thinking, not a bureaucratic checklist that must be completed in sequence without adaptation.
In 2021, the UK Ministry of Justice applied a tailored TOGAF ADM to its Common Platform transformation, covering over 75 courts. They ran a compressed Phase A (six weeks rather than the typical six months) and used Phase B to drive the capability map that identified which legacy HMCTS systems required replacement.
“The Architecture Development Method describes a recommended approach for developing and managing the lifecycle of an Enterprise Architecture. It is generic and can be used in conjunction with any appropriate set of standards and/or components.”
The Open Group, TOGAF Standard 10th Edition - Part II: Architecture Development Method
The phrase 'in conjunction with any appropriate set of standards' is deliberate. TOGAF does not prescribe specific technologies or design patterns. It provides a governance structure for architectural decision-making. This is why TOGAF applies equally to a 50-person organisation and a 50,000-person organisation: the framework governs the process of architectural thinking, not the content of the architecture itself.
The ADM phases produce architecture deliverables. Section 10.5 clarifies the distinction between the two types of building block TOGAF uses to describe those deliverables: Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs).
10.5 Architecture Building Blocks and Solution Building Blocks
TOGAF distinguishes two types of building block, and the distinction matters directly for procurement and governance decisions.
An Architecture Building Block (ABB) is a technology-agnostic description of a capability or component needed in the target architecture. An ABB defines what is required without specifying how it is delivered. "Claimant Identity Management" is an ABB: it defines what the system must be able to do (uniquely identify claimants, resolve duplicate identities, maintain audit records) without specifying whether it is delivered by an off-the-shelf product, a custom build, or a shared government service.
A Solution Building Block (SBB) is a concrete implementation of an ABB. It names the specific technology, product, or service that will fulfil the ABB requirement. The UK government's GOV.UK Verify identity assurance service was an SBB for the Claimant Identity ABB. When Verify was retired in 2021, the ABB remained valid; only the SBB was replaced by the successor NHS Login and GOV.UK One Login services.
This separation protects organisations from technology lock-in at the architecture level. Architecture decisions are made at the ABB level; technology procurement decisions are made at the SBB level. This prevents a single vendor's product from becoming embedded in the architectural blueprint and inseparable from the capability design.
Common misconception
“TOGAF is only for large enterprises.”
TOGAF's ADM phases are explicitly designed to be tailored to any scale. Small organisations can run a compressed ADM cycle in weeks, covering only the phases relevant to the scope of their change. The framework's value is in the discipline it brings to architectural thinking: separating concerns, documenting decisions, and managing change. The Open Group's TOGAF Foundation certification is specifically designed for practitioners applying TOGAF at smaller scale.
Building blocks describe the architecture components. The Target Operating Model brings those components together into a coherent picture of how the organisation will operate once the transformation is complete. Section 10.6 covers TOM design.
10.6 Target Operating Model Design
A Target Operating Model (TOM) describes how an organisation will operate in the future state: the people, processes, technology, data, and governance arrangements that will deliver the target capabilities. A TOM is distinct from a system architecture: it describes the operating model, not the technical design.
The five dimensions of a TOM are:
- People: skills, roles, team structures, and sourcing model
- Process: the target-state business processes
- Technology: the technology estate that enables the processes
- Data: information flows, ownership, and governance arrangements
- Governance: how decisions are made, policies enforced, and performance measured
DWP's Universal Credit TOM identified that its target state required 800 fewer manual caseworkers, 12 new digital product teams, and 3 new shared data services that did not exist in the legacy estate. The TOM made these human and organisational implications of the technical architecture visible to leadership before any investment was committed, allowing informed trade-off decisions.
A government department is replacing its legacy benefit payments estate. The lead architect proposes beginning by identifying which systems to retire. A business analyst proposes beginning by mapping the organisation's business capabilities. Who is correct, and why?
In TOGAF, what is the primary distinction between an Architecture Building Block (ABB) and a Solution Building Block (SBB)?
A value stream analysis of a mortgage application process finds: total process time 4 days, total wait time 31 days, total lead time 35 days. What is the efficiency ratio and what does it indicate?
Key takeaways
- A capability describes what an organisation must be able to do, independent of who does it or which system supports it; separating capabilities from processes and functions is the prerequisite for any large-scale legacy replacement.
- Business capability heat maps identify where investment is most urgent by combining business importance with current performance, creating a visual priority map for architectural work.
- Value stream mapping reveals efficiency ratios that are typically 5% to 25% in software delivery; the majority of lead time is wait time between steps, not process time within steps.
- The TOGAF ADM provides a cyclical, scalable framework for architectural development; all phases can be tailored to the scale and urgency of the change being designed.
- Architecture Building Blocks define what is required without naming a technology; Solution Building Blocks name the specific implementation; this separation prevents vendor lock-in at the architecture level.
- A Target Operating Model describes the future-state people, process, technology, data, and governance arrangements required to deliver target capabilities, making the human implications of technical decisions visible to leadership.
Standards and sources cited in this module
The Open Group, TOGAF Standard 10th Edition
opengroup.org/togaf
Primary source for TOGAF ADM phases, building block definitions, and architecture governance. Referenced throughout Sections 10.4 and 10.5.
Martin, K. and Osterling, M., Value Stream Mapping
McGraw-Hill Education, 2014
Primary reference for VSM application in knowledge work and software delivery contexts. Referenced in Section 10.3.
DWP Digital, Universal Credit Design History
dwpdigital.blog.gov.uk
Primary source for DWP Universal Credit capability mapping case study cited in the opening story and throughout the module.
NHS Digital, Transformation Programme Architecture Overview
digital.nhs.uk/about
Referenced in Section 10.2 for the patient identity management capability mapping case, 2019.
Lankhorst, M. et al., Enterprise Architecture at Work
Springer, 4th Edition, 2017
Academic reference for ArchiMate notation and capability modelling methodology underpinning TOGAF applications.
Womack, J. and Jones, D., Lean Thinking
Simon and Schuster, 1996
Original source for value stream analysis methodology applied in Section 10.3, adapted from manufacturing to digital delivery contexts.
Enterprise architecture provides the map. The next module examines how to keep the systems running: operations, observability, SRE practices, and the monitoring discipline that prevents architectural decisions from degrading in production.
Module 10 of 15 in Applied