CMDB and ITAM data quality: the precondition for Resource Tower integrity

Executive summary

The TBM model is an allocation engine. It takes counts and attributes from the configuration management database (CMDB) and the IT asset management (ITAM) repository as given, and it distributes Cost Pool dollars across Resource Towers on top of them. It has no native step that asks whether a server count is right, whether a storage volume still exists, or whether an application-to-server relationship was ever true. That is the design, and it is the right design. Allocation and validation are different jobs.

The consequence is that CMDB data quality is not an ITSM concern the TBM office can wait out. Every defect in the CMDB or the ITAM record is already a Tower defect the moment the model runs. A retired server still in the CMDB inflates the Servers Sub-Tower and depresses unit cost. A discovered host with no record leaves cost unallocated or dumped into a default bucket. Two records for one asset double-count the Tower. The defects arrive with signatures, and a practitioner who knows the signatures can read the state of the CMDB from the Tower report without opening the CMDB.

This paper sets out that inheritance model: five defect classes, the Tower-level effect of each, and the reason cleanup projects do not hold. It distinguishes what ITAM and the CMDB each contribute to the Taxonomy, shows why their disagreement is information rather than noise, and closes with a ten-question Tower integrity diagnostic a program can score this week. The thesis is plain: validate upstream of the model or the model will render your defects with excellent formatting.

The Cost Pool to Tower allocation inherits the count

The Technology Resource Towers layer sits between Cost Pools, which classify spend by type, and Solutions, which describe what the technology organization delivers. Towers classify spend by function: Compute, Storage, Network, Data Center in the Infrastructure domain; Application, Middleware, Database, Data in the Application domain; and so on through Field and Office and Operations.

Costs do not flow from Cost Pools into Towers on their own. Assigning cost to Towers is a separate mapping exercise, executed primarily through cost centers, contracts, and vendor data, with fixed asset, project, and cloud invoice passes filling gaps. Each of those passes ends in a driver. A vendor's hardware maintenance contract lands in the Compute Tower and then splits across Sub-Towers by server count. A storage lease splits by provisioned capacity. A hypervisor license splits by host count. The driver is the number that turns a Cost Pool dollar into a Tower dollar, and the driver comes from the CMDB, the ITAM repository, the array management console, or a discovery scan.

Here is the operational reality behind that sentence. The TBM analyst building the Compute allocation pulls a server export from the CMDB on the fifth business day after close. Say the export shows 4,212 physical and virtual servers in production. The allocation runs. Nobody in that workflow checks that 4,212 against the endpoint agent's device count, the hypervisor inventory, or the hardware maintenance vendor's covered-asset list, because that check is not part of the allocation job. It is a reconciliation job, and in most programs it belongs to nobody.

The TBM Council's 2025 State of TBM found that Cost Pools and Resource Towers are the layers most organizations have adopted, at 83 percent and 78 percent respectively, while Solutions and Consumers sit at 53 and 55 percent, and that nearly half of organizations stop at the Tower layer. Read that as a statement about credibility. For roughly half of TBM programs, the Tower report is the highest-value artifact the program produces. If the counts beneath it are wrong, there is no higher layer to blame and no lower layer to hide behind.

The Tower inheritance model: five defect classes and their signatures

A CMDB does not fail in one way. It fails in five, and each failure produces a distinct distortion in the Tower report. The table below is the working model. The sections that follow describe how each class arises, where it shows up, and how to confirm it.

Ghosts

Ghosts are the most common class in an estate that has been through a data center consolidation or a lease refresh. The decommission ticket closes, the rack is emptied, and the CI stays because nobody's runbook includes the CMDB step. The Servers Sub-Tower count carries the ghost forward. Because the hardware maintenance contract is often allocated by covered-asset count, the ghost also absorbs a share of real dollars, which depresses the unit cost of every live server. The signature is a Compute Tower whose unit cost is falling while the infrastructure team insists nothing has been retired. Confirm it by pulling the same server population from the endpoint management agent and the hypervisor. A CI that appears only in the CMDB, and has not reported to anything else in 60 days, is a ghost until someone proves otherwise.

Orphans

