8 Detect to Correct (D2C) Value Stream

This chapter provides an overview of the Detect to Correct (D2C) Value Stream – one of four IT Value Streams that comprise the IT Value Chain. It describes the business context, objectives, and details behind the D2C Value Stream.

8.1 Objectives

The D2C Value Stream provides a framework for the work of IT operations integrating Service Monitoring, Event, Incident, Problem, Change Control, Configuration Management, Service Remediation, and Service Level functions. It also provides a comprehensive overview of the business of IT operations and the services delivered by IT operations. This viewpoint provides understanding of the inter-relationships among its many domains; including Event, Incident, Problem, Change Control, and Configuration Management, and responsiveness to business requests and requirements. The D2C Value Stream is designed to incorporate a wide variety of sourcing methodologies across services, technologies, and processes. This value stream accommodates the technical inter-relationships and inter-dependencies required to fix operational issues and improve the ability of IT to support business objectives by providing agility, increased uptime, and lower per-service cost.

Today, all IT organizations have the ability to detect and resolve operational issues, but may have the following limitations:

Timely identification of an issue before users of the service are impacted.
Prioritization that understands business, IT operations, and technology impacts.
Complexity of service delivery across multi-sourced environments exceeds the capabilities.
Siloed organizational structure combines with process and technology misalignments.
Slow troubleshooting from poor cross-domain teamwork due to poor data sharing, unreliable data, and inconsistent terminology.
Slow remediation due to:

— Low levels of automation within domains

— Virtually no automation across domains

Poor linkage of Incidents and Problems to the R2D Value Stream (providing Defect information about the service).
Poor linkage of Problems to the S2P Value Stream (providing demand loop back information about the service).
No end-to-end management of the service lifecycle across domains which causes more disconnects between the IT department’s different groups, less focus on the business needs that are being served by the specific service, and a lack of coherent view of the service status at all times.

The D2C Value Stream provides a framework for bringing IT operations functions together to enhance IT services and efficiencies – thus reducing risk. Currently, data in each operation’s domain is generally not shared with other domains because they do not understand which key data objects to share and do not have a common language for sharing. When projects are created to solve this, it is often too difficult and cumbersome to finish or there is an internal technology or organization shift that invalidates the result. The D2C Value Stream defines the functional components and the data objects that need to flow between components.

8.2 Business Value Proposition

The D2C Value Stream enables IT organizations to increase efficiency, reduce cost, reduce risk, and drive continuous service improvement by defining the data objects and data flow required to integrate the operations of multiple domains.

Increase efficiency and reduce cost by:

Focusing response based on causal factor, priority, and business impact
Increasing sharing of information and reduction of multiple entry of the same data
Creating a prescriptive data flow between Event, Incident, Problem, and Change Control
Centralized Event Management for faster analysis
Automation between and across business functions
Knowledge management and self-service linkage
Driving Service Monitoring configuration, operating/Service Level targets, and predefined Knowledge linked to the R2F Value Stream
Improving the speed at which issues with a business service are identified, including proactive identification before service impact is severe

Reduce risk by:

Consistent data and configuration information shared between operational silos
Prescriptive flow semantics and data objects
Defined business impact
Reducing the need for best-guess routing and clannish knowledge
Increased uptime by reduced MTTR
Creating a consistent way of managing SLM definitions, measurements, KPI calculations, and reporting back to the proper service owner or user (in the R2F Value Stream)
Implementing network security to minimize intrusions that cause denial of service, viruses, and theft or corruption of data and minimize risk exposure
Utilizing SIEM to identify complex attack signatures that can disrupt operations and affect compliance
Performing threat and vulnerability assessments
Audit trail
Clear ownership

Continuous service improvement:

Defined data objects to be shared with Problem Management
Using this accumulated Knowledge as input into the S2P Value Stream
Improved management information and decision-making

8.3 Key Performance Indicators

The D2C Value Stream critical success factors and Key Performance Indicators (KPIs) are as follows:

Critical Success Factors	Key Performance Indicators (KPIs)
Achieve Operational Excellence	Events: % of monitored CIs versus unmonitored CIs in the Actual Service Number of Events that cause business disruptions Number of escalated Events Number of false-positive Events Incidents: Number of Incidents Number of escalated Incidents Number of false-positive Incidents Problems: Number of Problems identified Number of eradicated Problems Changes: Number of change-related outages Number of emergency changes Number of unplanned changes Knowledge: Number of Known Errors per version Average number of times each Known Error was read/used
Improve Customer Satisfaction	Number of failed agreements (SLA/OLA) % of availability of critical business systems Mean Time To Repair (MTTR) Events/Incidents Mean Time Between Failures (MTBF) Mean Time Between System Incidents Number of Incidents created by users on system performance % of first-call Incident resolution % of success rate for user self-fix
Improve Staff Effectiveness	% of automatically remediated Events % of Events correlated to a business service % of re-opened Incidents Average time to close an Incident % of automatically remediated Incidents % of rejected Incidents % of automatically remediated changes
Alignment with Business Strategy	Number of hours spent on business-critical services Number of business services defined % of business-critical services % of CIs that are not linked to a business service % of business-critical services with defined service-level targets

8.4 Value Stream Definition

The goal of the D2C Value Stream is to efficiently manage the IT operations by monitoring key services, correlating and appropriately escalating Events, managing (resolving) Incidents/Problems, running an effective Change Control, and doing all of that in an automated way. The D2C Value Stream is initiated when:

A new or updated service is deployed resulting in the creation of a Physical Service Model, and Service Monitors which must now be managed and maintained.
A Service Monitor generates an Event that must be handled (ignored, correlated, or escalated). This may be triggered when service discovery detects new CIs, which cause an existing Service Monitor to generate an Event.
The service desk receives an Incident. In addition to escalated Events, Incidents can also be initiated by Self-Service Support requests from the R2F Value Stream or a user call to the service desk.

The above inputs trigger functional components including:

Service Monitoring
Service Level
Event
Incident
Problem
Change Control
Configuration Management
Diagnostics and Remediation

As part of the D2C Value Stream, manual or automated Run Books may be executed to diagnose or remediate Events, Incidents, or Problems. When necessary, the Physical Service Model is updated and RFCs are created to record changes.

The D2C functional components are often owned and managed by different IT groups. The D2C Value Stream provides a framework that ensures that functional components used by IT groups can work together efficiently, through well-defined control points and data objects, to govern and run IT operations.

Figure 66 shows the functional components, data objects, and entity relationships for the D2C Value Stream.

Note: The red lines in Figure 66 represent recognized industry employed linkage variations. These variations and their associated implications will be detailed in future releases.

Figure 66: Detect to Correct Level 2 Value Stream Diagram

8.4.1 Service Monitoring Functional Component

Purpose

In charge of creating, running, and managing monitors which measure all aspects/layers of a service such as infrastructure (system and network), application, and security. Also in charge of storing all measurement results and calculating compound measurements. Not in charge of the monitor definitions. These are done earlier in the service lifecycle in the R2D Value Stream and are delivered to Service Monitoring by the Fulfillment Execution functional component in the R2F Value Stream.

Key Data Objects

Service Monitor (data object): Performs the operational measurement aspects of a CI or an IT service in order to understand the current operational status of that CI or IT service.

Note: The Service Monitor definition created in the R2D Value Stream is moved with the Release Package as a part of the Service Release Blueprint transfer to the R2F Value Stream and is received from the Fulfillment Execution functional component (R2F Value Stream).

Key Attributes

The Service Monitor data object shall have the following key data attributes:

Id: Unique identifier for the Service Monitor.
Name: Name of the Service Monitor.
Description: Description of the Service Monitor.
Type: Type of the Service Monitor (system, application, network, security, etc).
MeasurementDefinitions: The definitions of the measurements that the Service Monitor is collecting about the monitored CI.
LastRunTime: Date/time that the Service Monitor was last run.
LastRunStatus: Was the last run of the Service Monitor successful or not?
ActualServiceId: Identifier of related Actual Service(s).

Key Data Object Relationships

The Service Monitor data object shall maintain the following relationships:

Service Monitor to Event (1:n): Enables the traceability from the Events that are created to the Service Monitor they originated from.
Service Monitor to Actual Service (1:n): The Actual Service is the CI being monitored.

