A CMDB is a configuration management database: a record of the assets and software in an IT estate and, crucially, of how they depend on each other. The inventory half is the easy half.
The half that makes it a CMDB rather than a list is the relationships, and it exists to answer one question nothing else can: if this thing fails, what stops working.
- It records configuration items, called CIs, and the relationships between them
- The relationships are what separate a CMDB from an asset list
- It answers what breaks if this fails, and what changed before this broke
- Accuracy decays constantly, and an inaccurate CMDB is worse than none
- Discovery finds the CIs; the business context is manual and is what rots
On this page
CIsConfiguration items, and the part that matters
A configuration item, universally shortened to CI, is anything the CMDB tracks: a hardware asset, a virtual machine, a database instance, a network switch, a piece of software, a service, a contract, sometimes a person in a role. The definition is deliberately broad, which is both the strength and the first trap.
Recording CIs is inventory. Almost every organization has some data about its assets already, in an RMM tool, in a spreadsheet, in the virtualization platform, in the accounting system. Four partial inventories that disagree, usually, because none of them was built as a single source of configuration data.
What makes a CMDB different is that it records CI relationships, meaning how the items relate. This server runs that virtual machine. That virtual machine hosts this database. That database is used by the order application. The order application is what the warehouse uses at six in the morning.
Each of those is a relationship, and the chain is what turns an alert about a host into a sentence a manager understands.
That is why the asset inventory half is not the point. A perfect list of eight hundred machines with no relationships tells you that a machine is down. The relationships tell you that the warehouse cannot ship, and that is the information somebody actually needs.
What a CI record holds
A configuration management database stores each CI as a record with attributes, and most CMDB tools let an organization define its own CI types. The information kept on a typical record falls into six groups.
- Identity. A name, a unique ID and the CI type: server, application, network device, cloud service.
- Technical attributes. Model, serial number, operating system, software version, IP address, location.
- Ownership. The owner, the support team, and the business service the CI belongs to.
- Status. Where the CI is in its lifecycle: planned, in service, retired.
- Relationships. Runs on, hosted on, depends on, connected to.
- History. The changes and incidents that have touched the CI over time.
The first four groups are what IT asset management tools also keep. The last two are what make CMDBs worth the extra management effort.
The questionThe one question that justifies the project
Before buying or building anything, it is worth being able to state what the CMDB is for in a sentence, because the answer determines the scope and most projects skip it.
There are really two questions, and they are the same question at different times.
What breaks if this fails? Asked before a change and during an incident, and usually called impact analysis. A CMDB earns its cost the first time somebody proposes rebooting a hypervisor and the tool says which twelve services live on it, including the one nobody remembered.
What changed before this broke? Asked after an incident. This is the CMDB working with change records, and it is the reason the two disciplines are usually bought together.
If a proposed CMDB cannot answer either question better than an experienced engineer with an hour, it is an inventory project wearing a heavier name. That is not an argument against inventory, which is genuinely useful, only against paying CMDB prices for it.
Inside ITSMHow a CMDB works inside IT service management
Organizations rarely buy a CMDB by itself. It normally ships as part of an IT service management (ITSM) platform, and the other ITSM processes are its main users.
What it gives them is visibility into how assets and services connect. IT teams query it while they work tickets and plan changes, and other tools and systems read it through an API.
- Incident management. When a system fails, the service desk opens the CI, sees the services and users that depend on it, and knows the impact and the priority in minutes instead of asking around.
- Change management. Before approving changes, teams run an impact analysis: which CIs the change touches, what sits downstream, and who owns it. Closed changes update the CI records, which keeps the configuration data current.
- Problem management. Recurring incidents get linked to the same CI, and the history of changes to that CI is where root cause analysis usually starts.
- Audits and security. A current record of systems, software versions and owners is the evidence auditors ask for. It also tells security teams which assets a new vulnerability affects.
This is what vendors mean when they call the CMDB a single source of truth. The organization keeps one set of information about its IT infrastructure, and the service desk, operations and security teams all read the same data instead of each keeping a list.
The ITIL CMDB is the same thing seen from the process side. ITIL calls the practice service configuration management, and its purpose is to make accurate information about services and the CIs that support them available wherever it is needed. The CMDB is the tool that holds that information.
The dataWhere the data comes from, and which half rots
Configuration data has two sources, and they behave completely differently.
| Automated discovery | Entered by people | |
|---|---|---|
| Finds | Hardware, software, virtual machines, network CIs | Business services, owners, criticality |
| Sees relationships | The ones visible in traffic and platforms | The ones that live only in somebody memory |
| Stays current | Yes, it reruns | No, it decays from day one |
| Effort to maintain | Almost none | Continuous, and always deprioritized |
| Where the value is | The inventory | The answer to what breaks |
Read the last two rows together and the whole management problem is visible: the half that stays current is the half that was never the point.
Automated discovery scans the network and the platforms and finds what exists. CMDB discovery is good at this, and it is what all CMDB tools lead with.
Modern discovery reads virtualization platforms, cloud provider APIs, directory services, network devices and running processes, and it can find dependencies by watching which machines talk to which. It runs on a schedule and it corrects itself.
Service mapping is discovery pointed at one business service: it starts from the application entry point and traces the connections down to the systems and infrastructure underneath.
Most CMDBs also import data from other management tools, such as asset management, the RMM, cloud platforms and monitoring. Reconciliation rules decide which source wins when two disagree, and that data management work needs an owner too.
Human input supplies the information discovery cannot see: which business service a piece of software belongs to, who owns it, what the recovery objective is, which contract covers the asset, whether that virtual machine is production or a copy somebody made in March.
None of this is on the network. All of it is what makes the answer to "what breaks" a business sentence rather than a hostname.
The asymmetry is the whole operational problem. The discovered half stays current by itself. The human half is correct on the day it is entered and decays from then on, because the process that would update it is a process somebody has to remember during work that is already urgent.
That decay is why the honest first question is not which configuration management tool to buy but which relationships you will actually maintain, and by what mechanism.
AccuracyWhy an inaccurate CMDB is worse than none
This is the part vendor material does not say, and it is the reason most CMDB projects are judged failures.
A CMDB is a trust instrument. People stop verifying once they believe it, which is the entire benefit. An engineer who checks the CMDB, sees three dependencies, and proceeds has saved an hour.
The same engineer, when the CMDB was missing the fourth dependency, has caused an outage that would not have happened if the tool had never existed, because without it they would have checked.
So accuracy is not a data management metric here, it is the product. CMDBs at 95 percent accuracy are useful. At 70 percent one is a trap, and the failure is silent: nothing announces that a CI record is stale, and the discovery job reports success while the relationships it cannot see quietly diverge from reality.
The practical consequence is that scope should be set by what you can keep accurate rather than by what you can populate. A small CMDB that is right beats a comprehensive one that is nearly right, every time and by a wide margin.
What it is notWhat it is not
Not an asset register. The CMDB vs asset management question has a short answer, which is audience. IT asset management exists for finance: what was bought, what it cost, when it depreciates, who signed for it. A CMDB exists for operations.
The two overlap on hardware and diverge everywhere else, because finance does not care that this virtual machine depends on that database and operations does not care what either cost.
Not an RMM inventory. A managed service provider monitoring tool knows every machine, its operating system, its patch level and its agent status. That is very good asset and software data and it is not a CMDB, because it has no concept of the order application or of what the warehouse needs at six in the morning.
Not a monitoring system. Monitoring knows what is up right now. A CMDB knows what depends on what, and so what the business impact of an alert is. They are complementary and they are bought separately, and a monitoring alert becomes useful the moment it is enriched with CMDB relationships.
Not documentation. A wiki page describing an architecture is written once and read rarely. A CMDB is queried by other tools, which is why the relationships have to be structured data rather than prose.
Making oneMaking one that survives
The pattern that works in organizations of any size is narrow and deep rather than broad and thin.
Start from an incident, not from an inventory. Take the last three significant outages and ask what the CMDB would have had to contain to shorten them. That list is the first scope, and it is always smaller than the one a vendor proposes.
Model business services first, working down. The valuable relationships run from the service the business names to the infrastructure underneath. Building from the infrastructure up produces a graph that is technically complete and answers nothing.
Let discovery own every CI it can see. Never maintain by hand what a scan can find. The temptation to correct discovered data manually is how a CMDB starts fighting its own discovery job.
Give every CI an owner, and make ownership a field with a person in it. Unowned CIs are the ones that rot first, because nobody is wrong when they are stale.
Attach the update to a process that already happens. A relationship that is updated when a change ticket closes stays current, and changes are where most configuration data goes stale. A relationship that requires a separate housekeeping task does not, because that task is always the one deferred.
Measure accuracy and publish it. Sample twenty CIs a month and check the data against reality. A number that everybody can see is what stops the slow decay, and it is also the only honest answer when somebody asks whether the CMDB can be trusted.
PitfallsWhere CMDB projects fail
Trying to model every asset. The single most common cause. Scope expands to all the assets and systems in the infrastructure, the management burden exceeds what any team will carry, and the whole database goes stale together.
Buying the tool before deciding the question. Every ITSM vendor sells a CMDB, and the tools are all capable. None of them decides what information your teams will keep accurate.
Treating the discovery job as the project. Discovery populating the database with asset and software data looks like success and is the easy half. The relationships and the business mapping are the project.
No owner for the CMDB itself. A shared responsibility for data quality is no responsibility. Somebody has to be accountable for the accuracy number.
Letting it drift after go-live. Most CMDBs are accurate on the day of launch and nobody measures them again. The decay is invisible until an incident, which is the worst possible time to discover it.
Confusing it with the lifecycle inventory. Knowing which servers exist and when their support ends is a different question from knowing what depends on them. Both matter; only one of them is a CMDB.
ComparisonFour systems that know what exists, and what each one is for
| Criterion | CMDB | Asset register | RMM inventory | Monitoring |
|---|---|---|---|---|
| Knows what exists | Yes | Yes, what was bought | Yes, what has an agent | Yes, what it watches |
| Knows the relationships | Yes | No | No | Only what it is told |
| Knows current state | Sometimes | No | Patch and agent state | Yes, right now |
| Knows the cost | No | Yes | No | No |
| Answers what breaks if this fails | Yes | No | No | No |
| Stays current by itself | Partly | No | Yes | Yes |
| Primary audience | Operations | Finance | The provider | Operations |
The fifth row is the reason to have one, and the sixth is why they fail. The parts that stay current on their own are the parts that were never the point, and the parts that answer the question are the parts somebody has to maintain.
FAQFrequently asked questions
What is a CMDB?
A configuration management database: a record of the configuration items in an IT estate and of the relationships between them. The relationships are what distinguish it from an inventory.
What is a configuration item?
A CI is anything the CMDB tracks: a hardware asset, a virtual machine, a database, a switch, a piece of software, a business service, sometimes a contract or a role. The scope is a decision rather than a definition.
What is the difference between a CMDB and IT asset management?
Purpose. Asset management serves finance and records what was bought, what it cost and when it depreciates. A CMDB serves operations and records what depends on what. They overlap on hardware and diverge everywhere else.
Is an RMM inventory a CMDB?
No. It is an excellent inventory with current state, and it has no concept of business services or dependencies, which is the half that answers the question a CMDB exists for.
What question should a CMDB answer?
What breaks if this fails, asked before a change and during an incident, and what changed before this broke, asked afterwards. If it cannot answer those better than an experienced engineer with an hour, it is an inventory project.
How accurate does a CMDB need to be?
Accurate enough to be trusted, because trust is the product. At 95 percent it saves time; at 70 percent it causes outages that would not have happened without it, since people stop verifying once they believe it.
Why do CMDB projects fail?
Scope, almost always. Modeling every item in the estate creates a maintenance burden nobody sustains, and the whole database goes stale together. Narrow and accurate beats comprehensive and approximate.
What is CMDB discovery?
Automated scanning that finds configuration items and some relationships by reading virtualization platforms, cloud APIs, directory services and network traffic. It handles the half that can be seen from the network.
What cannot discovery find?
Business information: which service a piece of software belongs to, who owns it, what the recovery objective is, whether a virtual machine is production or a forgotten copy. That half is entered by people and is the half that decays.
Do I need a CMDB for a small business?
Rarely as a product. The question it answers is worth answering at any size, and under a few dozen servers a maintained diagram and a good inventory usually answer it for a fraction of the effort.
How do I keep a CMDB current?
Attach updates to a process that already happens, usually change management, rather than to a separate housekeeping task. Let discovery own everything it can see, give every item a named owner, and sample records monthly to measure accuracy.
Is a CMDB required by ITIL?
Configuration management is an ITIL practice and a CMDB is the usual way to implement it. The practice is the requirement; the database is one implementation of it.
What should be in scope first?
Whatever the last three significant incidents would have needed. That list is concrete, defensible and always smaller than a vendor's default scope.
How is a CMDB different from monitoring?
Monitoring knows what is up right now. A CMDB knows what depends on what. An alert becomes useful the moment it is enriched with the relationships, which is why the two are usually integrated.
What are CI relationships?
CI relationships are the recorded links between configuration items: this application runs on that server, which sits on that host and uses that database. They are what separates a CMDB from an asset list, because they let you see what a planned change or a failure will affect.
What is service mapping?
Service mapping is the automated discovery of those relationships, starting from a business service and tracing the connections between its components. It keeps the map current as things change, which manual entry never does. Most service mapping tools use network traffic, credentials on the hosts, or cloud APIs.
Keep readingRelated concepts
Read next · Managed IT What Is an MSP, and What Are You Actually Buying Whose monitoring tool holds a very good inventory that is not a CMDB, because it has no concept of a business service. Open this next10 min- Directory and identity · 15 min Active Directory Explained One of the sources discovery reads, and where the machines nobody put on the asset register are usually found.
- Operations · 9 min Windows Server End of Life, Version by Version A different question about the same machines: knowing which exist and when support ends is not knowing what depends on them.
- Operations · 11 min Infrastructure as Code, and the File That Knows What Exists The manual answer to the same question.
- Managed IT · 9 min What RMM Is, and What the Agent Can Actually Do What the inventory cannot tell you.
- Operations · 9 min Configuration Management, and the Two Jobs That Share the Name The two disciplines that share the name, and which half a small company should build first.
- Protocols · 10 min What LLDP Is, and Why It Answers the Port Question The half a live map misses.