CMDB Health: Because Having 100,000 CIs Doesn't Mean You Have a Good CMDB

There's a very impressive number you can put on a PowerPoint slide:

"Our CMDB contains 100,000 configuration items."

Sounds great.

Until someone asks:

"How many of those are accurate?"

"How many are duplicates?"

"How many haven't been updated in three years?"

"How many are missing important information?"

"How many have broken relationships?"

And suddenly that impressive number isn't quite as impressive.

This is one of the fundamental ideas behind CMDB Health.

A healthy CMDB isn't one that contains the most records.

It's one where the information is complete, correct, current, and useful enough to support the processes that depend on it.

That's a much harder thing to achieve.

What Makes CMDB Data "Healthy"?

There are several dimensions of CMDB data quality that are particularly important.

The big ones to understand are:

• Completeness

• Correctness

• Compliance

• Relationships

• Duplicate or stale data

• Overall data quality

These aren't simply different ways of saying "good data."

They help identify different types of problems.

A CI can be complete but incorrect.

A CI can be correct but missing important information.

A CI can have plenty of attributes but be missing relationships.

And a CI can look perfectly fine today while becoming stale over time.

That's why CMDB health requires looking at more than one measurement.

Completeness: Did We Fill In the Important Stuff?

Let's say your organization has a server CI.

It contains:

• Hostname

• IP address

• Operating system

• Manufacturer

• Serial number

But several fields that the organization considers important are empty.

Maybe the environment expects ownership information.

Maybe a support group is required.

Maybe the CI should be associated with an application.

The record exists.

It may even be technically accurate.

But information is missing.

That's a completeness problem.

Completeness asks whether the required or expected information has actually been populated.

The key word is missing.

If important information isn't there, you're dealing with a completeness issue.

Correctness: Is the Information Actually Right?

Now imagine the server has an operating system value.

It says:

Windows Server 2019

But the server is actually running:

Windows Server 2022

All the fields are populated.

Nothing is technically "missing."

But the data is wrong.

That's a correctness problem.

Correctness asks whether the information stored in the CMDB accurately represents reality.

This is an important distinction from completeness.

A record can be 100 percent populated and still be completely wrong.

And unfortunately, adding more fields to a CI doesn't magically make incorrect information correct.

Completeness vs. Correctness

This distinction is worth memorizing because exam questions can make the two sound very similar.

Imagine a CI has an empty Owner field.

That's:

Completeness

The information isn't there.

Now imagine the Owner field says:

John Smith

but John left the company two years ago and no longer owns the application.

That's:

Correctness

The information exists, but it isn't accurate.

So when you're reading a scenario, ask:

Is something missing?

Think completeness.

Is something present but wrong?

Think correctness.

That simple distinction is surprisingly useful.

Compliance: Does the Data Follow the Rules?

Now imagine the organization has established standards for how CIs should be represented.

Perhaps every production server must have:

• An owner

• A support group

• An environment classification

• A business application

• A required set of attributes

A CI might contain plenty of information but still fail to meet the organization's defined standards.

That's where compliance becomes relevant.

Compliance is concerned with whether the data conforms to established rules, policies, or requirements.

This is slightly different from simply asking whether the information is accurate.

Something can be technically correct while still failing an organizational standard.

For example, perhaps a server really does belong to the Infrastructure team.

But the organization's rules require a specific support group to be populated, and that field is empty.

The data may be factually accurate while still failing the required standard.

A CI Can Have More Than One Problem

This is important.

Don't assume that every CI has exactly one data quality issue.

Imagine a server record where:

• The owner is missing.

• The operating system is incorrect.

• The required support group isn't populated.

• There are no relationships to the application it supports.

That's not one problem.

That's several.

The CMDB can have completeness problems, correctness problems, compliance problems, and relationship problems at the same time.

Real CMDB health work is often about finding these different categories of issues and addressing their causes.

Relationships Are Part of CMDB Health

This is easy to overlook.

People tend to look at a CI and think:

"Does the hostname look right?"

But a CMDB isn't just a collection of individual records.

The relationships between CIs are extremely important.

Suppose ServiceNow knows about:

APP01

DB01

WEB01

All three records look perfectly accurate.

But the CMDB doesn't know that:

APP01 depends on DB01.

Or that WEB01 supports APP01.

The individual records may be correct.

The overall picture is still incomplete.

This is why relationship quality matters.

A CMDB becomes much more useful when it can show how the pieces of an environment fit together.

Why Relationships Matter During an Outage

Imagine a database server goes offline.

The CMDB knows about the database server.

Great.

But management's next question is probably not:

"Do we have a CI for the database?"

It's:

"What does this affect?"

If the relationships are accurate, ServiceNow may be able to help identify applications and services that depend on that database.