Event data flow integration between the Service Monitoring functional component and the Event functional component must manage the Event lifecycle state.

Functional Criteria

The Service Monitoring functional component:

Shall be the system of record for all Service Monitors.
Shall perform monitoring of all aspects of an IT service.
Shall store all of the results of the measurements being done on the IT service.
Shall calculate the results of compound Service Monitors from one or more simple measurements.
Shall manage the lifecycle of the Service Monitor.
Shall create, run, and manage monitors that measure all aspects/layers of a service, including:

— Shall monitor infrastructure (system and network)

— Shall monitor application

— Shall monitor security

— May monitor customer experience

— May monitor usage for the Usage functional component in the R2F Value Stream

May receive monitor definitions from the Fulfillment Execution functional component in the R2F Value Stream.

Data Architecture Criteria

The Service Monitoring functional component:

Shall create an association between the Service Monitor data object and the related Actual Service(s).
Shall initiate the creation of an Event or alert that is passed to the Event functional component if an Event functional component exists.
Can provide service monitoring status if an Offer Consumption functional component exists.
Can provide service Usage measurements if a Usage functional component exists.
Can provide business/IT measurements if a Service Level component exists.
Can receive Service Monitor definitions if a Fulfillment Execution functional component exists.

Model

Figure 67: Service Monitoring Functional Component Level 2 Model

8.4.2 Event Functional Component

Purpose

Manage Events through the Event lifecycle for events that occur on any IT service. The Event lifecycle includes but is not limited to detecting, categorizing, filtering, analyzing, correlating, logging, prioritizing, and closing events. During the event lifecycle some categories of Events can serve as initiators of Incidents and for diagnostics and remediation activities.

Key Data Objects

Event (data object): Represents an alert/notification signifying a change of state of a monitored CI.

Key Attributes

The Event data object shall have the following key data attributes:

Id: Unique identifier of an Event.
Name: Name of an Event.
Category: Category of an Event category (info, warning, error, etc.); aids in determining assignment and prioritization.
Type: Categorizing the Event to causal or symptom type.
Status: The current stage in the lifecycle of an Event.
StatusTime: Time stamp for the Status attribute.
Severity: Severity of the Event.
ThresholdDefinitions: The definitions of the thresholds by which the Event severity is determined.
AssignedTo: Group or person that is assigned to handle the Event.
IsCorrelated: Is the Event correlated to other Events?
ActualServiceId: Related CI(s).

Key Data Object Relationships

The Event data object shall maintain the following relationships:

Event to Incident (n:m): Enables the connection between the Incidents and Events and supports the integration lifecycle between them.
Event to RFC (1:n): Associated Event is available for RFC processing.
Event to Actual Service (n:m): The Actual Service(s) associated with the Event(s).
Service Monitor to Event (1:n): Enables the traceability from the Events that are created to the Service Monitor from which they originated.

Functional Criteria

The Event functional component:

Shall be the system of record for all Events.
Shall manage the state and lifecycle of the Events.
Shall manage the correlation between Events.
Shall categorize Event data.
Shall forward Events categorized as Incidents to the Incident functional component.
May initiate a change request (RFC) based on Event data to the Change Control functional component.
May send Events for diagnostics and remediation processing if a Diagnostics & Remediation functional component exists.

Data Architecture Criteria

The Event functional component:

Shall create an association between the Event data object and the related Actual Service(s).

Model

Figure 68: Event Functional Component Level 2 Model

8.4.3 Incident Functional Component

Purpose

Facilitate normal service operations restoration as quickly as possible and minimize the impact on business operations, thus optimizing service quality and availability. Service restoration can be facilitated through the following means:

In partnership with the Service Monitoring functional component, filter end-user Interactions and determine which ones should be associated with Incidents.
Detect Incidents, investigate the impacts across all domains (server, network, security, etc.), and determine the correct action to take.
Initiate change and/or remediation activity for some categories of Incidents.

An Incident is defined as an unplanned interruption to an IT service or reduction in the quality of an IT service as defined within the Service Contract related to the IT service. Failure of a CI that has not yet affected a service is also an Incident; for example, failure of one disk from a mirror set.

