5. IT4IT Value Streams

id view 08e511c1 fe15 4c7d b4a8 e07af789c257
Figure 20. IT4IT Value Streams Model

The IT4IT Value Streams, as shown in Figure 20, are integrated streams of capabilities within the Architecture Reference Model. They support a holistic lifecycle approach for the planning, creation, delivery, modification, operation, support, and retirement of a Digital Product, combining all of the necessary capabilities to deliver value and support to the dependent parts of the Digital Product lifecycle.

There are seven value streams defined:

Despite being highly integrated, value creation with regards to Digital Products requires a specific set of capabilities, functions, processes, and data per value stream. In the following sections therefore, for every value stream, the delivered value, main stakeholder(s), a set of scenarios and value stream stages are described in more detail. Value streams interact or depend on other value streams to support the Digital Product throughout the entire lifecycle.

5.1. Evaluate Value Stream

id aa99dfb9 ff9d 4e51 88d4 fcae6109387e
Figure 21. Evaluate Value Stream Model

Overview

The value stream “Evaluate”, as shown in Figure 21, contributes to the business strategy and portfolio planning activities. It provides a blueprint for optimizing products, services, and investment Portfolio Management. This value stream is focused on the continuous assessment and evaluation of the entire Digital Product Portfolio to optimize co-creation and alignment of business and technology Strategic Objectives.

Many organizations have portfolio processes and solutions in place but suffer from the following limitations:

  • Poor data quality and consistency

  • No holistic portfolio view across the enterprise

  • Inconsistent Portfolio, Service, and Product Management

  • Poor tracking and correlation of the product lifecycle

Organizations need accurate and point-in-time information to understand the inter-relationships and inter-dependencies required to truly orchestrate all the moving parts of Digital Products in ways that can help support business objectives and goals.

The Evaluate value stream provides holistic views of Product Portfolio activities. These views offer an understanding of the inter-relationships among many sub-domains, including Portfolio Management, Enterprise Architecture, Application Management, Information Management, Operations Management, and Information Security Management.

The Evaluate value stream is triggered by a portfolio planning cycle. Portfolio planning can be done in weekly, monthly, or annual cycles.

The overall funding of a Digital Product consists of portfolio epic-based funding (often referred to as Grow the Business (GtB), or discretionary) and product specific investments (often referred to as Run the Business (RtB), or non-discretionary). The product-specific Scope Agreement is defined in the Explore value stream and aligned with the prioritized portfolio level Scope Agreements. This funding methodology enables decentralized decision-making by the Product team.

Key Stakeholder

The primary value stream stakeholder of the Evaluate value stream is the Product Portfolio Manager. The Product Portfolio Manager is responsible for ensuring consistent services and portfolio balance through rationalization and sound investments. The Product Portfolio Manager works closely with Strategists, Business Relationship Managers, Architects, and Technologists to align with strategic drivers, consumer demand, and policy standards. They must work together to optimize the portfolio through well-defined control points, data objects, and governance.

Value

The outcome of the Evaluate value stream is a portfolio investment plan with funding and resources to conduct product exploration activities and refine the plan. Here, resources are referred as both IT-related resources such as IT infrastructure, database, software packages and non-IT-related resources such as HR, etc. This value stream delivers an optimized Product Portfolio with secure and quality Digital Products that are consumer friendly and cost effective, accomplished through continuous portfolio improvement and refinement.

Cross-Value Stream Dependencies

The Evaluate value stream depends on:

  • All value streams:

    • To continually bring in ideas, improvements, and demand to the Evaluate value stream

    • To capture data that ensures the quality of the Digital Product will meet the requirements

      Quality is an aspect of each task within each value stream. Quality data may also be used to help analyze the Portfolio Backlog.

Value streams that depend on the Evaluate value stream are:

  • All value streams:

    • Improvements start with drivers that are expected to arise from all seven value streams

      All value streams will capture data to ensure the quality of the Digital Product will meet the requirements.

  • Explore:

    • Requires qualified Portfolio Backlog Items that will be used to realize the Product Design, either a new or next Product Design version, and the necessary changes to Enterprise Architecture and Strategic Themes

The Evaluate value stream, as shown in Figure 22, is the more comprehensive view for included scenarios and detailed value stream stages for the value stream, and will be described in detail in the following sections.

id 428904d88da44fda89a682b3dc229fa0
Figure 22. Evaluate Value Stream Details Model

In the following sections we document the scenarios and stages of the Evaluate value stream:

5.1.1. Evaluate Scenarios

The Evaluate value stream is applicable for the following four scenarios:

Consider a New Digital Product Scenario

The trigger for this scenario is a business requirement for a new Digital Product. The outcome is a Scope Agreement and resource allocation focused on Portfolio Backlog Items and Strategic Objectives, indicating there is a strong business case for a new Digital Product. New Digital Products are often considered when a new technology is introduced in the marketplace that may solve a business problem; when technology becomes obsolete and needs to be modernized; or when a new business niche is desired.

Perform Digital Product Governance Scenario

The trigger for this scenario is the Change Management of Digital Products. The outcome is a secure, quality, consumer-friendly, cost-effective Digital Product that aligns with Strategic Objectives, Architecture Principles, technology standards, and financial and policy constraints. Governance ensures the traceability of the Digital Product lifecycle information from Strategy to Development and into Operations.

Rationalize the Product Portfolio Scenario

The trigger for this scenario is a business requirement to rationalize and balance the Digital Product Portfolio. The outcome is a Scope Agreement and resource allocation focused on Portfolio Backlog Items for the portfolio rationalization types: Retain, Replace, Re-Build, Retire. Based on the rationalization type a Digital Product is left as-is, substituted, modernized, or decommissioned. Rationalization is imperative to maintain a healthy and balanced portfolio by minimizing Digital Product technical debt and capability redundancy.

Plan Product Portfolio Investments Scenario

The trigger for this scenario is a portfolio planning increment. A portfolio planning cycle can be in weekly, monthly, or annual increments. The Product Portfolio provides information about the health of existing Digital Products and new product strategy. This information supports decisions for investing or reinvesting in products and services. The outcome of a portfolio planning cycle is a Scope Agreement that provides the required scope and funding for portfolio-related concerns. Digital Product-specific concerns are delegated to a Product Manager and Digital Product stakeholders for refinement in the Explore value stream. Big strategic initiatives and cross-product content are funded and governed at the portfolio level in the Evaluate value stream; while smaller product investments are better managed at the product level in the Explore value stream.

5.1.2. Gather Influencers Stage

The purpose of the value stream stage “Gather Influencers” is to bring together inputs for a planning cycle. Typical inputs include: consumer demand, improvement ideas, new technology opportunities, technology lifecycle events (e.g., end-of-life), and any known policy (legal and regulatory demands) or budget constraints for the Digital Product Portfolio. Other inputs may include an internal and/or external environmental scan to identify strengths, weaknesses, opportunities, and threats. Discussion with the business is centered on Digital Product value delivery for consumers and corresponding policy requirements. The deliverable for this value stream stage is new or updated Strategic Themes and/or Strategic Objectives.

An important part of this stage is to manage the strategic roadmap of the Digital Enterprise. Throughout the IT4IT Value Streams, this roadmap will be refined from the Strategic intent to the Architecture Roadmap to the Digital Product Roadmap to the Release Roadmap.

Table 1. Gather Influencers Value Stream Stage

Entrance Criteria:

  • Consumer demand

  • Improvement ideas

Exit Criteria:

  • Defined vision

  • Strategic Themes

  • Strategic Objectives

Value Item:

  • Technology investment plan input

Activities:

  • Shall co-create vision and strategic roadmap (Business + Technology)

  • Should consider existing strategic roadmap, consumer demand, improvement ideas, and budget constraints

  • Should review standards and policies for compliance gaps and new requirements

  • May conduct an environmental scan:

    • Internal analysis to assess strengths and weaknesses

    • External analysis of the market and competitors (political, environmental, social, technical, economic, and legal) to assess opportunities and threats

  • Shall define Strategic Themes and Strategic Objectives

Examples of Participating Stakeholders:

  • Business Analyst

  • Business Stakeholder

  • Chief Security Officer

  • Compliance Manager

  • Consumer

  • Enterprise Architect

  • External Stakeholder

  • Product Manager

  • Vendor Manager

5.1.3. Identify Gaps Stage

The purpose of the value stream stage “Identify Gaps” is to evaluate the current state and identify opportunities that align to the vision, Strategic Themes, and Strategic Objectives. Inputs for the current state evaluation should include the consideration of recent consumer survey information and capability assessments. Gaps are identified by comparing the current state to the desired future state, and opportunities are derived. The deliverable for this value stream stage is a list of gaps and opportunities expressed in proposed Scope Agreements, with any related Portfolio Backlog Items.

Table 2. Identify Gaps Value Stream Stage

Entrance Criteria:

  • Vision

  • Strategic Themes

  • Strategic Objectives

Exit Criteria:

  • Defined list of gaps and opportunities

  • Proposed Scope Agreements with related Portfolio Backlog Items

Value Item:

  • Consumer satisfaction and efficient/Agile operations

Activities:

  • Shall assess the current state of the Product Portfolio

  • Should consider consumer survey information

  • Should research consumer needs (consumer journey, business model, capabilities)

  • Should perform a capability assessment

  • Shall identify gaps in the Product Portfolio

  • May identify opportunities for improvement and Product Portfolio rationalization

  • Shall develop proposed Scope Agreements with identified opportunities and related backlog items

