Value streams

G178 Value Streams is the TOGAF Series Guide dedicated to value-stream mapping in enterprise architecture. It defines a value stream as a representation of an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end user. That definition contains three critical words that control how the concept should be applied.

End-to-end. A value stream is not a partial view of one team's work. It traces the complete journey from the moment a stakeholder expresses a need to the moment the outcome is delivered. If the stream starts partway through the journey, it cannot reveal where the real delays sit. If it ends before the outcome is realised, it misses the feedback that shapes future performance.

Value-adding. Not every step in a business process adds value. Administrative approvals, unnecessary handoffs, and duplicated data entry may be necessary under current arrangements but they do not create value from the stakeholder's perspective. A value stream focuses on where value is created, transformed, or delivered. Steps that exist only because the current arrangement requires them are visible as friction, not as value stages.

Overall result. The value stream exists to deliver a specific outcome that the triggering stakeholder cares about. For an electricity connections value stream, the overall result is an energised connection. For an insurance claims value stream, it is a settled claim. If the stream cannot name its outcome, it is not yet a value stream.

G178 distinguishes value streams from processes at a fundamental level. A process map shows how work is done in detail: every task, every decision point, every system interaction. A value stream shows how value reaches the stakeholder across major stages. The distinction matters because they serve different audiences and answer different questions.

A process map answers: "How exactly does the work get done?" A value stream answers: "Where does value get delayed, degraded, or made expensive?" Both views are legitimate. But they sit at different levels of abstraction and serve different viewpoints. If a value stream drops into task-level detail, it stops being an architecture artefact and becomes an operations manual.

Capabilities tell you what the enterprise must be able to do. Value streams show how those abilities combine to deliver stakeholder outcomes through a sequence of stages. G178 explicitly describes these as complementary lenses that belong together in Phase B because one shows ability and the other shows flow. Together, they reveal what needs to improve (capability assessment) and where the improvement matters most (value-stage analysis).

G178 describes a structured mapping method with specific notation conventions. Understanding each element of the method is essential because the architectural value of a value stream comes from the completeness of its mapping, not from the diagram alone. A value stream that has been drawn but not fully mapped is a picture, not an analysis tool.

Triggering stakeholder

Every value stream starts with a stakeholder who has a need or makes a request. The triggering stakeholder defines the perspective from which value is measured. This matters because different stakeholders will judge value differently. A customer waiting for a connection judges value by elapsed time and transparency. A regulator judges value by accuracy and compliance. A network planner judges value by data quality and completeness.

G178 requires the triggering stakeholder to be named explicitly. The reason is practical: if the triggering stakeholder is ambiguous, the team will struggle to decide which stages add value and which stages add only administrative overhead. For a connections value stream, the triggering stakeholder is the customer who submits a connection application. The entire stream is measured from that stakeholder's perspective: did the connection outcome arrive on time, with adequate transparency, and at a reasonable cost?

Value stages

The value stream is divided into a small number of major stages, each of which produces an identifiable output that contributes to the final outcome. G178 recommends keeping value streams to between five and twelve stages. Fewer than five tends to be too abstract to identify specific bottlenecks. More than twelve tends to drop into process-level detail that obscures the architectural view.

Each stage should represent a recognisable chunk of work that the triggering stakeholder can understand and that involves at least one significant handoff or decision. The word "recognisable" is doing important work here. If the triggering stakeholder cannot name the stage or understand what it produces, the stage may be an internal implementation detail rather than a genuine value stage.

Stage outputs

Each value stage should have a defined output that the next stage can consume. If a stage has no clear output, it may not be a genuine value stage. G178 uses stage outputs to identify where information is lost or degraded between stages. When the output of Stage 3 is not the same as the input that Stage 4 expects, that mismatch is an architectural problem.

Stage outputs also serve a governance function. If a stage claims to produce a certain output but the next stage regularly receives something different, the value stream has exposed a data-quality or handoff problem that needs architectural attention.

Participating stakeholders

