The Open Group is a global consortium that enables the achievement of business objectives through technology standards. With more than 870 member organizations, we have a diverse membership that spans all sectors of the technology community – customers, systems and solutions suppliers, tool vendors, integrators and consultants, as well as academics and researchers.

The mission of The Open Group is to drive the creation of Boundaryless Information Flow™ achieved by:

Further information on The Open Group is available at www.opengroup.org.

The Open Group publishes a wide range of technical documentation, most of which is focused on development of Standards and Guides, but which also includes white papers, technical studies, certification and testing documentation, and business titles. Full details and a catalog are available at www.opengroup.org/library.

The IT4IT Forum is a group of member organizations that work together to solve shared challenges in Digital Product Management in the digital enterprise.

The mission of the IT4IT Forum is to continuously develop and drive the adoption of an open standard that:

A key objective of the IT4IT Forum is to drive adoption of the IT4IT Standard through a variety of activities including publishing how-to guides in the IT4IT extended body of knowledge.

The IT4IT Forum is composed of a diversity of member organizations, such as technology vendors, service providers, consulting companies, end-user organizations, training companies, academic institutions, and other digital enterprises. All come together in a technology independent, industry independent, and vendor-neutral environment to work together in a non-competitive, consensus-driven environment governed by The Open Group Standards Process.

Member organizations and their employees that participate in the Forum activities can expect benefits, including:

Proposals from IT4IT Forum members drive the strategy and content for successive versions of the IT4IT Standard. If you would like to contribute to future versions of the IT4IT Standard, we invite you to explore membership in The Open Group IT4IT Forum.

For further information about membership in the IT4IT Forum, visit http://www.opengroup.org/it4it-forum.

For further information about the IT4IT Standard itself, visit http://www.opengroup.org/it4it.

This document is the specification of The Open Group IT4IT Standard, Version 3.0, a standard of The Open Group.

The IT4IT Standard addresses a critical gap in the Digital Transformation toolkit: the need for a unifying architectural model that describes and connects the capabilities, value streams, functions, and operational data needed to manage a Digital Product Portfolio at scale.

Traditional management paradigms, in which the technology budget is a combination of one-off projects and keep-the-lights-on operations, have constrained the value that could be delivered by technology. A fundamentally different approach is needed.

In recent years, this need continues to evolve rapidly as business management itself has become digital management. In other words, as the business delivers Digital Products, IT becomes the business.

By showing how to shift the focus of digital investment from project expense to product-based value delivery, the IT4IT Standard provides a powerful model for standardizing the digital automation fabric to support constant innovation and accelerated digital service delivery.

The ultimate target is a new style of technology management – “managing digital” – in which the primary metric for measuring IT investment value (and for measuring the performance of IT leaders) is the level of innovation and measurable business value delivered by a well-managed Digital Product Portfolio.

The following topics have been included/enhanced in Version 3.0 of the IT4IT Standard:

A common question is: what is the relationship between the new value streams in Version 3 and the value streams in Version 2.1?

Although strongly connected by data integrations and data flows, the original four IT4IT Value Streams are aligned to traditional IT organizational structures, which in most companies represented functional and cultural silos.

As the IT4IT Standard evolved into Version 3, IT organizations were also evolving and the old silos were giving way to concepts such as cross-functional development teams, new IT investment models, and DevOps integrations of development, deployment, and operations.

The new value streams in Version 3 take this evolution of industry into account, and align with modern IT management directions that are moving ever more strongly away from silos and toward the end-to-end integration of managing digital.

A close examination of both versions of the standard will quickly reveal the relationship between the old and new value stream definitions, and point the way to a migration path for those who have already implemented against the older version:

Normative references for this standard are defined in Section 1.3.

The following documents are referenced in this standard or provide further information:

The Open Group IT4IT™ Standard, Version 3.0, describes a reference architecture that can be used to manage the business of Information Technology (IT) and the associated end-to-end lifecycle management of Digital Products.

It is intended to provide a prescriptive Target Architecture and clear guidance for the transformation of existing technology management practices for a faster, scalable, automated, and practical approach to deploying product-based investment models and providing an unprecedented level of operational control and measurable value.

This foundational IT4IT Reference Architecture is independent of specific technologies, vendors, organization structures, process models, and methodologies. It can be mapped to any existing technology landscape. It is flexible enough to accommodate the continuing evolution of operational and management paradigms for technology. It addresses every Digital Product lifecycle phase from investment decision-making to end-of-life.

