DoIT Operational Framework - Section 5.0 - Configuration Management
Policies and Standards for Configuration Management at DoIT
DoIT staff support hundreds of servers, applications, software, databases and services, in addition to various network configurations, resulting in a large and complex environment.
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.
Information in the CMDB is intended for DoIT staff only. Any information stored in the CMDB that is shared beyond DoIT Staff must be done so with management approval.
The objectives, or goals, of Configuration Management at DoIT are to improve IT service management by:
Experience has demonstrated that these objectives can be achieved by:
- 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.
Configuration Management requirements cover all Information Technology Assets, Systems, and Services provided, monitored, or managed by DoIT.
Information recorded is that which is essential to IT Service Management - including both CI information and relationships between CIs. The following describes the types of CI information stored in the CMDB:
- 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
The above information types include data integral to meeting DoIT management, University, and State requirements; as well as information needed to maintain day-to-day service operations. Additional information types may be captured in the CMDB in support of any further organizational requirements, or operation needs.
Delegated service delivery where service impact is local and sanctioned is outside the scope of this document.
Managing the information of Configuration Items (CIs) is used to improve service operating efficiency by addressing reliability and performance.
This is achieved by efforts:
- To identify, control, record, report, audit and verify service assets and configuration items
Configuration Item records will be stored in the CMDB with Data elements that are defined in the CMDB Data Dictionary (see below).
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
Creation and modification of CIs in the CMDB are controlled actions and occur only in one of the following cases:
- An automated integration
- As a result of a process which is subject to Change Management
- As a result of an audit
Further, in order to ensure quality of CMDB data, no CI should exist in the CMDB without the ability to:
- Identify that unique CI within the CMDB
- Identify a point of contact - person or team - to contact regarding the CI
data is subject to Audits coordinated through the Configuration
Management IT Service Management Sub-Team, as well as ad-hoc audits
coordinated by the Configuration Manager. Reasons for ad-hoc audits
include (but are not limited to):
- Incident follow-up
- Change follow-up
- Newly-released Services
- Policy changes
- Data Verification
All CIs should be subject to annual audit to verify data - through formal or informal, manual or automated means.
CI Data Retention requirements are subject to University of Wisconsin System Information Technology Records General Records Schedule. As of 2012 the UW has a retention policy of 3 years after Discontinuance of System.
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
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
of the close relationship between the CMDB Data Dictionary and the ITSM
tool that serves as the functional CMDB, the CMDB Data Dictionary is
also expected to have tool-specific information. It will be a
requirement that tool-specific information be identified as such.
Examples of this could include specific database scheme information to
access values of a specific CI element defined in the Data Dictionary.
Describing the relationships between Configuration Items for impact analysis is used to mitigate risks to service availability.
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
A Configuration Model is composed of 2 or more CIs that have Relationships defined between them. It is typically represented as a directed graph, with CIs acting as nodes and Relationships acting as edges between the nodes. Below is an example of a Configuration Model as a directed graph:
(Note: for visual example only, all data has expired.)
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)
Section 220.127.116.11 Defining and Describing CI Relationships
Relationships captured in the CMDB all meet the following criteria:
- 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.
Because relationships have weight and direction, we standardize four possible ways to describe relationships between two CIs:
Definition: Source CI Uses <Related CI>.
Definition: Source CI (is) Used By <Related CI>
Definition: Source CI Requires <Related CI>.
Using the example diagram above, we see::
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
Note that #1 and #2 refer to the same relationship between the CIs HP OpenView Service Desk and Service Desk Web Console and differ in their description simply by orientation. The acknowledgement and understanding of differing perspectives when considering CI relationships is key for universal communication of relationship information through the organization as personnel are typically most familiar with the CIs representing their primary responsibilities, and need a way to describe their relationships to other CIs from that perspective.
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
Section 5.4.4 - Stakeholder Communications
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
Notification - any party interested in the relevant CI
- There must be at least 1 Primary Administrator and Team assigned to a CI
- 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
There are 2 types of Notification Stakeholders
- 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)
- Ensure that modifications to your CI have Change records
- Ensure that the CMDB is updated as part of the Change Records
- Understand your CI's direct dependencies
- Understand who your CI supports
- Maintain technical support contact documentation
- Provide information for, or if necessary, participate in audits of CI records for CIs you are responsible for
| Configuration Manager
- Oversee the implementation of the CMDB according to the scope provided by Tech Directors/higher management
- Understand and document procedures for implementing the guidelines established in the operational framework
- Be a resource for any questions involving configuration management policies and procedures at DoIT
- Own the process for all changes, additions, deletions to the CMDB
- Enforce Configuration Management process and standards where necessary
- Analyze the effectiveness of the Configuration Management processes
- Identify and lead implementation of Configuration Management process improvements
- Maintain Configuration Management documentation and tools
- Enable and support integration of Configuration Management into other processes
- Provide periodic updates on the state of Configuration Management to management
- Perform and/or coordinate periodic CI data audits to ensure CMDB data integrity.
| ITSM Process Owners
- Ensure that the responsibility and accountability for CMDB updates are defined for every process that may alter tracked CI information
| Service Level Manager
- Understand the complex relationships between interdependent and supporting services
| Tech Directors
- Define scope of CMDB
- Mandate adherence to Configuration Management policy
- Approve of the definitive source(s) of information for the CMDB