G178 maps which stakeholders participate in each value stage. This connects the value stream to the organisation mapping from Module 18 and helps identify where handoff ownership is unclear. If three separate teams participate in a single value stage but none of them owns the stage output, the value stream has revealed an accountability gap.

Participating stakeholders also help identify where the stream crosses organisational boundaries. These boundary crossings are often where the most significant delays occur, because each boundary introduces potential for information loss, priority conflict, and coordination failure.

Enabling capabilities

Each value stage is mapped to the capabilities that enable it. This cross-reference is what connects value streams to capability maps. A weak capability often manifests as a slow or unreliable value stage. If the "network planning visibility" capability is assessed as weak using the G211 framework, the value stages that depend on planning data will suffer. The cross-reference makes capability weaknesses visible in the context of stakeholder impact.

This is one of the most powerful aspects of the G178 method. Without the capability cross-reference, a value stream shows friction but cannot explain the root cause. With the cross-reference, the friction traces to a specific enterprise ability that can be assessed, invested in, and improved.

Pain points and bottlenecks

G178 recommends marking each value stage with identified pain points: where value is delayed, degraded, or made expensive. A value stream without identified pain points has not been analysed. It has only been drawn.

Pain points should be specific enough to guide later architecture work. "The handoff is slow" is a symptom, not a pain point. "The assess-to-study handoff loses information because planning and design teams use different systems with no shared evidence base, adding an average of twelve working days to the elapsed time" is a pain point that can direct architectural intervention.

Pain points also serve as the bridge from value-stream analysis to gap analysis. Each pain point identified in the value stream becomes a candidate entry in the business gap log, where it is enriched with consequence, dependency, and intervention information.

G178 is explicit about the relationship between value streams and capabilities. Capabilities describe what the enterprise must be able to do. Value streams show how those abilities combine to deliver stakeholder outcomes. The relationship works in both directions, and understanding both directions is essential for getting value from the combination.

From capabilities to value streams

A weak capability predicts a slow or unreliable value stage. If network planning visibility is assessed as weak (using the G211 framework from Module 19), the value stages that depend on planning data will suffer. The cross-reference makes capability weaknesses visible in the context of stakeholder impact.

This direction is predictive. Before the team has even mapped the value stream in detail, capability assessment results can tell them where to look for bottlenecks. A capability rated "weak" or "basic" on a maturity scale is almost certainly contributing to friction in at least one value stage. The capability assessment becomes a hypothesis generator: "We expect this stage to be slow because this capability is weak." The value stream confirms or refutes that hypothesis.

From value streams to capabilities

A bottleneck in a value stage points toward the capabilities that need attention. If the assess-to-study handoff consistently delays the connections journey, the value stream tells the architecture team which capabilities to examine more closely. In the London case, the assess-to-study bottleneck points toward network planning visibility and connection design coordination.

This direction is diagnostic. The value stream reveals the symptom (the handoff is slow). The capability cross-reference identifies the root cause (the enabling capability is weak). Together, they produce an architectural argument that is stronger than either one alone: "The connections journey is slow at the assess-to-study transition because planning visibility is weak. Strengthening that capability would reduce elapsed time at this specific value stage."

Why the combination matters

This bidirectional relationship is what makes the combination of capability maps and value streams more powerful than either one alone. A capability map without a value stream shows ability without context. A value stream without a capability cross-reference shows friction without root cause. G178 and G211 are designed to be used together precisely because the combination provides both context and root cause.

The practical consequence for Phase B work is that the architecture team should produce both views and cross-reference them. If the team produces a capability map and a value stream but does not cross-reference them, the two artefacts are decorative. The architectural value emerges from the cross-reference, not from either artefact individually.

G178 provides guidance on the right level of abstraction for value streams. If the stream is too high-level, it becomes vague and cannot identify specific bottlenecks. If it drops into every task and every system call, it stops being a business-architecture artefact and becomes a process map. Maintaining the right level of abstraction is one of the most difficult practical skills in value-stream work.

