What Is A CMDB?

A CMDB is the foundation of modern IT operations

A configuration management database (CMDB) holds two kinds of information. The first is the configuration items (CIs) themselves. The second, and the part most estates neglect, is how those items connect.

An inventory can tell you that a database server exists. A CMDB tells you which applications run on it, which business services those applications support, and who owns it when it fails. With that connected view, an incident team can trace a fault and a change board can judge a risk without starting from scratch.

In ServiceNow, the CMDB sits underneath incident, change, problem and vulnerability management. Each of those processes reads from it. When the data is wrong, every one of them inherits the error.

A configuration item isn’t the same thing as an asset, though the two often describe the same physical object: an asset is what finance tracks — cost, depreciation, licence status — while a CI is what operations tracks — what it connects to, what breaks if it fails, and who is accountable when it does.

Configuration items. Each CI belongs to a class, such as server, database or application service, and the class decides which attributes it carries. See our guide to CMDB configuration items.

Relationships between CIs. Runs on, depends on and hosted on relationships turn a list of records into a map you can use during an incident. See how we approach CMDB dependency mapping.

How systems support services. Application services and business services sit at the top of the model, linking the technology to the service a customer actually notices.

Ownership and support information. Every CI needs an owner and a support group. Without them, nobody certifies the record and nobody gets assigned when it breaks.

Life cycle and location data. Whether a CI is in build, live or retired, and where it sits. When a CI turns out to be in the wrong class, it has to be moved carefully, as we explain in CI reclassification in ServiceNow.

Application portfolio. The business applications your organisation runs, connected to the infrastructure that runs them.

Incident management

When a service fails, its relationships point the resolver group at the CIs underneath it, so the team starts from the likely cause.

Change management

Impact analysis reads the CMDB to show which services depend on the CI being changed. Without relationships, approvals are made blind.

Problem management

Recurring incidents logged against the same CI reveal an underlying fault, provided each incident is recorded against the right CI.

Vulnerability management

A scanner finding must match a CI before it can be assigned and patched. Findings that match nothing drop out of compliance reports.

Service mapping

Service Mapping draws how an application service runs across your infrastructure. The map is only as accurate as the CI data behind it.

Cost control

IT and cloud spend both hide in infrastructure nobody can account for. You can't retire what you can't see is still running.

Why many CMDBs fail

Many CMDBs exist but aren’t trusted. The cause is usually one of these four.

Inaccurate or incomplete data

Duplicate CIs usually start with identification rules that can’t tell two records apart. Overwritten values usually start with several sources writing to the same attribute and no agreed order of precedence.

We explain both in how CMDB duplicate prevention really works and ServiceNow reconciliation rules. To measure where your data stands, start with the 3 Cs of a CMDB. For the wider practices that keep configuration data reliable, see CMDB best practice.

Lack of governance

A CI with no owner is never certified, so it drifts out of date. Stale records then cost money through licences and support contracts nobody needs. Read unknown CI owners are driving up IT spend.

Ownership also breaks when people move on. If nobody inherits their CIs, the records go stale without anyone noticing. See what happens when CI owners leave.

Poor discovery coverage

Discovery only finds what it can reach. Missing credentials and unscanned network ranges leave parts of the estate invisible, and invisible CIs don’t get patched. See how we approach ServiceNow Discovery.

Even full coverage isn’t enough on its own, because someone still has to decide what the scan results mean and when it’s safe to scan. We explain that in why ServiceNow Discovery isn’t a CMDB.

Complex environments

Most enterprises feed the CMDB from Discovery and several third-party tools at once. Each integration adds another source that can create duplicates or overwrite good data. Read why ServiceNow integrations fail without accurate data.

Automating those feeds is only safe once every source’s precedence is agreed. See CMDB automation and optimisation.

Apex consultant giving advice to two members of a customer's staff

When CMDB works properly

You can tell a CMDB is working when people use it without double-checking it. Incident teams trust the relationships, change boards rely on impact analysis, and patch reports match what the security team finds.

Measuring is where that starts. A CMDB health dashboard shows how complete, correct and compliant the data is, and the CMDB Workspace is where the gaps get worked. The benefits of a CMDB follow once that data is trusted, and a CMDB health check is a sensible first step if you don’t know where yours stands.

Here’s what a CMDB health assessment involves. If specific data is already in doubt, start with what to check in a ServiceNow CMDB audit. For the wider case, see the primary purpose of a CMDB.

The signs of a healthy CMDB: