Q: David, we enjoyed your video on the differences between the AMDB and CMDB, and wanted to dig down a bit more into the difference between the two. So, first off… If the two databases were guests at the same ITSM dinner party, who would be the meticulous accountant and who would be the enthusiastic social networker?
A: The AMDB should serve as the meticulous accountant focused on financial and lifecycle data, while the CMDB acts as the enthusiastic social networker tracking dynamic relationships. The AMDB is focused on financial values, lifecycle management, and asset accountability, updating only at key events such as repairs or disposals. The CMDB aggressively tracks changes, relationships, and ITIL processes such as incidents and changes, reflecting a constantly evolving network of configuration items (CIs). This division ensures the CMDB handles fluid service and relationship data, while the AMDB manages stable, factual asset information, preventing overlap and data confusion.
Q: More seriously, where do you draw the cleanest operational boundary between hardware lifecycle data in the AMDB and service relationships in the CMDB?
A: A clean operational boundary exists where the AMDB manages hardware lifecycle events and financials, while the CMDB manages service relationships and configuration details. The AMDB tracks hardware lifecycle dates such as scheduled retirement, warranty expiry, and support end dates, which have little impact on the CI itself but are critical for asset management. The CMDB focuses on relationships such as IP ranges, service hierarchies, and application mappings that do not belong to asset lifecycle management. Organisations should avoid forcing full asset lifecycle management into the CMDB and instead implement a dedicated AMDB from the outset to maintain procurement, inventory, and lifecycle data control. This separation supports effective budgeting, auditing, and refresh planning while preventing confusion and data decay.
Q: Many organisations try to squeeze full asset lifecycle management into their CMDB. At what point does the CMDB politely revolt?
A: The CMDB effectively “rebels” when organisations lose control over hardware spending and lifecycle management, signalling an urgent need for a dedicated AMDB. Overspending millions annually on hardware without corresponding lifecycle tracking indicates a lack of control and raises concerns at CIO and director level. Without an AMDB, organisations struggle to track hardware refresh rates, perform internal audits, or maintain visibility of stock, leading to redundant purchases and poor asset governance.
Q: What are the key signals that the CMDB is about to launch a full-scale rebellion, and that the organisation needs a proper AMDB right now?
A: The warning signs are usually financial and operational. Organisations find themselves unable to track hardware refresh rates, unable to perform effective internal audits, and unable to account accurately for what hardware they own. Unexpected overspending, redundant purchases, and a lack of visibility into asset lifecycle status are all indicators that asset management has outgrown the CMDB. These signals suggest the need for a dedicated AMDB to regain control and provide predictive budgeting and refresh planning.
Q: If you had to choose one dataset that most organisations underestimate in hardware lifecycle management, which, when it’s missing, causes the biggest downstream chaos, what would it be?
A: Scheduled retirement dates and warranty expiry dates are probably the most underestimated data points in asset management. Yet they are critical for avoiding costly surprises and customer impact from obsolete hardware. When organisations capture and maintain this information properly, they can plan hardware refreshes years in advance, improve budgeting accuracy, reduce risk, and provide leadership with visibility into future investment requirements.
Q: You make the point that CMDBs are all about relationships — servers mapped to applications, applications mapped to services — but hardware assets have a very physical lifecycle: delivery, deployment, refresh and disposal. Where do you think organisations most often confuse how CIs behave versus the hardware asset lifecycle?
A: Organisations often blur the lines by trying to manage hardware lifecycle data inside the CMDB. The CMDB is designed to model relationships and dependencies, such as application mappings, service hierarchies, and infrastructure connections. Hardware assets, however, follow a physical lifecycle that includes procurement, deployment, maintenance, refresh, and disposal. Trying to manage both worlds in the same place often leads to overlapping responsibilities, reduced data quality, and loss of control over asset governance.
Q: It’s a truism that “not every asset is a CI, and not every CI is an asset.” In your experience, which types of records most often get misclassified and what operational problems does that create for ITAM teams?
A: Consumables and end-user devices are among the most commonly misclassified records. Headsets, for example, often lack serial numbers and rarely benefit from having both asset and CI records, creating unnecessary administration overhead. SIM cards should primarily exist as CIs to support joiner, mover, and leaver processes, while still linking to asset records for financial tracking. Mobile phones and tablets frequently generate disagreement around classification, which can result in missing CIs for lost or stolen devices and complicate incident management. These misclassifications create operational friction, data mismatches, and loss of control over IT processes.
Q: Would you agree that the AMDB and the CMDB should be best friends? In your view, what is the key to getting them to play well together on the IT merry-go-round?
A: Absolutely. For effective IT asset and configuration management, the AMDB and CMDB should be tightly integrated within the same platform. This enables real-time data sharing, automatic associations between assets and configuration items, and consistent updates across both datasets. Housing them within the same tool allows hyperlinking and synchronisation that prevents discrepancies and outdated records. Without this linkage, both databases gradually degrade, creating operational confusion and reducing confidence in the data. The key is recognising that the AMDB and CMDB have distinct responsibilities but complementary roles, and ensuring they work together seamlessly.