The useful middle is a small set of meaningful stages with clear outputs and pain points. G178 recommends that each value stage should meet four criteria.

1. Represent a recognisable chunk of work that the triggering stakeholder can name. If you told the customer that their connection application was currently in the "Assess" stage, the customer should have a rough idea of what that means. If the stage is called "DBA-7 subprocess validation", the customer has no idea, and the stage has dropped below the value-stream level.
2. Have a clear, identifiable output that the next stage consumes. If the output cannot be named, the stage boundary is probably in the wrong place. A stage that produces "an approved connection offer with costed scope" has a clear output. A stage that produces "some updated records" does not.
3. Involve at least one significant handoff, decision, or transformation of information. This criterion prevents the stream from being sliced too finely. If two adjacent stages do not involve a meaningful boundary crossing, they should probably be one stage.
4. Be understandable by a non-specialist audience. The board should be able to read the value stream. If the stage names require technical glossaries to interpret, the stream has drifted into territory that belongs in a process map or technical design document rather than in a business-architecture view.

If a stage cannot meet those four criteria, it may be too fine-grained for the value-stream view and belongs in a detailed process map instead. The discipline is to push detail down rather than pull it up. When someone says "but this detail is important," the right answer is usually "yes, and it belongs in the process layer, not the value-stream layer."

Capability-based planning (G233) uses capability assessment to prioritise investment. Value streams add a dimension that pure capability assessment cannot provide: stakeholder impact.

A capability assessment might rate "network planning visibility" as weak and "customer communication management" as moderate. Without a value stream, the enterprise might invest in whichever capability scores lowest. With a value stream, the enterprise can ask a more useful question: "Which capability weakness causes the most pain at the value stages that matter most to our stakeholders?"

If the connections value stream shows that the assess-to-study handoff is the single largest source of delay, and that handoff depends on network planning visibility, the investment case for that capability is strengthened by the value-stream evidence. The planning conversation shifts from "this capability scored 2 out of 5" to "this capability scores 2 out of 5 and its weakness adds an average of twelve working days to every connection."

G233 explicitly anticipates this combination. The guide recommends that capability assessment results should be tested against value-stream evidence before investment recommendations are finalised. A capability that is weak but does not sit on a critical value-stage path may be less urgent than a capability that is moderate but sits on the most painful handoff in the enterprise.

Producing a value stream that looks correct but is not architecturally useful is a common failure mode. Understanding the typical mistakes helps the architecture team avoid them.

Drawing without analysis. The team produces a neat diagram showing stages from left to right but does not identify pain points, does not cross-reference capabilities, and does not map participating stakeholders. The result looks like a value stream but functions as a decoration. G178 is clear that the mapping method includes all six elements, not just the stage diagram.

Dropping into process detail. The team includes twenty-seven stages with system-level interactions, individual email steps, and internal database queries. The result has left the business-architecture level and entered process territory. It cannot serve the board-level audience that a value stream should address.

Mapping the current state only. The team maps the baseline value stream in detail but does not produce a target value stream or identify which stages should change. A baseline-only value stream is descriptive but not architectural because it does not show the direction of improvement.

Skipping the triggering stakeholder. The team draws stages without naming who triggers the stream and whose outcome defines success. Without a named stakeholder, the team cannot decide which activities add value and which add only overhead.

Treating the value stream as standalone. The team produces the value stream but does not cross-reference it to capabilities, organisation mapping, or the gap log. The stream sits in a document alongside other artefacts but is never connected to them. This defeats the purpose of the G178 method, which is designed to work in combination with other business-architecture views.

The London connections value stream traces the complete journey from customer request to energised connection and the feedback loop that shapes future performance. Using the G178 mapping method, it includes eight value stages, each with a defined output, participating stakeholders, enabling capabilities, and identified pain points. The triggering stakeholder is the customer who submits a connection application. The overall result is an energised connection delivered on time, transparently, and with accurate data feeding back into planning.

