Why CMDB scope is the question every implementation gets wrong
The CMDB failure mode is almost always the same: the team scopes too broadly in the beginning, tries to load everything into the system, falls months behind on keeping records current, and ends up with a CMDB that nobody trusts because half the data is stale. The other common failure is scoping too narrowly and missing the relationships that make a CMDB useful in the first place.
A CMDB is not an asset register. It is not an inventory spreadsheet. It is a tool for understanding how the components of your IT environment relate to each other and to the services you deliver. The value is not in having a record of every device - it is in being able to answer "what is affected if this database server goes down?" or "what changed before this incident started?"
Those questions require relationship data, not just inventory data. And relationship data only stays accurate if the scope is manageable. When a CMDB has 50,000 CIs and a team of two people responsible for maintaining it, the relationships degrade fast. Within a year, the impact analysis is unreliable and incident responders stop using the tool.
The right scope question is not "what do we have?" It is "what do we need to trace in order to manage service impact?" Start there and you get a CMDB that is smaller, more accurate, and actually useful.
What the core CI types should be
Every CMDB needs a baseline set of CI types. These are the categories that show up in almost every IT environment and that support the most common CMDB use cases: incident impact analysis, change risk assessment, deployment tracking, and service dependency mapping.
Software products are the foundational CI type. A software product is a commercial or open source package that your organization uses - the thing you license, patch, and update. Examples: PostgreSQL, Red Hat Enterprise Linux, Nginx, the Atlassian Jira Data Center package. The product record captures the name, vendor, and license information. It does not capture the version - that is a separate CI type.
Versions are children of software products. Each major and minor version you actively run in your environment is a separate CI. PostgreSQL 14 and PostgreSQL 16 are different versions. This distinction matters because the same product may have multiple versions running in different environments, and knowing which version is deployed where is essential for vulnerability management and upgrade planning. When CVE-2024-XXXXX hits PostgreSQL 14, you need to know exactly which systems are running it.
Servers and infrastructure cover the physical and virtual compute that runs your software. Physical servers, virtual machines, containers (at the host level), and cloud instances all belong here. The key attributes are what services run on this system, who owns it, its environment (production, staging, development), and its network location. You do not need to record every network switch and patch panel - but the servers that run your services belong in the CMDB.
Databases are distinct from the servers they run on. A single server may run three databases serving different applications. Capturing databases as their own CI type lets you model the dependency: Application A depends on Database X which runs on Server Y. That three-level relationship is exactly what you need for incident impact analysis.
Application components are the individual pieces of a deployed application - web tier, API tier, background workers, scheduled jobs. For simple applications, one component record may be enough. For complex applications with independent scaling and failure modes, breaking them into components lets you model more precise dependencies.
Deployments tie everything together. A deployment is an instance of a software version running on a specific server or container environment. Deployments are how you answer "where is this version installed right now?" and "what changed before this incident?" Deployments should capture when they were last updated and who authorized the change.
What to leave out
Office furniture does not belong in a CMDB. This sounds obvious but it gets asked regularly, especially by teams coming from asset management backgrounds where furniture and equipment are tracked in the same system. If it is not IT infrastructure and it cannot cause a service outage when it changes or fails, it is not a CI.
Personal devices - employee laptops, phones, tablets used for work - are a judgment call, but for most organizations they do not belong in the CMDB proper. They belong in your MDM or endpoint management system. The CMDB is for infrastructure, not for every device that touches the corporate network. If a personal laptop fails, the impact is to one person's productivity. That is not what impact analysis in a CMDB is designed to track.
Network cables and patch panels should generally stay out. The exception is in environments where cable runs are critical to service delivery and where you have staff to maintain that level of detail - a data center with formal cabling management practices. For the average enterprise CMDB, cabling is below the level of abstraction you need to manage service impact.
Printers, monitors, keyboards, and peripheral devices are asset register items, not CI candidates. The test: if a printer fails, can you trace that to a service impact on something you are responsible for delivering? In almost every case, no.
Software licenses are a related but separate concern. License management belongs in a software asset management (SAM) system, which may be integrated with or separate from your CMDB. Conflating the two creates schemas that serve neither use case well.
How to decide on edge cases
The CI selection test is one question: can you trace this item to a service impact?
A network firewall between your application tier and the internet - service impact is clear. Include it. A test environment server that no production service depends on - if you cannot trace it to a production service impact, it probably does not need to be in the production CMDB. Track it elsewhere.
APIs exposed by third-party vendors are a common edge case. If your service depends on a vendor API and that API failing would cause a service outage, the vendor service should be a CI. You cannot manage impact analysis on a service you have not modeled.
Kubernetes clusters and container orchestration present a tricky scoping problem. You probably do not want to model every pod. You do want to model the cluster, the namespaces that correspond to services, and the deployments within those namespaces. Find the right level of abstraction for your environment.
Cloud services - AWS RDS instances, S3 buckets used by production services, Load Balancers - should be included if services depend on them. Cloud environments change fast and the CMDB needs to keep pace. Auto-discovery tools are valuable here; manual entry will always lag.
How to keep the CMDB current
A CMDB that is accurate on day one and wrong six months later is worse than no CMDB in many ways - because decisions get made based on incorrect data with false confidence.
The most reliable approach is automated discovery combined with change management integration. Discovery tools scan your environment and create or update CI records automatically. Change management integration ensures that when a change is approved and implemented, the CMDB is updated as part of the change closure process. Neither alone is sufficient.
Discovery tools find what exists. They do not capture the relationships between CIs - the fact that Application A depends on Database X has to be modeled explicitly. That modeling requires an initial effort and ongoing maintenance as your architecture evolves.
Change management integration requires process discipline. The change process has to include a step for updating the CMDB, and someone has to check that step happened. If CMDB updates are optional in your change process, they will be skipped under deadline pressure.
If you are starting a CMDB from scratch, the open source project at github.com/ovoco-co/cmdb-kit is a practical starting point. It provides a working data model with the core CI types described in this article, relationship schemas, and import tooling. It is designed to be deployed without enterprise ITSM licensing costs and extended to fit your specific environment.
How many CIs is too many
There is no universal number, but there is a ratio to watch: the number of CIs divided by the number of people responsible for maintaining the CMDB. If that ratio is over a few thousand, accuracy problems are coming.
A 500-person organization with a focused CMDB scope might have 2,000 to 5,000 CIs. A 5,000-person organization with a broad scope might have 100,000 CIs. The second case requires robust auto-discovery, strong change management integration, and likely a dedicated CMDB team. Most organizations are better served by a smaller, accurate CMDB than a large, stale one.
When you inherit a CMDB that has grown out of control, the fix is a scope review and a data quality purge. Run a report of every CI that has not been verified or updated in 12 months. Review each one. Either verify it is current and mark it reviewed, or retire it. Do not carry stale CIs indefinitely because someone worries about losing the history. Archive the history and keep the active record set clean.
FAQ
Q: What is the difference between a CI and an asset? A: Assets are things you own and manage - they have financial and procurement attributes. CIs are things you track because they affect service delivery - they have configuration and relationship attributes. Many CIs are also assets, but not all assets are CIs. A server is both an asset and a CI. A desk chair is an asset, not a CI.
Q: Should we include documentation as a CI type? A: In some environments, key documents - runbooks, architecture diagrams, DR plans - are managed as CIs with version control and relationships to the systems they describe. This is a reasonable extension of the CMDB model for mature organizations. For most teams just getting started, documentation as CIs adds complexity without proportional value.
Q: How do we handle CI ownership when teams change? A: Every CI should have a defined owner - a team or a role, not just a named individual who may leave. When teams change, ownership transfer should be part of the offboarding and onboarding process for the departing and arriving team. CIs without current owners are a data quality risk.
Q: What is the relationship between the CMDB and change management? A: Change management and the CMDB should be tightly integrated. A change request should reference the CIs being changed. When the change is closed, the relevant CI records should be updated to reflect the new configuration. Without this integration, change management and the CMDB drift apart and neither provides accurate information.
Q: Do we need a CMDB tool or can we use a spreadsheet? A: A spreadsheet can work for very small environments - under a few hundred CIs with simple relationships. Beyond that, the relationship modeling and the change history tracking that make a CMDB valuable are difficult to maintain in a spreadsheet. The cmdb-kit project at github.com/ovoco-co/cmdb-kit provides a structured starting point that scales beyond what spreadsheets can handle without requiring enterprise licensing.
Q: How do we handle CIs in a multi-cloud environment? A: Model each cloud provider as a context, not a CI type. Your server and database CI types work across AWS, Azure, and GCP - the cloud provider is an attribute on the record, not a separate schema. The challenge in multi-cloud is keeping discovery current, since each provider has different APIs for exporting inventory. Tools that aggregate across providers help significantly.