Examples of Participating Stakeholders:

  • Business Analyst

  • Business Stakeholder

  • Chief Security Officer

  • Data Protection Officer

  • Enterprise Architect

  • Product Architect

  • Product Manager

  • Product Portfolio Manager

  • Risk Analyst

  • Security Architect

5.1.4. Propose Investments Stage

The purpose of the value stream stage “Propose Investments” is to prioritize a list of opportunities and associated Scope Agreements. The prioritization should be based on a scoring method that considers business value, risk, costs, time, and resource availability. Scope Agreements are evaluated to determine if there is already a solution in the Product Portfolio that can be used or modified to satisfy the business need. If it is determined that there is not an existing solution and the new demand is in alignment with the digital strategy, the Scope Agreement is assessed against other work in the Portfolio Backlog and prioritized accordingly. The prioritization criteria should also consider factors like urgency and the impact of opportunities. The deliverable for this value stream stage is updated Scope Agreements with clarifications discovered during a prioritization of opportunities.

Table 3. Propose Investments Value Stream Stage

Entrance Criteria:

  • List of gaps and opportunities and proposed Scope Agreements with related Portfolio Backlog Items

Exit Criteria:

  • Updated list of prioritized opportunities and associated Scope Agreements

Value Item:

  • Portfolio decisions based on business priorities

Activities:

  • Shall consider business value, risk, costs, time, and resource availability for opportunities

  • May complete a what-if analysis

  • May consolidate demand and ideas

  • Shall classify investment/divestment strategic themes (try something new, invest, divest, continue to support)

  • Should analyze priority, urgency, and impact of opportunities

Examples of Participating Stakeholders:

  • Enterprise Architect

  • Product Manager

  • Product Portfolio Manager

  • Security Architect

  • Vendor Manager

5.1.5. Define Backlog Mandates Stage

The purpose of the value stream stage “Define Backlog Mandates” is to determine if there are any mandates or directives that will impact the Product Portfolio, and to ensure mandates are clearly defined in backlog items and related in Scope Agreements. This should include a review of the existing portfolio and managed service provider agreements. Portfolio rationalization to balance the portfolio should be completed regularly and may generate backlog items that are bundled into Scope Agreements. Upon approval to proceed on a Scope Agreement, initial funding is allocated to the Explore value stream to identify concerns specific to a Digital Product and determine feasibility. The deliverables for this value stream stage are refined Scope Agreements to reflect mandates and defined Architecture Roadmap Items.

Table 4. Define Backlog Mandates Value Stream Stage

Entrance Criteria:

  • List of prioritized opportunities and associated Scope Agreements

Exit Criteria:

  • Refined Scope Agreements with initial funding and defined Architecture Roadmap Items

Value Item:

  • The right digital technology for the business

Activities:

  • Should consider existing portfolio and managed service provider agreements

  • Shall further define Scope Agreements

  • Should develop the Architecture Roadmap

  • Should rationalize and balance the Product Portfolio (Retain, Replace, Re-Build, Retire)

  • May create Architecture Blueprints

  • May identify architecture enablers (reference architectures, building blocks, templates, patterns)

Examples of Participating Stakeholders:

  • Business Analyst

  • Business Stakeholder

  • Chief Security Officer

  • Compliance Manager

  • Data Protection Officer

  • Enterprise Architect

  • External Stakeholder

  • Product Manager

  • Product Portfolio Manager

5.1.6. Ensure Governance Stage

The purpose of the value stream stage “Ensure Governance” is to provide methods that guide consistent and compliant Digital Product deliverables. This should include the use of reference architectures, building blocks, patterns, and templates. The deliverables for this value stream stage are guardrails, integrated repositories, enablers, audit definitions, and Architecture Principles.

Table 5. Ensure Governance Value Stream Stage

Entrance Criteria:

  • Scope Agreements with initial funding and Architecture Roadmap Items

Exit Criteria:

  • Defined guardrails, integrated repositories, enablers, audit definitions, and Architecture Principles

Value Item:

  • Secure, high quality, cost effective, consumer-friendly Digital Product

Activities:

  • Should develop guardrails for adherence to technology standards and policies

  • Should create repositories that ensure the traceability of the Digital Product artifacts from Strategy to Development and into Operations to Retirement

  • Should confirm the use of enablers (reference architectures, building blocks, patterns, templates)

Examples of Participating Stakeholders:

  • Business Analyst

  • Business Stakeholder

  • Chief Security Officer

  • Enterprise Architect

  • External Stakeholder

  • Product Manager

  • Product Portfolio Manager

  • Vendor Manager

5.2. Explore Value Stream

id f5fbee88 75fe 4998 bb26 432035ae4d5e
Figure 23. Explore Value Stream Model

Overview

The value stream “Explore”, as shown in Figure 23, is performed on the Scope Agreements developed in the Evaluate value stream. It ensures that all planned and accepted Portfolio Backlog Items are further detailed, budgeted, and sourced for Digital Products. This value stream continuously explores new features and/or future directions of a Digital Product aligned with strategic direction and business needs. It ensures that the Product Design evolves to facilitate innovation and optimize business outcomes.

Digital Product Portfolio Backlog Items for investigating a new idea, optimizing existing ideas, or retirement may be resolved by different funding, management, reporting, and contractual obligations for various types of consumers. Differences in budgeting, technology, contracts, business domains, security, or organizational/management structures will influence the portfolios required for an organization.

The Explore value stream is intended to be executed in quick cycles to validate release iterations. The Portfolio Backlog Items should include the generation of a proof-of-concept, conceptual service, or Minimum Viable Product (MVP) with the high-level architectural attributes and activities to begin gathering requirements for the build stage.

The Explore value stream stage ensures that the allocation of resources, budget, and phases for Digital Product releases remain aligned with agreed, planned, and accepted Portfolio Backlog Items and Architecture Blueprints. The primary stakeholder of this value stream is a Product Manager who approves Scope Agreements and release plans for Digital Products.

This value stream can be triggered by a changed Scope Agreement.

Key Stakeholder

The primary value stream stakeholder of the Explore value stream is the Product Manager. The Product Manager is responsible for the development and success of a Digital Product for an organization. Product Managers own the business strategy, manage the requirements, and launch features for a product. The Product Manager coordinates the work done by other functions, including: Business Relationship Manager, Architect, Strategist, Technologist, Business Owners, and DevSecOps.

Value

The outcome of the Explore value stream is an accepted and planned Product Backlog with a detailed Scope Agreement, Release Roadmap, and resource allocation. During the Explore stages, Scope Agreements are refined to include product specific details. The value is a Digital Product roadmap with allocated resources.

Cross-Value Stream Dependencies

The Explore value stream depends on:

  • Evaluate:

    • Delivers qualified, as accepted and planned, Portfolio Backlog Items that will be used to realize the Digital Product and refine the Architecture Blueprint(s) (all product lifecycle stages, scaling and maturing the product, as well as retracting/retirement) and necessary changes to the Enterprise Architecture and Strategic Themes according to the Architecture Roadmap Items

  • Integrate:

    • Provides information on the progress of the Scope Agreement during execution back to the Explore value stream to enable governance on progress and planned dependencies with other Scope Agreements

    • If an agreed Scope Agreement cannot be met, the Explore value stream is responsible for changing the Scope Agreement; e.g., change the covered Portfolio Backlog Items (to include more or go for less), change the time or budget, or change the sourcing party

Value streams that depend on the Explore value stream are:

  • Evaluate:

    • Improvements start with drivers, that are expected to arise from all seven value streams

      All value streams will capture data to ensure that the quality of the Digital Product will meet the requirements

  • Integrate:

    • Will receive an approved Scope Agreement together with an agreed set of Product Backlog Items to start work on a Product Release

The Explore value stream, as shown in Figure 24, is the more comprehensive view for included scenarios and detailed value stream stages for the value stream, and will be described in detail in the following sections.

id 13891b3d4c1549a3a3d6f504daea7d03
Figure 24. Explore Value Stream Details Model

In the following sections we document the scenarios and stages of the Explore value stream:

5.2.1. Explore Scenarios

The Explore value stream is applicable for the following four scenarios:

Investigate a New Digital Product Idea Scenario

The trigger for this scenario is a Scope Agreement and an initial budget allocation to invest in a new Digital Product idea or enhancement that has a strong value proposition and alignment to one or more Strategic Objectives. The outcome is validation that the new product idea has a strong value proposition, alignment to one or more Strategic Themes, and will comply with technology standards and policy. The scope incorporates Portfolio Backlog Items for testing assumptions that may include a proof-of-concept, conceptual service, or an MVP to prove that consumer needs and problems can be addressed. Results retrieved from the proof-of-concept may lead to the refinement of Portfolio Backlog Items to continue researching the new product idea, or may result in a decision to reconsider, or rethink, a decision, and the reallocation or discontinuation of further investments and resources. This scenario may only be intended to validate a hypothesis and may not include the full operationalization of a Digital Product (for example, its inclusion in the Service Offer Catalog, automation using the Operate functions, or marketing it to consumers).

Optimize a Digital Product Scenario

