4.3 Value Streams, Value Stream Mapping, and Capability Cross-Mapping

4.3 Value Streams, Value Stream Mapping, and Capability Cross-Mapping

In the TOGAF Standard, value-driven architecture is realized through the formal modeling of Value Streams and their explicit cross-mapping to Business Capabilities. As documented in the TOGAF Series Guide: Value Streams, an enterprise cannot understand the true value of its internal capabilities without analyzing how those capabilities combine to serve external customers. While capabilities define what the business does, value streams define why those abilities matter by demonstrating how they generate tangible business value from the perspective of an external stakeholder.

---

The Strategic Role of Value Streams in Enterprise Architecture

A Value Stream is defined by The Open Group as an end-to-end collection of value-adding activities that creates an overall result for a customer, stakeholder, or end user. Value streams provide a stakeholder-centric, "outside-in" perspective on the enterprise, anchoring architectural design directly to value realization.

Historically, enterprise architectures were designed primarily along functional or technical boundaries—optimizing sales systems, warehousing databases, or accounting mainframes in isolation. This functional optimization frequently produced severe cross-functional friction: while each individual department met its internal performance metrics, the customer experienced sluggish service, dropped handoffs, and disjointed communication. Value streams solve this challenge by tracing horizontal value delivery across all departmental and functional silos.

---

Anatomy of a Value Stream: Triggers, Stages, Value Items, and Outcomes

A value stream is structured with rigorous architectural components:

1. Triggering Event: The initiating condition or request originated by a stakeholder that activates the value stream (e.g., Customer submits a home mortgage application or Fleet manager detects vehicle engine failure).
2. Value Stages: The discrete, sequential steps through which value progressively accumulates. A typical value stream consists of 4 to 8 high-level stages. Each stage represents a meaningful progression toward the end outcome.
3. Participating Stakeholders: The internal and external personas who engage with or contribute to the value stream at specific stages (e.g., Prospective Homebuyer, Loan Officer, Underwriter, Escrow Agent).
4. Value Items (Stage Outputs): The incremental value produced upon exiting a specific stage (e.g., Validated Applicant Dossier, Credit Risk Determination, Disbursed Loan Proceeds). A value item is not merely a work artifact; it is an incremental asset of value to the recipient.
5. Final Value Proposition: The overarching outcome delivered to the initiating stakeholder at the conclusion of the value stream (e.g., Secured Home Ownership Financing).

[Trigger: Home Purchase Contract Signed]
     │
     ▼
┌───────────────┐     ┌───────────────┐     ┌───────────────┐     ┌───────────────┐
│ Apply for     │ ──> │ Assess Credit │ ──> │ Underwrite    │ ──> │ Settle &      │
│ Financing     │     │ & Collateral  │     │ Commitment    │     │ Disburse      │
└───────────────┘     └───────────────┘     └───────────────┘     └───────────────┘
     │                     │                     │                     │
 [Pre-Approval]      [Risk Score]         [Binding Contract]   [Home Ownership Funds]
                                                                       │
                                                                       ▼
                                                             [Final Value Proposition]

---

Value Streams versus Business Processes: Outside-In versus Inside-Out

A cornerstone topic tested on the OGEA-103 examination is distinguishing between Value Streams and Business Processes. While both involve activities, they operate at different levels of abstraction, serve different audiences, and utilize different modeling conventions:

---

The Technique of Value Stream Mapping

When developing value streams during Phase B, enterprise architects execute a systematic four-step procedure:

1. Identify the Core Value Streams: Review corporate business strategies, product portfolios, and Phase A business scenarios to identify the primary value journeys (e.g., Concept-to-Market, Lead-to-Quote, Order-to-Cash, Incident-to-Resolution).
2. Define the Value Stages: Decompose each value stream into sequential stages. Each stage name should be expressed using a verb-noun or active phrasing reflecting progress (e.g., Select Product, Submit Order, Fulfill Items, Settle Account).
3. Specify Entry Criteria, Exit Criteria, and Value Items: For each stage, articulate what condition must be met to enter, what incremental value item is created, and what criteria determine successful completion.
4. Identify Primary Stakeholders: Document the external customer receiving the final value proposition and the internal organizational personas supporting each stage.

---

Capability Cross-Mapping: Connecting Outcomes to Enterprise Capabilities

A value stream describes the journey of value creation, but it cannot deliver value on its own. Enterprise capabilities are the operational engines that empower each stage of the value stream. The technique of Capability Cross-Mapping links value stream stages to the business capabilities required to execute them.

The Cross-Mapping Matrix

Architects construct a two-dimensional matrix where columns represent sequential Value Stages and rows represent Business Capabilities:

In this matrix:

• Core: The capability is directly responsible for creating the stage's primary value item.
• Supporting: The capability provides necessary auxiliary data, infrastructure, or administrative assistance.

---

Diagnostic Analysis: Identifying Value Bottlenecks and Investment Targets

The true power of capability cross-mapping lies in its diagnostic utility. When an enterprise suffers from poor customer satisfaction or degraded business outcomes, the root cause is rarely the value stream structure itself; rather, it is a deficient underlying capability.

Tracing Bottlenecks: A Diagnostic Scenario

Suppose a global e-commerce enterprise observes that customer cart abandonment spikes and delivery satisfaction drops during the holiday season. The architect overlays the Capability Assessment Heat Map (from Section 4.2) onto the Value Stream Cross-Mapping Matrix:

1. Value Stream Stage 2: Inventory Reservation relies on the business capability Inventory Management.
2. In the capability assessment, Inventory Management was heat-mapped as RED due to batch-mode inventory databases that synchronize only once every six hours (Technology: Low; Information: Low).
3. Architectural Insight: Because Inventory Management cannot calculate stock availability in real time, Stage 2 frequently confirms orders for out-of-stock items, causing downstream fulfillment cancellations in Stage 4.
4. Target Architectural Recommendation: Rather than attempting to redesign the customer-facing mobile application, the architect targets Phase C data architecture (real-time distributed event streaming) and Phase C application architecture (event-driven inventory microservice) to resolve the red capability directly.

This auditable chain of causation—connecting customer dissatisfaction at a value stage directly to technical debt within an underlying capability—demonstrates the strategic value of enterprise architecture to corporate leadership.

---

Practitioner Exam Traps: Avoiding Process-Modeling Habits

• The Conditional Branching Anti-Pattern: Inserting decision diamonds (e.g., "Credit Score > 700? Yes/No") into a value stream diagram. Value streams represent pure, end-to-end value realization chains. Decision logic, exception routing, and conditional loops belong strictly in business process models.
• The One-to-One Mapping Fallacy: Assuming that each capability serves only one value stream. In reality, a mature capability (such as Customer Identity Verification or Payment Settlement) is reused across dozens of distinct value streams across the enterprise.
• Confusing Value Propositions with Work Deliverables: Identifying an internal report, an invoice PDF, or a database record as a value proposition. A value proposition is the tangible benefit delivered to a stakeholder (e.g., Reliable Commercial Transportation or Seamless Digital Checkout), whereas work products are mere operational artifacts.