Orphans are the mirror image, and they are more expensive because they hide cost rather than diluting it. A host provisioned during a migration, a cloud instance spun up under a project account, or a storage volume created from the array console without a change record all exist and all consume. The invoice arrives. The allocation engine looks for a CI to attach the cost to and finds none. Depending on the model configuration, the cost lands in a default Sub-Tower, is spread across the Tower pro rata, or sits in an unallocated bucket the TBM office reports as a rounding item. The signature is a growing "Other" or "Unallocated" line, or an allocation that moves when the CI count moves even though consumption has not changed.

Duplicates

Duplicates arise wherever two systems describe the same asset under different keys. The hypervisor reports a virtual machine by its inventory name; the endpoint agent reports it by fully qualified hostname; the ITAM repository reports it by serial number and purchase order. If identification rules do not resolve those to one entity, the CMDB carries two or three CIs for one machine. Every one of them draws allocation. The signature is a Sub-Tower count that exceeds what any single source reports, and a showback statement in which a business unit sees the same server billed twice under two names.

Stale attributes

A stale attribute is a correct CI carrying an incorrect fact. The most damaging ones are environment (production versus non-production), owner, and lifecycle state, because Tower-to-Solutions mapping depends on them. A production database server tagged as development routes its cost to the wrong Solution and understates that Solution's total cost of ownership. An owner field pointing at someone who left two years ago means no one receives the variance query, and the discrepancy lives on. The signature is a Solution cost that jumps when someone finally corrects a tag, with no operational change to explain it.

Unclassified assets

The unclassified class is the quiet one. A CI class added for a new platform, a Sub-Tower Element nobody mapped, a cloud service type introduced after the last Taxonomy migration: each one lands in a catch-all. The Tower report totals correctly, so the drift is invisible at the top line. The signature is any Sub-Tower carrying more than a few percent of its Tower's cost under a generic label. If "Other Compute" is 9 percent of Compute, that is not a rounding item. It is where the unclassified assets live.

ITAM and the CMDB feed different Taxonomy steps

A recurring governance fight in TBM programs is which system is the authoritative inventory, ITAM or the CMDB. The question is malformed. They record different facts and they feed different steps of the model.

ITAM records what was acquired and under what terms: purchase, lease, license entitlement, support contract, refresh date, disposal. In Taxonomy terms, ITAM is evidence for the Hardware and Software Cost Pools and for the fixed-asset and contract-based passes of Tower mapping. It tells the model what the organization is paying for.

The CMDB records what is running and what it serves: the CI, its attributes, and its relationships to other CIs, applications, and services. In Taxonomy terms, the CMDB supplies the Sub-Tower counts and the relationship graph that Tower-to-Solutions mapping depends on. It tells the model what the organization is operating and for whom.

When the two disagree, the disagreement is information. An asset in ITAM but not in the CMDB was bought and never deployed, or deployed and never registered. An asset in the CMDB but not in ITAM was deployed without a procurement record, which is either a process gap or a ghost. An asset in both with different attributes tells you which system was updated last. A program that treats the delta as noise to be overridden by whichever analyst is loudest loses that information every month. A program that treats the delta as a work queue with named owners keeps it.

Here is what that queue looks like when it is handled by hand. An analyst exports the CMDB server list and the ITAM hardware list into a spreadsheet, builds a lookup on serial number, finds that a share of the rows fail to match because the serial formats differ, cleans the formats manually, matches again, and produces three tabs: in both, CMDB only, ITAM only. The three tabs go to the infrastructure lead by email. The infrastructure lead resolves the ones she recognizes and leaves the rest. The analyst adjusts the driver in the model to the number the infrastructure lead approved, notes it in a cell comment, and closes the period. Next month the export is different, the spreadsheet is rebuilt, and the cell comment is gone.

The cost of that workflow is not only the hours. It is that the resolution lives in one person's judgment and one spreadsheet, so the same defect is rediscovered every cycle and the Tower report's credibility rests on who happened to approve the number.

Why CMDB cleanup projects do not hold

Most organizations have run a CMDB cleanup. Most have run more than one. The pattern is consistent: a quarter of focused effort, a health score that improves, and a slide that returns to its prior state within two or three more quarters. Understanding why is the difference between repeating the cycle and ending it.