Refer to The Open Group website for conformance requirements for this document.

This document contains provisions which, through references in this standard, constitute provisions of The Open Group IT4IT Standard. At the time of publication, the edition indicated was valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent edition of the standard listed below:

ArchiMate^® 3.1 Specification (C197), a standard of The Open Group, November 2019, published by The Open Group; refer to: www.opengroup.org/library/c197

For the purposes of this document, the following terminology definitions apply:

It is expected that this document will need to be revised from time to time to remain current with both practice and technology.

The relationship between provider and consumer when an Offer is accepted by a consumer and an instance of the Digital Product created.

Note: Contract is defined in detail in Section 4.2.3.

A service, physical item, or digital item that provides an agreed and specific outcome for a consumer, and that incorporates and requires software to realize that outcome.

Note: Digital Product is defined in detail in Section 4.2.

A key data object in the IT4IT Reference Architecture that annotates an aspect of the Digital Product model in its planning, development, consumable, or running state.

Note: Digital Product Backbone data object is defined in detail in Section 11.7.8.

The smallest unit of technology that can stand on its own and be useful as a whole to a Digital Practitioner (or IT organization)

Note: Functional component is defined in detail in Section 11.7.4.

Data (records, information, and so on) that annotate or model an aspect of a Digital Product being planned, developed, offered, or consumed.

Note: Key data object is defined in detail in Section 11.7.5.

Possible Service Contract terms as perceived by the potential consumer of a Digital Product Instance.

Note: Service Offer is defined in detail in Section 4.2.2.

A key data object in the IT4IT Reference Architecture that controls and defines the consumption of a Digital Product.

Note: Service Offer Backbone data object is defined in detail in Section 11.7.9.

Technology components of a Digital Product Instance that will be managed by the provider.

Note: System is defined in detail in Section 4.2.1.

A synonym for a system that contains and/or controls authoritative source data.

Note: System of record is defined in detail in Section 11.7.6.

A construct that defines the relationships across the value-creating functions that deliver value.

Note: Value Network is defined in detail in Section 11.7.1.

The key value-creating activities for discrete areas within the Value Network where some unit of net value is created or added to the Digital Product as it progresses through its lifecycle

Note: Value stream is defined in detail in Section 11.7.2.

At the most basic level, the IT4IT Standard defines the “Digital Management” of “Digital Products” in order to create an efficient value delivery. This is illustrated in Figure 1.

A basic understanding of a few foundational IT4IT concepts is necessary for any detailed understanding of the material that follows: the standard describes how data objects, functional components, and value streams interact to deliver business value. Each is discussed briefly here. Formal definitions of these and other terms can be found in Chapter 11.

Data objects: The most critical element of the IT4IT Standard is the identification of which information must exist and be effectively integrated for the effective end-to-end management of the Digital Product lifecycle.

The information described by each data object may be stored in a database table but the storage method is not specified by the IT4IT Standard. Likewise the format of an instance of a data object can be any relevant format (e.g., model file, source file, script, executable file, a development deliverable, a word processing document, a mail message) that can be indexed by its associated functional component.

In many organizations, much of this information is held in informal, poorly managed, or poorly integrated systems including manual filing systems or as static documents. Part of the IT4IT Standard is about ensuring what data should be identified and which functional component should control the data object through its lifecycle.

Some key data objects make up the Digital Product Backbone: the full description of a Digital Product over its lifecycle.

Other key data objects make up the Service Offer Backbone: the data about the consumption of service delivered by a Digital Product.

Functional components: These define the minimum set of operational functionality essential for effective end-to-end technology management (e.g., Strategy, Product Backlog, Defect, Identity, Incident, and so on). Each is modeled as an Application Function whose job is to control one or more key Data Objects.

The definition of each functional component includes specific functional criteria, which are the minimum operational capabilities, data integrations, and data flows required for the coherence of the full IT4IT model.

Value streams: The architecture describes seven prescriptive value streams (see Section 3.3 and Chapter 5). These business views of Digital Product lifecycle management are broken down into a series of value stream stages that make use of functional components and data objects to deliver a defined outcome. For each value stream, a set of practical examples is provided in the form of business scenarios.

How do these concepts work together? To achieve the high-automation, large-scale vision of the IT4IT model, the functional components would be software components that participate in a fully integrated automated toolchain – a “Digital Product factory” – that maintains full data traceability from concept to deployed Digital Product and delivered service, and for which all value streams and associated data flows and integrations are automated based on a common IT4IT architecture.

