Riding the CMDB Tidal Wave, Part Two

By Dennis Drogseth

(Back to article)

Last month I introduced EMA’s approach to more effectively planning for CMDB system adoptions by introducing three key terms: CMDB system, core CMDB, and citizen CMDB.

The systems are overall inclusive models for multiple trusted sources with meta data and policy organizing consistent usage and access. Core CMDBs typically provide process control support for review, including ITIL’s notion of a change advisory board, and reflect desired state as mapped to discovered state.

There can be multiple physical entities in the core system. And citizen CMDBs reflect the broad arrays of trusted sources, from domain-specific configuration detail to monitoring solutions that contribute to the broader system.

Since last month, ITIL v3 has introduced new terminology around CMDBs including its configuration management system (CMS), which contains many CMDBs or trusted sources. I won’t take the time here but to say more but the fit is surprisingly close to our nomenclature.

This month’s column will provide you with five pointers taken from our IT consulting team directed at CMDB system deployments and developed by our lead consulting director, Chris Matney.

These tips closely follow EMA’s patent-pending consulting methodology for CMDB system success and are drawn from extensive customer engagements.

Gathering Detailed Requirements

In a typical consulting engagement, EMA finds expectations from IT staff and executives to range widely. Some expect to be able to resolve incidents more quickly by being able to map applications to underlying servers and devices, while others expect a single pane of glass visualization of the entire infrastructure.

The key to understanding, at the ground-level view, what the CMDB system will accomplish is to gather comprehensive, clearly-defined and detailed requirements. A solid, detailed requirements document provides a means to set expectations, create a meaningful roadmap and measure progress along the way.

As an example, high-level initiatives such as “lowering mean time to repair” are not detailed requirements because these types of goals are too vague to be actionable and measurable. On the other hand, too much detail can damage the project as well. For instance, listing each field in a report will result in a detailed requirements document that is thousands of items long and useless in a pragmatic implementation.

Setting Expectations

Requirements should evolve and be modified through dialog with CMDB system users. Setting expectations in part means developing a common foundation for “How can the CMDB System change my life?”

On the other hand, while the groundwork for setting expectations is the detailed requirements as described above, the excitement around the CMDB system can degenerate into thinking of the project as a silver-bullet. Scope creep is a common killer for CMDB implementation projects.

In EMA’s estimation, understanding what a CMDB won’t provide is almost as important as knowing what it will provide. EMA recommends the detailed requirements document also include those items that will not be provided by initial phase solutions as a matter of clarity. It should also clarify appropriate enthusiasms, objectives, and specific CI-related responsibilities.

Taking a Pragmatic Approach

Good process practices are critical to insure that the data in the CMDB system is accurate, reconciliation rules are updated, system of records are clearly understood, etc. Essentially, process is at the heart of any CMDB system.

In many companies, process is thought of as synonymous with ITIL. This misconception leads many firms to believe that by sending its staff through ITIL training it will improve processes and efficiencies, adequately addressing all process issues.

Not only is this wrong, but a poor understanding of processes has been the downfall of numerous CMDB implementations. EMA recommends taking a pragmatic approach to ITIL, focusing on changing the culture slowly by showing the advantages of process improvement in small, meaningful steps. Remember, ITIL is just a framework and common lexicon for addressing process issues. Choose those portions of ITIL that address the needs specific to your organization and avoid “boiling the ocean”.

Next Page: The most common causes of CMDB project failure...Back to Page 1

Addressing Organizational Issues

When addressing gating factors — those issues that can cause a CMDB implementation to fail — EMA finds consistently the highest scoring factors are cultural and organizational issues, not technology. As CMDB implementations are typically championed by evangelists drawn from within the ranks of IT, focus on CMDB projects tends to be technology.

Leading with buying a tool is a common mistake. Organizational issues that should be considered run the gamut from executives to production staff. At the top, executive sponsorship is critical. A CMDB project is a multi-year adventure that adds cost to the base IT budget for ongoing maintenance and support. While the return on investment (ROI) can be staggering, there needs to be a clear understanding of the costs in terms of hardware, software and people.

Executives need to be willing to prioritize the CMDB and commit domain expert resources to the effort. The CMDB team needs to have cross-domain authority to create policies and enforce them across the enterprise, breaking down resistance by technology silos that might not want to participate in the project. Understanding the cultural and organizational issues a company might face is a critical component to success.

Providing Short-Term Deliverables

Although the implementation of a CMDB system is a multi-year project for most large enterprises, ROI can be seen almost immediately. By focusing on those detailed requirements that are most important, a proper CMDB implementation should show results within 90 days.

Our research shows that focus wanes when project plans are longer than six months. From this, EMA has developed a phased approach that creates six-month and 12-month roadmaps with hard deliverables and measurable milestones.

A six-month roadmap includes specific software that will be installed and configured, processes that will be created or modified, and organization issues that will be addressed. In addition, it maps these tasks back to the detailed requirements document to demonstrate progress and measure success.

The 12-month roadmap is essentially a draft of the next tactical plan. This provides a means to plan longer term and set expectations accordingly.

These are five leadoff steps that complement five more deployment-oriented steps in EMA’s top 10 recommendations list. Those five oriented at deployment are: effective toolset selection, a focus on integration, trying to keep data out as well as putting it in, ongoing communication of status and objectives, and effective phase reviews.

While few CIOs and other C-level executives are directly involved in CMDB system deployments, C-level executives do hold the reins in several of the most critical areas: reviewing and approving appropriate, business-aligned objectives, assuring effective levels of resource and commitment, and being willing to support cultural and organizational change.

Indeed, a CMDB system deployment is almost invariably a catalyst for this last. And once that’s understood, and seen as a benefit, many of the toughest battles surrounding CMDB deployments can be fought on much friendlier ground.

Dennis Drogseth is a vice president and leads Enterprise Management Associates' New Hampshire office. Drogseth also is EMA's Network Services practice leader.