4. Digital Product

4.1. Summary

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.

4.2. Introduction

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.

4.3. Merging Application and Service Definitions into Digital Products

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

4.4. Digital Product Definition

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 product is the item offered for sale. A product can be a service or an item. It can be physical or in virtual or cyber form. Every product is made at a cost and each is sold at a price. The price that can be charged depends on the market, the quality, the marketing, and the segment that is targeted. Each product has a useful life after which it needs replacement, and a lifecycle after which it has to be re-invented.”

A “Digital Product” can be defined as:

“A service, physical item, or digital item that provides an agreed and specific outcome for a consumer; that incorporates and requires software to realize that outcome; that is expected to require active management of the software and its required resources over its lifecycle, in a manner prescribed by the provider; and that is described by a formal offer of the outcome to be provided in exchange for an explicit price.”

The criteria of a Digital Product:

  • A Digital Product must include one or more Service Offers which define Service Contract options for consumers

  • A Digital Product may be delivered as a Digital Product Instance (defined below) as described in the Service Offer

  • The Digital Product Instance may include a system containing IT, non-IT resources, and software

  • A Digital Product may be consumed within an organization or externally

  • A Digital Product may have dependencies on other Digital Products

  • A Digital Product may be comprised of other Digital Products

  • A Digital Product may be a resource for other Digital Products

  • A Digital Product must provide interactions via machine and/or human interfaces

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.

4.4.1. System Definition

The system comprises those technology components of a Digital Product Instance that will be managed by the provider.

Software, compute, and networking hardware are the most common system resources integrated into Digital Products. This may include custom and externally sourced software that may change frequently through Agile processes.

The system recursively includes any supporting resources upon which the system relies, including other products. Resources might be as simple as a few intangible lines of code to be deployed on hosted infrastructure in the cloud, or might be comprised of a large and complex number of components.

4.4.2. Service Offer Definition

The Service Offer (sometimes shortened to Offer) describes possible Service Contract terms as perceived by the potential consumer of a Digital Product Instance. The Offer must include all the elements that will become part of the contract if the Offer is accepted.

It formalizes the value statement and contract terms for consumer/provider interactions. The promises articulated in the Service Offer are recorded in a Service Contract as part of the agreed criteria for how the system will be managed and supported throughout its lifecycle. Longer-term contracts may be defined as subscriptions that track ongoing consumption and billing.

The Offer is derived from the Digital Product definition, which includes all available consumable variants, and all possible contract terms. A product may in theory provide as many unique Offers as there are prospective types of consumer.

Service Offers
Figure 10. Pricing Table

A consumer can either be a human or internal employee actor, a paying customer, or alternatively a machine actor such as another Digital Product. The structure of both the Offer and the Service Contract may vary significantly based on the type of actor involved, and how a particular product is to be consumed.

4.4.3. Contract Definition

When an Offer is accepted by a consumer, an Instance of the Digital Product is created in which the relationship between provider and consumer is captured in a contract based on the relevant Offer. The contract includes all the details required for financial recording, governance, measurement, charging, support, and servicing of the Digital Product Instance.

A contract for a Digital Product may include a subscription that describes the ongoing usage rights for a consumer, with periodic charges.

For example, a Wi-Fi network in a public place is made available to consumers. When a consumer logs on to the network using the credentials supplied by the network owner, a Digital Product Instance is created. The product is not the Wi-Fi network itself. The product is the provision of access to the network and its resources. This product incorporates other Digital Products including, at a minimum, the Wi-Fi router. The contract may be implicit or explicit, and will likely be governed by a range of legal and technical constraints, all of which form part of the contract.

In its simplest form, a Service Contract may record a single transaction that is not normally expected to have recurring charges, usage charges, or to require support. However, even such a one-off transaction will typically include mutual commitments to rules and metrics about possible future circumstances governed by the contract terms, such as regulatory compliance, warranty, repair, refunds, Service-Level Agreements (SLAs), consumer support, product recalls, offers on related items, commitments to keep the software up-to-date, and so on.

The contract structure includes Offer terms as agreed upon for the Digital Product Instance. The interaction process described in the Consume value stream addresses all the concerns for this interaction with a consumer, to include the following:

  • Warranties and SLAs

  • A record of the transactional commitments made by both parties

    For a consumer Digital Product sold online, this may be an identifier for a series of web page interactions in which terms are accepted and money is taken. For an internal machine-to-machine contract, this may be the digital record of a “handshake” acknowledgement between two systems.

  • Usage and financial rules, especially where there is a recurring financial payment

    In the IT4IT Standard, this contract data forms the basis for managing chargeback/showback, and penalties for the breach of SLAs.

  • A description of the usage monitors needed for governing the Digital Product Instance to ensure operational status

    Depending on the relationship between the provider and the consumer of the product, this may include legally binding terms with provisions for events such as returns, subscription renewal, refunds, warranty claims, recourse for breach, and so on.

  • A right for the provider to audit the consumer for such things as license compliance audits or conformance to usage rules

  • Long-term ownership rights to physical components or assets

  • Lifecycle management expectations such as support, updates, replacement, or retirement

