Configuration management database

A configuration management database (CMDB) is a repository that acts as a data warehouse for information technology (IT) installations. It holds data relating to a collection of IT assets (commonly referred to as configuration items (CI)), as well as to descriptive relationships between such assets. When populated, the repository provides a means of understanding:

the composition of critical assets such as information systems
the upstream sources or dependencies of assets
the downstream targets of assets

Purpose and Benefits

CMDBs are used to keep track of the state of different things that are normally referred to as assets, such as products, systems, software, facilities, and people as they exist at specific points in time, as well as the relationships between such assets. The maintenance of such state related information allows for things like the reconstruction of such assets, at any point in their existence, as well as for things such as impact analysis, in the cases of root cause analysis or change management.

The Information Technology Infrastructure Library (ITIL) framework, describes the use of CMDBs as part of infrastructure operations and support. In the ITIL context, a CMDB represents the authorized configuration of the significant components of the IT environment.

A CMDB helps an organization understand the relationships between the components of a system and track their configurations. The CMDB is a fundamental component of the ITIL framework's Configuration Management process. CMDB implementations often involve federation, the inclusion of data into the CMDB from other sources, such as Asset Management, in such a way that the source of the data retains control of the data. Federation is usually distinguished from ETL (extract, transform, load) solutions in which data is copied into the CMDB.

CMDBs can be used for many things, including but not limited to business intelligence, software and hardware builds, and impact analysis for both Change management^[1] and Incident management.

The CMDB contains and records data records that are also called configuration items (CI). It also provides details about the important attributes of CIs and the relationships between them.

CI attributes and data

Depending on the CI type or category, there are many attributes that might be captured:

CI Unique Identifier or Identification Code
CI Name or Label (often, both, long names and short names)
CI Abbreviations or Acronyms
CI Description
CI Ownership (organizations and people)
CI Importance

There can be many more, depending on the CI types. In some cases, there may be hundreds of attributes.

Because attributes are defined by metadata, CMDBs also contain metadata, and thus the concept overlaps with that of a metadata repository, which is also used to more effectively run IT organizations. Configuration management addresses how the data is to be kept up to date, which has historically been a weakness of metadata repositories.

Relationships between CIs

At a minimum relationships are often composed of a Source CI that is related to a Target CI. In the case of more advanced relationships, such as semantic relationships, it is desirable to have a descriptor between the Source CI and Target CI that helps provide context. For example, "Database X" is related as a "Component" of "Application Y". The descriptor is also known as a Predicate.

Configuration item types

A Configuration item type (or CI Type) is the data type of the element or configuration item an enterprise wishes to store within the CMDB. At a minimum, all software, hardware, network, and storage CI Types are stored and tracked in a CMDB. As enterprises mature, they start to also track business CI Types in their CMDB, as well, such as organizations, people, markets, products, and 3rd party entities such as vendors and partners. This allows the relationships between CIs to become more meaningful and the CMDB to become stronger source for knowledge management.

CI types are:

Hardware
Software
Communications/Networks
Location
Documentation
People (Staff and Contractors)

A key success factor in implementing a CMDB is the ability to automatically discover information about the CIs (auto-discovery) and track changes as they happen.

CMDB schematic representations

CMDBs schematic structures, also known as database schemas (or just "schemas"), take on multiple forms. Two of the most common forms are those of a relational data model and a semantic data model.

Relational data models are based on first-order predicate logic and all data is represented in terms of tuples that are grouped into relations. In the relational model, related records are linked together with a "key", where the key is unique to an entry's data type definition. Such relational models provide declarative methods for specifying data and queries. In other words, users directly state what information the database contains and what information they want from it, and let the database system take care of describing data structures for storing the data and retrieval procedures for answering queries.

Semantic data models typically rely on the resource description framework and use a model that simply relates any thing to any other thing through the use of a relationship descriptor, giving context to how things are related to each other.

Challenges

There are three core challenges to creating and maintaining a CMDB.

The first challenge has to do with what it takes to get all relevant data into a CMDB. In this case, collecting all the data, throughout each record's or CI's life cycle becomes critical. This means putting in processes and tools to collect the most recent changes to data as it occurs.
The second challenge has to do with maintaining the data, once it is in the CMDB, as it will change regularly and rapidly. Organizations that spend the investment to build out their CMDBs often find that one of the biggest challenges is the work and investment to maintain the data, after it is stored. This is because data about CIs and the relationships between them are constantly changing. Enterprises soon learn that manual maintenance of relationships is a significant undertaking that is often not planned for or expected.
The third challenge has to do with making the data usable and useful, after it is in the CMDB. Most CMDBs are just databases. This means they have no traits, features, or benefits of more complex applications. They lack tools to view data via complex visualizations or tools for advanced discovery. This means that most enterprises need to invest the funds, time, and energy to develop an application layer that adds such constructs to their CMDB, which adds a layer of complexity and cost that most enterprises do not plan for or expect. However, implementing features that ensure the database is up to date or allow it to interact with systems to run commands, apply updates, or deploy new applications extend the functionality and usefulness of the CMDB significantly.

It is because of the above three challenges that most enterprises opt to purchase their CMDBs, rather than designing, building, delivering, and supporting them themselves.

References

↑ Sauvé, Jacques; Rebouças, Rodrigo; Moura, Antão; Bartolini, Claudio; Boulmakoul, Abdel; Trastour, David (2006). Business-Driven Decision Support for Change Management: Planning and Scheduling of Changes. Springer Berlin Heidelberg. pp. 173–184. ISBN 978-3-540-47662-7. Retrieved 30 August 2014.