The Open Group IT4IT Standard, Version 3.0

This chapter describes the Digital Product: the single, simple, unifying entity referenced over the full management lifecycle and across all the value streams in the IT4IT Standard. It encapsulates the traditional management and deliverables of technology-based products and services. The definition of Digital Product describes what is managed, incorporating the main concerns of both traditional applications and services management, as well as meeting the need for Agile and DevOps practices where Product Manager or Owner roles are responsible for everything associated with a product, from funding through support activities. The Digital Product, as defined here, integrates traditional Product Management acumen with IT management disciplines, whether for internally or externally consumed digital offerings.

The rationale behind the Digital Product-oriented thinking is The Open Group White Paper The Shift to Digital Product: A Full Lifecycle Perspective [W205], where a proposed Digital Product definition, with examples, was initially documented. In the paper, a proposal was made to evolve the IT4IT Standard in order to better address the full lifecycle management intent of the standard with a more modern approach of a product-oriented IT management operating model.

Digital Product Portfolios, as described in the IT4IT Value Streams, reference aspects of the Digital Product along its lifecycle stages, including related data entities such as instances, source code, backlog, resources, subscribers, and incidents. The IT4IT data model and functional components reference the Digital Product to simplify traditional IT management disciplines where either application or service were previously used, often ambiguously.

Digital Product as a new entity provides an abstract definition that is applicable to a wide variety of product and IT management scenarios while addressing lifecycle management disciplines, regardless of the size, scope, and architecture of the Digital Product. The intent of our definition is to combine end-to-end management disciplines that include traditional IT Operations Management and IT Service Management (ITSM) with the product financial, marketing, and management concerns.

Establishing a single, well-defined concept for a Digital Product creates a fulcrum within the IT4IT Value Streams and functional components that promotes cooperation across disparate roles. Reporting, Financial Management, and team structures can better understand what they are working on, and what consumers they serve.

We extend the initial Digital Product definition into what we call a Digital Product Backbone, which elaborates on the Digital Product deliverables that support all stages in the lifecycle from planning, through operations, consumption, and support activities. The backbone ensures traceability, which is required to understand how investments impact the consumer and how consumer experience is traced back to initial investments.

In defining the Digital Product with a mapping across the entire IT4IT model, we bridge the disparate management practices and disciplines in each area and component to address traceability, delivery and reporting concerns; see Figure 2.

In the IT4IT Standard, Version 2.1 [C171], as well as in ITIL and other service management practices, “service” has been used to describe the core element that IT should be managing throughout its lifecycle. Application is the common portfolio used for planning and development activities. A simplified approach using one abstract unifying term, “Digital Product”, to relate to all aspects of the IT context solves contextual challenges and removes ambiguity.

A “Digital Product” aligns with the semantics of IT trends (such as DevOps and Agile practices and IT management “Project to Product” shifts in Financial Management), reorganizing work from separate silos along the lifecycle to a single cross-functional team.

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

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

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 more 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 lifecycle of the contract is predicated on the existence and management of the system that is used by the consumer. The system(s) should not be retired until all contractual obligations are met, or the contract is terminated per the provider/consumer agreement.

The provider may choose to end a contract with the consumer, ceasing to support the underlying system and effectively ending obligations to support or warranty the system per the contract. This can leave consumers frustrated with regard to being able to retrieve critical data, being able to migrate to alternative systems, or being able to maintain the system on their own. In some situations, consumers have banded together to continue supporting Digital Products long after the support from the provider has ceased. A Digital Product Manager must consider these end-of-life scenarios and provide consumers with recourse when facing end-of-life situations.

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

The main objective in defining a Digital Product is to establish more rigorous management practices to apply the IT4IT Value Streams to all Digital Products recursively and to manage them using the same IT4IT Standard definitions, regardless of where they are located in the organization. This approach provides a clear understanding of the technology investment and the value to consumers. As more formal dependencies are managed through Service Contracts and Subscriptions, the roll-up of costs, accountability, and commitments are better understood allowing the organization to make better business decisions on technology spend.

Organizations wishing to adopt the Digital Product Management approach can apply the IT4IT Standard and tooling ubiquitously, ensuring the rigor of proper management and cost accounting practices are in place for Product Managers and other stakeholders to report on and make management decisions to invest, or divest in Digital Products, no matter where and how they are used.

The Digital Product concept described in this chapter simplifies the management approach described in the rest of the IT4IT Standard that strengthens the core management functions and tools for all teams involved in creating, using, and selling Digital Products.