The trigger for this scenario is a Scope Agreement and an initial budget allocation that incorporates Portfolio Backlog Items for optimizing a Digital Product. The outcome is an enhanced Digital Product. The scope includes activities to optimize a Digital Product based on innovating new features and addressing Defects, mandates, and technical debt. The outcome is a Scope Agreement and resource allocation priority focused on Portfolio Backlog Items for implementing a release for an existing Digital Product. The scope includes the creation of an MVP/Minimum Marketable Product (MMP) release together with testing assumptions about the business model. Results retrieved from the MVP may result in a decision to continue and refine, to pivot and reallocate, or to discontinue further investments and resources. This may lead to a request to increase or decrease investment, a change to resource allocation, a change in scope, or a change in timeline. An MVP may only include quick enhancements to Digital Products, as small changes, resulting in immediate business value (time, resources, and scope).

Refine Digital Product Feasibility Scenario

The trigger for this scenario is a portfolio level Scope Agreement with a decision to invest in a new or existing product. Product planning cycles are conducted to further detail the budget, resource allocation, and feasibility for planned and accepted Portfolio Backlog Items. The outcome is a product level Scope Agreement that further details the scope and budget for a Product Design and the optimization of business outcomes. While big strategic initiatives and cross-product content are funded and governed on the portfolio level in the Evaluate value stream; smaller product investments are better managed at the product level by the Product team in the Explore value stream.

Retire Digital Product Scenario

The trigger for this scenario is a Scope Agreement and an initial budget allocation that incorporates Portfolio Backlog Items for retiring a Digital Product. The outcome is a decommissioned Digital Product. The scope includes activities to mitigate negative effects on consumers, impacts to dependencies, the re-allocation of resources, and the archival of data. Reasons for retirement may be driven based on technology debt, cost, duplication in the environment, lack of interest or use, or other valid reasons to no longer maintain a Digital Product. It is important to retire Digital Products that are no longer in use to reduce the complexity of technical environments.

5.2.2. Prioritize Backlog Items Stage

The purpose of the value stream stage “Prioritize Backlog Items” is to refine qualified Portfolio Backlog Items and mandates for new or existing Digital Product investment decisions. The budget allocated in the Evaluate value stream for the Product Portfolio is used to explore Digital Product ideas and determine feasibility. This should include ensuring that scoped Product Backlog Items deliver value, mitigate risks, and meet governance criteria (technology, security, reliability, supportability, etc.). The deliverables for this value stream stage are a Scope Agreement with prioritized Product Backlog Items; scope and timing refined.

Table 6. Prioritize Backlog Items Value Stream Stage

Entrance Criteria:

  • Digital Product is selected for exploration and to determine feasibly

Exit Criteria:

  • Refined Scope Agreement with prioritized Product Backlog Items, scope, and timing

Value Item:

  • Digital Product investments that meet budget, compliance, and supportability requirements

Activities:

  • Shall prioritize and refine qualified Portfolio Backlog Items and mandates for new or existing Digital Product investment decisions

  • May consider new revenue opportunities, Strategic Themes, rationalization effects, customer demands, improvements, emergency fixes, directives related to compliance or regulatory, Digital Product dependency changes, end-of-life and decommissioning, transition to next version

  • May adjust funding and resource allocations for Scope Agreements

  • May group, correlate, and rationalize qualified Product Backlog Items to avoid redundancy and maximize resources to gain efficiencies and scale

  • Should ensure scoped Product Backlog Items deliver value, mitigate risks and meet governance criteria (technology, security, reliability, supportability, etc.)

  • Should plan program increments (e.g., quarterly planning)

  • Should align portfolio and product roadmap

Examples of Participating Stakeholders:

  • Business Analyst

  • Compliance Manager

  • Enterprise Architect

  • External Stakeholder

  • Product Manager

  • Product Portfolio Manager

5.2.3. Define Digital Product Architecture Stage

The purpose of the value stream stage “Define Digital Product Architecture” is to collaborate with stakeholders to validate product viability. This should include industry research and a Business Impact Analysis (BIA). Product Portfolio funding and resource allocation may be adjusted based on findings. The deliverable for this value stream stage is a conceptual product architecture.

Table 7. Define Digital Product Architecture Value Stream Stage

Entrance Criteria:

  • Scope Agreement with prioritized Product Backlog Items, scope, and timing

Exit Criteria:

  • Defined conceptual product architecture

Value Item:

  • Feasible Product Architecture and impact assessment

Activities:

  • Should define the Digital Product conceptual architecture or high-level Product Design

  • Shall create Architecture Blueprints

  • Shall collaborate with stakeholders to validate product viability

  • Should research industry best practices, the consumer needs, including the business model, customer journey, and capabilities

  • May re-validate the Digital Product Scope Agreement against risk, cost, time, value, and other parameters

  • Should establish business impacts and resource (people, process, data, technology) availability

    • Address delivery and supportability requirements to maintain Digital Product Instances

  • May adjust Product Portfolio funding and resource allocations

Examples of Participating Stakeholders:

  • Business Stakeholder

  • Data Protection Officer

  • Enterprise Architect

  • Product Architect

  • Product Manager

  • Security Analyst

  • Security Architect

  • Vendor Manager

5.2.4. Refine Product Backlog Stage

The purpose of the value stream stage “Refine Product Backlog” is to translate a Scope Agreement into smaller pieces of work that can be assigned to product level features and linked to the product backlog. This includes organizing assigned backlog items into work packages and adjusting the Scope Agreement, business case, and budget as needed. The deliverables for this value stream stage are established Architecture Roadmap Items.

Table 8. Refine Product Backlog Value Stream Stage

Entrance Criteria:

  • Conceptual product architecture

Exit Criteria:

  • Established Architecture Roadmap Items

Value Item:

  • Incremental Digital Product work packages with dependencies and priorities

Activities:

  • Shall translate a Scope Agreement into “smaller” pieces of work that can be assigned to the “product” level; e.g., features (linked to the product backlog)

  • Shall organize/assign backlog items into work packages

  • Should determine and accommodate dependencies

  • Shall size and prioritize the work

  • Shall update the Scope Agreement with new findings

  • May re-confirm the product work package aligns with the vision, strategy, policies

  • May create Architecture Blueprint(s) per product work package in line with the overall Enterprise Architecture

  • May align the product work packages with the Architecture Roadmap

  • May refine the business case and adjust budget

Examples of Participating Stakeholders:

  • Business Analyst

  • Business Stakeholder

  • Data Protection Officer

  • Enterprise Architect

  • Product Manager

  • Security Analyst

5.2.5. Finalize Roadmap & Scope Agreement Stage

The purpose of the value stream stage “Finalize Roadmap & Scope Agreement” is to assign work and begin to conduct planning meetings on a regular cadence. Stakeholder buy-in and agreement to the Release roadmap and outcomes must be obtained. This includes setting up tracking and reporting on progress. The deliverables for this value stream stage are an approved Architecture Roadmap and outcomes.

Table 9. Finalize Roadmap & Scope Agreement Value Stream Stage

Entrance Criteria:

  • Architecture Roadmap Items

Exit Criteria:

  • Approved Architecture Roadmap and outcomes

Value Item:

  • Architecture Roadmap with work packages outlining resource requirements and budget allocation

Activities:

  • Shall assign/allocate resources to work packages

  • May assign/allocate resources to work on subsequent work packages

  • May conduct planning meetings on a regular cadence

  • Shall obtain stakeholder review and agreement of the Architecture Roadmap and outcomes

  • Shall track and report on the progress of the Scope Agreement, work packages, and related IT initiatives

  • May update a Scope Agreement and work packages

  • May allocate / assign resources for build and deliver activities (link to value streams)

  • Shall update Portfolio Backlog Items to reflect the build and deliver progress status

Examples of Participating Stakeholders:

  • Development Team

  • Enterprise Architect

  • Product Manager

  • Risk Analyst

  • Security Analyst

  • Vendor Manager

5.3. Integrate Value Stream

id c98d6905 fa50 47ad 9368 9359a0577c08
Figure 25. Integrate Value Stream Model

Overview

The value stream “Integrate”, as shown in Figure 25, creates a new Product Release. It covers the planning, design, development (or configuration), and testing of a new Product Release (in non-production environments), and makes the Product Release available for deployment and release into production. A new Product Release can also be related to an emergency fix needed to resolve a production issue (such as resolving vulnerabilities and critical bugs).

The Integrate value stream covers the creation and modification of all types of Digital Products such as custom-build software, configuration of SaaS applications, Commercial Off-The-Shelf (COTS) software packages, PaaS platforms, Infrastructure as a Service (IaaS) products, etc. This value stream is not limited to application development, but also subject to the development and maintenance of infrastructure products (and platforms).

Work is initiated and managed in the Product Backlog (and related team backlogs), which can receive demand signals from consumer or business stakeholders (e.g., new features or business requirements), or from other functional components such as Portfolio Backlog Management, Policy Management, and Problem Management. This may take the form of an approved Portfolio Backlog Item, or may be a smaller-grained signal such as an individual feature, user story, Defect, or Problem.

The Integrate value stream continuously pulls work from the Product Backlog based upon various triggers and inputs; such as:

  • New features and requirements raised by a consumer (or a business stakeholder) and/or other product teams

  • New or modified non-functional requirements such as those related to Service-Level Objectives (SLOs), security, risk, and compliance

  • New portfolio epics from the portfolio backlog which need to be refined into Product Backlog Items

  • New versions, updates, or fixes provided by the vendor (e.g., software updates and patches) and/or other technology refresh activities

  • Problems detected in operational environments (e.g., functional issues, performance issues, etc.)

  • Emergency changes to resolve major incidents and/or mitigate major risks (e.g., security issues and vulnerabilities)

The Integrate value stream delivers the Product Release (for a new or modified product) which is packaged for immediate or future deployment through the Deploy value stream.

