Why Do CMDB Projects Fail? Lessons from Tech Leaders, Developers, and Ops

Technical Leader Perspective

From the viewpoint of senior engineers, CMDB usage must be supported by solid technical architecture; limiting CMDB to pure operations creates a lack of external driving force.

Development / Product Perspective

Many CMDB products in China have taken wrong paths, falling into traps after months of effort.

Common issues include unclear product attributes, blind imitation, and insufficient abstraction capability.

Learning from foreign products reveals three core attributes: a single source of truth, dynamic data collection, and mapping between services and resources.

Without proper abstraction, products become feature‑heavy, low‑quality, and hard to standardize.

Dynamic collection across multi‑cloud environments is a costly engineering challenge.

Mapping services to configuration items must be driven by business‑specific rules.

Automation, monitoring, and workflow orchestration rely heavily on CMDB integration.

Operations / User Perspective

Ops staff often lack abstract modeling skills, leading to CMDB misunderstandings.

Existing domestic CMDB products are adequate; the problem may be user capability.

CMDB must be built to fit the specific operational habits and processes of each environment.

Adaptation and data collection are only parts of the effort; proper modeling cannot be solved by manpower alone.

There is a misconception that a good CMDB can be adopted without learning new tools or processes.

Modern operations are a ecosystem of many platforms, with CMDB as the data foundation driving production activities.

Many still consider Excel the most practical CMDB, highlighting gaps in current solutions.

How Huawei Built Its CMDB

Failures are often blamed on missing consumption scenarios, inadequate tools/technology, and weak process control, but cost‑benefit analysis is essential.

Success hinges on the scale of managed objects and the organization’s execution capability.

Huawei’s CMDB evolved through three phases: startup, integration, and value realization.

Key enablers included strong execution, large scale with automation demand, globalization opportunities, and a bit of luck.

Lessons learned:

Prefer relocation over forced migration.

Design configuration models that are grounded in reality.

Maintain an open mindset and adopt data tiered management.

Simplify data maintenance workflows.

Ensure data integrity.

Provide feedback loops for data consumption.

Invest in visualization.

Resist the urge for premature data analysis in early stages.

Conclusion

Understanding the pain points of CMDB developers helps operations appreciate and integrate the system; likewise, developers who hear ops’ frustrations can create more grounded iterations. Senior architects must guide from a macro perspective, fostering cross‑team collaboration to boost overall efficiency.

We tend to overestimate CMDB’s short‑term impact but underestimate its long‑term value. — bmcsoftware