Copyright © 2015 The Open Group
| < Previous | ▲ Home | Next > |
|
IT4IT Reference Architecture, Version 2.0 Technical Standard Copyright © 2015 The Open Group |
|
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.
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.
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
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: Increase in breadth and depth of monitoring endpoints, reduction of escalated events (via filtering/correlation/ automated resolution), reduction of false positives, and reduction of the number of security events that cause business disruption. Incidents: Incident reduction, reduction of escalated Incidents, reduction of false positives, reduction in the total number of security-related Incidents. Problems: Increase Problems identified, increase Problems eradicated. Changes: Reduction of change-related outages, reduction of emergency changes, reduction of unplanned changes, and reduction of security vulnerabilities introduced during Change Management. Knowledge: Increase Known Error availability (enrich Known Error database), increased usage. |
|
Improve Customer Satisfaction |
OLA/SLA: Reduction of failed agreements. Availability of critical business systems: Increase uptime, decrease MTTR, increase MTBF. Performance (user experience) of critical business systems: Decrease user complaints. Incidents: Increased rate of first call resolution. Self-service: Increased success rate for user self-fix. |
|
Improve Staff Effectiveness |
Events: Increase automatically remediated Events, increase the percentage of Events correlated to a business service. Incidents: Reduction of re-opened Incidents, increase percentage of first call resolution, reduction in average time to close an Incident, increase automatically remediated Incidents, reduce average handling time, and reduce rejected Incidents. Changes: Increase automatically remediated changes. |
|
Alignment with Business Strategy |
Cost: Increase percentage of time invested on business-critical services. Services: Increase number of business services defined, decrease percentage of business-critical services, decrease number of CIs that are not linked to a business service, increase “quality of service” monitoring for internal and external business services. SLA/SLO: Increase percentage of business-critical services with defined Service Level targets. Security: Number of security-related outages to business-critical systems, number of security Incidents causing financial loss, business disruption, or public embarrassment, number of security Incidents resolved without business impact. |
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 into action that typically lead to the resolution and closure of the related Events, Incidents, or Problems.
The D2C Value Stream may interact with other value streams by creating:
• Portfolio Backlog Item (demand request) in the S2P Value Stream (Problems that can’t be solved or are bigger than regular Defects).
• Defects in the R2D Value Stream (emergency fixes required to resolve the Incident or Problem).
• Usage in the R2F Value Stream (the Service Monitoring functional component provides usage for Subscription management, billing, chargeback, and showback).
• Knowledge data objects in the R2F Value Stream (problem resolution may capture knowledge of Known Errors).
• Status and Service Level status information for the R2F Value Stream (supplying monitoring status and SLA status to the Offer Consumption functional component).
• Storing the Service Contract (template) coming from the R2D and R2F Value Streams (as a base artifact for SLA management and creating the Service Contract instances) and also creating the Service Contract (instance) once the Subscription has been created in the R2F Value Stream.
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 65 shows the functional components, data objects, and entity relationships for the D2C Value Stream.
Note: The red lines in Figure 65 represent recognized industry employed linkage variations. These variations and their associated implications will be detailed in future releases.
Figure 65: Detect to Correct Level 2 Value Stream Diagram
Purpose
The Service Monitoring functional component is 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. It is also in charge of storing all measurement results and calculating compound measurements. The Service Monitoring functional component is 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:
• ServiceMonitorID: 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?
• ActualServiceCI_ID: Identifier of related CI(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 CIs (1:n): The Actual Service CI 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.
Main Functions
The Service Monitoring functional component:
• Shall be the system of record for all Service Monitors.
• Shall manage the lifecycle of the Service Monitor.
• 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 create an association between the Service Monitor data object and the related Actual Service CI(s).
If an Event functional component exists, the Service Monitoring functional component:
• Shall initiate the creation of an Event or alert that is passed to the Event functional component.
If an Offer Consumption functional component exists, the Service Monitoring functional component:
• Can provide service monitoring status.
If a Usage functional component exists, the Service Monitoring functional component:
• Can provide service usage measurements.
If a Service Level component exists, the Service Monitoring functional component:
• Can provide business/IT measurements.
If a Fulfillment Execution functional component exists, the Service Monitoring functional component:
• Can receive Service Monitor definitions.
Model
Figure 66: Service Monitoring Functional Component Level 2 Model
Purpose
The Event functional component manages 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:
• EventID: 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.
• EventType: Categorizing the Event to causal or symptom type.
• EventStatus: The current stage in the lifecycle of an Event.
• EventStatusTime: Time stamp for the EventStatus 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?
• ActualServiceCI_ID: 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 CIs (n:m): The Actual Service CI(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.
Main Functions
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.
• Shall create an association between the Event data object and the related Actual Service CI(s).
If a Diagnostics & Remediation functional component exists, the Event functional component:
• May send Events for diagnostics and remediation processing.
Model
Figure 67: Event Functional Component Level 2 Model
Purpose
The Incident functional component facilitates normal service operations restoration as quickly as possible and minimizes 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.
• 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:
• IncidentID: Unique identifier for the Incident record.
• Category: The category aids in determining assignment and prioritization.
• SubCategory: The second level of categorization, following Category.
• IncidentStatus: The current stage in the lifecycle of an Incident.
• IncidentStatusTime: Time stamp for the IncidentStatus 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.
• ActualServiceCI_ID: Related CI(s).
The Interaction data object shall have the following key data attributes:
• IteractionID: 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 CIs (n:m): CI 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.
Main Functions
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 CI(s).
If a Defect functional component exists, the Incident functional component:
• 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 Diagnostics & Remediation functional component exists, the Incident functional component:
• Can trigger the execution of a Run Book (either automated or manual) to provide diagnostic information or remediation steps.
If a Problem functional component exists, the Incident functional component:
• May create a Problem record when the Incident is severe, requires further deep investigation, or is repeating.
If a Change Control functional component exists, the Incident functional component:
• Can trigger the creation of an RFC in order to implement a fix to the Incident fault.
If a Self-Service Support functional component (R2F Value Stream) exists, the Incident functional component:
• Can allow the initiation of an Interaction or an Incident.
If a Service Level functional component exists, the Incident functional component:
• Can provide business measurements of Incident data.
Model
Figure 68: Incident Functional Component Level 2 Model
Purpose
The Problem functional component is responsible for managing the lifecycle of all Problems. The objectives of the Problem functional component 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. The Problem functional component 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:
• ProblemID: 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.
• ProblemStatus: The current stage in the lifecycle of a Problem.
• ProblemStatusTime: Time stamp for the ProblemStatus attribute.
• Title: Title of the Problem.
• Description: Description of the Problem.
• AssignedTo: Group or person that is assigned to fix the Problem.
• ActualServiceCI_ID: Related CI(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 CI (n:m): Problem records are mapped to the affected CI(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.
Main Functions
The Problem functional component:
• Shall be the system of record for all Problem records.
• Shall manage the state and lifecycle of the Problem.
• Shall associate Problem(s) to CI(s).
• Shall create Known Error data object instances from unsolved Problems.
If a Diagnostics & Remediation functional component exists, the Problem functional component:
• 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 Change Control functional component exists, the Problem functional component:
• 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 Knowledge & Collaboration functional component exists, the Problem functional component:
• Shall use existing Knowledge data to solve a Problem.
• Can create a new Knowledge data object based on Problem Management activities (from the Known Error data object instances).
If an Incident functional component exists, the Problem functional component:
• Shall associate Incident data to the corresponding Problem record and continue the investigation around the Incident reported fault within the Problem lifecycle.
If a Defect functional component exists, the Problem functional component:
• Shall push Problem data requiring emergency/specific development to the Defect functional component (R2D Value Stream).
If a Portfolio Demand functional component exists, the Problem functional component:
• May push a Portfolio Backlog Item to the Portfolio Demand functional component for backlog processing.
Model
Figure 69: Problem Functional Component Level 2 Model
Purpose
The Change Control functional component is the system that is responsible for managing the lifecycle of all the RFCs in the IT environment. It makes sure that changes are done in a standardized and auditable way so that the business risk is minimized. It manages 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 CI relationship 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.
• ChangePhase: The current step in the RFC workflow.
• ChangePhaseTime: Time stamp for the change phase.
• ApprovalStatus: The current status of the RFC approval.
• ChangeRisk: 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.
• ActualServiceCI_ID: Related CI(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 CIs (n:m): Associates the RFC with affected CI(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 (1:n): 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.
Main Functions
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 associate change(s) to CI(s).
• 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.
If an Incident functional component exists, the Change Control functional component:
• Shall associate changes with Incidents bi-directionally (changes in response to Incidents, and changes that actually cause Incidents; i.e., unsuccessful changes).
If an Event functional component exists, the Change Control functional component:
• May associate changes with Events when a change triggers an Event or an Event occurs during a change period.
If a Fulfillment Execution functional component exists, the Change Control functional component:
• Shall associate the Fulfillment Request with the RFC record as the overall framework that facilitates the IT service implementation/instantiation.
If a Problem functional component exists, the Change Control functional component:
• Shall associate RFCs to the Problem in order to implement a fix to the issue that is documented by the Problem.
Model
Figure 70: Change Control Functional Component Level 2 Model
Purpose
The Configuration Management functional component is focused on tracking the inventories of Actual Service CIs and their associated relationships. It identifies, controls, records, reports, audits, and verifies service CIs; including versions, constituent components, their attributes, and relationships.
Key Data Objects
• Actual Service CI (data object): Serves as the data store for the realization of the service in the production environment. CIs may be populated by service discovery, created by manual processes, or sourced from other processes such as IT Asset Management. A CI is defined as any component that may need to be managed in order to deliver an IT service. Typical CIs include but are not limited to: application services, infrastructure services, databases, message queues, batch jobs, logical transactions, servers (virtual and physical), network devices, storage devices, racks, power distribution units, laptops, software packages, and components.
Key Attributes
The Actual Service CI data object shall have the following key data attributes:
• ActualServiceCI_ID: Unique identifier of the CI.
• Name: Name of the CI.
• Type: Type of the CI (e.g., service, computer, network card, database, etc.).
• CreateTime: Date/time the CI was created.
• LastModifiedTime: Date/time the entry was last modified in a significant way.
• Owner: Group or person that is assigned to own the CI.
• Location: Location of the CI. Can vary from high-level country to city or low-level, such as building or room.
Key Data Object Relationships
The Actual Service CI data object shall maintain the following relationships:
• RFC to Actual Service CIs (n:m): The Actual Service CIs represent the CI(s) associated with the change activity.
• Problem, Known Error to Actual Service CI (n:m): Problem records are mapped to the affected CIs.
• Run Book to Actual Service CI (n:m): Run Book records are mapped to the associated CIs.
• Incident to Actual Service CIs (n:m): CI(s) to which the Incident is associated.
• Actual Service CIs to Event (n:m): The Actual Service CI(s) associated with the Event.
• Actual Service CIs to Service Contract (n:1): Connecting between the CIs and the Service Contract they are measured in.
• Service Monitor to Actual Service CIs (1:n): The Actual Service CI represents the CI being monitored.
Main Functions
The Configuration Management functional component:
• Shall be the system of record for all Actual Service CIs and their associated relationships.
• Shall manage the lifecycle of the CI.
• Shall allow hierarchical relationships between CIs.
• Shall serve as the data store for the realization of the service in the production environment.
• Can be populated by service discovery.
If a Diagnostics & Remediation functional component exists, the Configuration Management functional component:
• Shall associate a Run Book with the CI against which the Run Book is associated.
If a Change Control functional component exists, the Configuration Management functional component:
• Shall associate a CI with an RFC with which the change is associated.
• Shall calculate and provide the change impact based on the proposed change and the CI relationships.
If a Problem functional component exists, the Configuration Management functional component:
• Shall associate the CI with the Problem record against which the Problem is associated.
If an Incident functional component exists, the Configuration Management functional component:
• Shall associate the CI with the Incident with which the Incident is associated.
• Shall calculate and provide the business impact of the Incident to help in the prioritization process.
If an Event functional component exists, the Configuration Management functional component:
• Shall associate the CI with the Event with which the change is associated.
• Shall calculate and provide the business impact of the Event to help in the prioritization process.
If a Service Monitoring functional component exists, the Configuration Management functional component:
• Shall associate the CI with the Service Monitor with which the change is associated.
Model
Figure 71: Configuration Management Functional Component Level 2 Model
Purpose
Through the use of manual and automated Run Books, the Diagnostics & Remediation functional component provides 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:
• RunbookID: 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.
• ActualServiceCI_ID: Related CI(s).
Key Data Object Relationships
The Run Book data object shall maintain the following relationships:
• CI to Run Book (n:m):Track Run Books and the CI with which they are associated.
Main Functions
The Diagnostics & Remediation functional component:
• Shall be the system of record for all Run Books.
• Shall manage the Run Book lifecycle.
• Shall allow hierarchical relationships between Run Books.
• Shall associate a Run Book with a CI.
If an Event functional component exists, the Diagnostics & Remediation functional component:
• Can allow an Event to trigger a Run Book mainly for diagnostics purposes.
If an Incident functional component exists, the Diagnostics & Remediation functional component:
• Can allow an Incident to trigger a Run Book for diagnostics or remediation purposes (remediation that does not require RFCs).
If a Problem functional component exists, the Diagnostics & Remediation functional component:
• Can allow a Problem to trigger a Run Book for remediation purposes (after an RFC has been opened).
Model
Figure 72: Diagnostics & Remediation Functional Component Level 2 Model
Purpose
The Service Level functional component enables the design and creation of Service Contracts (SLAs). It is 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. This functional component is 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:
• ServiceContractID: 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.
• ActualServiceCI_ID: Related CI(s).
The Key Performance Indicator data object shall have the following key data attributes:
• KeyPerformanceIndicatorName: The name of the Key Performance Indicator.
• KeyPerformanceIndicatorDescription: A short description of the Key Performance Indicator.
• KeyPerformanceIndicatorThreshold: 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 CIs to Service Contract (1:n): CI relationships 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.
Main Functions
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 allow hierarchical relationships between Service Contracts.
• 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.
If a Service Monitoring functional component exists, the Service Level functional component:
• Can receive business/IT measurements from Service Monitoring.
If a Release Composition functional component exists, the Service Level functional component:
• Can instantiate a Service Contract from a Service Release Blueprint using the Service Contract (template).
If an Offer Management functional component exists, the Service Level functional component:
• May instantiate a Service Contract from a Service Contract (template) originating from the Offer Management functional component (R2F Value Stream).
If a Request Rationalization functional component exists, the Service Level functional component:
• Shall create a Service Contract (instance) and start measuring it once a Subscription is instantiated.
If an Incident functional component exists, the Service Level functional component:
• May receive Incident business measurements from the Incident functional component.
If an Offer Consumption functional component exists, the Service Level functional component:
• Can send reporting data on the Service Level status.
Model
Figure 73: Service Level Functional Component Level 2 Model
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.
| < Previous | ▲ Home | Next > |