Without those relationships, the CMDB may know that the database exists but have very little idea what it supports.

That's a huge difference.

The value of configuration data isn't simply knowing that things exist.

It's understanding how they are connected.

Stale Data: The CI That Time Forgot

Here's another classic CMDB problem.

A CI was accurate when it was created.

Then nobody updated it.

Six months pass.

A year passes.

The server is upgraded.

The application moves.

The owner changes.

The server gets retired.

But the CI remains in the CMDB.

Now the record may still look perfectly legitimate.

It has a name.

It has an IP address.

It has attributes.

It has a creation date.

But it no longer reflects reality.

That's stale data.

Stale data is dangerous because it can look trustworthy at a glance.

The record exists, so people assume it must still represent something that exists.

That assumption can be wrong.

Orphaned CIs

A related problem occurs when a CI no longer has the relationships or supporting information expected for it.

For example, perhaps an application service is still in the CMDB, but the infrastructure that supported it has been removed.

Or perhaps a CI exists without the relationships necessary to understand where it fits.

These situations can contribute to poor CMDB quality.

The exact problem depends on the scenario, but the general lesson is:

A CI shouldn't be evaluated only in isolation.

Its relationships and context matter too.

Duplicate CIs

Remember our previous breakdown?

Two different sources discover the same server.

If identification isn't working correctly, ServiceNow may end up with two records representing the same thing.

That's a duplicate CI problem.

Duplicates are particularly nasty because each record may look perfectly legitimate on its own.

You might have:

WEB01

and

WEB01-PRD

Both have realistic values.

Both have relationships.

Both have recent updates.

But if they actually represent the same physical or logical item, you've now divided your data across two records.

That can create problems throughout the platform.

Why Duplicates Are So Bad

Imagine an application depends on WEB01.

But somebody associated the application with the duplicate record instead.

Now Discovery updates the original CI.

The application relationship is attached to the duplicate.

Your incident points to one.

Your asset record points to another.

You haven't merely created an extra row in a database.

You've created multiple versions of the same reality.

That makes impact analysis, reporting, and operational decisions much more difficult.

This is why good identification and reconciliation practices are so important to CMDB health.

CMDB Health Is a Measurement Problem Too

You can't improve what you don't measure.

Organizations need ways to determine where CMDB quality is strong and where it needs work.

ServiceNow provides CMDB Health capabilities to help organizations assess data quality.

The goal isn't to stare at a giant dashboard and admire the numbers.

The useful part is identifying where the problems are.

For example:

"Production server completeness is poor."

"Application relationships are missing."

"Duplicate CIs are increasing."

"Certain classes have large amounts of stale data."

Those findings can lead to targeted improvement efforts.

Health Indicators

CMDB Health includes measures that help evaluate different aspects of the CMDB.

Depending on the area being assessed, these can help identify problems such as:

• Missing required information

• Duplicate CIs

• Orphaned relationships or CIs

• Stale information

• Other data quality issues

The important exam-level concept is that CMDB Health provides visibility into the quality of CMDB data, rather than simply telling you how many records exist.

That's a major difference.

The Numbers Can Tell You Something Important

Imagine two CMDBs.

CMDB A

200,000 CIs

CMDB B

80,000 CIs

At first glance, CMDB A looks better.

But suppose:

CMDB A has a huge number of duplicates and stale records.

CMDB B has fewer records but much higher accuracy and better relationships.

Which CMDB is more useful?

Probably CMDB B.

This is why CMDB maturity isn't a contest to see who can create the most records.

More data isn't automatically better data.

Useful data is better than lots of data.

Data Quality Starts With the Source

Here's the slightly annoying part.

CMDB Health can tell you that something is wrong.

It doesn't necessarily fix the underlying problem.

Suppose 40 percent of your application CIs are missing ownership information.

You can identify the problem.

But then you have to ask:

Why is ownership missing?

Maybe the source system doesn't provide it.

Maybe the integration isn't mapping it.

Maybe the field isn't required.

Maybe nobody knows who owns the applications.

Maybe the data exists somewhere else but isn't being integrated.

Maybe people are manually entering it and simply aren't doing so.

The health measurement tells you where the pain is.

The organization still has to figure out why it exists.

Fixing Symptoms vs. Fixing Causes

This is one of the most important ideas in data quality.

Suppose a CI is missing an owner.

You could manually open the record and enter an owner.

Problem solved?

Maybe.

Until the next 4,000 CIs show up without owners.

Now you're playing whack-a-mole.

A better approach might be to determine where ownership information should come from and establish a reliable process for maintaining it.

That's the difference between fixing an individual record and fixing the data quality process.

Good CMDB management focuses heavily on the latter.

Data Quality Is a Lifecycle Problem

CMDB health isn't something you check once a year.

