Business Capabilities & Value Streams

4.1 Purpose and decisions supported

A capability model describes what an institution needs to be able to do. A value stream explains how those abilities combine to produce a result for a stakeholder. Together, they connect the purpose and outcomes of Section 03 to responsibilities and investment decisions. They do not prescribe an application, department structure or technology stack.

This section supports decisions about missing abilities, duplicated responsibility, fragile handoffs and priorities for improvement. The first question is not which platform to buy. It is whether the institution can reliably perform the work required by its mandate, including exceptions, correction and continuity.

The chapter proposes a modelling method and a fictional worked example. No real institution has adopted the maps, accepted ownership or passed the checks described here. Adoption requires institutional review; publication remains an editorial draft.

4.2 Separate the concepts before drawing

Different concepts answer different questions. Mixing them produces attractive diagrams that cannot guide a decision. A department may exercise several capabilities, a capability may support several services, and an application may implement parts of many capabilities.

The terms follow a distinction also present in published business architecture material from OMG and TM Forum: capabilities describe institutional abilities, while value streams connect activities and capabilities to stakeholder value. ZAF uses its own scoped examples and identifiers; it does not claim certification or conformance to those frameworks.

A capability called “PostgreSQL” or “Finance Department” fails this distinction. PostgreSQL is a technology; Finance is an organizational unit. “Financial authorization” describes an ability that can remain meaningful when either the technology or organization changes.

4.3 Establish the modelling boundary and inputs

Begin with the mandate in Section 01, the context and concern registers in Section 02, and the outcome register and measurement contracts in Section 03. Record the versions actually used. An unapproved proposed outcome is an input for discussion, not authority to commit the institution.

The fictional institution has headquarters, six regional offices and a small engineering team. The assessment remains limited to one operational request type and one candidate pilot office. Submission, departmental review, finance approval, fulfilment and reconciliation form the assumed journey to investigate. No timing, volume or maturity baseline has been measured.

Define the trigger, beneficiary, terminal states, participating actors, excluded request types and external dependencies before decomposition. The map should cover the selected service sufficiently to expose important handoffs; it must not imply that a pilot view is a complete enterprise capability model.

All CAP, VS, STG, H and DEC identifiers below belong to ZAF-I-04. Cross-section outcome references retain their full prefix, for example ZAF-I-03-OUT-01. Reusing a number in another chapter does not make it the same record.

4.4 Build and name the capability model

Name capabilities in stable business language, usually a noun phrase expressing an ability: request intake, decision management, fulfilment coordination. Define each by purpose, scope and observable ability rather than a list of screens or job titles.

Start broad enough to compare responsibility, then decompose only where ownership, requirements or investment decisions require it. A parent capability groups related abilities; its children are more specific abilities, not arbitrary phases or a list of purchased products.

For a candidate parent “Operational request management,” useful children might include intake, decision control and fulfilment coordination. A separate report describing the same ability is not automatically another capability. Use a shared glossary to resolve synonyms, overlaps and genuinely different meanings.

The proposed capability map below groups six service abilities and two supporting abilities. Grouping does not establish departments, software deployment boundaries or a microservices design.

A capability may be performed manually, by a partner, by software or by a combination. Record the realization separately. The capability description should survive a change from a spreadsheet to an application without needing to be renamed after the new tool.

4.5 Create a capability register with explicit ownership

A capability owner is accountable for the ability, its intended performance and improvement decisions. Process participants execute work; data owners govern meaning and permitted use; technical owners operate supporting systems. These are related responsibilities, not interchangeable titles.

These are proposed roles, not confirmed appointments. CAP-02 does not give a department the power to override financial authorization. Its record should distinguish the accountable coordination role from the separate authorities whose decisions are required.

If accountability is disputed, record the gap and its escalation owner. Do not assign all unresolved business capabilities to IT. Section 05 will develop the operating model; Section 06 will examine domain ownership in greater depth.

4.6 Define the value stream as a stakeholder progression

ZAF-I-04-VS-01 is “Obtain an accountable operational request outcome.” Its beneficiary is the requester of the selected service. Its trigger is an intention to submit a request; its endings include fulfilled, rejected or withdrawn work with an authoritative state. Fulfilment is therefore one possible outcome, not the definition of every legitimate completion.

Describe stages by the value established at their exit. A stage is more than an activity label. “Send email” names an action; “Request acknowledged” describes a useful condition that the next participant and requester can rely on.

This is a stakeholder value progression, not a detailed executable workflow. A refusal may terminate at STG-02 with its own reporting obligations; it does not need to be forced through fulfilment. Reporting and status communication can occur throughout the journey, not only at its last stage.

4.7 Map capabilities to stages and outcomes

A capability can support several stages. A stage usually needs several capabilities, including people, information and operating practices. A mapping entry means there is a contribution to examine; it does not prove that the capability is effective.

All abbreviated OUT references in this table are scoped to ZAF-I-03. The table expresses proposed dependencies. Use its links to find gaps: if no capability can establish receipt, a polished requester interface cannot establish institutional acceptance.

Maintain the mapping as a register as well as a diagram. Each material relationship should state why it exists, which evidence supports it and what observation could refute the proposed contribution. Do not add every capability to every stage simply to make the map look comprehensive.

4.8 Describe the handoff contract

A capability map alone does not explain how responsibility changes hands. At every significant boundary, define the receiving responsibility, information meaning, acceptance condition and exception route. The transport may be manual or technical; an email delivered is not proof that work was accepted.

For each handoff, record who acknowledges acceptance, what happens if acknowledgement is missing, and how a disputed state is resolved. The institution sets response and escalation expectations after evidence review; this draft invents no deadline or service commitment.

