Most CMDBs fail. I would rather build for the odds than pretend they are not real.
I have spent more than fifteen years building service management platforms and configuration data structures, with recent years focused heavily on Jira Service Management and Assets. In that time I have watched the same story play out again and again. A CMDB gets stood up with real intent, and somewhere between the kickoff and the second year it quietly stops being trusted.
Industry analysts and infrastructure vendors frequently cite CMDB programme failure rates in the 70% to 80% range. I am not going to dress LaunchPad up as a magic exemption from that. What I can do is share what I learned from the deployments that did not fail, and show you what we are building so yours has a genuine chance of becoming one of the deployments people still trust two years later.
The shift in practice
Five principles I work to, and the tooling intended to support them in practice.
Here is how the project-to-service shift actually shows up in the work. For each one I have been clear about what LaunchPad ships today and what we are still building, because a CMDB strategy built around features that do not exist yet usually becomes part of the same failure pattern.
Start with outcomes, not an inventory
A CMDB is not a trophy cabinet for everything you own. Before a single object is modelled, I want to know which service decision it will improve.
Linking servers to the applications they support so incidents resolve faster. Mapping dependencies so a change can be risk-assessed before it ships. Tracking hardware and software lifecycles so licence spend stops leaking and audits stop hurting.
If an object does not support an operational outcome like that, it has not earned its place yet.
Today
LaunchPad's schema accelerators are designed around common ITSM operational outcomes such as incident, change, asset and compliance workflows, rather than around a generic inventory structure you later have to interpret.
Scope lean. Begin where it actually hurts
Trying to map the whole estate at once is one of the biggest drivers behind CMDB failure.
So I start narrow and on purpose.
The top five to ten mission-critical services first. Only the attributes that support a decision, such as owner, environment and address. Nothing temporary, personal or hyper-granular that simply adds noise to the database.
Today
The schema models on the Marketplace are accelerators and implementation patterns, not a mandate to model everything. You deploy the ones that fit the services you are starting with.
The Environment Analysis scan reads your existing Jira Service Management project and identifies areas where free-text fields may be better represented as structured Assets data, helping surface where consistency and reporting could improve.
Automate the data in, and keep it fresh
Manual entry cannot keep pace with cloud and hybrid estates, and stale data is where trust starts to disappear.
Industry commentary frequently cites significant data decay in poorly maintained CMDBs. The long-term goal is to pull from systems that already hold operational truth and reduce dependence on manual updates wherever possible.
Today
The Workbook Engine supports structured bulk import and export of Assets objects through a schema-aligned Excel workbook workflow, so large-scale updates and corrections can happen more efficiently than editing objects one at a time.
On the roadmap
We are designing Assets Sync Manager, a scheduled, diff-based synchronisation capability intended to compare source data against existing Assets objects, surface detected changes, and support review before approved updates are applied on a schedule.
The goal is to make operational data maintenance progressively less manual over time.
We are also researching potential integrations with platforms such as Microsoft Intune, AWS and ServiceNow to help reduce repetitive data management work.
Make ownership and governance non-negotiable
A CMDB starts to fail the moment nobody is accountable for its accuracy.
Every class of object needs a named owner. Significant operational changes should trigger corresponding relationship reviews. And owners should regularly re-confirm that the data still reflects reality instead of assuming it does.
Today
Ownership is treated as a first-class attribute in the schema accelerators, so accountability is modelled from the beginning rather than introduced after data quality has already drifted.
On the roadmap
Governance Intelligence is a planned operational governance layer focused on maturity analysis, relationship quality, ownership gaps, lifecycle governance, and structural drift across Jira Service Management and Assets environments. It is the area I am most committed to evolving.
The intention is to move from point-in-time analysis toward continuous quality visibility by helping surface objects with missing ownership, stale ownership, likely duplicates, schema anti-patterns and weak service mapping relationships.
The goal is governance the platform helps surface and reinforce, rather than governance that depends entirely on manual discipline.
Watch the CMDB's health continuously
Even a well-built CMDB drifts over time.
The way you catch that drift is by monitoring a small set of operational health indicators consistently.
What is newly discovered and still missing context. What has not checked in recently and may now be stale. Where completeness or relationship quality is starting to slip before trust in the data erodes.
Today
The Environment Analysis scan provides a point-in-time analysis of areas where structure or standardisation may currently be inconsistent.
On the roadmap
The same Governance Intelligence work is intended to introduce scheduled scoring and trend visibility so health can be monitored continuously over time rather than only when somebody manually checks.
A read-only Rovo Assets Schema Assistant is also planned for environments where Rovo is active. The intention is to provide natural-language explanations of installed Assets schemas and relationships. It is not part of the current production build.
Plainly stated
What ships today, and what we are still building
I would rather you evaluate what is real today than buy into promises about what might exist later.
Available now
Schema accelerators on the Marketplace
A library of service-oriented schema patterns designed to accelerate Jira Assets implementations.
Workbook Engine
Structured bulk import and export of Assets objects through a schema-aligned Excel workbook workflow.
Environment Analysis scan
A read-only analysis of your existing Jira Service Management project that highlights candidate areas where structured Assets relationships may improve consistency and reporting.
On the roadmap
Governance Intelligence
A planned governance and maturity analysis layer for operational structure, ownership, and Assets quality across Jira Service Management environments. Continuous quality visibility intended to help surface ownership gaps, duplicates, anti-patterns, relationship integrity issues and weak service mapping trends.
Assets Sync Manager
A scheduled, diff-based synchronisation capability designed to support controlled updates from governed external sources.
External source integrations
Researching potential integrations with platforms such as Microsoft Intune, AWS and ServiceNow.
Schema Merge Engine
Controlled schema merge workflows currently in development.
Rovo Assets Schema Assistant
A planned read-only companion intended to provide natural-language explanations of installed schemas where Rovo is available.
Where this leaves us
Not a guarantee. A more sustainable operating approach.
The 70% to 80% figure is sobering, and I will not insult you by pretending LaunchPad makes that risk disappear.
What I am offering is an operational approach drawn from real-world enterprise implementations, supported by tooling intended to reduce the friction that commonly causes CMDB initiatives to drift over time.
Built from practical implementation experience. Structured around operational outcomes. Designed to be run as an ongoing service rather than treated as a one-off delivery project.
If you are weighing this up, two questions tell me almost everything about where to start:
-
What is driving your CMDB initiative right now? Failed changes, slow outage resolution, audit pressure, asset visibility gaps, or something else?
-
Are you primarily cloud, primarily on-premise, or operating in a genuinely hybrid environment?
Those answers usually make the initial direction much clearer.
Andreas Nyberg
Founder, Let's Talk Solutions
Maker of LaunchPad for Jira Service Management
Figures referenced are drawn from widely cited industry commentary and vendor research discussing CMDB programme failure rates, operational data decay and infrastructure visibility challenges. These references are included to frame common industry risks and should not be interpreted as guarantees of outcome.