If you have questions, please email Configuration Management.

• 5.1 Background
• 5.2 Objectives and Goals
• 5.3 Scope of Configuration Management
• 5.4 Managing CI Information
• 5.4.1 Types in the CMDB
• 5.4.2 Fields and the CMDB Data Dictionary
• 5.4.3 Relationships and the Configuration Model
• Section 5.4.3.1 Defining and Describing CI Relationships
• 5.4.4 Stakeholder Communication
• 5.5 Roles & Responsibilities

Section 5.1 - Background

DoIT staff support hundreds of services, comprised of locally and “cloud” hosted servers, applications, software, and databases, resulting in a large and complex environment. The Configuration Management Database, or CMDB, is the information repository where Configuration Items, or 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.

Section 5.2 - Objectives and Goals

The objectives, or goals, of Configuration Management at DoIT are to improve IT service management by:

• improving operating efficiency by addressing reliability and performance,
• mitigating risks to service availability, and
• providing communication and transparency to users.

Experience has demonstrated that these objectives can be achieved by:

• 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.

Section 5.3 - Scope of Configuration Management

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.

Section 5.4 - Managing CI Information

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
• 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

Configuration Item records will be stored in the CMDB with Data elements that are defined in the CMDB Data Dictionary (see below). 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

CI Owners may update their own "owned" CIs (responsible technologist) if the updates do not change CI dependencies and therefore impact analysis, i.e., Change Management is unnecessary. 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

CMDB 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):

• Problem 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.

Section 5.4.2 - Fields and the CMDB Data Dictionary

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. The CMDB Data Dictionary will describe every tracked Configuration Item data element, including:

• Purpose
• 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

Because 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.

Section 5.4.3 - Relationships and the Configuration Model

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 5.4.3.1 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 CI record. Open CI<some relationship>Related CI.
• 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:

• Uses
  • Definition: Source CI Uses<Related CI>
• Used By
  • Definition: Source CI Used By<Related CI>
• Requires
  • Definition: Source CI Requires<Related CI>
• Required By
  • Definition: Source CI Required By<Related CI>

Using the example diagram above, we see:

1. "Uses" - HP OpenView Service Desk Uses Service Desk Web Console
2. "Used By" - Service Desk Web Console (is) Used By HP OpenView Service Desk
3. "Requires" - OPSDP1 Requires CIMRMAN
4. "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 acknowledgment 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.

Section 5.4.3.2 Relationship Logic

The key criteria in "Requires" versus "Uses" is the Environment of the CI in question.

• Environment = Production = Requires/Required By
• Environment <> Production = Uses/Used By

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:

1. 1. 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
      • 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)
   2. Notification - any party interested in the relevant CI
      • There should be at least 1 notification stakeholder assigned to a CI
        • Exceptions: Facility Device
      • There are 2 types of Notification Stakeholders
        • 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 NagiosXI)

Section 5.5 - Configuration Management Roles & Responsibilities