CMDB
Configuration Management Database: a central repository that tracks every IT asset — applications, servers, licenses, cloud resources — and the relationships between them.
A CMDB (Configuration Management Database) is the central repository describing the components of an information system and, above all, the relationships between them. Servers, applications, databases, network equipment, licences: each element is recorded as a Configuration Item (CI), with its attributes and dependencies.
Its value lies not in the inventory — plenty of tools can list assets — but in the dependency graph. Knowing a server exists is useful; knowing that shutting it down will stop payroll for 3,000 employees is decisive.
Formalised by the ITIL framework, the CMDB underpins IT service management (ITSM) processes.
What a CMDB contains
Four building blocks structure the data model:
- •Configuration Items (CIs): every managed entity in the IT estate — hardware, software, service, contract, even documentation.
- •Attributes: the properties of each CI (version, owner, criticality, environment, commissioning date).
- •Relationships: the heart of the system. "Depends on", "hosts", "is used by", "connects to".
- •History: the record of change over time, essential to understand a regression.
The data model — or meta-model — determines the value of the whole. Too granular and it becomes impossible to maintain; too coarse and it answers no useful question.
What a CMDB is actually for
Four use cases justify the investment.
Impact analysis. Knowing what will be affected before a change. This is the highest-return use: it turns guesswork into a documented decision.
Incident resolution. When a service goes down, walking the dependency chain to find root cause instead of polling every team.
Change management. Assessing requests against real risk rather than assumed risk.
Compliance and audit. Proving you know what you operate — now an explicit requirement under NIS2 and DORA.
CMDB, ITAM, EAM: who does what
The three disciplines share inventory data but answer different questions:
- •The CMDB answers "how does it work?" — dependencies, configuration, impact. An operational angle.
- •ITAM: answers "what does it cost?" — contracts, licences, financial lifecycle. An economic angle.
- •EAM: answers "where are we going?" — target architecture, business capabilities, roadmap. A strategic angle.
These angles complement each other. Siloing them across three tools that never talk to one another is among the most common causes of failure.
Four classic pitfalls
CMDB projects have a poor reputation, and for good reasons.
Completeness as the goal. Trying to model everything before delivering any value. These projects stall before the first release. The better approach starts with one critical service and expands in concentric circles.
Manual data entry. A hand-maintained CMDB is wrong within weeks. Without automated discovery, data goes stale faster than it can be entered.
No owner. With no designated owner per domain, nobody fixes discrepancies and trust erodes. A CMDB teams no longer believe in is a dead asset.
A frozen data model. The IT estate evolves; a meta-model designed once and for all becomes a straitjacket.
How to build a CMDB that lasts
An approach that works unfolds in four stages:
- Scope by use case. Start from the questions the CMDB must answer, not from the data available. Two or three priority use cases are enough to define scope.
- Automate discovery. Agents, connectors, SSO, network scanning, cloud APIs: the data must collect itself.
- Reconcile sources. Deduplicate and arbitrate conflicts between sources, with an explicit precedence rule per data type.
- Govern over time. Named owners, freshness metrics, periodic review of discrepancies.
Do you still need a CMDB in 2026?
The question is fair. The classic model — an exhaustive repository fed by a centralised project — was designed for stable, mostly on-premise IT estates. It copes poorly with SaaS, elastic cloud and Shadow IT, where assets appear and disappear without ever passing through IT.
What remains essential is knowledge of dependencies. What has changed is how you obtain it: through continuous discovery rather than declaration, and by placing the application — not the server — at the centre of the model.
The Kabeen approach
Kabeen starts from actual usage: applications are discovered automatically, their data flows and dependencies are continuously reconstructed, and each application carries its costs, contracts and usage.
You get the value expected from a CMDB — impact analysis, dependencies, governance — without the eighteen-month project or the manual maintenance that follows it. See our approach to application portfolio mapping.
Questions fréquentes
What is a CMDB?
A CMDB (Configuration Management Database) is the central repository describing the components of an information system and the relationships between them. Each element — server, application, database, network device — is recorded as a Configuration Item (CI) with its attributes and dependencies. Its value lies less in the inventory itself than in the dependency graph it makes visible.
What is a CMDB used for?
A CMDB serves four main purposes: impact analysis before a change (knowing what will be affected), incident resolution (walking the dependency chain to root cause), change management (assessing requests against real risk), and regulatory compliance, particularly under NIS2 and DORA requirements.
What is the difference between a CMDB and ITAM?
A CMDB answers the question of how things work: dependencies, configuration, impact analysis — an operational angle. ITAM answers the question of what things cost: contracts, licences, financial lifecycle — an economic angle. Both disciplines share inventory data but use it differently, and benefit from being unified rather than siloed in separate tools.
Why do CMDB projects so often fail?
Four causes recur: aiming for completeness before delivering any value, which stalls the project; maintaining the database manually, which makes it wrong within weeks; designating no owner per domain, so discrepancies are never corrected; and freezing the data model while the IT estate keeps evolving.