4.4.4. Price Definition

Each Service Offer and Service Contract describes a price which may require direct payment by a consumer through the Chargeback Record and may include an ongoing subscription.

Price need not be related to cost and is merely relayed to the customer as showback. In some cases, the price may consist entirely of indirect benefits anticipated by the provider with no financial charge at all.

The element of chargeback and showback at a minimum is meaningful for effective reporting and Product Management. In every offering, a Product Manager should be able to describe the Return on Investment (ROI) over the product lifecycle. Offering a Digital Product Instance with no direct price should always be a deliberate pricing decision that is explained in the product’s lifetime financial model.

In cases where the Digital Product is perceived by the consumer primarily as software, it will always include other components defined by the Digital Product Manager, including those required by the business or legal context of product delivery, as well as the provision of a supporting infrastructure.

These other associated components – which may not be explicit in the Offer or Service Contract – may include hardware in which software is embedded (disk drive, smartphone, IoT doorbell, automobile). They may also include contractual elements (SLAs, chargeback terms, warranties, software maintenance commitments, customer support).

4.5. From IT Service to Digital Product

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.

original IT service model
Figure 11. Original IT Service Model

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:

  • Replacing “IT Service” with “Digital Product” as the main entity managed across the IT Value Network

  • Narrowly defining Service System to focus on technical and data components that deliver outcomes

  • Changing “Service System” to simply “System”

digital product
Figure 12. Digital Product Interaction

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:

  • The Service Interaction is a process or event, and depicted in the Consume value stream

  • The System is a set of configured software, compute, devices, technology, information, and subscriptions to dependent Digital Product systems, as depicted in the Actual Product Instance

  • The Service Offer is a description of the service consumable, based on product rules and in some cases may be dynamically created as described in the Offer functional component

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.

4.6. Examples of Digital Products

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.

4.6.1. eCommerce Websites

A website that provides functionality for shoppers and vendors to reach a commercial agreement is a typical Digital Product. The consumer of this Digital Product would be the vendor’s Sales Department(s), not the shopper.

The ecommerce website may be comprised of several Digital Products. These may have different functionalities to support other users, such as those who maintain site data or manage financial transactions. The different functionality may also be different Digital Products.

4.6.2. Mobile Applications

Mobile applications are Digital Products. Most are provided through a store managed by the digital platform provider. They may also be linked to other products, physical, and digital. Fitness mobile applications typically require a separate physical device to track motion and location. Other mobile applications act as channels to Digital Products, such as a newspaper subscription or online banking.

Digital Products are often comprised of other Digital Products, or are dependent on other products to provide a complete outcome.

4.6.3. Operational IT

Digital Products can also automate manufacturing, warehouses, or other automated activities. This is commonly known as Operational IT (OT).

For example, OT for managing a wind farm may monitor and adjust equipment, create orders for planned and unplanned maintenance, or change operational characteristics due to weather events and forecasts. There may be a network link to allow software updates to be applied on an ongoing basis.

In factory automation there may be dozens or hundreds of smart OT devices, for which software may be updated frequently to implement changes driven by data gathered from the devices. The possibility of such a continuous improvement feedback loop means that software design can be more Agile and at the same time more complex than the design of traditional embedded systems for which firmware updates may be expensive and complicated, or even impossible.

4.6.4. Smart Devices with Digital Interfaces

This is a rapidly growing category of internet-connected products ranging from smart watches to automobiles that combine a traditional physical product format with software to create Digital Products. These smart products do not contain only the physical device and its embedded software; the core product definition may also include cloud-based software and software running on other platforms, such as smartphones. For example:

  • A digital oven that can be programmed by scanning a barcode on a food package using a mobile app, providing the oven with cooking instructions via a cloud-based cooking instruction look-up system; alerts can be sent to a smart watch to inform the user that cooking is complete

  • A modern car, containing more lines of code than Microsoft® Windows® 10, for which updates are routinely pushed from the car manufacturer, and which can be monitored and controlled from miles away using a smartphone app

    The product definition includes software in the car and the app, software elsewhere in the supporting ecosystem, and all the mechanisms needed to keep the software up to date.

Figure 13. Digital Watch

4.6.5. Digital Platforms

An important category of Digital Product is the digital platform. This product is designed to enable the creation or hosting of other Digital Products which can be sold or shared with consumers.

Common examples of how this works in practice include the app stores available to Apple® and Android™ customers, or the Azure® and Amazon Web Services™ platforms that provide a range of easily orderable plugins, and also the ability for users to create their own.

There are many types of platforms that use the same model:

  • Platform as a Service (PaaS) raw compute and virtual compute

  • Software as a Service (SaaS) platforms accessed in the cloud

  • Low code/no code development

  • Content platform, such as for music, videos, and documents

  • Digital Services, such as connecting drivers, passengers, and deliveries

  • Software applications that rely on shared platform capabilities, such as smartphones, TVs, and platforms built for Sales, Human Resources (HR), or IT Management

Many digital platforms incorporate shared resources, such as platform-specific development tools, an integrated store for configuring or adding features through plugins, platform-dependent application management, self-service interactions for purchase, and knowledge and support features.