The environment changes constantly.

New servers appear.

Applications are upgraded.

Systems are retired.

Cloud resources are created and destroyed.

Employees change roles.

Ownership changes.

Relationships change.

If your data management processes don't keep up, the CMDB gradually becomes less accurate.

That's why ongoing monitoring and maintenance matter.

The goal isn't to make the CMDB perfect once.

The goal is to keep it useful as the environment changes.

A CMDB Can Be Technically Full but Operationally Empty

Here's a fun thought.

Suppose your CMDB contains 500,000 records.

But nobody trusts the data.

People don't know which records are current.

They don't know which source is authoritative.

Relationships are missing.

Duplicate CIs are everywhere.

Teams maintain their own spreadsheets because they don't believe the CMDB.

Technically, you have a massive CMDB.

Operationally, you don't have much of a CMDB at all.

The real measure of success is whether people can rely on the information when they need it.

The Connection to Everything We've Covered

This is where the earlier breakdowns start coming together.

CSDM gives the organization a common model for organizing service-related information.

Integrations, imports, connectors, and Discovery bring data into ServiceNow.

Identification helps determine which CI incoming information belongs to.

Reconciliation helps determine which sources should be allowed to update that information.

And CMDB Health helps determine whether the resulting data is actually meeting the organization's quality expectations.

Each piece supports the next.

If the data comes in badly, health suffers.

If identification creates duplicates, health suffers.

If reconciliation allows conflicting values, health suffers.

If relationships aren't maintained, health suffers.

CMDB Health is therefore not some isolated reporting feature.

It's a way of looking at the results of the entire data management process.

An Example

Let's say the CMDB contains 10,000 server CIs.

He celebrates briefly.

Then he runs a health check.

He discovers:

1,200 are missing required ownership information.

800 haven't been updated in more than a year.

400 appear to be duplicates.

Thousands have incomplete relationships.

And several important fields contain values that don't match the organization's authoritative sources.

The organization has not discovered that the CMDB contains 10,000 CIs.

He has discovered that the organization has a data quality project.

That's the mindset you want to develop.

The number of records is only the beginning of the conversation.

What the Exam May Actually Ask

Don't expect every question to say:

"Which CMDB Health metric is being described?"

The scenario may instead say:

"An organization wants to determine whether required CI attributes are populated."

That's pointing toward completeness.

Or:

"An organization wants to determine whether CI information accurately reflects the current environment."

Think correctness.

Or:

"The organization wants to ensure CIs meet established data standards."

Think compliance.

Or:

"The organization wants to identify duplicate configuration items."

Think duplicate detection / CMDB data quality.

Or:

"The organization wants to understand whether configuration items are properly connected to the services or components they support."

Think relationship quality.

The trick is to recognize the underlying problem rather than waiting for the question to hand you the vocabulary.

Don't Assume "Missing" Always Means the Same Thing

Here's a subtle distinction worth watching.

Suppose a CI doesn't have a business owner.

That could be a completeness issue because the information is missing.

But suppose the organization's CSDM or governance standards specifically require every CI of that class to have an owner.

Now you're also dealing with compliance with the organization's data requirements.

One scenario can legitimately touch multiple data quality concepts.

The exam question will usually give you enough context to determine which aspect it wants you to focus on.

The Goal Isn't Perfect Data

This deserves to be said clearly.

No large enterprise environment is going to have a magical CMDB where every record is always perfect.

The goal is fit-for-purpose data.

If a particular process depends on accurate ownership information, that information needs to be reliable.

If impact analysis depends on application-to-infrastructure relationships, those relationships need to be trustworthy.

If a report depends on current CI status, stale data becomes a serious problem.

The appropriate level of data quality depends partly on how the data is being used.

The question isn't:

"Is every field on every CI perfect?"

It's:

"Is the data reliable enough to support the decisions and processes that depend on it?"

The Mental Model to Keep

When you think about CMDB Health, don't picture a giant green dashboard.

Picture someone asking:

Can I trust this information?

If important information is missing, that's a completeness concern.

If the information is wrong, that's a correctness concern.

If the information doesn't follow established requirements, that's a compliance concern.

If the relationships don't accurately represent dependencies, that's a relationship quality concern.

If the same thing appears multiple times, that's a duplicate problem.

If information no longer reflects the current environment, that's a stale data problem.

And if you want to know whether the CMDB is suffering from these kinds of issues, CMDB Health provides tools for measuring and monitoring data quality.

That's the real point.

A CMDB isn't valuable because it contains a lot of information.

It's valuable because people can trust the information that's in it.

And if there's one lesson from this entire topic, it should probably be that a 100,000-CI CMDB nobody trusts is a lot less impressive than a 50,000-CI CMDB people actually use.