The two lists differ by several hundred servers and nobody can say which is right, so the TBM analyst picks one, notes it, and the Compute Tower allocation runs on a number two people dispute. The itam vs cmdb question keeps getting asked as if one system should win. It should not. ITAM and the CMDB record different facts, feed different steps of the TBM Taxonomy, and are both wrong in ways only the other can expose. This post assigns each its job.
What ITAM records, and where it lands in the Taxonomy
IT asset management (ITAM) is the financial and contractual record of technology assets. A hardware asset record carries purchase or lease terms, serial number, cost center, refresh date, warranty and support contract, and disposal status. A software asset record carries entitlement counts, license metric, maintenance term, and vendor. ITAM answers the question "what did we acquire, on what terms, and when does it end."
In the TBM Taxonomy that makes ITAM evidence for the Cost Pool side of the model and for the early passes of Tower mapping. The Hardware and Software & SaaS Cost Pools are populated from the general ledger, and ITAM is what tells you which GL lines belong to which assets. When the TBM Council's mapping guidance lists contract-based and fixed-asset-based passes among the approaches for assigning Cost Pool dollars to Resource Towers, ITAM is the system those passes read from. A hardware maintenance contract mapped to the Compute Tower gets there because ITAM says which covered assets are servers.
ITAM's characteristic defect follows from what it records. It knows what was bought. It does not reliably know what was deployed, moved, or quietly powered off. An asset can sit in ITAM as active for two refresh cycles after it left the rack, because the disposal step happened in a ticket that never updated the asset record.
What the CMDB records, and where it lands
The configuration management database (CMDB) is the operational record. A configuration item (CI) carries what the thing is, its class, its attributes, its environment, its owner, and above all its relationships: which application runs on which server, which server sits on which hypervisor, which database supports which service. The CMDB answers the question "what is running, how is it configured, and what does it serve."
In the Taxonomy, that puts the CMDB on the supply-and-service side of the model. CI counts by class are the natural drivers for Sub-Tower allocation within Compute, Storage, and Network. CI relationships are the raw material for Tower-to-Solutions mapping: the step that moves cost from the Servers Sub-Tower to the applications and business services that consume those servers. Without a relationship graph, Solutions allocation falls back to percentage splits someone estimated in a workshop. With a validated one, it follows the actual dependency chain.
The CMDB's characteristic defect is the mirror of ITAM's. It knows what was registered. It does not reliably know what was never registered, and it forgets slowly: a CI for a decommissioned host persists until someone deletes it, and its relationships persist with it. One FogLifter deployment carries 3,300+ applications in its Solutions layer, and that is the scale at which a stale relationship graph stops being a nuisance and becomes a material allocation error.
Where they disagree, and why the disagreement is the useful part
Put the two records side by side, matched on serial number or hostname, and three populations appear. Assets in ITAM and not in the CMDB were bought and never deployed, deployed and never registered, or retired from operations but never disposed in the asset record. Assets in the CMDB and not in ITAM were deployed without a procurement record, inherited through an acquisition, or are ghosts of hardware that ITAM correctly disposed. Assets in both with different attributes, a different owner, cost center, or location, tell you which system was updated last and which one was not.
Each of those populations has a different TBM consequence. The first inflates Cost Pool dollars against assets generating no consumption, so unit cost is understated. The second leaves consuming assets with no acquisition cost to allocate, so unit cost is overstated. The third misroutes cost to the wrong Sub-Tower or Solution. None of that is visible if the program resolves the delta by choosing a winner. All of it is visible if the program treats the delta as a work queue.
The mechanism FogLifter uses here is deliberately not "pick the trusted source." Both records are ingested, along with discovery, hypervisor, endpoint, and billing data. The ontology normalizes keys, so a server known by hostname in the CMDB, by serial in ITAM, and by inventory name in the hypervisor resolves to one entity. Each attribute is then assigned an authoritative source by rule, and the Validation View records which source won for which field and why. The count that reaches the Tower allocation is one count with lineage, not the CMDB's count or ITAM's count.
ITAM vs CMDB ownership: a working split for TBM programs
Ownership of the systems does not change. ITAM stays with asset management or procurement. The CMDB stays with configuration management or ITSM. What TBM has to own is narrower and more specific.
TBM owns the standard that a count must be validated before it drives an allocation. TBM owns the recurring reconciliation of the two populations against each other and against the estate, at the cadence of the financial close. TBM convenes the variance queue but does not resolve it; the ITAM lead resolves acquisition and disposal variances, the CMDB steward resolves registration and relationship variances, and each resolution is recorded with the reason and the source that was deemed authoritative.
This split ends the itam vs cmdb argument because it stops asking either system to be the inventory of record for the whole estate. ITAM is the record of acquisition. The CMDB is the record of operation. TBM is the consumer that needs both to agree, and it is the only function with a monthly reason to make them.
Conclusion
Next time the two lists disagree, do not pick one. Match them on serial and hostname, split the result into the three populations, and hand each population to the owner whose system it implicates. Write down which source was treated as authoritative for the count that reaches the Compute Tower, and why. Then run the same match next close. The delta will shrink, the Tower allocation will stop moving for reasons nobody can explain, and the question of which system is right will become the question it always should have been: which system is right about which fact.
To see how validated ITAM and CMDB records are reconciled before they reach the model, start with FogLifter's ITAM validation overview.
The whitepaper behind this blog
For the five-class defect model and the Tower integrity diagnostic, read the anchor whitepaper: CMDB and ITAM data quality: the precondition for Resource Tower integrity.
Frequently asked questions
ITAM records what the organization acquired: purchases, leases, license entitlements, contracts, refresh and disposal dates. The CMDB records what is running: configuration items, their attributes, and their relationships to applications and services. In TBM terms, ITAM is evidence for Cost Pools and contract-based Tower mapping; the CMDB supplies Sub-Tower counts and Tower-to-Solutions relationships.
No. Asset management tracks financial and contractual lifecycle from acquisition to disposal. A CMDB tracks operational configuration and dependencies. Many platforms host both in one product, which is where the confusion starts, but the records answer different questions and drift in different directions. The CMDB tends to keep retired items; ITAM tends to miss items that were never procured through the standard process.
A CMDB can hold asset attributes, and many do, but it is not built to manage acquisition, entitlement, or disposal workflows. Using it as the sole asset record usually means contract and lease data live somewhere else anyway. For a TBM program the practical answer is to reconcile the two rather than collapse them, so each record's defects are exposed by the other.
Neither alone. Sub-Tower counts should be validated across the CMDB, ITAM, and at least one independent operational source such as the hypervisor or endpoint agent, with an authoritative source assigned per attribute and recorded. A count taken from one system inherits that system's blind spots directly into the Tower allocation.
At the cadence of the financial close, because that is when the counts become allocation drivers. Monthly is typical. A one-time cleanup improves the numbers for a quarter or two; a recurring reconciliation with recorded resolutions is what keeps the Tower allocation stable and defensible over time.
Related Resources
Continue reading on connected topics from FogLifter®.