Newsletters:

Riding the CMDB Tidal Wave, Part Two - Page 1

Jul 3, 2007
By

Dennis Drogseth






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...

Page 1 of 2


 

0 Comments (click to add your comment)
Comment and Contribute

Your comment has been submitted and is pending approval.

Author:

Comment:

 (click to add your comment)

Comment and Contribute

Your name/nickname

Your email

Comment:

(Maximum characters: 1200). You have characters left.