Note that although the stage is shown as a linear process, the actual work in the value stream consists of multiple iterations, continuous cycles, and flow of work with feedback loops (e.g., Continuous Integration/Continuous Delivery (CI/CD) and continuous testing, etc.).

Key Stakeholder(s)

The typical key stakeholders involved in the Integrate value stream are the Product Manager and associated Development Teams (also referred to as Product Teams, or DevOps Teams if Development and Operations are combined into one team), responsible for the planning, design, creation, and testing of a Product Release.

Other key stakeholders involved are business stakeholders and customer representatives involved in defining business needs (voice of the customer), validating (and testing) the product, and those who ultimately benefit from the value created by using the product.

Value

The outcome of the Integrate value stream is a new Product Release, accepted and ready for deployment and release into production. This is a release for a new or existing Digital Product which provides additional value (and/or reduced risk) once made available and used by consumers in production, as a result of:

  • New features (e.g., providing additional value by fulfilling new consumer needs)

  • Non-functional improvements (e.g., improving performance, improve user experience, compliance, security, availability, improved resilience, etc.)

  • Reducing technology debt (and reducing risks), such as those related to technology upgrades/patches and code quality improvements

  • Resolving issues/problems (e.g., improve reliability, reduce Incidents in production, improve performance, etc.)

  • Reduce costs (e.g., improve utilization of resources, etc.)

Cross-Value Stream Dependencies

The Integrate value stream depends on:

  • Explore:

    • Delivers Portfolio Backlog Items and an approved Scope Agreement to start creating or updating the Product Backlog

    • If the agreed Scope Agreement cannot be met, the Explore value stream is responsible for changing the Scope Agreement within the boundaries of the Architecture Roadmap and Product Portfolio; for example, to allocate more time or a higher budget

    • Delivers an updated product vision and high-level roadmap

  • Consume:

    • Deliver the environments to work on, as a request can be used to fulfill the provisioning of a needed development, test, and staging environment

  • Deploy:

    • Deployment of the Product Release into a production environment

  • Operate:

    • Delivers an inflow for Defects, as Problems related to Actual Product Instances may require a fix (or patch) to be created through the Integrate value stream

Value streams that depend on the Integrate value stream are:

  • Evaluate:

    • The Evaluate value stream uses all lifecycle information from all value streams to identify potential improvements in the product (and/or way of working)

  • Explore:

    • Provides development progress and team capacity

      The status of the Product Backlog Item is fed back so it can be taken into account when planning the Portfolio Backlog Items for sourcing.

    • If an agreed Scope Agreement cannot be met, the Explore value stream is responsible for changing the Scope Agreement; for example, by changing the covered Portfolio Backlog Items (to include more or go for less), changing the time or budget, or changing the sourcing party

  • Deploy:

    • Provides the approved Product Release, which in turn triggers the deployment scheduling of the Product Release to the production environment

  • Release:

    • Due to a new Product Release, one or more Service Offers need to be modified (or created) to make the new Product Release available for consumption

  • Operate:

    • The Operate value stream depends upon the development of operations features, such as monitoring (and observability), logging, and automated remediation Runbooks

      The Integrate value stream needs to develop the required functionality to manage the product in an operational environment.

The Integrate value stream, as shown in Figure 26, is the more comprehensive view for included scenarios and detailed value stream stages for the value stream, and will be described in detail in the following sections.

id e7abe40528854f9689ce55aff1d9b7f2
Figure 26. Integrate Value Stream Details Model

In the following sections we document the scenarios and stages of the Integrate value stream:

5.3.1. Integrate Scenarios

The Integrate value stream is applicable for the following four scenarios:

Develop a New or Initial Product Release Scenario

In this scenario a Product Release is developed which may be software and/or infrastructure and is developed in-house or (partly) sourced with an external partner. The approach may either be traditionally waterfall or iterative, which would imply that iterations have taken place inside the Design & Develop value stream stage.

Configure an Off-the-Shelf or SaaS Product for Use Scenario

Off-the-Shelf applications and SaaS solutions need to be integrated in a business Value Stream and supporting infrastructure environments, which might include the configuration of the application software. The Scope Agreement contains the mandate to contract the software or SaaS solution with the vendor and configure the product to fit in the specific business Value Stream and supporting infrastructure.

Deliver an Emergency Change or Hotfix Scenario

The Integrate value stream can be triggered by the Operate value stream in case a Defect needs to be created. The Build Package of the Digital Product in Operations is changed to fix the Defect, after which a new Product Release is delivered. It will be investigated whether this fix also needs to be applied (backported) to the newest Product Release under development (to prevent regression issues).

Update of a Vendor Product Scenario

A Digital Product can be based upon multiple third-party services and software components (packaged-based software, SaaS, PaaS, etc.). The Integrate value stream should therefore also cover the technology refresh of new releases delivered by the software vendor and/or the SaaS service provider. It is important to include these technology lifecycle events into the Product Backlog so they can be planned and executed accordingly.

A new release of the vendor product could, for example, include new features, patches/fixes for problems, or vulnerabilities and performance improvements. Changes from the vendor need to be integrated into the product build and release of the Digital Product, and tested to ensure the updates are successfully applied.

5.3.2. Plan Product Release Stage

Description

The purpose of the value stream stage “Plan Product Release” is to plan all development and testing activities required for creating the Product Release. Multiple teams may be needed, and different development methodologies may be used. This value stream stage is revisited as it oversees the other value stream stages in this value stream to cater for changes in the planning and iterations of the Design & Develop value stream stage.

Table 10. Plan Product Release Value Stream Stage

Entrance Criteria:

  • New or modified Product Backlog Item/Requirement (e.g., linked to a portfolio epic, Scope Agreements)

  • New problem (to be resolved)

  • Emergency change request (e.g., to resolve a major product issue or vulnerability)

  • Modified/new policies

Exit Criteria:

  • Prioritized and refined Product Backlog

  • Iteration/sprint plan created

Value Item:

  • Defined, prioritized, and planned Product Backlog Items

Activities:

  • Shall analyze the needs of stakeholders

  • Shall capture/document Product Backlog Items (e.g., derived from portfolio epics, problems, etc.)

  • Shall refine Product Backlog Items

  • Shall prioritize Product Backlog Items (including value, risk, and effort estimation)

  • Shall create the test strategy and Test Plan

  • Shall create a sprint/iteration plan

Examples of Participating Stakeholders:

  • Business Analyst

  • Business Stakeholder

  • Consumer

  • Development Team

  • Product Architect

  • Product Manager

  • Risk Analyst

  • Scrum Master

  • Test Specialist

5.3.3. Design & Develop Stage

Description

The purpose of the value stream stage “Design & Develop” is to analyze the requirements, create (or update) the design artifacts, and develop the changes (and associated Test Cases) for the Product Release. This includes the coding and configuration of software and related infrastructure (e.g., infrastructure as code).

This value stream stage covers the development of the changes that are part of the new release of the Digital Product based on the requirements, architecture boundaries, and policies set by the organization. In addition, requests might be needed to cater for setting up a development environment for the developers.

Table 11. Design & Develop Value Stream Stage

Entrance Criteria:

  • Prioritized and refined Product Backlog

  • Iteration/sprint plan created

  • Identified Defects

Exit Criteria:

  • Committed code/configuration changes (stored in the source code repository)

  • Test Cases created

  • Requirements and acceptance criteria defined

  • Updated Product Design

Value Item:

  • Development or configuration of changes have been completed and committed to the source code repository (ready to be merged)

Activities:

  • Shall define/analyze requirements (e.g., engage and collaborate with stakeholders)

  • Shall create and approve the Product Design, including data model design, UX design, and interface design

  • Shall define and create the Test Plan and associated Test Cases

  • Shall develop/configure the required changes (actual software development and/or configuring a product)

  • Shall commit code (into the source code repository)

Examples of Participating Stakeholders:

  • Business Analyst

  • Business Stakeholder

  • Consumer

  • Data Protection Officer

  • Development Team

  • Product Architect

  • Product Manager

  • Scrum Master

  • Security Analyst

  • Security Architect

  • Test Specialist

  • Vendor Manager

5.3.4. Build, Integrate, & Test Stage

Description

The purpose of the value stream stage “Build, Integrate, & Test” is to perform the build, integrate, and test activities to ensure the release package is ready for deployment into production.

Table 12. Build, Integrate, & Test Value Stream Stage

Entrance Criteria:

  • Committed code/configuration changes (in the source code repository)

  • Test Cases created

  • Requirements and acceptance criteria defined

  • Updated Product Design

Exit Criteria:

  • New or updated Build Package

  • New or updated release package

  • Tests executed

  • Identified Defects/issues

Value Item:

  • Created and tested Product Release with associated Build Package

Activities:

  • May compile code (if applicable)

  • Shall create the build artifacts as part of the Continuous Integration pipeline

  • Shall perform code reviews (and static code analysis)

  • Shall validate compliance and security aspects of the build created (and associated components)

  • Shall create the release package

  • Shall deploy to test (and other environments such an acceptance/staging environment)

  • Shall perform tests and verify against policies and compliance requirements, this includes security testing, performance testing, regression testing, integration testing, etc.

  • Shall identify potential Defects/issues (feedback loop to plan stage)

Examples of Participating Stakeholders:

  • Business Stakeholder

  • Consumer

  • Consumer

  • Development Team

  • Product Architect

  • Security Officer

  • Test Specialist

  • Vendor Manager

