Value Streams Inventory and Attributes

About This Inventory

The Value Streams Inventory governs the enterprise’s portfolio of value streams — the end-to-end flows through which the organization delivers value to its stakeholders. A value stream is not a process, not a capability, and not an organizational unit: it is the flow itself, viewed from the stakeholder need that triggers it through to the value that is ultimately delivered. The inventory records each Value Stream as a governed Noun Instance with a unique Semantic ID, an ordered sequence of stages, a triggering stakeholder and a receiving stakeholder, and the full set of governance attributes needed to assess its performance, its health, its cost, and its strategic importance.

What a Value Stream Is

A value stream is the end-to-end sequence of stages through which an enterprise delivers a specific form of value to a specific stakeholder. It begins with a triggering stakeholder need — a customer placing an order, a user reporting a problem, a borrower seeking credit — and it ends with the delivery of value: revenue recognized, service restored, a loan funded. A value stream is defined by its endpoints. Knowing where a value stream begins and where it ends, and who stands at each end, is what makes it a coherent, governable thing rather than an arbitrary slice of enterprise activity.

A value stream is stable in a way that the work beneath it is not. The “Order to Cash” value stream exists today, will exist five years from now, and would still exist if the enterprise replaced every system, redesigned every process, and reorganized every department that currently supports it. What changes over time is how the value stream is carried out — not the fact that the enterprise must turn orders into cash. That stability is what makes the value stream a durable unit of analysis for Enterprise Architecture and for enterprise improvement.

Operational and Development Value Streams

The framework recognizes two kinds of value stream. An operational value stream delivers value to a customer or stakeholder in the course of running the enterprise — “Order to Cash,” “Incident to Resolution,” “Application to Funded Loan.” A development value stream builds and delivers the products, systems, and solutions that the operational value streams depend on — most commonly, the value stream by which new software is conceived, built, and deployed. This inventory governs both, with operational value streams as the primary construct, since they are the flows that deliver value directly to enterprise stakeholders. Each Value Stream record carries a Value Stream Type attribute identifying which kind it is.

A Value Stream Is Composed of Stages and Enabled by Capabilities

The internal structure of a value stream is an ordered sequence of stages. A stage is a distinct phase of the end-to-end flow — “Application Intake,” “Identity Verification,” “Underwriting and Decisioning,” “Closing and Funding.” The stages are sequenced: each follows the one before it, and value is created progressively as an instance of the value stream moves from stage to stage. The stages are the parts; the value stream is the whole; the order is meaningful.

Each stage does its work by drawing upon Capabilities. The “Identity Verification” stage of a value stream draws upon an identity verification capability; the “Underwriting and Decisioning” stage draws upon underwriting, risk assessment, and policy capabilities. A value stream, therefore, is composed of an ordered sequence of stages, and is enabled by the set of Capabilities that those stages draw upon. The Capabilities are recorded in the Capabilities Inventory; the value stream’s Enabling Capabilities attribute references them. This relationship is the reciprocal of the Parent Value Streams attribute carried by the Capabilities Inventory — the same relationship, viewed from the two inventories it connects.

A Value Stream Is Not a Sequence of Capabilities

It is tempting to describe a value stream as simply a sequence of Capabilities — Capability A, then Capability B, then Capability C. This is a modeling error, and an important one to avoid. There are three reasons it is wrong.

First, a Capability has no inherent sequence. A Capability is an outcome-oriented ability — a thing the enterprise can do. It has no “before” and no “after.” Sequence is a property of the stages of a value stream, not of Capabilities. To say a value stream is a sequence of Capabilities is to attribute sequence to something that does not possess it — the same category error as confusing a Capability with a Process.

Second, the same Capability is often drawn upon at more than one stage of the same value stream. A fraud detection capability may be used at an intake stage, again at an adjudication stage, and again at a payment stage. A model that treats the value stream as a strict sequence of Capabilities cannot represent this — it would force the fraud detection capability into a single position. A model built on stages handles it naturally: several stages each draw upon the same Capability.

Third, a single stage is usually enabled by several Capabilities at once, not one. An underwriting stage draws upon underwriting, risk assessment, and policy capabilities simultaneously. The relationship between stages and Capabilities is many-to-many, not one-to-one. The correct statement of the model is therefore precise and worth stating plainly: a Value Stream is composed of an ordered sequence of stages, and is enabled by the set of Capabilities that those stages draw upon.