An Interaction is a record of any end-user contact with the service desk agent. In some cases, either the service desk agent or self-service knowledge can resolve the Interaction without creating and managing an Incident. In other cases, an Interaction can be associated with an existing Incident (eliminating the need for Incident creation and correlation). When an Interaction cannot be associated with an existing Incident because it requires additional clarification, diagnostics, or support actions, a new Incident will be created.

Key Data Objects

Incident (data object): Hosts and manages Incident data.

Auxiliary Data Objects

Interaction (data object): Hosts the record of an end-user’s contact with the service desk.

Key Attributes

The Incident data object shall have the following key data attributes:

Id: Unique identifier for the Incident record.
Category: The category aids in determining assignment and prioritization.
SubCategory: The second level of categorization, following Category.
Status: The current stage in the lifecycle of an Incident.
StatusTime: Time stamp for the Status attribute.
Severity: Severity of the Incident.
Priority: Priority of fixing the Incident.
Title: Title of the Incident.
Description: Description of the Incident.
AssignedTo: Group or person that is assigned to fix the Incident.
ActualServiceId: Related CI(s).

The Interaction data object shall have the following key data attributes:

Id: Unique identifier for the Interaction record.

Key Data Object Relationships

The Incident data object shall maintain the following relationships:

Incident to Problem, Known Error (n:m): Connection between the Incidents that are converted to Problems to permanently address severe/repeating Incidents.
Incident to RFC (1:n): Connecting RFCs to the Incidents they originated from.
Incident to Defect (1:1): Current practice: connecting Defects that are created when Incident diagnostics determines there is need for an emergency fix from development.
Incident to Actual Service (n:m): Actual Service to which the Incident is associated and usually the main subject of.
Event to Incident (n:m): Enables the connection between the Incidents and Events and supporting the integration lifecycle between them.

Incident data flow between the Event functional component and Incident functional component must manage the Incident lifecycle state.

Problem data flow between the Incident functional component and the Problem functional component must manage the Problem lifecycle state.

Functional Criteria

The Incident functional component:

Shall be the system of record for all Incidents.
Shall manage the state escalation paths and general lifecycle of the Incident.
Shall allow an Incident to be initiated from an Event.
Shall create an Incident when an Interaction cannot be associated with an existing Incident because it requires additional clarification, diagnostics, or support actions.
Shall create an association between the Incident data object and the related Actual Service(s).
May initiate the creation of a Defect when Incident diagnostics determines that an emergency fix is required from development for resolution. The Defect is created and forwarded to the Defect functional component in the R2D Value Stream if a Defect functional component exists.
Can trigger the execution of a Run Book (either automated or manual) to provide diagnostic information or remediation steps if a Diagnostics & Remediation functional component exists.
May create a Problem record when the Incident is severe, requires further deep investigation, or is repeating if a Problem functional component exists.
Can trigger the creation of an RFC in order to implement a fix to the Incident fault if a Change Control functional component exists.
Can allow the initiation of an Interaction or an Incident if a Self-Service Support functional component (R2F Value Stream) exists.
Can provide business measurements of Incident data if a Service Level functional component exists.

Model

Figure 69: Incident Functional Component Level 2 Model

8.4.4 Problem Functional Component

Purpose

Responsible for managing the lifecycle of all Problems. The objectives are to solve severe/repeating Incidents, prevent Incidents from happening, and minimize the impact of Incidents that cannot be prevented. The Problem cause is not usually known at the time of the Problem data object instance creation, and the Problem functional component is responsible for the investigation. Also serves as the main exit point from the D2C Value Stream for the feedback information about IT services issues. The feedback is reported to the R2D Value Stream in the form of Defects and to the S2P Value Stream in the form of Portfolio Backlog Items (demand request).

Key Data Objects

Problem, Known Error (data object): Defines the Problem or Known Error and manages the Problem and Known Error lifecycle.

Key Attributes

The Problem data object shall have the following key data attributes:

Id: Unique identifier for every Problem record.
Category: The Category aids in determining assignment and prioritization.
SubCategory: The second level of categorization, following the Category attribute.
Status: The current stage in the lifecycle of a Problem.
StatusTime: Time stamp for the Status attribute.
Title: Title of the Problem.
Description: Description of the Problem.
AssignedTo: Group or person that is assigned to fix the Problem.
ActualServiceId: Related Actual Service(s).