The IT4IT Standard is about defining the value stream, the associated functions, and the data objects needed to control the planning, development, delivery, and run management of Digital Products. This can be seen as a factory for digital.

In the rest of this chapter we will outline:

The detailed normative definition of this can be found in Chapters 5 to 10.

Functionality groups provide an abstraction of what is needed to manage the new digital reality in a way that helps to simplify conversations between interested stakeholders. In the IT4IT Standard, we use it to describe a collection of functionality and data that is responsible for a well-defined part of the overall value creation. We describe the groups at a high level, and we decompose one level to have well-defined categories for defining the Supporting Functionality.

The IT4IT Standard defines four IT4IT groups of functions that deliver the outcome for the high-level IT4IT Value Streams. These are known from previous versions of the IT4IT Standard as making up the IT4IT Value Chain:

In addition to these four IT4IT functional groups, digital management depends on a set of Supporting Functions. The IT4IT Standard defines six of these in Chapter 10.

The Supporting Functions are only defined in terms of the minimum functionality they need to deliver in order to support the core of the IT4IT Reference Architecture. Other standards define these capabilities in much more detail and it is not our aim to compete with these standards.

Figure 2 illustrates how the capabilities work together, with the IT4IT Value Streams and the associated decomposition of the concept of a Digital Product.

A traditional model for defining factories is Porter’s Value Chain concept [Porter]. This revision of the IT4IT Standard breaks with the Value Chain model and moves to the more recent concept of the Value Network. This reflects that value creation is a complex interaction within many systems and organizations.

In Figure 3, it is recognized that in addition to the core value stream for managing digital, a complex interaction with a number of supporting capabilities in an enterprise is needed. These functions are not at the heart of the IT4IT Standard, as other standards and frameworks have these functions and capabilities as a focal point.

The Value Network is further defined through the interaction of the Digital Product with customers, business partners, vendors, as well as government and regulatory entities. The Digital Product is creating value for its consumers. The business partners and service providers can both provide resources for delivering Digital Products as well as creating their own value using the Digital Products delivered through the IT4IT Standard. As you develop Digital Products you must comply with government and regulatory rules and thus participate in the value creation of society; see Figure 4.

For the second decomposition, a split is made with the Digital Product as an abstract entity in a set of data objects that form the essence of the Digital Product Backbone. This is complemented with seven new value streams that, together, explain how to define and manage the delivery of digital value.

A value stream is a representation of an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end user. For more detailed treatment of the definition of value streams; see the TOGAF Series Guide: Value Streams [G178].

As shown in Figure 5, the complete set of value streams depicts the various ways in which an organization orchestrates its capabilities to create stakeholder value through Digital Products. The value stream has a direct linkage to an organization’s business model (specifically to the value proposition). As an organization translates its business model to an operating model, those value stream stages can be translated into digital delivery processes as well as related data objects, tools, integrations, etc.

This document defines the following seven value streams: Evaluate, Explore, Integrate, Deploy, Release, Consume, and Operate.

These value streams are briefly introduced and described in the following sections.

The seven IT4IT Value Streams are defined in Chapter 5. Each IT4IT Value Stream depends upon an end-to-end flow of work – via data objects – through multiple functional components to deliver the expected result for the customer, stakeholder, or end user.

