Why Most CMDB Projects Fail and How Huawei Made It Work

Every time I read a book on configuration management I wonder: the definitions are precise and the processes complete, but that isn’t the real challenge.

The real challenge for a configuration manager is not drawing a massive data model or designing an all‑encompassing control process, but promoting data consumption and continuously improving data quality during that consumption.

I spent seven years at Huawei working on configuration management and witnessed the CMDB evolve from a marginal system to the core of operations.

After leaving Huawei I saw many CMDB projects and realized that few organizations treat CMDB as an essential part of operations; most either fail or hover on the brink of failure.

Key Factors for CMDB Success

Common explanations for CMDB failures focus on lack of consumption scenarios, inadequate tools, or weak process control. From my experience, the deeper cause is the balance between cost and benefit.

Each IT organization already maintains numerous self‑built configuration repositories (host, network, data‑center libraries, etc.). These “self‑built libraries” survive without sophisticated tools because they are low‑cost, give owners full control, and can be quickly adapted to business changes.

When a CMDB is introduced, it often reduces owners' control and offers limited cost savings at current scales, creating resistance.

Configuration management is essentially “data management outsourcing.” Its initial value is reducing duplicate data maintenance costs, allowing business teams to focus on core capabilities.

Because management scale is small, the cost of separate data maintenance is low.

Owners prefer direct control to flexibly adjust data models and input rules.

This self‑sufficient model works well until scale grows, at which point the balance shifts and a CMDB becomes the new equilibrium.

How Huawei Built Its CMDB

Huawei’s CMDB development can be divided into three phases: initial, integration, and value‑realization.

1. Initial Phase (2002‑2007)

Huawei introduced ITIL and a CMDB in 2002 but lacked clear usage guidance. Each department built its own “self‑built library,” leading to fragmented data and skepticism about the CMDB.

2. Integration Phase

In 2007 I moved from change management to the CMDB team. With leadership support we forced the retirement of self‑built libraries, redesigned configuration models to match business granularity, and rebuilt the CMDB tool for better usability.

Despite developing a new JavaScript‑rich front‑end, users resisted migration because of habit and missing features. We eventually purchased a commercial CMDB, but adoption remained limited.

3. Value‑Realization Phase

We began consuming CMDB data for account management and monitoring, automating password‑reset tickets and linking CI status to monitoring deployment. This demonstrated CMDB’s automation potential and sparked broader consumption.

Automation expanded to multi‑process coordination, reducing server delivery time from one month to three days and eliminating cross‑department hand‑offs.

Ensuring Data Accuracy

Data accuracy is vital. We introduced “gate‑keeping” (forcing downstream users to correct data in the CMDB) and “empowerment” (allowing owners to update their own CI instantly). The latter proved effective because most errors stem from delayed updates, not incorrect changes.

We also tackled “black CIs” (unregistered assets) by linking IP address allocation to CI registration and performing network scans to detect rogue IPs, then reconciling them back to the CMDB.

Visualization Attempts

We built a visualization system (CMS) that auto‑generated architecture diagrams from CI relationships. The effort highlighted challenges: high data‑quality requirements, overly granular CI nodes, tangled edge lines, and layout issues. Ultimately a manual canvas proved more useful for users.

Lessons Learned

Forceful migration is riskier than gradual data copy; preserve existing maintenance habits.

Design configuration models that align with current operational granularity.

Adopt an open mindset and tiered data management—only critical data needs strict configuration control.

Simplify data‑maintenance workflows to encourage timely updates.

Protect data completeness; missing data is harder to detect than incorrect data.

Enable feedback loops from data consumption to improve accuracy.

Use visualization to lower comprehension barriers and expose quality issues.

In early stages, focus on basic data supply rather than advanced analytics.

Future Outlook

Configuration management can become less burdensome by integrating CMDB non‑intrusively, offering self‑service and visual tools that lower adoption barriers for midsize IT organizations.

Respect to all comrades who have fought on the configuration front lines.