Key Data Object Relationships

The Problem data object shall maintain the following relationships:

Problem, Known Error to RFC (1:n): This connection enables the relation of an RFC record that is created when problem resolution requires a change.
Problem, Known Error to Portfolio Backlog Item (1:1): Ensures a Portfolio Backlog Item is created for Problems requiring a future fundamental/big fix/enhancement to the IT service.
Problem, Known Error to Defect (1:1): Enables the creation of Defects when emergency/specific fixes require development.
Incident to Problem, Known Error (n:m): Connection between the Incidents that are converted to Problems to permanently address severe/repeating Incidents.
Problem, Known Error to Actual Service (n:m): Problem records are mapped to the affected Actual Service(s).
Problem, Known Error to Knowledge (n:m): Creating a relationship between the Knowledge data object and the Problem it originated from.

Defect data between the Problem functional component and the Defect functional component must manage the Problem to Defect lifecycle state.

RFC data between the Problem functional component and the Change Control functional component must manage the RFC lifecycle state.

Functional Criteria

The Problem functional component:

Shall be the system of record for all Problem records.
Shall manage the state and lifecycle of the Problem.
Shall create Known Error data object instances from unsolved Problems.
Can push Problem data to trigger the execution of a Run Book data object (either automated or manual) to provide diagnostics information or remediation steps if a Diagnostics & Remediation functional component exists.
Shall create an RFC associated to a Problem in order to implement a fix to the issue that is documented by the Problem if a Change Control functional component exists.
Shall use existing Knowledge data to solve a Problem if a Knowledge & Collaboration functional component exists.
Can create a new Knowledge data object based on Problem Management activities (from the Known Error data object instances) if a Knowledge & Collaboration functional component exists.
Shall push Problem data requiring emergency/specific development to the Defect functional component (R2D Value Stream) if a Defect functional component exists.
May push a Portfolio Backlog Item to the Portfolio Demand functional component for backlog processing if a Portfolio Demand functional component exists.

Data Architecture Criteria

The Problem functional component:

Shall associate Problem(s) to Actual Service (s).
Shall associate Incident data to the corresponding Problem record and continue the investigation around the Incident reported fault within the Problem lifecycle if an Incident functional component exists.

Model

Figure 70: Problem Functional Component Level 2 Model

8.4.5 Change Control Functional Component

Purpose

The system that is responsible for managing the lifecycle of all the RFCs in the IT environment. Make sure that changes are done in a standardized and auditable way so that the business risk is minimized. Manage change through the following means:

Facilitate communication with stakeholders.
Assess risk of proposed changes and their implementation. Support the impact and risk assessments to minimize risk of production disruptions involved when rolling out changes
Enable management of organizational changes and training needed for making a new release a success (which may include oversight that ensures that these tasks are included as part of the deployment package).
Enable notification of all affected change stakeholders and facilitate their collaboration on change execution.
Support automation of changes so that human participation is reserved for the highest added value and most complex change work. For example, the Event functional component or Incident functional component may use a manual or automated Run Book to resolve well understood issues without an active RFC. These classes of pre-approved RFCs will vary by company and by criticality of service. For these pre-approved RFCs, it is assumed that the RFC is recorded and that the Change Management process has access to that information. A typical example would be a Run Book automation script that both fixes the issue and logs what was changed as a closed RFC record. The relationship to the Actual Service is maintained to allow Configuration Management to have access to change information.
Enable RFC management against a change calendar and avoid change collisions.
Check and steer conflict resolutions between parallel planned deployments.

Key Data Objects

RFC (data object): Change data to manage the change lifecycle. An RFC includes details of the proposed change and may be recorded on paper or electronically.

Key Attributes

The RFC data object shall have the following key data attributes:

RFCId: Unique identifier for the change record.
Category: The category aids in determining assignment and prioritization.
SubCategory: The second level of categorization, following Category.
Phase: The current step in the RFC workflow.
PhaseTime: Time stamp for the change phase.
ApprovalStatus: The current status of the RFC approval.
Risk: The probability that the change could cause harm or loss, or affect the ability to achieve objectives.
PlannedStartTime: Date/time that RFC implementation is planned to start.
PlannedEndTime: Date/time that RFC implementation is planned to end.
Title: Title of the Incident.
Description: Description of the Incident.
AssignedTo: Group or person that is assigned to fix the Problem.
ActualServiceId: Related Actual Service(s).