Value Stream Stages in This Inventory

In this version of the Value Streams Inventory, the stages of a value stream are captured as an ordered descriptive attribute of the Value Stream — the Value Stream Stages attribute — and the Capabilities that enable the value stream are related to the value stream as a whole through the Enabling Capabilities attribute. This is sufficient for most analysis: it records the structure of each value stream and the Capabilities it depends on.

Some enterprises, however, need more. They need to know precisely which Capabilities enable which individual stage — so that they can perform pinpoint impact analysis when a Capability degrades, diagnose which specific stage is constrained, or make investment decisions at the level of a single stage. Those enterprises will choose to break value stream stages out into a separate inventory, in which each stage becomes a governed entity in its own right, with its own identifier, its own attributes, and Capabilities related directly to it. In that arrangement the value-stream-level relationship to Capabilities still exists — it simply becomes derived, computed as the union of the Capabilities that enable each of the value stream’s stages. This is a deliberate trade-off: the stages-as-attribute approach in this document is simpler and sufficient for most needs, while a dedicated stages inventory is more granular and supports finer analysis at the cost of more to build and govern. Whether to make that move is a decision each enterprise makes according to its own needs. The IF4IT recognizes a Value Stream Stages Inventory as an anticipated Noun Type in the Enterprise Inventory Management taxonomy and may publish a companion Value Stream Stages Inventory and Attributes document to standardize the practice.

Document Organization

This document is organized into attribute categories, each forming its own subsection. Each subsection contains one part with an attribute table. The attribute table has three columns: Attribute Name, Maturity, and Description and Notes. The Attribute Name column uses bold text in Title Case — multi-value attributes are annotated [Multi-Value], and the ordered stage attribute is annotated [Ordered]. The Maturity column contains one of three values: Crawl (minimum viable attributes without which the inventory cannot function as a governance instrument), Walk (attributes that add the rigor needed for assessment and analysis), or Run (attributes that enable advanced analytics and cross-inventory derivation). The Description and Notes column is structured into labeled subsections: Description, Benefit(s), Source, Examples, and Notes. The attributes shown represent the IF4IT’s current best thinking for governing a Value Streams Inventory — a suggested baseline, not a complete enumeration. No attribute in this document is mandatory.

General Governance Principles

For the general inventory governance principles that apply to this inventory — including semantic identifier conventions, data quality standards, owner accountability, lifecycle management, AI-assisted population, and the connection to the Enterprise Model — refer to the IF4IT Enterprise Inventory Management Best Practices document.

Customization

Every attribute in this document is a recommendation — not a mandate. Enterprises are explicitly encouraged to add attributes specific to their context, rename attributes to match their existing vocabulary, adjust valid value sets to match their organizational standards, and sequence Crawl/Walk/Run adoption differently based on their priorities. Two things are discouraged: removing foundational Crawl attributes entirely, since value stream governance consistently fails without them; and abandoning the Semantic ID convention, since it is the connective tissue that makes cross-inventory traversal and AI-assisted analysis possible in the Enterprise Model.

The Enterprise Model

This inventory is a component of the Enterprise Model: every record in it, and every attribute of every record, contributes to the enterprise intelligence platform that connects every IT Management discipline through the typed relationships of the Enterprise Ontology. The Value Stream is the Noun Type that represents the delivery of value end to end; it relates to Capabilities, Applications, Processes, Organizational Units, Vendors, Data and Information Types, and Regulatory Obligations. Value-stream-anchored cross-inventory queries are the primary path through which the Enterprise Model answers the question that matters most to enterprise stakeholders: how is value actually delivered, and where is its delivery constrained?

Suggested Baseline

The content of this document — including all attribute categories, attribute definitions, maturity designations, governance guidance, and structural recommendations — represents the IF4IT’s current best thinking for building and governing a Value Streams Inventory. Everything presented here is a suggested baseline, not a mandate. No attribute is required. No category is mandatory. No structural pattern is enforced. Enterprises are explicitly encouraged to adapt, extend, and reshape everything in this document to match their specific context, vocabulary, regulatory environment, industry, and organizational maturity. Practitioners are the experts in their own organizations — use this document as a starting point, not a ceiling.