These contracts describe business meaning. Book II will later determine suitable integration and consistency mechanisms. They do not imply that every handoff must use an API, event bus or distributed transaction.

4.9 Model exceptions and assisted paths

The happy path is insufficient. Test correction before approval, amendment after approval, rejection, requester withdrawal, incomplete fulfilment, duplicate submission and loss of connectivity. Ask whether each path preserves authority and understandable state.

A local draft may resume after an interruption without becoming institutionally received. If the user switches to an assisted channel, define how the institution identifies the same request and avoids conflicting records. Do not assume staff can solve the problem by keeping an unofficial spreadsheet.

After approval, correction may require a new version and decision. Preserve the original approved record. Whether the old approval remains valid for any part of the work is a policy and service decision, not something an application developer should infer.

For rejection or challenge, record the authorized next route and disclosure boundary. There is no universal claim here about legal entitlement. The policy owner confirms what applies to this institution and request type. Link unresolved paths back to the concern register rather than hiding them in diagram footnotes.

4.10 Assess ability using evidence, not decorative scores

A capability assessment should distinguish importance, demonstrated ability, operating fragility and evidence confidence. A critical capability may have little evidence; a well-documented one may still deliver poor outcomes. Combining these dimensions into a single red/amber/green score can obscure the decision.

In the example, CAP-04 has unverified reporting definitions. That supports “definition unresolved,” not a fabricated maturity level. CAP-07 remains “not demonstrated” until the relevant exercise has been performed; a backup configuration screenshot is not a recovery result.

If an institution adopts scoring later, document scale definitions, assessors, evidence and treatment of unknowns. Never translate missing evidence into a confident low score or imply an assessment has happened because the template contains colored cells.

4.11 Compare improvement options and sequence dependencies

Use the capability-stage map to identify the smallest change that could improve an intended outcome. Compare process clarification, staffing or training, information agreements and technical changes. A platform purchase is only one candidate intervention.

These are alternatives or dependent changes, not an approved delivery backlog. A technical implementation of version-bound approval depends on an agreed authority rule. A dashboard depends on a reporting definition. Sequence decisions before tools that encode unresolved meaning.

Record proposed decisions ZAF-I-04-DEC-01 through DEC-04 against these four rows respectively. Each needs an owner, alternatives, rationale, evidence gaps and revisit condition. Their illustrative presence is not evidence of institutional approval.

4.12 Translate into engineering without equating models

A business capability is not automatically a bounded context, microservice, repository or team. One software component may support several capabilities; one capability may require multiple systems and manual work. Decomposition requires further analysis of meaning, authority, consistency and change.

For example, CAP-02 and CAP-03 could be supported by one application or separate services. This chapter does not settle that choice. Ask which invariants must hold, how decisions are versioned, what failures are tolerable and who can operate the result before drawing deployment boundaries.

Likewise, shared status communication does not automatically justify an enterprise-wide platform. Compare repeated needs, semantic differences, governance and operating cost. Standardize common contracts where useful; preserve legitimate domain differences where a shared model would distort authority or service meaning.

The handoff to Book II includes capability definitions, ownership questions, information contracts, value-stage contributions and verification scenarios. Infrastructure and Kubernetes adoption remain downstream choices, conditional on actual requirements.

4.13 Validate with participants and control changes

Walk one ordinary case and several material exceptions through the map with the requester representative, service owner, decision authority, information owner and operations representative. Ask each participant to explain the state they receive and the responsibility they accept. A meeting held is not a validated model.

Record conflicting interpretations, missing capabilities and unsupported transitions. Preserve disagreement rather than resolving it through diagram aesthetics. The sponsor accepts the scoped model only after the required owners have reviewed their responsibilities and material unresolved issues are explicitly handled.

Version the capability register and stage map together with their dependencies. A policy change, new request type, organizational reassignment or altered reporting definition can invalidate a mapping even when the software is unchanged.

Keep identifiers stable when names change without changing meaning. When scope splits or merges, retain predecessor references and explain migration of ownership and evidence. Do not recycle a retired ID for an unrelated capability.

4.14 Expected artifacts and review gate

The seven artifacts below are proposed templates for adopting institutions, not completed client deliverables. Record actual authors, owners, versions, sources, limitations and decisions when used.

Review the model for institutional use separately from accepting a technical design. An agreed capability map does not authorize production access, procurement or deployment. Editorial acceptance of this ZAF section is also separate; it remains a working draft.

4.15 Verification checklist and next section

• Distinguish capabilities, outcomes, processes, services, roles and applications.
• State the selected service boundary and avoid implying enterprise completeness.
• Define each capability by a stable ability, not a technology product.
• Record accountable ownership separately from participation and technical support.
• Give value stages observable exit conditions and legitimate alternative endings.
• Map material capability contributions to the Section 03 outcomes.
• Define information and authority acceptance at important handoffs.
• Exercise interruption, correction, rejection and duplicate-submission scenarios.
• Preserve unknowns and evidence confidence in capability assessments.
• Sequence semantic and ownership decisions before implementing their technical form.
• Validate interpretations with actual participants and retain unresolved disagreement.
• Keep identifiers, source versions and revisions traceable.

Section 05, Institutional Operating Model, will explain how these responsibilities are organized and sustained: decision rights, service ownership, delivery and operational arrangements, escalation and capacity. It should use the capability and handoff records rather than deriving institutional responsibility from a technology diagram.

Reading references

• OMG · Business Architecture Overview
• TM Forum · Value Stream Framework