Key Data Object Relationships

The RFC data object shall maintain the following relationships:

Fulfillment Request to RFC (1:1): An RFC initiated from the Fulfillment Execution functional component (R2F Value Stream) is created on service implementation/instantiation.
RFC to Actual Service (n:m): Associates the RFC with affected Actual Service(s).
Problem, Known Error to RFC (1:n): Enables the relation of an RFC record that is created when problem resolution requires a change.
Incident to RFC (1:n): Connecting RFCs to the Incidents they originated from.
RFC to Event (n:1): Associated Event is available for RFC processing.

RFC data between the Fulfillment Execution functional component and Change Control functional component must manage the RFC lifecycle state.

RFC data between the Problem functional component and the Change Control functional component must manage the RFC lifecycle state.

Functional Criteria

The Change Control functional component:

Shall act as an authoritative system of record for all change request information.
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 risk of production disruptions involved when rolling out changes.
Shall enable management of organizational changes and training needed for making a new release a success (which may include oversight that ensures that these tasks are included as part of the deployment package).
Shall enable notification of all affected change stakeholders and facilitate their collaboration on change execution.
May support automation of changes so that human participation is reserved for the highest added value and most complex change work. For example, the Event functional component or Incident functional component may use a manual or automated Run Book to resolve well understood issues without an active RFC. These classes of pre-approved RFCs will vary by company and by criticality of service. For these pre-approved RFCs, it is assumed that the RFC is recorded and that the Change Management process has access to that information. A typical example would be a Run Book automation script that both fixes the issue and logs what was changed as a closed RFC record. The relationship to the Actual Service is maintained to allow Configuration Management to have access to change information.
Shall enable RFC management against a change calendar and avoid change collisions.
Shall check and steer conflict resolutions between parallel planned deployments.
Can provide change data to the Event and/or Service Monitoring functional components to facilitate root-cause analysis process in the context of the impact changes may have.

Data Architecture Criteria

The Change Control functional component:

Shall associate change(s) to Actual Service (s).
Shall associate changes with Incidents bi-directionally (changes in response to Incidents, and changes that actually cause Incidents; i.e., unsuccessful changes) if an Incident functional component exists.
May associate changes with Events when a change triggers an Event or an Event occurs during a change period if an Event functional component exists.
Shall associate the Fulfillment Request with the RFC record as the overall framework that facilitates the IT service implementation/instantiation if a Fulfillment Execution functional component exists.
Shall associate RFCs to the Problem in order to implement a fix to the issue that is documented by the Problem if a Problem functional component exists.

Model

Figure 71: Change Control Functional Component Level 2 Model

8.4.6 Configuration Management Functional Component

Purpose

Focused on tracking the inventories of Actual Services and their associated relationships. Identify, control, record, report, audit, and verify service items; including versions, constituent components, their attributes, and relationships.

Key Data Objects

Actual Service (data object): Represents the realized deployment of the service. Includes Configuration Items that represent the implemented service components. Should be kept in sync with the Desired Service, but includes specific implementation characteristics and details.

Key Attributes

The Actual Service data object shall have the following key data attributes:

Id: Unique identifier of the Actual Service.
Name: Name of the Actual Service.
Type: Type of the Actual Service (e.g., infrastructure service, customer-facing service, enabling service, front office, etc.).
CreateTime: Date/time the Actual Service was created.
LastModifiedTime: Date/time the entry was last modified in a significant way.
Owner: Group or person that is assigned to own the Actual Service.
Location: Location of the Actual Service. Can vary from high-level country to city or low-level, such as building or room.

Key Data Object Relationships

The Actual Service data object shall maintain the following relationships:

Desired Service to Actual Service (1:1): Create traceability between the Desired and Actual Service(s).
RFC to Actual Service (n:m): The Actual Service(s) associated with the change activity.
Problem, Known Error to Actual Service (n:m): Problem records are mapped to the affected Actual Service(s).
Run Book to Actual Service (n:m): Run Book records are mapped to the associated Actual Service(s).
Incident to Actual Service (n:m): Actual Service(s) to which the Incident is associated.
Actual Service to Event (n:m): The Actual Service(s) associated with the Event.
Actual Service to Service Contract (1:n): Connecting between the Actual Services and the Service Contract in which they are measured.
Service Monitor to Actual Service (1:n): The Actual Service being monitored.

Functional Criteria

The Configuration Management functional component:

Shall be the system of record for all Actual Services and their associated relationships.
Shall manage the lifecycle of the Actual Service.
Shall serve as the data store for the realization of the service in the production environment.
Can be populated by service discovery.
Shall calculate and provide the change impact based on the proposed change and the Actual Service relationships if a Change Control functional component exists.
Shall calculate and provide the business impact of the Incident to help in the prioritization process if a Change Control functional component exists.
Shall calculate and provide the business impact of the Event to help in the prioritization process if an Event functional component exists.

Data Architecture Criteria

The Configuration Management functional component:

Shall allow hierarchical relationships between Actual Services.
Shall associate a Run Book with the Actual Service against which the Run Book is associated if a Diagnostics & Remediation functional component exists.
Shall associate an Actual Service with an RFC with which the change is associated if a Change Control functional component exists.
Shall associate the Actual Service with the Problem record against which the Problem is associated if a Problem functional component exists.
Shall associate the Actual Service with the Incident with which the Incident is associated if an Incident functional component exists.
Shall calculate and provide the business impact of the Incident to help in the prioritization process if an Incident functional component exists.
Shall associate the Actual Service with the Event with which the change is associated if an Event functional component exists.
Shall associate the Actual Service with the Service Monitor with which the change is associated if a Service Monitoring functional component exists.

Model

Figure 72: Configuration Management Functional Component Level 2 Model

8.4.7 Diagnostics & Remediation Functional Component

Purpose

Through the use of manual and automated Run Books, provide diagnostics information and/or remediation steps to shorten the MTTR. Run Books help streamline diagnosis and remediation for service functions by applying knowledge solutions to service anomalies.

Key Data Objects

Run Book (data object): A routine compilation of the procedures and operations which the administrator or operator of the system carries out. A Run Book can be either a manual process or an automated script.

Key Attributes

The Run Book data object shall have the following key data attributes:

Id: Unique identifier for the Run Book record.
Description: Description of the Run Book.
Category: The Category aids in determining assignment and prioritization.
ExecutionTime: Date/time the Run Book was created.
ActualServiceId: Related Actual Service(s).

Key Data Object Relationships

The Run Book data object shall maintain the following relationships:

Actual Service to Run Book (n:m):Track Run Books and the Actual Service(s) with which they are associated.

Functional Criteria

The Diagnostics & Remediation functional component:

Shall be the system of record for all Run Books.
Shall manage the Run Book lifecycle.
Can allow an Event to trigger a Run Book mainly for diagnostics purposes if an Event functional component exists.
Can allow an Incident to trigger a Run Book for diagnostics or remediation purposes (remediation that does not require RFCs) if an Incident functional component exists.
Can allow a Problem to trigger a Run Book for remediation purposes (after an RFC has been opened) if a Problem functional component exists.

Data Architecture Criteria

The Diagnostics & Remediation functional component:

Shall allow hierarchical relationships between Run Books,
Shall associate a Run Book with an Actual Service.

Model

Figure 73: Diagnostics & Remediation Functional Component Level 2 Model

8.4.8 Service Level Functional Component

Purpose

Enable the design and creation of Service Contracts (SLAs). Also responsible for the management of all Service Contract data objects throughout their lifecycle including the governance of the Service Contract instances from the moment they are instantiated. Also responsible for collecting the relevant information in order to monitor compliance with the terms specified in the Service Contract and exposing data that reflects that actual performance against the defined Service-Level Objectives (SLOs).

The actual legal aspects of the Service Contracts are not handled by the Service Level functional component directly; however, these documents (usually created and managed by the legal department and not in IT) are used by the functional components in the S2P and R2D Value Streams as the main input for the demand and requirements definition stages.

Key Data Objects