The IT4IT Standard defines functional components as the application building blocks for managing Digital Products. Related functional components are associated together into four functional groups. A further decomposition is made from the four high-level functional groups into eight (sub-functional groups that must be established in order to manage Digital Products: Strategy, Portfolio, Develop, Test, Consume, Fulfill, Support, and Assure.

Each functional group manages one or more data objects which are controlled by applications. The integrated data objects comprise the Digital Product Backbone and Service Offer Backbone which ensure traceability through the Digital Product Management lifecycle.

While the IT4IT Value Streams orchestrate, consume and/modify multiple data objects in the flow of work to deliver value, we provide a high-level visualization in Figure 6 where we highlight only the backbone data objects.

These eight functional groups shown in Figure 7 are then populated by 33 functional components that control 44 key data objects. The 44 data objects are manipulated as the seven value streams are exercised: exploring, integrating, deploying, releasing, consuming, operating, and evaluating the Digital Products. The data objects are related to each other and in Figure 7 we show some of the most important relations. For the full list of relations and their associated cardinality see Chapters 6 to 10.

The IT4IT Standard defines seven value streams that manage the Digital Products. Information on the Digital Products is tracked through a set of interconnected data objects managed by functional components. These are the components at the center of delivering the digital management capabilities, as illustrated in Figure 8.

Combining the value streams with the four high-level functional groups results in Figure 5. Combining the value streams with the eight sub-level functional groups results in Figure 6. Combining the data objects with functional components and functional groups results in Figure 7.

For details on the formal object types, metamodels, and associated ArchiMate solution patterns used in Chapter 11, see Figure 9.

In the IT4IT Standard, Version 2.1 [C171] and in typical IT Service Management (ITSM) practices, the term “service” has been used to describe the core consumable output that the IT organization will manage throughout its lifecycle.

“Application” is a common term that overlaps “service” in common IT usage. The word “product”, often used to describe the same concept, has also become popular in Agile practice to reference development teams’ “code” delivery.

While acknowledging the ambiguity arising from choosing any of these terms, a single, simplified approach using one abstract unifying term, “Digital Product”, is used to clarify the intention of how the term “service” was used in previous IT4IT versions, and to consolidate the management aspects required for “application,” “service,” and “product” as described above.

The term “Digital Product” aligns well with recent trends and business semantics (such as those documented in DevOps and Agile practices and illustrated in IT management “Project to Product” directions and associated shifts in Financial Management), and with reorganizing the work of separate silos into single cross-functional teams.

Product Management disciplines have become a focus for traditional IT organizations, and in startup Digital Product teams that need to scale up as they grow. In both scenarios, the IT4IT Standard provides value. Product Management is a proven, mature competency with well established roles, activities, frameworks, lifecycle management approaches, and so on. Adopting “product” as the governing metaphor within the IT4IT Standard brings this acumen to the fore. The IT4IT Standard does not formally define the role of a Product Manager; instead we focus on defining Digital Product in the context of the main value streams, functional components, and data models required to manage them.

The IT4IT Standard is part of a solution set that supports Digital Transformation, connecting proven management practices with newer methods. For many successful organizations, Product Management and IT management roles will converge and unite into a new competency we call “Digital Product Management” a fundamental capability for managing digital.

The Digital Product definition used in the IT4IT Standard highlights the distinction between Digital and non-Digital Products and provides clarity about the use of the term “digital” throughout the rest of the IT4IT Standard.

This definition flows from widely accepted definitions of both “digital” and “product”, brought together to form a unique type of product that incorporates IT management. Merriam-Webster defines digital as “characterized by electronics, especially computerized technology”.

The Business Dictionary defines product as “a good or service that most closely meets the requirements of a particular market and yields enough profit to justify its continued existence”.

The Economic Times defines product in more detail as:

A “Digital Product” can be defined as:

The criteria of a Digital Product:

A Digital Product refers primarily to the perspective of a Product Manager and represents a complete product line over its lifetime, to include product variants, types and locations of consumers, annual and lifetime financial models, dependencies on other products and services, supplier relationships, capacity, service-level options, distribution models, pricing and usage rules, delivery and management of Digital Product Instances, and so on.

In the IT4IT Reference Architecture, Version 2.1, the Service Model Backbone represents the full lifecycle of an IT service, which had previously included services from both a labor and a digital perspective. The Digital Product, however, changes this focus to address technology or code as the main actor in the delivery of an outcome of a service, removing those services performed by human labor.

Figure 11 describes service relationships and interactions from the IT4IT Reference Architecture, Version 2.1. This conceptual view has evolved in this document with a redefinition of the service to a Digital Product concept, exclusively addressing digital type services. In Figure 12, the IT service model has been refactored by:

Figure 12 provides a view for how the Digital Product’s software and supporting technical components interact with consumers, following practices described in the IT4IT Value Streams and functional components:

Figure 12 can be used as a template for the instantiation of a Digital Product Instance, in which a specific Service Offer becomes the basis for a Contract, and a specific subset of system resources is allocated per the Offer and supported in the Operate value stream for the term of the Service Contract.

The examples listed here are consumer products that are easy to recognize. However, the majority of Digital Products are primarily designed to be incorporated within another product. When thinking about a Digital Product we need to recognize that the critical boundary of a product is what a supplier provides to the consumer.

A Digital Product may be composed of, or relies upon, other Digital Products. For example:

The network of dependencies of interconnected Digital Products may be deep, and may form very complex systems.

Each component in the system may be another Digital Product. Each Interaction may have a Service Offer, though sometimes they are not well defined.

Some Digital Products are expected to be shared and used broadly as components or dependencies in more complex Digital Products. Microservices architectures are a common example. For a Digital Product that is an “internal” sub-component or dependency of another Digital Product, some formalism in understanding pricing and contracts helps in three ways:

Digital Product Portfolios are managed from three perspectives, as depicted in Figure 14:

Jeanne Ross et al. made these perspectives clear in Designed for Digital: How to Architect your Business for Sustained Success [Ross et al.]. In this book, the authors explain that there are two areas in which organizations should focus their Digital Transformation:

Figure 14 captures these two perspectives as subsets of the overall Digital Product Portfolio. A third portfolio captures those shared, foundational Digital Products used in both contexts.

Directly linking Digital Product Portfolios to Strategy in this way provides clarity on investment priorities and should reduce bad outcomes in competition for funding. Management agility is improved when analyzing costs, and investment decisions become strategically aligned.

A career and competency of “Digital Product Management” has emerged in which two distinct professional competencies are combined:

Digital Products inherently rely on technology resources and infrastructure such as networking, computers, databases, and software to realize value, each with their own lifecycle and contract and/or subscription.

Digital Products may have shared resources, such as people, marketing, and lifecycle processes assigned to them. Digital Products may have tightly integrated, shared resources dedicated to facilitating delivery, support, and lifecycle management processes for systems and consumer interactions. Shared functionality could include self-updating apps, in-app support processes, in-app usage monitoring, and update processes within a smart device, and so on.

Digital Product Management must address two distinct lifecycle concerns that map to various IT4IT Value Streams (see Figure 15):

The system lifecycle is a familiar concept in IT management. For example, an internal application system remains a subject of active concern for as long as it is in use.

After such a system is decommissioned, we will quickly lose interest in most of the hardware and software. We still must address any residual data retention and disposal requirements, sometimes for many years. This is included in traditional understandings of technology lifecycles.

The contract lifecycle for a Digital Product may be more complex, especially regarding residual or implied lifecycle management concerns for external consumers or for a product that is a sub-unit of another product:

As our societal understanding of digital rights evolves this may include obligations defined after the fact by legislation or court cases.

When the provider ends a contract, thus ending support for the underlying system and explicit support or warranty obligations, terminated consumers may be unable to retrieve critical data, to migrate to alternative systems, or to maintain the system. In these situations, consumers have banded together to continue to support Digital Products long after support from the provider has ceased.

For example, modern farming relies on Global Positioning System (GPS) modules supplied by tractor manufacturers that are used to ensure crops are planted or cultivated in straight rows. Data generated by the system has a financial value to the farmer. Ongoing updates and patches to the software are essential to ongoing product value.

Such a tractor is a Digital Product for which the contractual context can be murky, and this gives rise to litigation and pressure on legislatures about data ownership, rights to use the data, and the “right to repair”:

The manager of a Digital Product must consider end-of-life scenarios such as these and provide consumers with suitable recourse in end-of-life situations. Managing contract risks such as the pressure for “right to repair” becomes part of the Product Management function.

Until a system is retired, its underlying resources and dependencies must be managed until no active consumers depend on it and all instances have been retired, and possibly longer, depending on factors such as regulatory requirements for data retention.

To maintain the operational integrity of a Digital Product, the code, hardware, third-party software (each has their own support lifecycle), and integrations must be managed. Often, dependencies have their own upgrade and maintenance cycles that should be tracked as well.

Digital Products rely on a supply chain that is often real-time: code-executed and data-driven functionality. The Digital Product Manager is accountable for ensuring that dependencies with other Digital Products are managed along with any contractual, financial, and technical requirements.

The rapid cycle time for changes in Digital Products requires a level of automation not needed for more traditional products. Many products receive software updates weekly or even daily. This can only be managed using an automated toolchain and support process. The IT4IT Standard describes how this can be done.

Data, both generated by and used within a Digital Product, presents unique opportunities and advantages, as well as risks if improperly managed. Data can be collected from a wide range of sources to include the consumer, external sources, automatic capture through embedded sensors, or related Digital Products in complex systems. Insights for the consumer or Product Manager can be generated as data is analyzed to provide reports and recommendations, and to take proactive action.

For effective full lifecycle management, policies and controls should be put in place to ensure the information created in the design, creation, management, and support of the Digital Product, and operational support of systems deployed to support Digital Product Instances remain available for a much longer period than is typical in a project-oriented investment model.

Data governance must be effectively applied across the full lifecycle of the product, including data retention management and compliance with privacy and other applicable policies.

The design, planning, source code, and other information created to define and manage the system should be retained for future planning and support purposes. Without this, it is impossible for the Product Manager to track technical, operational, and financial aspects of the Digital Product over time.

The Service Contract exists separately from the digital and physical components of the Digital Product, and may require management for reporting and regulatory purposes long after active users or Digital Product Instances have gone.

A simple example would be a regulatory requirement to retain financial and customer records for a period of time based on laws and regulations in the country of operation.

The fulfillment flow illustrated in Figure 16 demonstrates consumer integration with the Offer. The initial Request to Fulfill process captures the steps involved in fulfilling a request to consume a Digital Product. This often results in allocating devices and resources specific to the consumer, shared resources, and resources from an external dependency, such as another Digital Product.

Figure 17 more fully shows the elements of a Digital Product Instance. This Digital Product Manager’s perspective includes the contract as well as common concerns such as dependencies on other Digital Products, the product team, market and distribution factors, and lifecycle management processes.

Different types of consumer have different expectations and ways to interact with the Digital Product. A robust Digital Product includes a well-defined, detailed Service Offer structure that defines all anticipated consumer interaction methods, and that can be expressed in terms of the consumer contract.

Figure 18 suggests a classification of key consumer types to consider in the Digital Product Offer, interaction methods, and system design: consumers of a Service Offer may be internal or external (or both), and may be machine or person/organization (or both).

Criteria for Service Offer types are:

It is important to set proper expectations for both human and machine consumers in the Service Offer, such as response time, resolution to issues, notification of planned down-time, etc. as described in the Offer functional component. Characteristics may vary across this landscape, requiring different Cost Models, SLA templates, consumption rates, security requirements, and business criticality commitments, resulting in more complex Service Offer definitions, and ongoing Subscription management.

As mentioned above, the resources within the system may include contracts to use other internal or external Digital Products, with both technical and financial dependencies. These third-party dependencies and their explicit or implied contracts are an integral part of product definition, and a consideration in pricing and other management concerns.

Figure 19 shows a more complex view of the possible dependency mesh of a Digital Product.

When more elaborate Digital Product systems are deployed and connected using Service Management models such as ITIL^®, some resources can be managed as Configuration Items (CIs), representing the system’s underlying and integrated resources. Each CI represents a device or software object (such as an executable file for an application, operating system, etc.) that is discoverable when active on the enterprise network, or that has been manually recorded.

A Configuration Management Database (CMDB) is used by most large organizations to manage a subset of possible CIs that has been defined as interesting for management of the IT landscape. Discovery tools or manual data entry are used to capture and update CI information.

More sophisticated CMDBs and CMDB users are able to aggregate individual CIs into a data set that represents more complex and interesting management objects, such as licensed software instances, in-house applications recognizable with a “signature”, etc. A challenge for Digital Product Management is to define the extent to which the Digital Product footprint can or should be recorded using an extended CMDB metamodel.

For example, it may be sensible for each instance of a Digital Product found in the CMDB to include a foreign key pointing to the Subscription record created at instantiation, or to the consumer represented by that record. This or some other mechanism should enable system resources identified in the Configuration functional component to be traceable to those consumers, their Service Contracts, and Subscriptions.

As suggested in Figure 19, interaction among collaborating Digital Products, through Service Contracts and Subscriptions, pertains to both human and machine interfaces, entitlements, ownership, and access to systems.

Underlying code executes within interconnected systems to complete interactions for consumers, and may involve external suppliers as well.

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:

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:

Value streams that depend on the Evaluate value stream are:

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:

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:

Value streams that depend on the Explore value stream are:

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:

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:

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:

Cross-Value Stream Dependencies

The Integrate value stream depends on:

Value streams that depend on the Integrate value stream are:

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:

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:

Value streams that depend on the Deploy value stream are:

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:

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 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:

Cross-Value Stream Dependencies

The Release value stream depends on:

Value streams that depend on the Release value stream are:

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:

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:

Value streams that depend on the Consume value stream are:

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:

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:

Value streams that depend on the Operate value stream are:

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:

The Strategy Function is centered around managing and evolving the digital strategy.