8. Deliver Functions
Description
The Deliver functions (formerly Request to Fulfill) represent a modern, consumption-driven engagement model that goes beyond the traditional service request management. It is a framework for connecting various consumers (business users, technology practitioners, or end customers) with the goods and services that they need to drive productivity and innovation. It fosters service consumption and fulfillment, service costing, knowledge sharing, self-service support, and collaboration between communities of interest to improve the overall engagement experience with IT. Many organizations use multiple technology services and/or service catalogs to address the needs of their consumers. The Deliver functions bring these different catalogs and consumer personas into a single consumption experience, thereby eliminating complexity and confusion for consumers in browsing through multiple service catalogs to choose what services they need.
The Deliver functions contain the following functional components:
-
Consume functionality:
-
Consumption Experience component
-
Identity Management component
-
Offer Management component
-
Order component
-
Chargeback component
-
-
Fulfill functionality:
-
Change component
-
Fulfillment Orchestration component
-
Resource component
-
Fulfillment component
-
Usage component
-
One of the main objectives of the Deliver functions is to drive the System of Engagement (SoE) by facilitating a unified engagement framework between consumers and the other related IT4IT Functional Components. Below are some of the key goals of SoE:
-
Drive the consumption through the unified aggregated catalog
-
Enable collaboration between communities of interest
-
Obtain support through a self-service interface
-
Access knowledge that enables them to be better informed about services offered by IT
Related Value Streams
The following value streams use one or more functional components from the Deliver functions:
-
Release
-
Consume
-
Deploy
Business Benefits
The Deliver functions place emphasis on time-to-value, repeatability, and consistency for consumers looking to request and obtain services from IT. It optimizes both service consumption and fulfillment experiences by delineating between the creation of offers and catalog aggregation. The Deliver functions enable the aggregation of catalogs and Service Offers from multiple service providers into a single consumption experience. Therefore, while there is complexity on the delivery side in managing the various catalogs and Service Offers, it is not exposed to the consumer and the ordering experience is seamless and inviting. This also enables effective chargeback and service costing mechanisms, a key requirement in a multi-sourcing environment.
The key benefits of using the Deliver functions are:
-
Provides a blueprint for increasing business innovation velocity by facilitating a service Consumption Experience that allows consumers to easily find and subscribe to goods and services through a self-service engagement model
-
Provides a functional framework that delineates between a single Service Offer Catalog and Identity Management and Consumption Experience portal to reduce complexity in the consumer experience
-
Provides an architectural foundation for moving from traditional request management to service brokerage that increases both business and effectiveness
-
Increased fulfillment efficiency and consistency through standard change deployment and automation
-
Provides holistic visibility and traceability across the service subscription, usage, and chargeback to improve Financial Management
-
Enables increased cost optimization; for example, by canceling expired Subscriptions and reclaiming resources, Subscriptions, and/or licenses that are unused
8.1. Consume Function
The Consume functionality is centered around making it easy and efficient to consume digital services.
8.1.1. Consumption Experience Functional Component
Purpose
The Consumption Experience functional component is based on an SoE integration design pattern where consumers access different functional components through a common user experience. This enables a centralized location for all kinds of communication channels for consumers (such as chatbots, web applications, mobile applications) to provide a one-stop portal that facilitates the following features:
-
Request a new service
-
Request service support
-
Request service modification
-
Request service termination
This facilitates service consumption by connecting any potential consumer with the right information, goods, services, or capability at the right time through a single and intuitive experience, supporting “click, call, face” principles to get access to the desired support. Self-service concepts are used to limit the interaction flow to people and provide direct remediation, thereby enhancing customer experience.
The Consumption Experience functional component also embraces Customer Journey Mapping; typically the path followed by a consumer when they interact with the Consumption Experience portal. It includes every touchpoint the consumer might run into throughout their interactions with IT, which helps in creating the overall self-service functionality in the Consumer Experience portal that drives improved customer experience.
This provides an interface supported across multiple devices such as smartphones, tablets, etc. and also a plug-and-play connectivity for components that need to be exposed through the portal. Components for connectivity include but are not limited to catalog-driven service consumption.
The Consumption Experience functional component supports the value streams:
Functional Criteria
The Consumption Experience functional component:
-
Shall be available to all users that desire to consume digital services
-
Shall expose functionality based on user profile and entitlement
-
Shall expose relevant aspects of the IT4IT functions and capabilities in a single place, unifying the experience – these functions and capabilities may be exposed in many forms; for instance, a form similar to smartphone apps, a traditional web application, or just as an API
-
Shall determine each interaction, whether it is a Request for Information (RFI), a new Order, a Change, or an Incident, and route them to the appropriate functional component
-
Shall route requests to queues for assignment or assign them to fulfillers automatically
-
Shall provide the interface for consumers to search and read Knowledge Item data objects of all types and sources
Knowledge Item data objects may include but are not limited to technology or supplier-created technical briefs, training videos, and user-created content.
-
Shall reduce the load on the support organization by enabling and promoting self-help and self-healing behavior through the use of community assistance, knowledge sharing, content, etc.
-
Shall enable users to create new support tickets for issues and/or questions that they were not able to resolve, or their questions that remain unanswered
-
Shall enable users to view and update their existing support tickets
-
Shall provide the consumer a view and status update of planned and executed changes
-
Can route users to access the Knowledge Item data objects before a new support ticket is created
-
Can engage Collaboration & Communication secondary functional components to provide the user front end (such as a chat capability) for various purposes including service desk interaction, order routing, or information/knowledge gathering
-
Can provide service consumers with a way to address more of their Digital Product and service-related issues, as well as receive information regarding their existing records without necessarily engaging underpinning providers
8.1.1.1. Interaction Data Object
Purpose
The Interaction data object manages a Consumption Experience for consumers that represents a request for assistance. The Interaction record can be created either through a virtual agent conversation (chatbot), a traditional self-service interface, or service desk agents. The Interaction determines whether the engagement is a new service order, a Change, an Incident, or a simple RFI such as knowledge, contract, chargeback information, etc.
Key Attributes
The Interaction data object shall have the following key data attributes:
-
Id: unique identifier of the Interaction record
-
Description: description of the consumer needs
-
Status: current stage of the Interaction
-
Opened For: consumer who initiated the Interaction
-
Assigned To: name of the fulfiller: live agent name or virtual agent
-
Opened: date and time when the Interaction started
-
Updated: date and time when the Interaction record was last updated
Key Data Object Relationships
The Interaction data object shall maintain the following relationships:
-
Interaction to Identity (n:1): connection to Identity for obtaining the consumer profile and contact information
-
Interaction to Order (n:1): initiates the Order as per the information provided in the Interaction
-
Interaction to Incident (1: n): provides the interface for consumers to submit their own Incidents or break-fix requests
-
Interaction to Knowledge Item (1:n): provides the interface for consumers to search for information about products and services
8.1.2. Identity Functional Component
Purpose
The Identity functional component controls the information about the IT4IT service consumers of the services provided by the Digital Products managed by the IT4IT system. IT4IT service consumers can either be humans or machines who are required to access the Consumption Experience functional component to initiate an RFI, a new Order, a Change, or an Incident. It provides access to the catalog view based on user Entitlement.
The Identity functional component is for managing the IT4IT service consumer identity, and tracking access rights to consume the IT4IT functionality. This facilitates the creation and administration of data used to identify a consumer, authorize, and define the attributes of IT4IT service consumers. This also facilitates the service with extensive information about a user, including address books, preferences, entitlements, and contact information. This information is subject to privacy and/or confidentiality requirements. The Identity functional component provides the required access control mechanism.
Users (Identities) get one or more Entitlements based upon their role and job profile, and through which they are authorized to access specific resources. Accordingly, Orders for these services are automatically approved.
The Identity functional component supports the Consume value stream.
Functional Criteria
The Identity functional component:
-
Shall maintain the confidentiality of information by controlling access
-
Shall ensure that all consumers (humans or machines) and their activities in the Consumption Experience functional component are uniquely identifiable
-
Shall confirm that consumer access to the catalog items data is in line with defined and documented business needs, and that Entitlements are attached to user Identities
-
Shall provide the organization with the ability to meet compliance requirements and to verify adherence to regulations with respect to access to information
-
Shall be able to list all consumers who have access to the Consumption Experience portal, and identify the Entitlement level they have each been granted
8.1.2.1. Identity Data Object
Purpose
The Identity data object identifies, authenticates, and authorizes individuals (machines and users) who are required to access the Consumption Experience engagement portal.
Key Attributes
The Identity data object shall have the following key data attributes:
-
Id: unique identifier value for the Identity
-
Name: name of the Identity
-
Discriminator: indicates the Identity type (i.e., user, agent, group, or role) of the Identity
-
Location: location of an Identity assuming it is a person
-
Creation Date: creation date of the Identity
-
Expiry Date: expiry date of the Identity
-
Organization Id: organization (company) to which the Identity belongs
Key Data Object Relationships
The Identity data object shall maintain the following relationships:
-
Identity to Interaction (n:1): validates the Identity of the consumer and manages their access to the Consumption Experience portal
-
Identity to Order (1:n): validates access, Identity, and Entitlement for the consumer request that directly came to order
-
Identity to Entitlement (1:n): validates the consumer’s Entitlement to the Service Offer as per the attached Entitlement policy
-
Subscription to Identity (n:1): to make an Identity an owner of one or more Subscriptions to manage the Subscription(s)
8.1.2.2. Entitlement Data Object
Purpose
The Entitlement data object is a set of attributes that grants or denies access to Service Offers, Digital Product Instances, and associated resources as per the defined Entitlements, such as Entitlement by organization, department, location, group, employee band, user profile, and country.
Key Attributes
The Entitlement data object shall have the following key data attributes:
-
Id: unique identifier for every Entitlement type
-
Type: whether the Entitlement can only be viewed or ordered
Key Data Object Relationships
The Entitlement data object shall maintain the following relationships:
-
Entitlement to Service Offer (n:1): provides the Entitlement policy that needs to be attached to the Service Offer for validation
-
Entitlement to Identity (n:m): indicates what Identities have the given Entitlement
8.1.3. Offer Functional Component
Purpose
The Offer functional component aggregates all published services, delivered both internally and also from external supplier catalogs, into consumable Service Offers that the user can order through the Consumption Experience functional component. It builds and publishes the various offerings into Service Offer Catalogs for populations to consume, and to determine prices and valid options that consumers can select. It enables Service Offers to be grouped into a single Service Offer Catalog to expose them as a collection of consumable items for a given group of consumers. It ensures all required information is captured for the fulfillment (deployment/delivery) of the service from the Offer template of the Release Composition functional component. It fulfills each Service Offer through numerous underlying Offer templates as determined by this functional component. The offerings typically include the approval mechanisms needed for their fulfillment.
The Offer functional component supports the value streams:
Functional Criteria
The Offer functional component:
-
Shall contain all Offers available to consumers and provide this information to the Consumption Experience functional component
-
May create the Service Contract template and provide information to the Service Level functional component
-
Shall aggregate and provide a unified service catalog through the Consumption Experience functional component
-
Shall drive consumption through Service Offer Catalogs and help identify prices and options for selection
-
Shall enable the grouping of different Service Offers into a single consumption experience
8.1.3.1. Service Offer Catalog Data Object
Purpose
The Service Offer Catalog data object represents a set or collection of Service Offers that are grouped together as something that can be consumed by certain consumers or consumer groups.
Key Attributes
The Service Offer Catalog data object shall have the following key data attributes:
-
Id: unique identifier for the Service Offer Catalog
-
Name: Service Offer Catalog name used for consumers
Key Data Object Relationships
The Service Offer Catalog data object shall maintain the following relationships:
-
Service Offer Catalog to Service Offer (n:m): represents the collection of Offers that comprise each Service Offer Catalog
8.1.3.2. Service Offer Data Object
Purpose
The Service Offer data object defines how a Service Offer template will be instantiated and under what terms and conditions – price, deployment, approval, workflow, service level (contract), etc.
Key Attributes
The Service Offer data object shall have the following key data attributes:
-
Id: unique identifier for every Service Offer in the catalog
-
Catalog Id: identify in which catalog this Service Offer is available (from the Service Offer Catalog)
-
Name: description of the Service Offer for consumers to identify/search Offers
-
Start Date: date/time on which the Service Offer may be consumed
-
Expiry Date: date/time on which the Service Offer is no longer available
-
Status: indicates if the Service Offer is ready for consumption (e.g., draft, published, retired, etc.)
-
Price: if applicable, the pricing information on the service, including the type of Subscription
-
Required Value: mandatory options or variables linked to the service which need to be provided by the consumer to prevent issues during the fulfillment; (some of) these options or variables might not be selectable for customers but are pre-filled by the Offer itself upon creation of the Offer
Key Data Object Relationships
The Offer data object shall maintain the following relationships:
-
Service Offer to Product Release Blueprint (n:1): each Service Offer is based upon the definition of one Product Release Blueprint
-
Service Offer to Order (1:n): provides Service Offer details that will help to manage Orders
-
Service Offer to Subscription (n:m): Service Offer obtains contract-related terms and conditions (pricing, service levels, etc.) from Subscription
-
Service Offer to Entitlement (1:n): determines what a consumer (human or machine) is entitled to order
-
Service Offer to Interaction (n:1): makes Service Offers available to consumers through the Consumer Experience functional component
-
Service Offer to Service Offer (n:m): Service Offers can be built and defined as a collection of more fine-grained service components or service actions
8.1.4. Order Functional Component
Purpose
The Order functional component rationalizes, breaks down, and routes “clean order” requests (ready for fulfillment) to appropriate Fulfillment Orchestration functional components in order to deliver services to consumers. This may involve breaking down a single order/request into multiple Fulfillment Orders/requests. It ensures appropriate fulfillment-related Subscription information is kept up-to-date, such as approval/rejections, modifications, cancellations, and so on. It enables the recording of patterns of service consumption that can be used to shape demand for new and/or improved services. The fulfillment status is tracked and completion notifications from the fulfillment channel(s) are received. Consumers will be able to receive status updates at the Subscription level. The Order functional component can receive the order from three different channels:
-
Consumer-initiated – the consumer may initiate a new Order using consumption experience communication channels such as chatbot, web application, or mobile applications
-
Machine-initiated – a machine (such as an API) can directly trigger an Order request to the Order functional component; for instance, provisioning of a new Virtual Machine (VM), provisioning for a user Id, allocating a software license, etc.
-
Pipeline-initiated – in this case, the Pipeline functional component will directly engage the Order functional component to order resources for the upkeep and running of the pipeline; for example, deploying a test instance infrastructure, deploying a test code, etc.
The Order functional component supports the value streams:
Functional Criteria
The Order functional component:
-
Shall provide information to the consumer on the fulfillment status
-
Shall provide Subscription information for the creation of the associated Chargeback Contract
-
Shall confirm that consumer access to the catalog items data are in line with defined entitlements and attached to user identities
-
Shall provide information on Order delivery times for SLA measurements
-
Shall break down the composite Order into the individual orders/requests that need to be fulfilled
-
Shall send the bound Offer template information from the Product Release package to the Change functional component in order to create the Change needed to deliver the Order fulfillment
-
Shall rationalize, break down, and route “clean order” requests (ready for fulfillment) to appropriate fulfillment orchestrators or providers in order to deliver services to consumers
-
Shall ensure the fulfillment-related subscription data is updated
-
Shall identify service consumption trends for effective demand analysis
-
Shall break the service order down into the appropriate fulfillment change request(s) and provide these to the Fulfillment Orchestration functional component via the Change functional component and create the Subscriptions for these services upon their successful fulfillment
-
Shall create a traceability for fulfillments through the fulfillment channel(s)
-
Should send the instances of the Service Contracts to the Service Level functional component if a Service Level functional component exists
8.1.4.1. Order Data Object
Purpose
The Order data object represents the formal request for the creation of, modifications to, or deletion of user consumption of a Service Offer.
Key Attributes
The Order data object shall have the following key data attributes:
-
Id: unique identifier for the Order (request)
-
Status: controls the status of the Fulfillment functional component
-
Date: date/time the Order was received
-
Latest Fulfill Date: maximum date/time by which the Order needs to be fulfilled
-
Actual Fulfill Date: date/time on which the Order is fulfilled
-
Required Value: based on the Offer, the user might need to provide values/options for a successful fulfillment (from Offer)
Key Data Object Relationships
The Order data object shall maintain the following relationships:
-
Order to Interaction (1:1): an Order can be a result of an Interaction and the relationship ensures that the status can be updated back to the requesting Identity using the same engagement
-
Order to Identity (n:1): obtains information from Identity which can be used to validate and manage the approval of the Order
-
Order to Subscription (n:m): enables traceability between the Order and the resulting Subscription; this helps to better understand how the current Subscription state was realized
-
Order to Service Offer (n:1): obtains Service Offer details to initiate recursive Order requests (sub-orders) that may be required to fulfill an Order
-
Order to Change (1:n): used for tracking the Order fulfillment through a Change Management system
8.1.4.2. Subscription Data Object
Purpose
The Subscription data object represents the rights to access a service that has been provided to a consumer.
Key Attributes
The Subscription data object shall have the following key data attributes:
-
Id: unique identifier for the Subscription
-
Status: provides a status update to consumers on the Order status at the Subscription level, such as WIP, RFI, completed, closed, etc.
-
Start Date: the date on which the Subscription was created
-
Expiry Date: the date on which the Subscription will end
Key Data Object Relationships
The Subscription data object shall maintain the following relationships:
-
Subscription to Service Offer (n:1): provides traceability between the Subscription and the Service Contract (via the Service Offer)
-
Subscription to Chargeback Contract (1:n): facilitates the various chargeback/showback calculations that are dependent on Subscription details such as its contract duration and service status
-
Subscription to Desired Product Instance (n:1): enables traceability between the consumer, their Subscription, and the Desired Product Instances; there can be multiple Subscriptions linked to a single Desired Product Instance
-
Subscription to Identity (n:1): associates an Identity as an owner of one or more Subscriptions to manage the Subscriptions
-
Subscription to Service Contract (1:1): sends the instances of Service Contracts to the Service Level functional component
8.1.5. Chargeback Functional Component
Purpose
The Chargeback functional component provides chargeback (or showback) for internal and external services based on Subscription, Service Contract, and/or Usage information.
The Chargeback functional component supports the Consume value stream.
Functional Criteria
The Chargeback functional component:
-
Shall provide cost consumption information at the service level to consumers through the Consumption Experience engagement portal
-
Shall calculate the chargeback (or showback) of consuming/subscribing a service to a subscriber/consumer
-
Can take actual Usage into consideration when calculating the charge of consuming a service
-
Shall consolidate the charges from all subscribed services once Usage is collected for the given billing period
-
Shall send the subscribed service charges to the Product Portfolio functional component for an Actual Product Instance if a Product Portfolio functional component exists
-
Should send a Chargeback Record for approval and an internal reconciliation request to the finance function if a Finance function (external to IT) exists
8.1.5.1. Chargeback Contract Data Object
Purpose
The Chargeback Contract data object details the contract for financial obligations between the service consumer and provider(s) as defined at the time of Subscription. The Chargeback Contract typically defines the billing rule and billing frequency used to price a given service and is often tightly linked to the Subscription.
Key Attributes
The Chargeback Contract data object shall have the following key data attributes:
-
Id: unique identifier for the Chargeback Contract
-
Status: status of the contract (active, inactive, etc.)
-
Rule: pricing rule captured at the time of Subscription describes the method/formula for translating the usage into chargeback; this might be as simple as a product or as complex as an algorithm depending on the kind of service and granularity of chargeback/usage required to be captured
-
Frequency: charging frequency to the subscriber (e.g., daily, weekly, monthly, quarterly)
Key Data Object Relationships
The Chargeback Contract data object shall maintain the following relationships:
-
Chargeback Contract to Subscription (n:1): this relationship provides the traceability between the service rendered (represented by the Subscription) and the expected charges for those services (described in the Chargeback Contract)
-
Chargeback Contract to Chargeback Record (1:n): multiple billing records can be generated for a single Chargeback Contract as the Chargeback Record will be generated for each billing period
8.1.5.2. Chargeback Record Data Object
Purpose
The Chargeback Record data object represents the actual charge or showback amount to the subscriber based on the usage of subscribed services in a given time period. It is computed by the Chargeback functional component using the rules stored in the associated Chargeback Contract(s), with the input being the Usage Records collected for the period.
Key Attributes
The Chargeback Record data object shall have the following key data attributes:
-
Id: unique identifier of the related Chargeback Record
-
Status: status of the Chargeback Record (initiated, recorded, etc.)
-
From Date: start date of the Chargeback Record
-
To Date: end date of the Chargeback Record
-
Amount: amount to be charged for the given period
Key Data Object Relationships
The Chargeback Record data object shall maintain the following relationships:
-
Chargeback Record to Chargeback Contract (1:n): indicates to which contract (and thereby to which Subscription) the Chargeback Record relates
-
Chargeback Record to Usage Record (1:n): each Chargeback Record is calculated based on all the Usage Records it is associated with
8.2. Fulfill Function
The Fulfill function is centered around efficiently fulfilling requests.
8.2.1. Change Functional Component
Purpose
The Change functional component is responsible for controlling the lifecycle of Changes in the technology environment to make sure that Changes are captured, analyzed, assessed, and implemented in a standardized and auditable way so that the business risk is minimized through the following means:
-
Facilitate communication with stakeholders
-
Assess the risk of proposed Changes (Change Orders) and their implementation; support the impact and risk assessments to minimize the risk of production disruptions involved when rolling out Changes
-
Enable notification of all affected Change stakeholders and facilitate their collaboration on Change execution
-
The Change authority reviews the Change Orders and authorizes the valid Changes
-
The Change type, standard or normal, is determined based on the Change risk profile
-
Support the automation of Changes so that human participation is reserved for the highest value-added and most complex Change activity
For example, the Event functional component or Incident functional component may use a manual or automated Runbook to resolve well-understood issues without an active Change. These classes of pre-approved Changes may vary by company and by the criticality of service. For these pre-approved changes, it is assumed that the Change is recorded and that the Change Management process has access to that information. A typical example would be a Runbook automation script that fixes the issue. The relationship to the Actual Product Instance is maintained to allow Configuration Management to have access to Change information.
-
Changes initiated by the Pipeline functional component (for CI/CD) making it completely automated, with a reduced change size (iterative) and to an acceptable risk level; therefore, only log the Change details in the Change record
-
Change Management may automate the creation of the Change record, the risk assessment, and its approval process using data that is collected via integration to existing CI/CD pipelines to expedite the overall product deployment process while maintaining compliance
-
Change functional component integration with the Fulfillment Orchestration functional component to orchestrate the deployments
If a Change is low risk, it will be automatically approved, and deployed instantly. If a Change is high risk, the deployment will be delayed until the Change record is manually approved or stopped completely if a Change record is rejected.
-
Certain types of changes (e.g., end-user request items) are initiated from the Order functional component and may directly trigger the Fulfillment Orchestration functional component for the fulfillment of the order
-
Enable Change Management against a Change calendar to avoid Change collisions
-
Check and steer conflict resolutions between parallel planned deployments
The Change functional component supports the value streams:
Functional Criteria
The Change functional component:
-
Shall act as an authoritative system of record for all change requests
-
Shall manage the state and lifecycle of the Change
-
Shall facilitate communication with stakeholders
-
Shall assess the risk of proposed Changes and their implementation
-
Shall support the impact and risk assessments to minimize the risk of production disruptions involved when rolling out Changes
-
Shall identify affected Change stakeholders and send them notifications throughout the Change lifecycle
-
May support the automation of Change execution as much as possible
-
Shall maintain the relationship of the Change to the actual service to allow Configuration Management to have access to Change information
-
Shall facilitate with a Change calendar to avoid Change collisions
-
Shall manage conflicting resolutions for collateral deployments
-
Can receive a Change directly from the Pipeline functional component to fulfill the order initiated by the Pipeline
These Changes, initiated by the Pipeline functional component (for CI/CD), are often completely automated, with a decreased Change size (iterative) and to an acceptable risk level
-
Can provide Change data to the Event and/or Monitoring functional components to facilitate a root-cause analysis process in the context of the impact Changes may have
-
Shall associate a Fulfillment Order request with a Change record
-
Shall associate Change(s) to Desired Product Instance(s)
-
Shall classify the Change type (standard, emergency, or normal) based on the Change risk profile
-
Shall associate Changes with Incidents in response to Incidents that are resolved by implementing an emergency change
-
Shall associate Changes to the Problem in order to implement a fix to the issue that is documented by the Problem if a Problem functional component exists
8.2.1.1. Change Data Object
Purpose
The Change data object includes details of a proposed Change to one or more CIs.
Key Attributes
The Change data object shall have the following key data attributes:
-
Id: unique identifier for the Change record
-
Title: title of the Change
-
Description: description of the Change
-
Category: classify and define the type (emergency, standard, normal, etc.) of Change requested; each category has its own lifecycle
-
Approval Status: current status of the Change approval
-
Risk: the probability that the Change could cause harm or loss, or affect the ability to achieve objectives
-
Planned Start Time: date/time when the Change implementation is planned to start
-
Planned End Time: date/time that Change implementation is planned to end
-
Assigned To: actor that is assigned to implement the Change
Key Data Object Relationships
The Change data object shall maintain the following relationships:
-
Change to Order (1:n): receives Change request and Change request status
-
Change to Desired Product Instance (1:n): acquires relevant information about the Desired System(s)
-
Change to Pipeline (n:1): the Pipeline supplies the Change Orders with information needed to instantiate the service
-
Change to Change (n:m): a Change can depend on other Changes that have been delivered, or it can be decomposed into a number of more fine-grained Changes
-
Incident to Change (n:1): tracks the Incident(s) caused by the Change
-
Change to Incident(1:n): tracks the Incidents that needs emergency Changes to fix the issues
-
Problem to Change(1:n): to implement a fix to the issue that is documented by the Problem
Change data between the Order, Desired System, and the Change must manage the Change lifecycle state.
8.2.2. Fulfillment Orchestration Functional Component
Purpose
The Fulfillment Orchestration functional component orchestrates the delivery of various Orders across one or more Fulfillment functional components in order to fulfill the service orders (such as the provision of VMs, modification of resource allocation, addition/removal of capacity, patches installation, modification of access rights, etc.) that are triggered by:
-
Release Composition to deploy new Product Releases received from the Integrate value stream
-
Order (e.g., end-user request from the portal, application access request, password reset, etc. )
-
Change (e.g., provision of the test environment, deployment of bug-fix, deployment of the patch, etc. )
-
Pipeline (for continuous deployment)
The Fulfillment Orchestration may orchestrate through multiple internal and/or external Fulfillment functional components to automatically execute a fulfillment process workflow. To be able to engage the fulfillers, the Fulfillment Orchestration functional component needs to:
-
Manage a registry of the available fulfillers; this registry captures:
-
What each fulfiller does (capabilities)
-
How to engage each fulfiller (where they are located and how to invoke them)
-
-
Take the released Offer template deployment recipe from Release Composition and update the change request (for fulfillment) and also the Desired Product Instance data object that represents the service model in its preconfigured state
-
Get the resources allocated that are required to fulfill the service order
-
Update the resource pool inventory as resources are provisioned
-
Based on the new or updated Desired Product Instance and the result of fulfilling the Change (Change data object), inform the Configuration functional component (if needed)
The Fulfillment Orchestration functional component can be used via two paradigms:
-
Consumer-driven
In this paradigm, a consumer request results in a bound catalog item that is broken down into the necessary Change Orders needed to fulfill the originating request; typically, this is for delivering the consumption of service from an existing product/service system that has previously been deployed.
-
Pipeline-driven
In this paradigm, the Fulfillment Orchestration functional component is directly engaged by the Pipeline functional component; this paradigm is used when the Development team is ready to transition a product into the production environment and wants to deploy a service system for the product.
The Fulfillment Orchestration functional component supports the value streams:
Functional Criteria
The Fulfillment Orchestration functional component:
-
Shall orchestrate the implementation of the various Change Orders across the fulfillment systems, or track and manage manual change task implementation to fulfill the Orders
-
Update the resource inventory as resources are ordered
-
May manage a registry of the available fulfillers to include what each fulfiller does (capabilities) and how to engage each fulfiller (where they are located and how to invoke them)
-
May take the bound Offer template from the Change functional component and generate both the relevant Fulfillment Orders to realize/fulfill the originating consumer request and the Desired Product Instance data object, which represents the system in its preconfigured state
-
Shall get the technology resources (such as license, IP, VMs, etc.) allocated to fulfill the service order from the Resource functional component
-
Shall select the appropriate fulfillment mechanism
-
Shall coordinate if multiple fulfillment mechanisms are needed, and manage the dependencies required to fulfill the digital service orders
-
Shall create a Desired Product Instance based on a template in the Product Release package if the Order is a request for a new product system
-
Should modify the associated Desired Product Instance for all consumer Subscriptions to the service in order to track service delivery
-
Shall provide the Subscription status to the Order functional component
-
Shall create the Actual Product Instance as a copy of the Desired Product Instance within the Configuration functional component
-
May update the resource pool inventory as resources are provisioned
-
May trigger the Order functional component to order the appropriate dependent services, to fulfill a service order
-
Can create a new Service Monitor or modify an existing one for the service provided in the Order as part of fulfillment
-
Can create/route an Order to an external service provider to fulfill a part or all of the service
-
Can create an Order if a given Digital Product is to be delivered as a service from another product system (enabling product)
-
Can trigger fulfillment automation systems to enable fulfillment of (parts of) the service
8.2.2.1. Desired Product Instance Data Object
Purpose
The Desired Product Instance data object specifies the deployment of a product so that it meets the deployment requirements specified in the Order or Change records. It contains the relevant fulfillment parameters that determine how to instantiate the product.
Key Attributes
The Desired Product Instance data object shall have the following key data attributes:
-
Id: unique identifier of the Desired Product Instance
-
Name: name of the Desired Product Instance
-
Type: type of the Desired Product Instance
-
Configuration Items: model of the configuration of the Product Instance as a set of interconnected CIs
-
Create Time: date/time the Desired Product Instance was created
-
Last Modified Time: date/time the entry was last modified
Key Data Object Relationships
The Desired Product Instance data object shall maintain the following relationships:
-
Desired Product Instance to Subscription (n:1): creates the traceability from service to Subscription
-
Desired Product Instance to Product Release (n:1): acquires all the necessary service information for fulfillment
-
Desired Product Instance to Actual Product Instance (1:1): creates traceability and enables verification of correct deployment/fulfillment
-
Desired Product Instance to Fulfillment Book (m:n): creates Fulfillment Book(s) for each Desired Product Instance(s)
-
Desired Product Instance to Resource (1:n): requests for resources needed for Order fulfillment demand
-
Desired Product Instance to Change (1:n): obtains orchestration details for Order fulfillment
-
Desired Product Instance to Desired Product Instance (n:m): the Desired Product can depend on services being delivered by other products
8.2.3. Resource Functional Component
Purpose
The Resource functional component manages the pool of resources (a logical abstraction of digital assets) that support Actual Product Instances delivering digital services, such as infrastructure, applications, and third-party services. This also ensures that the resource requirements for the services and their underlying resources are well understood and provisioned efficiently.
The Resource functional component ensures the pooling of resources that may be virtual or physical (such as server, storage, networking, software licenses, IP address, etc.) are made available for the Order fulfillment. It maintains the soft limits or hard limits of resource pooling for cloud computing and acts appropriately when there is a breach of the limits. It also provides resource utilization details for Usage functional components to compute costs.
The Resource functional component supports the value streams:
Functional Criteria
The Resource functional component:
-
Shall manage the pool of Resources that support services, such as infrastructure, applications, and third-party services
-
Shall ensure that the digital Resource requirements against the services are ascertained
-
Shall ensure the availability of physical assets/virtual Resource pools for the Order fulfillment
-
Shall maintain the soft limits, hard limits, quotas, etc. of Resource pools for cloud computing, and act appropriately when there is a breach of the limits
-
May provide capacity Resource utilization details to the Usage functional component for cost computation
8.2.3.1. Resource Data Object
Purpose
The Resource data object represents an asset or other entity that is limited in nature. It can be allocated to a Digital Product or it can be unallocated.
Key Attributes
-
Id: unique identifier for each Resource
-
Type: describes the type of each Resource pool
-
Status: record if the Resource is available
Key Data Object Relationships
The Resource data object shall maintain the following relationships:
-
Resource to Desired Product Instance (n:1): indicates if a Resource is allocated to a given Product Instance
-
Resource to Usage Record (1:n): provides Resource usage details for cost computation
8.2.4. Fulfillment Functional Component
Purpose
The Fulfillment functional component ensures that fulfillment activities are documented and automated for the resources that support the Digital Product Instance. Such activity items may include provisioning, deploying, modifying, actions (i.e., start, stop, etc.), decommissioning, and so on. This manages the routine deployment and configuration activities into automated/semi-automated Runbooks. The automated/semi-automated fulfillment scripts are often included in the release package. The Fulfillment functional component may receive these deployment scripts from Release Composition functional component for the product deployment.
The Fulfillment functional component supports the value streams:
Functional Criteria
The Fulfillment functional component:
-
Shall ensure the fulfillment activities are standardized, automated, or, if manually executed, well-documented for the resources that support the Digital Product Instance
-
Shall ensure that the automated Runbooks are updated with routine deployment and configuration activities including but not limited to building and deploying resources, configuring VMs, decommissioning VMs, configuring platforms, etc.
-
Shall monitor that the Fulfillment Books are being executed as per the designed specification
-
Can allow the Fulfillment Orchestration functional component to trigger automated Fulfillment Books for deploying or configuring resources underpinning a digital service in order to fulfill a service order
8.2.4.1. Fulfillment Book Data Object
Purpose
The Fulfillment Book data object is a Runbook for the fulfillment of individual Resources as part of the Fulfillment Orchestration functional component. The plan can either be an automated template or/and manual process description.
Key Attributes
The Fulfillment Book data object shall have the following key data attributes:
-
Id: unique identifier for the Fulfillment Book record
-
Category: helps in associating the Fulfillment Book to the Desired Product Instance
-
Description: description of the Fulfillment Book
-
Execution Time: date/time when the Fulfillment Book was created
Key Data Object Relationships
The Fulfillment Book data object shall maintain the following relationship:
-
Desired Product Instance to Fulfillment Book (m:n): every Desired Product Instance will have one or more fulfillment plans
8.2.5. Usage Functional Component
Purpose
The Usage functional component tracks and manages the actual usage of subscribed digital services and their associated costs.
The Usage functional component supports the Consume value stream.
Functional Criteria
The Usage functional component:
-
May track actual usage of subscribed digital services by gathering service usage metrics, activity, and history for both internal and external sourced services associated with an aspect of the Desired Product Instance
-
Usage Records can have any unit:
-
CPU usage, storage consumption, transaction numbers, etc.
-
It can also be a cost number from the Resource functional component
-
It can be the price a sub-supplier is reporting – a price is considered as the cost of running that component
-
-
May process and break down usage information for each Subscription, its consumers (singular, group), provider, etc.
-
May collect service usage metrics from the Monitoring functional component
-
Shall encrypt sensitive usage information or set appropriate access controls
-
Can generate service usage history and activity reports
-
May provide usage information to the Chargeback functional component, enabling usage-based chargeback (or showback)
-
Shall collect costs associated with sub-services if a service is further decomposed; this will be the cost reported as Chargeback Records on the sub-services and will be reported as usage back up to the next level in the service composition
-
Shall collect usage information from vendor invoices that represent Resources used by the service
-
Shall collect cost of capacity partaking in delivery of the service
8.2.5.1. Usage Record Data Object
Purpose
The Usage Record data object represents a measurement of consumption of a particular service or service component. An example Usage Record can be composed of (internal) hours, system usage (capacity, CPUs, etc.), or external supplier usage.
Key Attributes
The Usage Record data object shall have the following key data attributes:
-
Id: unique identifier for the service usage
-
Usage Date From: date from which the service usage is captured (linked to billing frequency in the Chargeback Contract)
-
Usage Date To: date up to which the service usage is captured (linked to billing frequency in the Chargeback Contract)
-
Units: transaction or consumption units
-
Unit Type: type of units used (CPU seconds, disk space, web transactions, etc.)
Key Data Object Relationships
The Usage Record data object shall maintain the following relationships:
-
Usage Record to Chargeback Contract (n:1): every Usage Record for a Subscription is associated with a Chargeback Contract; the Chargeback Contract defines the billing rule and frequency for a Subscription
-
Usage Record to Resource (n:1): if a Resource is measuring the consumption of a dedicated Resource for the Actual Product Instance
|
Note
|
In case of fixed-price Chargeback, no Usage Record may exist for a given Chargeback Record. |