The Open Group IT4IT Standard, Version 3.0

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.

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, and any known policy 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.

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.

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.

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.

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.

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.

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.

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 Assessment (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.

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.

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.

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.

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.

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.

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.

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).

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 KPI targets. Additional training of specialists for the Operate value stream, 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:

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.

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.

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.

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.

Description

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

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:

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:

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:

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:

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.

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.

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.

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:

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:

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:

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.

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.

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.

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.

Description

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

Description

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

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.

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 Business Impact Analysis (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.

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.

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.

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.