5.3.5. Accept & Publish Release Stage

Description

The purpose of the value stream stage “Accept and Publish Release” is to accept the Product Release as a candidate for deployment into production. The required change authority, such as the Product Manager, accepts the Product Release for deployment and/or release into production. The Product Manager accepts the Product Release after engaging with relevant stakeholders, which includes reviewing test results to accept or reject the list of remaining Defects, and reviewing the collateral produced. In a DevOps model, Operations has been participating all along but at this point an approval is given for the Product Release to be deployed into production.

This value stream stage ensures only validated and approved release packages can be deployed into production. The release package is tagged and secured to prevent any modification at a later stage (e.g., to prevent unauthorized changes being made).

Table 13. Accept & Publish Release Value Stream Stage

Entrance Criteria:

  • Tested and validated release package (ready for release)

Exit Criteria:

  • Accepted and published new Product Release (ready for deployment to production)

  • Securely stored and tagged Product Release

  • Release notes available (including outstanding Defects and associated Problems)

Value Item:

  • The Product Release is ready for deployment; the future consumer is informed and able to prepare for the release

Activities:

  • Shall review readiness of the release (e.g., verify test results, verify outstanding Defects, code quality, deployment Runbooks, data migration, and backout procedure, etc.)

  • Shall accept the new Product Release (by the Product Manager and required stakeholders)

  • Shall inform stakeholders of the new release

  • Shall publish the final release package (make the release available for consumption)

Examples of Participating Stakeholders:

  • Business Stakeholder

  • Consumer

  • Product Architect

  • Product Manager

  • Risk Analyst

  • Security Analyst

  • Security Officer

  • Support Specialist

5.4. Deploy Value Stream

id b356c451 0edd 43a8 b97c 0979879dbdbe
Figure 27. Deploy Value Stream Model

Overview

The value stream “Deploy”, as shown in Figure 27, is installing a Product Release into production. It can also imply the removal, disposal, or updating of an existing installed Product Release, so it is made available or unavailable to the customer. Many possible strategies for deploying a Product Release can be scenarios within the Deploy value stream; for example, deployment to a targeted audience, or deployment using a dark launch in which functionality is not directly released to consumers. If the user requirements and/or the characteristics of the Digital Product demand that the installed Product Release is improved, released, and deployed frequently, a drive to automate these value streams can emerge. To comply with regulatory requirements, organizations can require approvals and an audit trail of all the Changes made in production environments. The Deploy value stream ensures that all changes are tracked and related to a specific Product Release.

The Deploy value stream delivers the initial deployment, update, or removal of an Actual Product Instance, and will put the Service Contract into operation.

Key Stakeholder

The main stakeholder of the Deploy value stream is the Product Manager, who can authorize deployment of Actual Product Instances to the customer in the production environment.

Value

The outcome of the Deploy value stream is that new Product Releases can be installed safely without causing unexpected outages to the current Actual Product Instances in use.

Cross-Value Stream Dependencies

The Deploy value stream depends on:

  • Integrate:

    • Provides approved Product Releases that require deployment to the production environment

  • Consume:

    • Delivers a foundation to work on, as an Order can be used to fulfill the underlying setup of a needed production environment

Value streams that depend on the Deploy value stream are:

  • Evaluate:

    • Improvements start with drivers, that are expected to arise from all seven value streams

      All value streams will capture data to ensure that the quality of the Digital Product will meet the requirements.

  • Release:

    • Deploy a context in the form of an Actual Product Instance in which the Service Offer can be consumed and supported

  • Operate:

    • Actual Product Instances can be enabled, changed, disabled, or removed by the deployment of the Product Release

The Deploy value stream, as shown in Figure 28, is the more comprehensive view for included scenarios and detailed value stream stages for the value stream, and will be described in detail in the following sections.

id a90a0cc448b34fa8a8abc4f81536ae4d
Figure 28. Deploy Value Stream Details Model

In the following sections we document the scenarios and stages of the Deploy value stream:

5.4.1. Deploy Scenarios

The Deploy value stream is applicable for the following three scenarios:

Deploy a First Product Release for a New Digital Product Scenario

The goal of this scenario is to plan, prepare, and execute the deployment of the initial version of the Digital Product. Part of the planning is determining the priority, assessing the risk and dependencies, and scheduling the time slot. The information used for the risk assessment will be limited as this is the first release of the Digital Product. However, during development, information from earlier deployments in non-production environments should provide the necessary information to minimize risk. Since no customer is using the Digital Product, available time slots might include office hours. The available capacity for dependent Digital Products can be checked, and IT assets requested if needed. The deployment schedule must consider any dependencies on the Orders required to allocate the necessary Resources.

During execution of the deployment, the Service Contract will be activated; this requires instrumentation of the data for the metrics that will be collected to measure the Key Performance Indicator (KPI) targets. Additional training of specialists involved in the Operate value stream are performed, although it is advisable to train specialists before the Product Release is finalized. Knowledge Items are created based on the Defects and test results (e.g., metrics from performance tests).

Deploy a New Product Release Version for a Digital Product Scenario

The goal of this scenario is to plan, prepare, and update the existing Actual Product Instances. This ensures a stable Product Instance after the Deploy value stream is completed. The deployment strategy may depend on the Digital Product: some might require a maintenance window in which deployment can be executed, while for others a completely new version will be installed alongside an existing version. As every deployment should result in a stable Product Instance in production, there are some points to address:

  • To mitigate risk, the plan should include a “point of no return” in time, and a “rollback to the last known good configuration” plan

    These should be addressed and practiced during the development of the Product Release.

  • During the execution of the deployment, stakeholders should be informed; for example, the monitoring events can be suppressed to prevent disrupting the Operate value stream

Disable or Remove Existing Product Release Instances of a Digital Product Scenario

The goal of this scenario is to completely or partly disable or remove Actual Product Instances of a Digital Product. The deployment design (which is part of the Product Release) should provide information on the active Product Release that needs to be removed or undeployed, whereas the Operate value stream has the actual information on which related Actual Product Instances are to be disabled or removed.

Removing a Digital Product might require changes to the Product Design, and, in some cases, customer data may have to be retained for a while and made available for the customer to view. Some of the components of the Digital Product can be removed, but new components may also be installed or deployed.

5.4.2. Plan & Approve Deployment Stage

Description

