Industry figures consistently show that only about 25% of organisations realise meaningful value from their CMDB investments. In most cases, the CMDB data model is implemented from a predominantly technical perspective. As technology stacks grow more complex, the CMDB becomes increasingly difficult for business stakeholders to understand and use. The consequences are familiar: outdated operating models remain in place, modern practices are only partially adopted, data quality declines, operational costs rise, and the promised benefits of the CMDB fail to materialise.
Seven Success Factors for Operationalising CSDM5
Effective operationalisation of CSDM5 depends less on tooling and more on disciplined choices. The following success factors consistently
distinguish CMDBs that deliver value from those that do not:
- Manage the Digital Portfolio,
Ownership, data quality, and dependencies of managed digital portfolio items must be reviewed and audited periodically. Performance, costs, risks, threats, and vulnerabilities of the portfolio items must be controlled. Stakeholders must be trained/stimulated to do so. - Plan for maturity/scope growth
Do not register more (or less) than is required at each (maturity) phase. The needs of current and future consumers of CMDB data should drive the scope/roadmap. That said, don’t try to run before you can walk; you will fall. Manage expectations: follow a roadmap. - Use recognisable portfolio items.
Services and applications should be understandable to the people who govern and consume them. Wherever possible, adopt market-standard names and definitions (e.g, of TBM or OpenGroup) that are recognizable to internal/external stakeholders and auditors. - Automate data maintenance
CMDB content should be maintained through automated discovery and federation of the technical artefacts that underpin managed services and applications. Depending on the use cases and data consumers, keep the data up to date periodically or near real-time. - Respect authoritative sources
CMDB data should only be changed at its source. The CMDB is no longer the sole system of record; it is now one of several consumers of authoritative data. Detect Health policy breach for federated data, and automatically assign/monitor Health remediation tasks - Tag runtime artefacts intelligently
Tag Runtime components so they can automatically inherit ownership, commitments, teams, and ratings from related Portfolio Items, even if the runtime artefact itself is not yet (or no longer) registered in the CMDB. - Stimulate CSDM data consumption
CSDM data that is not actively used provides cost without value. Every dataset should exist for a defined purpose and audience. Process Owners/Communities must be made aware of and kept informed about the consumable information made available in CSDM.
How Emerging Technologies Have Changed the CMDB
Cloud platforms, containers, microservices, DevSecOps automation, and increasingly agentic AI have fundamentally reshaped IT operations. Infrastructure is now dynamic, ephemeral, and often self-governing. This does not diminish the relevance of the CMDB—but it changes its role.
Modern CMDBs no longer attempt to track every transient technical component or govern individual runtime changes. Instead, they focus on:
- Service-centric transparency
- Stable dependency modelling
- Risk & Impact awareness
- Ownership and control context
By modelling business and application services and their stable relationships, and keeping them current through automated discovery and integrations, organisations can still assess impact, manage risk, and demonstrate operational resilience—even when the underlying technology continuously changes.
Core Object Types in CSDM5
CSDM5 distinguishes a limited number of clearly scoped object types, including:
- Business Applications – Business-facing products that provide business capabilities
- Technical Applications – Technology-facing products that provide technical capabilities
- SDLC Components – Deployable components that form part of an application
- Business Services – Business-facing services offered to customers or employees
- Technology Management Services – Technology-facing services that manage/support Service Instances
- Service Instances – Logical representations of deployed stacks, typically aligned to DTAP environments and/or regions
- Dynamic CI Group – A Dynamic Group of similar technical products, that often are not associated with a Service Instance (e.g., Active PC’s in NL)
- Service Delivery Systems – Collections of technical products supporting applications and services
- Product Models – Versioned models of discovered or federated hardware and software products
All of these refer to shared foundational data such as organisations, teams, persons, locations, and standards, typically managed by corporate functions or authoritative external institutions.
The Central Role of the Service Instance
The Service Instance is currently the pivotal construct in CSDM5. It is the point where Business meets Technology, and where design-time is related to run-time and vice versa. Anything above it is portfolio, anything below it is technology. The Service Instance is an environment/region-specific stack of deployed technical instances, which stack is (part of) one offered service and which may be depended on by multiple business service offerings.
For most organisations, creating one Service Instance per deployed instance of a logical business or technical application provides the most scalable, efficient, and comprehensible model.
This enables:
- Horizontal dependency mapping between Service Instances (e.g., run-time application instance inter-dependencies)
- Inheritance of ownership and attributes from the parent Application/Offering to the related instances/technology
- Alignment with a single Technology Management Service Offering
- Subscription of production instances to Business Service Offerings
- Mapping of consumed technical products (servers, databases, cloud accounts, components)
Some companies with multiple teams/vendors working on the same application benefit from registering/governing logical “products” offered as (part of) a Service, each managed by a single team with a single product backlog. A word of caution: depending on the way of modelling, the cost/effort/complexity can easily spiral out of hand, and stakeholder satisfaction can deteriorate, whereas the value-add of managing fine-grained products often does not justify the downsides of it.
Only portfolio content requires manual governance. Service instances (including their underlying technical components, which are detected) inherit ownership, commitments, architecture characteristics, and support structures from the portfolio item that contains them. When the attributes of parent portfolio items are updated, the administrative changes are automatically applied to the child technologies as well..
Versioned fine-grained components of runtime applications/products (e.g, microservices) shall never be registered as Service Instances; instead, they may be registered in the CMDB (if there is a use case for it) and/or may be observed/orchestrated elsewhere.
Service Instance Tags placed on relevant technical objects can be detected and/or provided as attributes by observation tools; each instance is contained within an offering of the team that operates it, so each tagged item has an owner, support team, and commitments. At the same time, the Service Instance tags may also be used by Observability, Orchestration, or AI Tools to retrieve managed attributes and commitments of the Service instances (such as Environment type) or of related Service Offerings from the CSDM.
There is a decreasing overlap between design-time (portfolio baselines) and transient runtime (technology instances) in CSDM. Still, I believe there will always be some overlap between the designed, managed, and observed worlds.
Populating the CMDB: Discovery and Federation
Relevant Service Delivery Systems can be populated through a combination of:
- Credential-less discovery
- Credential-based discovery
- Pattern-based discovery
- Agent Client Collector
- Vendor-maintained Service Graph Connectors (e.g., AWS, Azure, Intune, O365)
- Vendor integrations (e.g., SAP APIs)
- Custom integrations where unavoidable
The emphasis is on automation, reconciliation, and authoritative sources—not manual curation.
CMDB Use Cases Across the Value Chain
When implemented correctly, CSDM data supports a wide range of use cases, including:
- Customer and employee interactions
- ITSM processes (requests, incidents, problems, changes)
- Risk and vulnerability management
- Ideas, demands, and portfolio planning
- Strategy, design, and build activities
- Asset and license management
Each use case references the CMDB differently, but all rely on the same stable service-centric model.
In Summary
In modern IT landscapes, the CMDB exists to provide authoritative, service-centric context—not to compete with DevSecOps pipelines, cloud control planes, Kubernetes, SDN, or autonomous AI systems.
Its evolution is clear: from manually maintained asset inventories to dynamically discovered service models enriched with ownership, relationships, and control context. By translating continuously changing technical components into stable, auditable service structures, the CMDB remains a cornerstone for impact analysis, risk management, operational decision-making, and regulatory assurance—without attempting to govern ephemeral runtime behaviour.
When operationalised pragmatically, CSDM5 enables accountability and resilience at scale, precisely where modern IT needs it most.
