ServiceNow CMDB best practices

A configuration management database is a model of the things you run and how they depend on each other. The reason it exists is not inventory. Inventory is a by product. The reason is impact: when this server is taken down for patching, which services stop, and who should be told.

That is the test to apply to every decision about it. A CMDB that can answer the impact question for the services people care about is doing its job, even if it models very little. A CMDB with two hundred thousand configuration items and no relationships cannot answer it at all, and it is the more common of the two.

Where it lives: configuration items are records in tables descending from cmdb_ci, one table per class, with the class hierarchy deciding which fields exist. Relationships are separate records in cmdb_rel_ci, each with a parent, a child and a relationship type. Two tables, and almost everything else is machinery around them.

Two layers are worth separating in your head from the start, because most confusion about the CMDB comes from mixing them. The infrastructure layer is servers, databases, network devices and software: things discovery can find on its own. The service layer is applications and business services: things that exist because a human said so. Discovery populates the first layer well and cannot invent the second, which is why a CMDB filled entirely by discovery still cannot tell you what stops when a server goes down.

The single most important mechanism, and the one most often bypassed, is the identification and reconciliation engine. It does two jobs and they are different.

Identification answers whether an incoming record is something you already have. It uses identification rules per class: a set of attributes that, taken together, uniquely name a configuration item. Get those wrong and you create duplicates every time a source runs, which is how a CMDB reaches two hundred thousand items without describing anything new.

Reconciliation answers who wins when two sources disagree about an attribute. Rules are set per attribute and per source, so discovery can own the operating system version while an asset system owns the cost centre. Without them, the last source to run overwrites everything, and the data flips back and forth on a schedule.

Loading straight into the CI tables, with an import set or a script, skips both. It works, it is fast, and it is the cause of most unusable CMDBs. Every inbound source goes through the identification engine, without exception.

One symptom is worth learning to recognise, because it points straight at these rules. If a CI's attributes change on a regular cycle, reverting and then changing back again, two sources are both writing that attribute and no reconciliation rule says which wins. It looks like flaky discovery and it is a missing rule. The fix is a precedence decision, not a discovery investigation.

An hour, and it tells you more than any health dashboard.

1. Pick one business service that people would notice if it stopped.
2. Open its record and look at the dependency map. If it is empty, stop: the CMDB cannot answer the question for this service, and that is the finding.
3. Walk down one branch to a server. Check whether the relationship types are meaningful or whether everything is related to everything.
4. Take that server and look at what claims to own each of its key attributes. Compare against what the reconciliation rules say should own them.
5. Now search the CI tables for that server by name and by serial number. If more than one record comes back, you have a duplicate, which means an identification rule is wrong.
6. Repeat for two more services.

Three services is enough to know whether you have a CMDB or a list. See integration practices.

Over modelling is the failure that looks like diligence. Every class you populate is data somebody has to keep correct, and data nobody keeps correct is worse than absent because people trust it once.

The decision rule that holds up: model something if a process consumes it. Change management needs services and their dependencies. Incident needs enough to route and to see impact. Asset needs ownership and lifecycle. Security needs software and versions. If no process reads a class, populating it is cost without benefit.

The corollary is that a CMDB grows with the processes that use it, rather than being built completely and then adopted. Programmes that try to model everything first usually deliver nothing anybody uses.

The related decision is depth. A service mapped down to individual processes on individual hosts is accurate on the day it is built and needs constant maintenance. A service mapped to the application and the handful of hosts it runs on is less precise and stays true for much longer. For change impact, which is what most of this is for, the second is usually the better trade, and teams that chose the first often quietly stop maintaining it within a year.

Data without an owner degrades, and a CMDB degrades faster than most because so many sources write to it. Assign ownership per class rather than for the CMDB as a whole, because the person who can say what a correct database record looks like is not the person who can say that about a network device.

The health dashboards measure three things and they mean different things. Completeness asks whether required attributes are filled. Correctness asks whether values match the authoritative source. Compliance asks whether items follow the rules you set, including having relationships at all. Completeness is the easy one to score well on and the least useful, so a dashboard that is green on completeness and silent on relationships is not telling you what you need.

Version note: the identification engine, the health metrics and the service mapping tooling have all been extended repeatedly across releases, and the class model itself changes with the common service data model. Check which version your instance runs before following any specific guidance, because the recommended class for a given thing has moved more than once. See update sets and scripting practices for how changes to all this should travel.

One practice is worth adopting whatever else you do: publish the health figures to the people who own the data, not to a governance forum. A class owner who sees their own duplicates and missing attributes every week fixes them. A quarterly slide showing an overall score changes nothing, because nobody in the room owns any particular record.

• Loading CIs directly. It bypasses identification, and duplicates arrive quietly.
• Items without relationships. An inventory, not a CMDB.
• No reconciliation rules. Sources overwrite each other on a schedule and nobody trusts the data.
• Modelling classes no process reads. Cost with no benefit.
• One owner for everything. Which means no owner. See catalog practices for the same principle applied elsewhere.

The rules above take an afternoon to read, and building a CMDB that people actually trust for change impact is the work the course covers.