The purpose of the value stream stage “Plan & Approve Deployment”` is to create a deployment plan for a Digital Product and, based on this plan, to sign it off with all relevant stakeholders.

The details of the plan and the extent of approval required depends on the complexity of the deployment.

Table 14. Plan & Approve Deployment Value Stream Stage

Entrance Criteria:

  • A Product Release in a fully-tested form

Exit Criteria:

  • An approved deployment plan

Value Item:

  • Ensuring that production deployment is not a surprise to any part of the organization, and that the resources needed for deployment are available

Activities:

  • Shall estimate the time for deployment and associated service downtime if any

  • Shall ensure resources are available for the full deployment, including the validate and observation stage

  • Shall plan a deployment time based on effort, resources, and corporate policies

  • May validate Knowledge Items exist for open, accepted Defects and work-arounds that are part of the Product Release

  • Shall obtain necessary approval for deployment as per the organization policy

    This typically includes but is not limited to approval from:

    • Operations teams for increased operations support

    • Support teams for the potential increase of support needed, as well as training

    • Security operations for sign-off on product security mandates

    • Legal teams for any potential license and copyright issues with product

Examples of Participating Stakeholders:

  • Operations Manager

  • Product Manager

  • Release & Deployment Manager

5.4.3. Fulfill Deployment Stage

Description

The purpose of the value stream stage “Fulfill Deployment” is to execute the Fulfillment Orchestration when the change window for deployment is open. The Fulfillment Orchestration is documented in the change records and can be coded as part of the Product Release to automate the Fulfillment Orchestration.

Table 15. Fulfill Deployment Value Stream Stage

Entrance Criteria:

  • Signed-off preconditions for deployment

  • Validated Knowledge Item for Product Release

Exit Criteria:

  • Actual Product Instance is deployed in production

Value Item:

  • Deployed Actual Product Instance

Activities:

  • Shall create the Desired Product Instance topology from the Product Design

  • Shall reserve the required Resources (e.g., hardware capacity, cloud resources, licenses, …​)

  • Shall create Order(s) to cater for the deployment of any dependent services required

  • May inform support specialists from the Monitoring bridge and the service desk

  • Shall verify the orchestration for the Desired Product Instance and associated Fulfillment Books, and validate if all preconditions are met

  • May suppress monitoring Events to prevent them from being escalated during the change window

  • Shall deploy artifacts from the Build Package as part of the Product Release on the Actual Product Instance(s), and update the topology

  • Shall deploy new or updates to Runbook(s)

  • Shall deploy new or updates to Service Monitor(s)

  • Shall deploy/activate the Knowledge Item(s) as part of the Product Release

  • May start the Actual Product Instance(s)

Examples of Participating Stakeholders:

  • Operations Manager

  • Product Manager

  • Release & Deployment Manager

  • Release & Deployment Manager

5.4.4. Validate Deployment Stage

Description

The purpose of the value stream stage “Validate Deployment” is to ensure that all aspects of the deployment activities were correctly executed. This includes checking that the Product Instance is indeed running and configured according to plan, and that the monitoring and documentation associated is configured and made available.

Table 16. Validate Deployment Value Stream Stage

Entrance Criteria:

  • Deployed new or updated Product Instance

Exit Criteria:

  • It is validated that the Actual Product Instance is running

Value Item:

  • Ensure that the deployment went OK

Activities:

  • Shall inspect/discover the deployed CIs registered in the Actual Product Instance Model

  • Shall validate that the discovered Actual Product Instance model is compatible with the Desired Product model

  • Shall validate that all the components of the Product Instance are running, and that the Service Monitor and Log systems are working for the Product Instance

  • Shall validate that the Service Level monitoring for the Product Instance is registered, and Monitoring is working

  • Shall validate that the known errors/Defects are registered in the known error system

Examples of Participating Stakeholders:

  • External Stakeholder

  • Operations Manager

  • Product Manager

  • Release & Deployment Manager

  • Support Specialist

5.4.5. Observe Deployment Stage

Description

The purpose of the value stream stage “Observe Deployment” is to ensure that the Actual Product Instance (= deployed product instance) is delivering expected functional and non-functional requirements.

Table 17. Observe Deployment Value Stream Stage

Entrance Criteria:

  • Running and validated Actual Product Instance

Exit Criteria:

  • New or updated Actual Product Instance can be handed over to the Operations team

Value Item:

  • Actual Product Instance is operational

Activities:

  • Shall observe Logs, Events, and service levels, and ensure they are stable and acceptable

  • May observe if consumption of the product is working through test consumption and the monitoring of help desk interactions

  • Shall consider if any issues require a quick patch forward or a rollback of deployment

Examples of Participating Stakeholders:

  • Business Stakeholder

  • Development Team

  • Product Manager

5.5. Release Value Stream

id 914b6415 cbda 42c4 a78d afd972ce3c30
Figure 29. Release Value Stream Model

Overview

The value stream “Release”, as shown in Figure 29, ensures that the Service Offers for ordering a new, a change in, or the decommissioning of an Actual Product Instance or its support to them are offered to consumers. The Release value stream maintains the Service Offer Catalog, the catalog views, and the Service Offer promotion and information of available Service Offers to the consumer base so that the individual consumer can find and order Digital Products, or support for them. Service Offers should be made available for viewing and requests for access over multiple channels. This value stream publishes the Service Offers based on various triggers and inputs, such as:

  • The Product Release, as a result of the Integrate value stream

  • The decision of the Product Manager to provide a new (bundled) Service Offer based on existing Service Offers and releases

  • The decision to change or terminate an existing Offer

The Release value stream delivers a digital service by means of a Service Offer that is made available and can be requested.

Key Stakeholder

The primary stakeholder of the Release value stream is the Catalog Manager, who is primarily responsible for defining, implementing, and publishing the Service Offers so that they are available to be consumed by the target consumers.

Value

The outcome of the Release value stream is to ensure the management of the consumable Service Offers for the Digital Product. These Service Offers are for new service consumption; there are Service Offers for support or to change/retire an Actual Product Instance. This also provides the following additional value to the consumers but is not limited to:

  • Centralization of the catalog (e.g., providing access control to all the products and services being offered to the consumers)

  • Enabling self-service (e.g., the aggregated Service Offer Catalog facilitates user self-service capabilities by providing detailed information about the Service Offer Catalog item and its detailed attributes)

  • Providing traceability (e.g., the Service Offer Catalog allows traceability of service, from ordering to fulfillment of the service)

  • Reducing cost (e.g., the Service Offer Catalog reduces the time that the consumer requires from ordering to fulfillment of the service)

Cross-Value Stream Dependencies

The Release value stream depends on:

  • Deploy:

    • Released Offers for the support or consumption of an Actual Product Instances (new, changed, or terminated) can depend on a deployed Product Release

Value streams that depend on the Release value stream are:

  • Evaluate:

    • Improvements start with drivers, that are expected to arise from all seven value streams

      All Value Streams will capture data to ensure that the quality of the Digital Product will meet the requirements.

  • Consume:

    • Service Offers that can be fulfilled are based on released Service Offers, and can only be activated after deployment of the release

    • The Consume value stream feeds the result of the deployment back into the Release value stream stages for reporting

The Release value stream, as shown in Figure 30, is the more comprehensive view for included scenarios and detailed value stream stages for the value stream, and will be described in detail in the following sections.

id 75bd2c984e4543c493df4dbb211e9753
Figure 30. Release Value Stream Details Model

In the following sections we document the scenarios and stages of the Release value stream:

5.5.1. Release Scenarios

The Release value stream is applicable for the following four scenarios:

Release a New Service Offer Scenario

The outcome of this scenario is to provide the consumers with the possibility to request a new Actual Product Instance of a Digital Product or to request a new form of support on an Actual Product Instance. The following activities are part of this scenario:

  • Link the Service Offer to existing (via deploy/deployed) support/fulfillment plan(s); this includes linkage of the Service Offer to its internal and external support or fulfillment parties

  • Provide customer access to the Offer (views)

  • Promote and inform the availability of the new Service Offer

Change an Existing Service Offer Scenario

The outcome of this scenario is to maintain an up-to-date Service Offer for the consumers. The reason for the change of the Service Offer can vary. Recurring Change activities are:

  • Change of charged service price; e.g., annual service fee recalculation

  • Change of underlying terms and conditions; e.g., when the SLA changes

  • Change of the fulfillment or support plan; e.g., to include more automation

  • Change of access to the Service Offer; e.g., to change who can consume the service

Bundle Existing Service Offers Scenario

The outcome of this scenario is to combine multiple existing Service Offers into a single Service Offer, so that customers only need to order a single Service Offer, instead of multiple Service Offers. Activities in this scenario are:

  • Combining and chronologically orchestrating/sequencing the Service Offers

  • Providing customer access to the Service Offer (views)

  • Promoting and informing the availability of the new bundled Service Offer

Terminate a Service Offer Scenario

The outcome of this scenario is to remove a Service Offer from the catalog and stop it from being ordered in the future. This scenario can be executed when the all-encompassing Digital Product is terminated, but it can also be executed in a normal release cycle of a Digital Product, when new versions of the Digital Product become available. Activities in this scenario are:

  • Marketing and promotion of the termination of the Service Offer; this could include promotion to, for example, a new or replacement Product Release

  • Change the Service Offer validity

  • Remove customer access to the Service Offer (views)

5.5.2. Define Service Offer Stage

Description

The purpose of the value stream stage “Define Service Offer” is to obtain the Service Offer information from the Integrate value stream and to plan the creation and publication of Service Offers to Consumers. Offers can also represent the consumption of cloud services making the Service catalog an Aggregation catalog between their own and cloud services; planning should take place to identify which cloud Service Offers would be made available.

Table 18. Define Service Offer Value Stream Stage

Entrance Criteria:

  • New or modified Product Release (from the Integrate value stream)

  • Request for Service Offer improvements (prices, Quality of Service (QoS), bundles, …​)

Exit Criteria:

  • Approved Service Offer update plan

Value Item:

  • The Service Offer demand is planned for its release

Activities:

  • Shall take in new demand for Service Offers:

    • New Service Offers

    • New Service Offer bundles

  • May be based on consumer need, existing Service Offers, and demand captured:

    • Service Offer changes

    • Service Offer terminations

  • Shall validate completeness of offering information:

    • Including availability of fulfillment and support plans, self-service Runbooks, additional Knowledge Management documents, or required customer training

  • Shall take in the catalog structure and view changes

  • May plan Service Offer release activities and the release date

Examples of Participating Stakeholders:

  • Catalog Manager

  • Release & Deployment Manager

5.5.3. Implement Service Offer Stage

Description

The purpose of the value stream stage “Implement Service Offer” is to onboard the Service Offer into the Service Offer Catalog and to prepare all that is needed so that the Service Offer can be published.

Table 19. Implement Service Offer Value Stream Stage

Entrance Criteria:

  • Approved Service Offer release plan

Exit Criteria:

  • New, updated, or terminated Service Offer ready for publication

Value Item:

  • The Service Offer is ready for its release, and the future Consumer and Operations teams are informed of the release dates and can prepare for the release

Activities:

  • Shall create or update the Service Offer, where the Service Offer can have:

    • A description and validity period

    • A defined cost

    • A price and margin

    • Delivery terms and conditions

    • Payload options needed for the fulfillment (including feature toggles; all options for delivery are asked up front)

    • A defined target consumer audience

    • Additional training/knowledge documents for the target consumers

    • For delivery, references to a:

      • Service request fulfillment plan

      • Support request handling plan

      • An Actual Product Instance, system, or Subscription

      • Working alignment with Monitoring

  • Shall maintain the following attributes of the Service Offer:

    • Service Offer information, including price list

    • Service access

    • Service Offer Catalog structure

    • Service Offer Catalog views

  • May terminate the validity of the Service Offer

  • Can inform relevant stakeholders (Consumer and Operations Managers) on the upcoming Service Offer release changes

Examples of Participating Stakeholders:

  • Catalog Manager

  • Development Team

  • Operations Manager

  • Product Manager

  • Release & Deployment Manager

  • Support Specialist

  • Test Specialist

5.5.4. Publish Service Offer Stage

Description

The purpose of the value stream stage “Publish Service Offer” is to activate or release the Service Offer so that it can be ordered by consumers.

Table 20. Publish Service Offer Value Stream Stage

Entrance Criteria:

  • New, updated, or terminated Service Offer ready for publication

Exit Criteria:

  • Active new or updated Service Offer

  • Terminated Service Offer

Value Item:

  • Service Offer is released, and the future Consumer and Operations teams are informed on the release and can start using the Service Offer

Activities:

  • Shall activate Offer at the valid-from date

  • May inform relevant stakeholders (Consumer and Operations Managers) on the released changes

  • Shall ensure the Service Offer is created in the catalog and:

    • Shall be accessible by the target consumer group (supporting canary releases)

    • Can be selected, configured, priced, requested, delivered, adopted, supported, modified, and terminated

    • May be promoted through targeted informative activities to drive consumption

    • May be sold through targeted business sales activities to drive consumption

Examples of Participating Stakeholders:

  • Catalog Manager

  • Consumer

  • Development Team

  • Operations Manager

  • Product Manager

  • Release & Deployment Manager

  • Test Specialist

5.6. Consume Value Stream

id 54c9996d 3a72 4bdd a530 306931efd909
Figure 31. Consume Value Stream Model

Overview

The value stream “Consume”, as shown in Figure 31, manages the lifecycle of consuming a Digital Product. Digital Products are consumed as services and the lifecycle is managed as a Subscription to the service.

The Consume value stream covers the entire set of activities of a consumer, from selecting a Service Offer, ordering the service, fulfillment of the service, getting support, and status on the service.

The consumer can be a person internal to the business or an external customer. The Consumer can also be a system actor that on behalf of an organization consumes the service.

The Consume value stream ensures the ordered Desired Product Instance will be delivered as an Actual Product Instance within the agreed terms. The value stream is responsible for all activities needed to deliver the Actual Product Instance(s) successfully or provide support for them to Consumers.

If ordered, the Consume value stream will create or update the Service Contract. To increase its delivered value and identify areas for improvement, the value stream will also measure the consumption of the Service Contract, and assess the ongoing needs of the stakeholder. These actions support the offering, deployment, and monitoring of the Actual Product Instance, ensuring commitment to the Service Contract.

Key Stakeholder

The main stakeholder of the Consume value stream is a customer and/or consumer (human or system actor) in need of a Digital Product.

Value

The outcome of the Consume value stream is to have customers able to locate desired Digital Product service offerings, and obtain them in a timely manner as deployed and instantiated Digital Products that will be supported by the Operate value stream, according to a Service Contract.

Cross-Value Stream Dependencies

The Consume value stream depends on:

  • Release:

    • Offers are based on releases, and can only be activated after deployment of the release

    • The Consume value stream feeds the result of the deployment back into the Release value stream stage for reporting

  • Operate:

    • Fulfillment feedback of a Service Offer that resulted in an Incident and needed to be handled in the Operate value stream

Value streams that depend on the Consume value stream are:

  • Evaluate:

    • Improvements start with drivers, that are expected to arise from all seven value streams

      All value streams will capture data to ensure that the quality of the Digital Product will meet the requirements.

  • Integrate:

    • A request can be used to fulfill the setup of a test or build environment

  • Deploy:

    • A request can be used to fulfill the underlying platform setup of a needed production environment

  • Operate:

    • Actual Product Instances can be enabled, changed, or disabled by the fulfillment of the Service Offer

    • Consumption of a Service Offer can result in an Incident that needs to be handled in the Operate value stream

The Consume value stream, as shown in Figure 32, is the more comprehensive view for included scenarios and detailed value stream stages for the value stream, and will be described in detail in the following sections.

id eb6fb73f89f24c7db2e7d6e2a616336d
Figure 32. Consume Value Stream Details Model

In the following sections we document the scenarios and stages of the Consume value stream:

5.6.1. Consume Scenarios

The Consume value stream is applicable for the following four scenarios:

Order a New Desired Product Instance Scenario

The outcome of this scenario is to look for, select, and obtain a new Actual Product Instance by means of ordering a new Desired Product Instance based on an available Service Offer; for example:

  • New Subscription

  • Stage a Build Package to an Actual Product Instance

  • Access to a business application

Order an Actual Product Instance Modification Scenario

The outcome of this scenario is to look for, select, and obtain a modification to an Actual Product Instance; for example:

  • Changing a Subscription

  • Changing an asset

  • Changing an Actual Product Instance

  • Lifecycle management actions to an Actual Product Instance (e.g., start, stop, scale up)

  • Changing access to a business application

This scenario as such will influence the usage (and chargeback) of the Actual Product Instance.

Order an Actual Product Instance Termination Scenario

The outcome of this scenario is to terminate a running Actual Product Instance; for example:

  • End a Subscription

  • Return or decommission an asset

  • Decommission an Actual Product Instance

  • End access to an application

Order an Actual Product Instance Support Scenario

The outcome of this scenario is to look for, select, and obtain support for a running Actual Product Instance; like a support request. This scenario supports omni-channel principles to get access to the desired support. Next to that, self-service concepts are used to limit the interaction flow to people and provide direct remediation.

5.6.2. Select an Offer Stage

Description

The purpose of the value stream stage “Select an Offer” is to help the customer to select the Digital Product Service Offers(s) best suited to their needs.

Table 21. Select an Offer Value Stream Stage

Entrance Criteria:

  • Customer searches for a Service Offer

Exit Criteria:

  • Service Offer selected

Value Item:

  • Consumption Experience channel available to the customer

  • Service Offers available to the customer

Activities:

  • May advertise across channels and making customers aware of the Digital Products

  • Shall display Service Offers to present Digital Products in a searchable form

  • Shall enable selection filtering and assessments of the best product(s) matched to customer needs

Examples of Participating Stakeholders:

  • Catalog Manager

  • Consumer

  • Product Manager

  • Release & Deployment Manager

5.6.3. Agree to Service Offer Stage

Description

The purpose of the value stream stage “Agree to Service Offer” is to get agreement from the customer to the terms and conditions of the Service Contract.

Table 22. Agree to Service Offer Value Stream Stage

Entrance Criteria:

  • Service Offer selected

Exit Criteria:

  • Service Contract agreed

Value Item:

  • Active Service Contract

  • Active Subscription

  • Delivery commitment

Activities:

  • Shall finalize the contractual agreement, and have the customer accept the terms and conditions of the Service Contract as part of the Service Offer and delivered Product Instance

Examples of Participating Stakeholders:

  • Business Stakeholder

  • Product Manager

  • Vendor Manager

5.6.4. Subscribe to Service Offer Stage

Description

The purpose of the value stream stage “Subscribe to Service Offer” is to make the Actual Product Instance, as result of the Order and Desired Product Instance, available to the customer, in such a way that the customer is able to consume the Digital Product.

Table 23. Subscribe to Service Offer Value Stream Stage

Entrance Criteria:

  • Agreed Service Contract

Exit Criteria:

  • The Actual Product Instance is ready to be consumed

  • Customer consumes the Actual Product Instance

Value Item:

  • The Actual Product Instance available to and used by the customer

Activities:

  • Shall orchestrate the Desired Product Instance fulfillment by orchestrating all necessary changes that enable the customer to consume the Digital Product

    Note: Orchestration can trigger Fulfillment Books that are also used within the Deploy value stream.

  • Shall order and deliver the Actual Product Instance and provide the customer access to the Digital Product

  • Can measure the Service Contract against the agreed terms and conditions

Examples of Participating Stakeholders:

  • Consumer

  • Product Manager

  • Service Desk Agent

  • Vendor Manager

5.6.5. Provide Service Support Stage

Description

The purpose of the value stream stage “Provide Service Support” is to deliver support to a consumer of an active Subscription.

Table 24. Provide Service Support Value Stream Stage

Entrance Criteria:

  • Subscription created or changed for a service

Exit Criteria:

  • Support provided

Value Item:

  • Support for Subscriptions

Activities:

  • Shall provide self-help access to knowledge related to the service

  • Shall provide a mechanism to request for help with using the service

  • Shall provide a mechanism for reporting issues

  • The service support shall provide:

    • Resolutions to reported issues

    • Escalation to the Operations team for underpinning operational issues

    • Feedback to the Development team for issues that identify product improvement opportunities

Examples of Participating Stakeholders:

  • Consumer

  • Support Specialist

  • Vendor Manager

5.6.6. Publish Service Status Stage

Description

The purpose of the value stream stage “Publish Service Status” is to deliver status to a consumer on an active Subscription.

Table 25. Publish Service Status Value Stream Stage

Entrance Criteria:

  • Subscription created or changed for a service

Exit Criteria:

  • Status calculated and communicated to the consumer

Value Item:

  • Status of consumed service is up-to-date

Activities:

  • Shall collect and calculate usage statistics

  • Shall provide KPI calculations on service delivery according to the Service Contract

  • Shall provide notification to the relevant service consumer to inform them if there are any ongoing service issues

  • May proactively predict if a service will have any impacting event in the future, and communicate this to the consumer

Examples of Participating Stakeholders:

  • Consumer

  • Product Manager

5.7. Operate Value Stream

id 4a4ff1ae 15f8 4ceb ba1a d388775f89e5
Figure 33. Operate Value Stream Model

Overview

The value stream “Operate”, as shown in Figure 33, monitors and ensures that the availability and performance of Actual Product Instances are within the boundaries of their agreed Service Contract and Key Performance Indicator (KPI) targets. The scope of this value stream includes managing any compliance and security aspects of running Digital Product Instances and underlying systems that may result from deployment and/or fulfillment. The IT4IT Standard describes how to achieve this using integrated, automated, or fully autonomous data flows between the event monitoring (Event, Incident, Change, Configuration, and Problem Management) functions of the digital services. In addition, the data flows may be designed to be reactive, proactive, or predictive, and include a retrospective.

The Operate value stream delivering the Actual Product Instance is operated in a sustainable way within the agreed terms and conditions of a Service Contract.

Key Stakeholder

The primary stakeholder of the Operate value stream is the Consumer, who can use an Actual Product Instance or system within the boundaries of the Service Contract.

Value

The outcome of the Operate value stream is to ensure that the Actual Product Instance operates, and can be consumed as agreed in the terms of the Service Contract.

Cross-Value Stream Dependencies

The Operate value stream depends on:

  • Deploy:

    • Actual Product Instances can be enabled, changed, or disabled by the deployment of the Product Release

  • Consume:

    • Actual Product Instances can be enabled, changed, or disabled by the fulfillment of the Service Offer

    • Consumption of a Service Offer can result in an Incident that needs to be handled in the Operate value stream

Value streams that depend on the Operate value stream are:

  • Evaluate:

    • Improvements start with drivers that are expected to arise from all seven value streams

      All value streams will capture data to ensure the quality of the Digital Product will meet the requirements. Quality is an aspect of each task within each value stream. The Evaluate value stream uses data produced in all value streams to evaluate drivers.

  • Integrate:

    • Problems related to Actual Product Instances can require a fix from development (system defect)

  • Consume:

    • Fulfillment feedback of a Service Offer that resulted in an Incident and needed to be handled in the Operate value stream

The Operate value stream, as shown in Figure 34, is the more comprehensive view for included scenarios and detailed value stream stages for the value stream, and will be described in detail in the following sections.

id f924a60d5d9941c6857be5acd1e616b3
Figure 34. Operate Value Stream Details Model

In the following sections we document the scenarios and stages of the Operate value stream:

5.7.1. Operate Scenarios

The Operate value stream is applicable for the following five scenarios:

Remediate an Identified Back-End Issue Scenario

In this scenario, the Operate value stream is triggered by an issue (a breach and/or vulnerability) or a potential future issue (triggered by a threshold breach) in the infrastructure, platforms, applications, user transactions, and/or behavior of the back-end network. The scenario ends with the outcome that the service remains operational without affecting consumer experience and within the boundaries of the Service Contract.

The activities undertaken in the scenario include the detection, diagnosis, evaluation, and resolution of issues, alerts, and anomalies related to the performance, compliance, and security aspects of the organization’s back-end.

  • Performance remediation examples include: “reactive” event detection and correlation through the monitoring of the Digital Product Instance, system, and topology; “pro-active” event detection, through periodic service restarts, test transactions, or built-in self-healing capabilities; or “predictive” event detection, done by generating test events from the analysis of historical monitoring data and other data sources (e.g., business performance, social media, weather, etc.) to identify potential degradation based on predicted consumer behavior

  • Security remediation examples include responses to different types of attack, including unauthorized system access, phishing, password cracking, spyware, malware, Denial of Service (DoS) attacks, and more

  • Compliance remediation examples include inspections to detect compliance with the rules; for example, adherence to legislation, statutes, regulations, standards, policies, contracts, processes, procedures, and operational controls

Ensure Disaster Recovery Objectives Scenario

This scenario is about ensuring that any capabilities listed in the business continuity/disaster recovery plan can work within the boundaries of the Service Contract. The activities in this scenario, which are planned and triggered by the business continuity and/or disaster recovery plan activities calendar, include: detection, diagnosis, and remediation tasks related to the plan. The purpose of the activities is to ensure that recovery objectives (e.g., Maximum Acceptable Outage (MAO), Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO)) remain within the boundaries of the agreed Service Contract and BIA. Real-world examples of these activities include performing backups, ensuring plans and mechanisms for graceful degradation, removing Single Points Of Failure (SPOFs), validating recovery libraries, performing redundancy validations, testing backup sites, and performing running (scheduled or random) disaster recovery simulations.

Remediate a major Event or Incident Scenario

This scenario is triggered by a major event (e.g., full system outage, significant application failure); its outcome is that the service is restored within the boundaries of the Service Contract. The activities undertaken in the scenario include the correlation of Events/Incidents to identify (detect) that a major Event/Incident has occurred, collaboration with multiple teams to perform research and analysis to determine the underlying cause of the issue and to establish a remediation plan (diagnose), and the execution of remediation plans by those involved to resolve the major Event/Incident and restore services.

Remediate Consumer Front-End Issue Scenario

This scenario is triggered when an issue is raised by or through the service desk. The outcome of the scenario is restored consumer experience, normal service operations, and service delivery to the consumer within the boundaries of the Service Contract. The activities of the scenario include capturing/detecting, diagnosing, resolving, and evaluating any service interactions raised and escalated by consumers or the service desk. This might include service interactions which have been generated by users or by the service desk, and have been subsequently escalated into an Incident, requiring second or third-line handling for remediation. In cases where handling is not or cannot be performed due to operational decisions or lack of capacity, the risk of working outside of agreed boundaries will be logged and communicated with the consumer and can be input into the Evaluate value stream.

Perform Scheduled Maintenance Scenario

This scenario is triggered when a planned activity is scheduled or when certain thresholds are met which trigger an alert/event for proactive maintenance. The planned activity or maintenance is reviewed and scheduled. Manual or automated action is taken to complete the activity/maintenance.

5.7.2. Detect Issue Stage

Description

The purpose of the value stream stage “Detect Issue” is to detect issues in an Actual Product Instance or system that has caused or may cause degradation of the service or breach the agreed service levels, then to prioritize and assign them for further diagnosis in a structured and repeatable manner.

Table 26. Detect Issue Value Stream Stage

Entrance Criteria:

  • Monitoring and analytical tooling continuously monitors an Actual Product Instance or system for issues or triggers for proactive or self-healing maintenance activities

  • The service desk identifies and raises issues based on support interactions

Exit Criteria:

  • Prioritized list of issues and/or maintenance activities assigned to a resolver group to diagnose or review

Value Item:

  • The Actual Product Instance is continuously monitored for anomalies, issues, or alerts for maintenance activities

  • The service desk supports consumers of the Actual Product Instance and assigns Incidents

Activities:

  • Should proactively monitor the Actual Product Instance to:

    • Discover the Actual Product Instance and system topology

    • Track usage to support charging and licensing

    • Detect current or potential future issues in the Actual Product Instance or system that may impact:

      • Agreed service performance levels

      • Service security

      • Compliance policies

    • Identify and report patterns and trends

    • Detect incoming issues from the service desk or reported through a self-service mechanism

  • Shall create Events and/or Incidents when defined policies or thresholds are breached

  • Should correlate Events and/or Incidents with other Events and/or Incidents to determine impact for the Digital Product Instance or system

  • Shall assign prioritized Events and/or Incidents to a resolver group considering the impact on value realization based on a complete and up-to-date overview of all managed Events or Incidents

Examples of Participating Stakeholders:

  • Compliance Manager

  • Consumer

  • Development Team

  • Security Analyst

  • Service Desk Agent

  • Support Specialist

5.7.3. Diagnose Issue Stage

Description

The purpose of the value stream stage “Diagnose Issue” is to prepare the best/quickest course of action to retain or restore normal operations. Further diagnosis can be performed to identify the root cause(s) of a potential or detected issue.

Table 27. Diagnose Issue Value Stream Stage

Entrance Criteria:

  • Prioritized list of issues and/or maintenance activities assigned to a resolver group to diagnose or review

Exit Criteria:

  • Validated course of action as a (first) measure for issue prevention or issue resolution is defined and assigned

  • Actual Product Instance or system problem areas identified by the problem analyst, as input for the Development team Product Backlog

Value Item:

  • Course of action defined for issue prevention or remediation and assigned to the resolution group

Activities:

  • Should understand severity, business impact, escalation paths, and find fixes by consulting the knowledge base or accessing up-to-date information from the Digital Product lifecycle

  • Should find quick fixes and/or work-arounds

  • Should identify root causes

  • Shall propose a course of action or activities needed to start, change, restore, or stop service operation levels

  • Shall approve the proposed course of action steps as a valid measure to resolve an Incident or to retain/resolve service operation

Examples of Participating Stakeholders:

  • Chief Security Officer

  • Consumer

  • Development Team

  • Risk Analyst

  • Security Analyst

  • Service Desk Agent

  • Vendor Manager

5.7.4. Resolve Issue Stage

Description

The purpose of the value stream stage “Resolve Issue” is to execute the (prepared) course of action to retain, restore, and confirm normal service operations.

Table 28. Resolve Issue Value Stream Stage

Entrance Criteria:

  • Validated course of action as a (first) measure for issue prevention or issue resolution is defined and assigned

Exit Criteria:

  • Resolved issue for the Actual Product Instance or system

  • Resolution acceptance is asked to the consumer

  • The consumer provides feedback based on the resolution by the team or team member

  • Updated Knowledge Item usability rating

Value Item:

  • Service level for the Actual Product Instance or system is maintained or restored

  • Consumers have not been impacted or can continue to use the Actual Product Instance or system

Activities:

  • Shall ensure everything is in place to resolve Incidents and/or related Events

  • You should collaborate on the execution of the course of action (e.g., a Pipeline or Runbook) and implementation of changes for the Actual Product Instance or system where applicable

  • Should validate success by performing post-execution checks and obtaining consumer acceptance

  • Shall close related Incidents, Interactions, and/or Events

Examples of Participating Stakeholders:

  • Chief Security Officer

  • Consumer

  • Data Protection Officer

  • Development Team

  • Security Analyst

  • Service Desk Agent

  • Vendor Manager