4. Digital Product
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.
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 and a proposal was made to evolve the IT4IT Standard in order to better address its full lifecycle management intent with a product-oriented technology management model, which replaces the traditional practice of viewing IT investment as a combination of project and run costs spread across loosely-coupled silos.
Managing the Digital Product Portfolio becomes the focal point of all IT investment. The Digital Product owner becomes accountable for all value-creation activities associated with a product, from funding through support activities.
This approach integrates traditional Product Management acumen with IT management disciplines. It applies to internally and externally consumed digital offerings. In Enterprise Architecture terms, the consumer of a Digital Product is an actor – individual, organization, or machine.
Only the most granular Digital Products are simple: what seems like a single product to the consumer will usually be made up of a recursive array of sub-products.
The Digital Product is a unifying concept that aligns end-to-end management activities ranging from business strategy through Product Management, development, consumer interactions, and operational support. It promotes cooperation across the disparate roles needed to support cross-functional automation and scaling up of Lean, Agile, and DevOps approaches to software delivery. Team members can better understand what they are working on, and what consumers they serve.
The integrated data objects that comprise the Digital Product Backbone provides the full end-to-end description of a Digital Product. The backbone ensures traceability through the lifecycle, which is required to understand all phases of managing the Digital Product, its impact on consumers, and how consumer experience is traced back to initial investments; see Figure 2.
4.1. Merging “Application”, “Service”, and “Products”
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.
4.2. 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.2.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.2.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.
The Offer 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.
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.2.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.2.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, Internet of Things (IoT) doorbell, automobile). They may also include contractual elements (SLAs, chargeback terms, warranties, software maintenance commitments, customer support).
4.3. 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.
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”
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.4. 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.4.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.4.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.4.3. Operational Technology
Digital Products can also automate manufacturing, warehouses, or other activities outside of typical back-office applications. This more industrial and embedded use of automation technology is commonly known as Operational Technology (OT).
For example, applications are now typically used to manage wind farms, monitor and adjust factory equipment, create tasks for planned and unplanned maintenance, or change operational characteristics due to weather events and forecasts. There may be a network connection to support communications and software updates to be applied on an ongoing basis, much in the same way data centers are managed.
In factory automation, there may be dozens or hundreds of smart OT devices with embedded computers, for which software may be updated periodically to update code and change configurations. 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.4.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 model desktop operating systems, 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.
4.4.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.4.6. Interplay Among Digital Products
The digital oven example in Section 4.4.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.5. 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.5.1. Examples of Digital Product Granularity
Consider an insurance policy (a type of Digital Product) that relies on software to calculate premium charges.
4.6. 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:
-
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.
-
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.
-
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.7. 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:
-
Digitizing internal processes that improve employee productivity and experience.
-
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.
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.
4.8. The Digital Product Management Competency
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.9. 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.10. 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)
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:
-
The lifecycle of the contract depends on the existence and management of the system used by the consumer
The underlying system(s) should not be retired until all contractual obligations are met.
-
The contract lifecycle concept depends partly on maintaining enough information and related capability to ensure that the contractual obligations for every consumer are fully discharged
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”:
-
Can the manufacturer keep the GPS component design and code secret, so that no one else can service the product?
-
Who owns the data created while the product is being used?
-
What happens if the manufacturer discontinues support – can the farmer be forced to buy a new module or even a whole new tractor to stay in business?
-
Can consumers who band together to continue to support Digital Products after support has ceased insist on being given enough information to be able to do so?
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.
4.11. 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.12. 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 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.
4.13. 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.14. 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.
4.15. 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.
4.16. 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.
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.17. 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.
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.