Service Contract (data object): Describes the service characteristics and supports service measurement tracking, governance, and audit. Service Contracts can be related to logical services as well as physical services. Service Contracts related to logical services are known as Service Contract templates, while Service Contracts related to physical services are known as Service Contract instances. Each Service Contract data object is comprised of two main parts: the General Contract definitions (aka the header) and the SLOs (the line items), which also enable nesting other Service Contracts that define Service Levels for different aspects of the service. These lines may need to be detailed due to the service being composed of multiple services, because there are multiple providers involved, or to cover different areas of Service Levels.
Key Performance Indicator (data object): The definition of an objective that is measured, its requested thresholds, and the exact mathematical method in which measurement data items are used in order to calculate the KPI measurements.

Key Attributes

The Service Contract data object shall have the following key data attributes:

Id: Unique identifier of the Service Contract.
Name: Name of the Service Contract.
Type: Type of the Service Contract (SLA, OLA, UC).
Provider: Provider of the service.
Consumer: Consumer of the service.
StartDate: Start date/time of the Service Contract.
EndDate: End date/time of the Service Contract.
SupportCalendar: Contracted support hours of the service.
AdherenceCalculationPeriodicity: Service measurement calculation period.
MaintenanceWindow: Service maintenance timeframes/blackout periods.
ActualServiceId: Related Actual Service(s).

The Key Performance Indicator data object shall have the following key data attributes:

Name: The name of the Key Performance Indicator.
Description: A short description of the Key Performance Indicator.
Threshold: The threshold of the Key Performance Indicator.

Key Data Object Relationships

The Service Contract data object shall maintain the following relationships:

Service Release Blueprint to Service Contract (n:m): The Service Release Blueprint serves as the place where the Service Contract templates are being stored after their development and before they are shipped to the Service Level functional component.
Actual Service to Service Contract (1:n): Relationships to Actual Service(s) are maintained and updated to ensure functional component and data object traceability in the value stream.
Service Contract to KPI (n:m): KPIs will track the measurements associated with Service Contracts. Service Contracts will have multiple KPIs.
Subscription to Service Contract (1:1): Once a Subscription is instantiated it also triggers the instantiation of a Service Contract instance from the Service Contract template.

Service Contract (instance) data flow between the Request Rationalization functional component and the Service Level functional component must manage the Service Contract (instance) lifecycle state.

Functional Criteria

The Service Level functional component:

Shall be the system of record for the Service Contract.
Shall manage the Service Contract lifecycle (create, store, and maintain).
Shall manage the lifecycle (create, store, and maintain) of KPIs.
Shall manage the state of the Service Contract.
Shall manage the relations between the Service Contract data object and the KPI data object throughout their lifecycle.
Shall receive measurements such as Incident data as well as other information that may be covered by the Service Contract and used for calculating the KPI measurements.
Shall create reports on the Service Contracts to show the quality of service per SLO.
Can receive business/IT measurements from Service Monitoring if a Service Monitoring functional component exists.
Can instantiate a Service Contract from a Service Release Blueprint using the Service Contract (template) if a Release Composition functional component exists.
May instantiate a Service Contract from a Service Contract (template) originating from the Offer Management functional component (R2F Value Stream) if an Offer Management functional component exists.
Shall create a Service Contract (instance) and start measuring it once a Subscription is instantiated if a Request Rationalization functional component exists.
May receive Incident business measurements from the Incident functional component if an Incident functional component exists.
Can send reporting data on the Service Level status if an Offer Consumption functional component exists.

Data Architecture Criteria

The Service Level functional component:

Shall allow hierarchical relationships between Service Contracts.

Model

Figure 74: Service Level Functional Component Level 2 Model

8.4.9 Other IT Operations Areas

IT operations include a broad area of capability and many of these capabilities are not part of the D2C Value Stream.

Capacity planning is currently not included in the D2C Value Stream; however, there is a definite relationship with the D2C Value Stream. Its impact and relationship will be reviewed in future releases.
Availability Management, although not represented in the D2C Value Stream, is recognized as adding value to the D2C Value Stream. It will be reviewed in future releases.
Intelligence, trending, proactive alerting (for example) are capabilities within the D2C Value Stream functional components Service Monitoring, Event, and Incident that may be sources of Events or Incidents.