5. IT4IT Value Streams
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
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.
In the following sections we document the scenarios and stages of the Evaluate value stream:
-
Scenario: Consider a New Digital Product
-
Scenario: Perform Digital Product Governance
-
Scenario: Rationalize the Product Portfolio
-
Scenario: Plan Product Portfolio Investments
-
Stage: Gather Influencers
-
Stage: Identify Gaps
-
Stage: Propose Investments
-
Stage: Define Backlog Mandates
-
Stage: Ensure Governance
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
5.2. Explore Value Stream
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.
In the following sections we document the scenarios and stages of the Explore value stream:
-
Scenario: Investigate a New Digital Product Idea
-
Scenario: Optimize a Digital Product
-
Scenario: Refine Digital Product Feasibility
-
Scenario: Retire Digital Product
-
Stage: Prioritize Backlog Items
-
Stage: Refine Product Backlog
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
5.3. Integrate Value Stream
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.
In the following sections we document the scenarios and stages of the Integrate value stream:
-
Scenario: Develop a New or Initial Product Release
-
Scenario: Configure an Off-the-Shelf or SaaS Product for Use
-
Scenario: Deliver an Emergency Change or Hotfix
-
Scenario: Update of a Vendor Product
-
Stage: Plan Product Release
-
Stage: Design & Develop
-
Stage: Build, Integrate, & Test
-
Stage: Accept & Publish Release
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
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).
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
5.4. Deploy Value Stream
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.
In the following sections we document the scenarios and stages of the Deploy value stream:
-
Scenario: Deploy a First Product Release for a New Digital Product
-
Scenario: Deploy a New Product Release Version for a Digital Product
-
Scenario: Disable or Remove Existing Product Release Instances of a Digital Product
-
Stage: Plan & Approve Deployment
-
Stage: Fulfill Deployment
-
Stage: Validate Deployment
-
Stage: Observe Deployment
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
5.5. Release Value Stream
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.
In the following sections we document the scenarios and stages of the Release value stream:
-
Scenario: Release a New Service Offer
-
Scenario: Change an Existing Service Offer
-
Scenario: Bundle Existing Service Offers
-
Scenario: Terminate a Service Offer
-
Stage: Define Service Offer
-
Stage: Implement Service Offer
-
Stage: Publish Service Offer
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
5.6. Consume Value Stream
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.
In the following sections we document the scenarios and stages of the Consume value stream:
-
Scenario: Order a New Desired Product Instance
-
Scenario: Order an Actual Product Instance Support
-
Stage: Select an Offer
-
Stage: Agree to Service Offer
-
Stage: Subscribe to Service Offer
-
Stage: Provide Service Support
-
Stage: Publish Service Status
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
5.7. Operate Value Stream
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.
In the following sections we document the scenarios and stages of the Operate value stream:
-
Scenario: Remediate an Identified Back-End Issue
-
Scenario: Ensure Disaster Recovery Objectives
-
Scenario: Remediate a major Event or Incident
-
Scenario: Remediate Consumer Front-End Issue
-
Scenario: Perform Scheduled Maintenance
-
Stage: Detect Issue
-
Stage: Diagnose Issue
-
Stage: Resolve Issue
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |
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.
Entrance Criteria:
|
Exit Criteria:
|
Value Item:
|
|
Activities:
|
|
Examples of Participating Stakeholders:
|
Participating Data Objects (Component): |