4.6.6. Interplay Among Digital Products

The digital oven example in Section 4.6.4 illustrates an accelerating trend in which collaboration between interacting Digital Products adds greater value than when they function independently.

The oven example of an IoT-based product reflects marketing collaboration among multiple Product Managers of the oven, the watch app, the phone app, and the food-cooking instruction suppliers. All this functionality is embodied in software created by each company involved and supported by interoperability standards such as O-DEF™, the Open Data Element Framework, Version 2.0, a standard of The Open Group [C202] and the Open Messaging Interface (O-MI), The Open Group Standard for the Internet of Things (IoT), Version 2.0 [C19E]. The result is a value-added ecosystem which others can join – or from which competitors can be excluded.

This interplay creates opportunities and data for all parties. The data and ongoing consumer feedback received helps the Digital Product Manager to make decisions such as adding features, improving performance, adjusting pricing models, and updating market strategies.

4.7. Granularity and Dependency of Digital Products

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

  • An app that offers room booking or transportation may rely on a cloud-based Digital Product providing mapping-as-a-service

  • A web or mobile app-based streaming video service may rely on a separate platform of web service products to manage and provide streaming content

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.

4.7.1. Examples of Digital Product Granularity

Consider an insurance policy (a type of Digital Product) that relies on software to calculate premium charges.

Case A
The insurance company uses a third-party software package and signs a license agreement allowing use of the software. The agreement is a contract for a Digital Product Instance and defines the exact details of how the insurance company can use the software, including pricing and payment terms. The contract will also include vendor guarantees of calculation accuracy and system performance, and may define penalties and liability for failures. Information about this contract should be easy to incorporate into the design of the insurance product to meet stipulations of compliance and audit, consumer needs, and warranty. The cost of the calculation system’s software license – as well as risk management for possible errors – will be a factor in setting valuation and pricing rules for the insurance “book” that represents the affected product line.

Case B
The software used to calculate premiums is created, managed, and supported by a separate in-house department. Is it a “product”? Should it still be managed as a Digital Product? If not, will there be the same confident understanding of long-term cost and risk for this software over the life of the insurance “book”? Does using in-house software make it any less important to track the cost of the calculations, to define and manage expected performance, or to analyze the risk and liability of incorrect calculations?

4.8. Benefits of Formalism between Internal Digital Product Teams

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:

  1. It may create an objective basis for understanding financial outcomes and value for the sub-component products. Increased formalism and consequential measurement practices provide continuous visibility of the operational and financial data needed to support full lifecycle Product Management, providing the same level of insight and routine control provided by Enterprise Resource Planning (ERP) systems or by cloud platform providers.

  2. It may provide the data collection processes needed to understand internal products by the same standards used for externally sourced products. This can result in a more objective comparison of options. In some cases, an internally sourced product may be a candidate external product in its own right. Alternatively, an apples-to-apples comparison of well-defined internal and external products could provide the case for replacing internal products with more viable external options.

  3. It may support long-term planning of the product lifecycle and the management of technology risks. Roadmapping and investment planning can become more proactive and long-term (as opposed to reactive and ad hoc). The use of automated reports can reveal concerns about the full stack of components such as end-of-life, security vulnerabilities, and compliance.

4.9. Managing the Digital Product

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

  • Market-facing: primarily for use by external customers

  • Internal-facing: primarily to improve employee experience or productivity; may replace employees with fully autonomous processes

  • Foundational: a combination of both

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:

  1. Digitizing internal processes that improve employee productivity and experience

  2. Creating digital offerings for the market to improve customer experience

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.

digital product portfolio
Figure 14. Digital Product Portfolios

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.

4.10. The Digital Product Manager

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

  • Technology competency based on a functional understanding of relevant technologies, including a meaningful understanding of how those technologies are created and managed over time

  • Product Management marketing competency that includes an understanding of markets, consumers, distribution, logistics, customer value propositions, and financial aspects of products

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.

4.11. Shared Resources

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.

4.12. Digital Product Lifecycle Concerns

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

  • System Lifecycle (the managed IT component of the product)

  • Contract Lifecycle (governs consumed instances, warranties, commitments, and dependent systems)

product lifecycle
Figure 15. Digital Product Lifecycle Management

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.

4.13. Code, Dependencies, and Instance Resource Management

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.

4.14. Data-Driven Opportunities and Concerns

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.

4.15. Service Contract Lifecycle Concerns

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.

4.16. Digital Product Fulfillment and Lifecycle Management

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.

instance event
Figure 16. Digital Product Fulfillment Event

4.17. The Digital Product Instance

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.

digital product instance
Figure 17. Digital Product Instance Structure

4.18. Consumer Types and Interaction Methods

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.

consumer types
Figure 18. Consumer Types

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:

  • May have internal consumers, such as employees or departments

  • May have external consumers or corporate customers and partners

  • May have internally exposed APIs, integrations, and processes

  • May have externally exposed APIs, integrations, and processes

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.

4.19. Complex Digital Product Systems

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.

digital product contract
Figure 19. Typical Contractual Mesh Among Digital Products

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.

4.20. Conclusion

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.