Understanding Configuration Management System (CMS) and Configuration Management Database (CMDB) – Part 1

In ITIL V2, the CMDB is described as a database that contains the relationships between all the system components, including Incidents, Problems, Known Errors, Changes and Releases. The CMDB also contains information about Incidents, Problems, Known Errors, corporate data about employees, suppliers, locations and business units. It also goes on to say that the CMDB is often used to store details of Services and relate them to the underlying components and may also be used to store contracts and licences.

ITIL V2 seems to imply that a configuration management system is a set of tools used to support the Configuration Management activities.

In ITIL V3, the definition of CMS and CMDB is slightly changed from that of ITIIL V2. According to the ITIL V3 Glossary:

CMS = A set of tools AND databases that are used to
manage an IT Service Provider's Configuration data. The CMS also
includes information about Incidents, Problems, Known Errors, Changes
and Releases; and may contain data about employees, Suppliers,
locations, Business Units, Customers and Users. The CMS includes
tools for collecting, storing, managing, updating, and presenting data
about all Configuration Items and their Relationships. The CMS is
maintained by Configuration Management and is used by all IT Service
Management Processes.

CMDB = A database used to store Configuration Records
throughout their Lifecycle. The Configuration Management System
maintains one or more CMDBs, and each CMDB stores Attributes of Configuration Items (CIs), and Relationships with other CIs.

In other words, a CMDB is a database within a CMS. At the data level, the CMS may take data from several physical CMDBs, which together constitute a federated CMDB. Other data sources will also plug into the CMS such as the definitive media libraries (DML). A SCD (Supplier and Contracts Database) which stores information on supplier and contracts used in service management is also a database within the CMS and can be considered a CMDB.  A service catalogue is just a form of CMDB.

According to the ITIL V3 books, the CMS maintains the relationships between all service components and any related incidents, problems, known errors, change and release documentation and may also contain corporate data about employees, suppliers, locations and business units, customers and users.

Relationships are the mechanism for associating RFCs, incident records, problem records, known errors and release records with the services and IT infrastructure CIs to which they refer. All these relationships should be included in the CMS. Request for Change (RFC) and change and release records will identify the CIs affected.

What about the actual incident, problem, change and release records? Are the actual records stored in or forms part of the CMS? According to the ITIL Glossary, the CMS contains “information about” incident, problems, Known Errors and Releases. 

I think actual incident, problem, change and release records should be considered as part of the CMS although the ITIL V3 Service Operation book does not explicitly mention about storing incident records in the CMS. However, it mentions that Problem Management uses the CMS to identify faulty CIs and also to determine the impact of problems and resolutions. The CMS can also be used to form the basis for the KEDB and hold or integrate with the Problem Records. This means CMS may or may not store Problem and Known Error records, but the relationships information should be captured in the CMS.

The ITIL V3 Service Transition book does explicitly mention that the change and release records are stored within the CMS.

• As an RFC proceeds through its lifecycle, the change document, related records (such as work orders) and related configuration items are updated in the CMS, so that there is visibility of its status. Estimates and actual resources, costs and outcome (success or failure) are recorded to enable management reporting.
• Release information is recorded within the CMS, supporting the release and deployment process.

In real-life implementations, off-the-shelf tools from vendors like HP (HP Service Center) and BMC (Remedy) provides an integrated toolset that contain integrated modules to support the Incident, Problem, Change and Configuration Management processes. It contains all incident, problem and known errors records with relationships and linkages to the services and CI details stored in a database.