DoIT Operational Framework - Section 5.0 - Configuration Management
Policies and Standards for Configuration Management at DoIT
DoIT Operational Framework - Section 5.0 - Configuration Management
Section 22.214.171.124 Defining and Describing CI Relationships
5.4.4 Stakeholder Communication
The Configuration Management Database, or CMDB, is the information repository where CIs are tracked. This enterprise-wide repository allows for standardized management of CI data and provides a common point of reference for the organization. As DoIT's Service offerings have grown, become more sophisticated, and interdependent, information in the CMDB has become key to successful IT business practices governing DoIT's day-to-day operation.
- improving operating efficiency by addressing reliability and performance,
- mitigating risks to service availability, and
- providing communication and transparency to users.
- managing the information of Configuration Items (CIs),
- describing the relationships between Configuration Items for impact analysis, and
- leveraging stakeholder ties to Configuration Items for Event, Incident, Problem and Change notifications.
- IT Asset identification information - Inventory, CI type, manufacturer, model, version, etc.
- Financial information - UDDS, DoIT Number or CBS
- Availability information - Maintenance windows
- Accountability information - administrators and responsible parties
- Dependency information - relationships of CI(s) to CI(s)
- Capacity information - storage
- Disaster Recovery information - COOP
This is achieved by efforts:
- To identify, control, record, report, audit and verify service assets and configuration items
- To account for, manage and protect the integrity of service assets and configuration items, ensuring only authorized components are used and authorized changes are made
- To capture, retain and maintain all Continuity of Operations information required by DoIT's Continuity of Operations Plan
- An automated integration
- As a result of a process which is subject to Change Management
- As a result of an audit
- Identify that unique CI within the CMDB
- Identify a point of contact - person or team - to contact regarding the CI
- Incident follow-up
- Change follow-up
- Newly-released Services
- Policy changes
- Data Verification
Section 5.4.1 - Types in the CMDB
Types are distinguished in the CMDB so that different Assets or Configuration Items:
- Can be grouped logically; and
- Relevant fields can be allocated.
CI Types can be viewed here (KB Doc 47433).
In keeping with data management best practice, the CMDB requires a Data Dictionary (KB 47408) . The Data Dictionary shall be maintained by the Configuration Manager as the place where data elements of the CMDB are defined and tracked. It is through the management of this Dictionary the Configuration Manager can enforce good data management practices for enterprise configuration management, such as avoidance of overloading data fields or duplicate data fields.
The CMDB in practice will adhere to the definitions contained in the data dictionary. Edits, additions, and removals from the data dictionary will occur as required to meet CMDB business needs. These will be done by the Configuration Manager and reviewed by the Configuration Management ITSM sub-team. Any changes in content that would require Operational Framework policy changes would be subject to full Operational Framework document edit approval process.
This verbose dictionary will be subject to good knowledge management practices, including periodic review, and version control.
The CMDB Data Dictionary will describe, in full every tracked Configuration Item data element, including:
- Data Type
- Title of Element
- Authoritative source of element data
- If it is a required element in any or all CI cases
- If it requires a unique value in the CMDB
- If there are unique access restrictions or editing restrictions to the element data
Configuration Management can deliver a “model” of services by describing Configuration Items, their categorizations, their relationships to each other, and important CI attributes, such as Life Cycle and Status. The Configuration Model will enable other processes (such as those governed by Incident Management and Change Management) to:
- Assess the impact and cause of Events
- Assess the impact of proposed Changes
- Plan and design new or changed Services
- Plan technology refreshes and software releases
- Plan Release and Deployment packages
- Familiarize personnel with the dependencies of a particular IT Service or set of Services
In this example, nodes are CIs, with the different shapes/colors indicating the type of CI it is, and relationships are directed edges, with solid arrows indicating a "Requires" relationship and dashed a "Uses" relationship - see below)
- A Relationship is only between 2 Configuration Items.
- A Relationship is directional. Direction indicates dependency of one Configuration Item upon another for it to function as required to support IT Services as intended.
- A Relationship is defined from the open Configuration Item record. Open Configuration Item <some relationship> Related Configuration Item.
- A CI can have any number of relationships to other CIs defined in the CMDB.
- There are 2 'weights' of dependency defined:
- "Requires" which indicates an absolute dependency.
- "Uses" which indicates a dependency that exists, but is not absolute.
Definition: Source CI Uses <Related CI>.
Exception (IP/DNS only): SERVERNAME uses IP, IP uses DNS
Definition: Source CI (is) Used By <Related CI>
Definition: Source CI Requires <Related CI>.
Definition: Source CI (is) Required By <Related CI>.
- "Uses" - HP OpenView Service Desk Uses Service Desk Web Console
- "Used By" - Service Desk Web Console (is) Used By HP OpenView Service Desk
- "Requires" - OPSDP1 Requires CIMRMAN
- "Required By" - OPSDP1 (is) Required By Service Desk App
Used/Used By relationships can have a reason for the apparent dependency. This reason describes the nature of the Used/Used By relationship.
- Definition: SERVERNAME is used by <Related CI> for LINK REASON. SERVERNAME is not required by <Related CI>
- Link Reasons:
- Cluster Member - between a cluster object and that cluster's member servers
- Periodic Feed - information transferred between CIs, the cessation of which does not cause a service outage
- Supporting Tool - this CI being unavailable does not impact another CI's availability
Leveraging stakeholder ties to Configuration Items for Change and Event notifications is used to provide communication and transparency to users.
There are 2 types of stakeholders tied to a Configuration Item:
- Administrative - A technologist, and the Team to which that technologist belongs
- There must be at least 1 Primary Administrator and Team assigned to a CI
- Exceptions: IP, DNS
- Administrative Stakeholders receive email notifications for Changes and Events (i.e., alerts from Enterprise Monitoring, currently only OVO)
- Administrative Stakeholders are akin to Notification Change and Monitoring Stakeholders (see below)
- There should be at least 1 notification stakeholder assigned to a CI
- Exceptions: IP, DNS, Facility Device
- Change - Notification Stakeholder will receive emails from Changes
- Change and Monitoring - Notifications Stakeholder will receive emails from Changes and Events
(i.e., alerts from Enterprise Monitoring, currently only OVO)
|ITSM Process Owners||
|Service Level Manager||
- DoIT Operational Framework - Section 1.0 - Overview
- DoIT Operational Framework - Section 2.0 - Glossary of Significant Terms
- DoIT Operational Framework - Section 3.0 - Change Management
- DoIT Operational Framework - Section 4.0 - Incident Management
- DoIT Operational Framework – Section 6.0 - Event Management
- Working with the Operational Framework (Policy)
- The DoIT Operational Framework, ITIL & Service Management Contacts at DoIT