CMDB health tooling measures the CMDB against its own rules. ServiceNow's CMDB Health, to take the most widely deployed example, scores three KPIs: correctness, which aggregates orphan, staleness, and duplicate metrics; completeness, which measures required and recommended fields; and compliance, which audits CI values against expected templates. Staleness defaults to 60 days without an update. Duplicates are evaluated using identification rules. Those are useful tests, and a program that has not turned them on should. But every one of them is an internal test. A CI can pass completeness, correctness, and compliance while describing a server that was physically removed 14 months ago, because none of the three KPIs asks the endpoint agent or the hypervisor whether the machine still answers.

ServiceNow's Identification and Reconciliation Engine addresses the ingestion side, using identification rules to prevent duplicate CIs and reconciliation rules to allow only authoritative data sources to write specific attributes. That is the right control for data entering the CMDB. It does not, by itself, tell the TBM office whether the CMDB's population agrees with the estate's other systems of record on the day the allocation runs.

The gap between an internally healthy CMDB and an externally validated one is where the five defect classes live. Closing it requires a test the CMDB cannot run on itself: a recurring, cross-source comparison of the CMDB and ITAM populations against discovery, hypervisor, endpoint, cloud, and billing data, with each variance classified, assigned to an owner, resolved on the record, and the resolution carried forward to the next run.

This is the design premise of FogLifter®. FogLifter is built as the validation layer beneath TBM, ITFM, and FinOps practice, rather than another reporting surface on top of unvalidated data. It ingests the CMDB, the ITAM repository, discovery and endpoint data, hypervisor inventory, cloud APIs, and vendor invoices; normalizes naming and keys through its ontology so that one machine described three ways resolves to one entity; and continuously compares the populations. Discrepancies surface in the Validation View, where the data owners on each side of a variance, a CMDB steward and a storage administrator, a provider and a customer, IT and a business unit, see the same evidence and record the disposition. Where authorized, corrected records are written back to the ServiceNow CMDB programmatically. Validated counts then flow into the Tower model as drivers, with lineage attached: which source was deemed authoritative for each field, and why.

One FogLifter deployment runs that discipline across 70,000+ servers under management. That is a single deployment figure, not a benchmark, and validation tooling was one component of a broader program that also involved process change and data remediation at that organization. The point it establishes is narrower and sufficient: cross-source validation is achievable at full enterprise scale, which removes the most common reason for skipping it.

The TBM Council's 2024 State of TBM report puts the stakes in the practitioner's own terms. Only 10 percent of respondents strongly agreed their organization had high data trust before TBM practices were in place; 48 percent reported high data trust once they were. The same report found 76 percent of organizations planning to invest more in data quality management over the following one to three years. Trust is buildable. It is built at the count, not at the dashboard.

The Tower integrity diagnostic

Score each question one point for yes, zero for no. The mapping beneath the table tells you which defect class to chase first.

Nine or ten: your Tower layer is defensible and you are ready to extend into Solutions with confidence. Six to eight: pick the class your "no" answers point to and run one reconciliation cycle on one Sub-Tower before the next close. Five or fewer: stop extending the model. The Tower report is inheriting defects you have not yet measured, and any Solution or Consumer figure built on it will inherit them too.

Question 8 deserves a note. Patch compliance is a ratio, and its denominator is a server count. If security's denominator and finance's denominator differ, at least one of them is wrong, and the two teams have been arguing about the wrong number in separate meetings. It is the fastest external check on Servers Sub-Tower integrity available to most programs, because the security team's count already exists and nobody has to build it.

Conclusion: sequence the work

Start with one Sub-Tower, preferably Servers, because the sources are plentiful and the stakes are visible. Pull its population from the CMDB, the ITAM repository, the endpoint agent, and the hypervisor in the same week. Classify every variance into one of the five classes; do not resolve yet, classify. Assign each class an owner who is not the TBM analyst. Resolve on the record, with the reason and the authoritative source captured for each corrected CI. Then make the run recurring at the cadence of your close, so that next month starts from last month's resolutions rather than from zero.

Only after two consecutive runs produce a count both owners will sign should the program extend that Sub-Tower's cost into Solutions. The model will allocate whatever it is given. Give it something validated.

To see how the Validation View handles this cycle on your own CMDB and ITAM data, book a demo.

Frequently asked questions