Stage 1: Request

Trigger: Customer submits connection application. Output: Validated application with site and demand details. Participating stakeholders: Customer, connections front-office team. Enabling capability: Customer connections management. Pain point: Application forms require information that customers struggle to provide, causing rework and delay at the entry point. Customers frequently submit incomplete applications because the form asks technical questions about load profiles and generation capacity that a domestic or small-commercial customer cannot answer without specialist help.

Stage 2: Assess

Output: Initial capacity assessment and route to study or offer. Participating stakeholders: Network planning team, connections assessment team. Enabling capability: Network planning visibility. Pain point: Planning data is fragmented across GIS, DMS, and spreadsheet-based planning tools. Engineers spend time assembling a view of available capacity that should be readily available from a single, trusted source. The time spent assembling data is non-value-adding from the customer's perspective.

Stage 3: Study

Output: Detailed network study and reinforcement requirements. Participating stakeholders: Design team, planning team, third-party contractors (where reinforcement is needed). Enabling capability: Connection design coordination. Pain point: The assess-to-study handoff loses information because planning and design teams use different systems. The design team often needs to re-gather data that the assessment team already assembled. This is the single largest source of delay in the London connections journey, adding an estimated twelve to fifteen working days on average.

Stage 4: Decide

Output: Approved connection offer with costed scope. Participating stakeholders: Governance board, programme sponsor, finance team. Enabling capability: Evidence-backed decision-making. Pain point: The governance review operates on a fixed monthly cycle. Urgent decisions wait for the next scheduled board meeting regardless of complexity or commercial impact. A connection offer that is ready on the second day of the month waits twenty-eight days for governance review.

Stage 5: Publish

Output: Updated network data published for planning and regulatory purposes, including LTDS data. Participating stakeholders: Data team, regulatory reporting team. Enabling capability: Information publication. Pain point: The decide-to-publish handoff introduces errors because publication is manual and disconnected from the study data. The data team receives governance decisions through email and manually updates publication datasets. Each manual step is an opportunity for transcription error.

Stage 6: Connect

Output: Physical connection completed and commissioned. Participating stakeholders: Field engineering team, third-party contractors, customer. Enabling capability: Operational resilience governance. Pain point: As-built records are often incomplete because field teams use paper-based recording or disconnected mobile tools. Incomplete as-built data creates downstream problems for future planning and network modelling.

Stage 7: Operate

Output: Connection operating safely within network parameters. Participating stakeholders: Control room, SCADA operations, network monitoring team. Enabling capability: Operational resilience governance. Pain point: The connect-to-operate transition is where incomplete as-built records create downstream risk. If the SCADA system does not have accurate asset data, the control room cannot model the network correctly. This creates a compounding data-quality problem that affects every subsequent connection in the same network area.

Stage 8: Learn

Output: Performance data feeding back into planning and improvement. Participating stakeholders: Planning team, data quality team, performance and improvement function. Enabling capability: Data quality management. Pain point: Feedback loops are informal. Lessons from completed connections rarely reach the planning team in a structured form. When a connection took twice as long as expected, nobody systematically analyses why or updates the planning assumptions. The enterprise repeats the same estimation errors because the learn stage is not connected to the request stage.

Cross-reference to capability weaknesses

The value stream reveals that the three most significant bottlenecks (assess-to-study, decide-to-publish, connect-to-operate) all trace to capability weaknesses identified in Module 19: network planning visibility, information publication, and data quality management. This cross-reference is what makes the combination of G178 value streams and G211 capabilities more powerful than either one alone.

The cross-reference also reveals something that a systems-first analysis would miss. The three most painful bottlenecks do not all map to the same system. Planning visibility involves GIS and DMS integration. Information publication involves data governance and regulatory reporting. Data quality management involves field tools and SCADA. A portal replacement would not touch any of these root causes. The value stream, cross-referenced to capabilities, proves that the transformation is a business-architecture problem, not a single-system replacement problem.