Monday, March 17, 2008

10 Tips for a Successful CMDB Project

By Michele Hudnall March 13, 2008

CMDB is all the rage but making it work requires more than buzz-words, writes ITSM Watch guest columnist Michele Hudnall of Managed Objects.

While Ms. Hudnall makes a few good high-level points about what to consider when designing the CMDB process, it's nothing we haven't heard before. I've excerpted the article below and, of course, I've provided my commentary (in blue).

The ability to understand relationships and dependencies across IT components, applications and services has long been desirable for IT organizations and it is the promise of configuration management database (CMDB) projects. The accuracy of data that application dependency mapping tools provide, in combination with the need for higher quality configuration data to improve ITIL processes of incident, problem and change, are part of a collection of reasons why CMDBs grew so explosively over the last 12-18 months.

The catalyst for CMDB projects is simple and the benefits are a tangible reality. If IT understands infrastructure relationships and dependencies they are better able to control change and manage the impact of change when it does occur. Patch management is a good case in point. A recent Computerworld survey found that two-thirds of Oracle DBA’s don’t apply security patches, primarily because they can’t understand the impact installing a patch will have on the database service.

The business case for a CMDB project is compelling, however the implementation can be a bit more challenging. To that end, below are 10 tips for a successful CMDB:

1. The 4 “Ps”
A good chef knows that cooking up something appetizing is a combination of culinary skill, a time-tested recipe and fine ingredients. The best chef with the perfect recipe cannot even hope for a delicious outcome if the ingredients are lacking. Likewise a CMDB is about the ingredients or as ITIL says people, process, products and providers. A CMDB implementation requires organizational buy-in, a proven methodology for implementation and best-of-breed technology.

Actually, starting a CMDB does not require very sophisticated technology. It is usually a better idea to begin with a very simple tool (example: excel spread sheet) at first and then as the process matures, the organization is in a better position to decide which tool meets the process requirements. The benefit to this approach: time and cost savings associated with initial tool selection, set up and population.

Additionally, careful process planning and design can be useful in helping to avoid populating the CMDB with useless information.

Remember, process first, then people. Tools last. In the the words of HP's Lindsay Parker, A Fool with a Tool is Still a Fool


2. It’s what you do with the data

Don’t spend all your time defining the CMDB instead give it a purpose. It’s easy to fall into the habit of parsing words and arguing semantics. However, the point of a CMDB is to improve service quality. If IT folks can clearly describe what it intends to do with the data in the CMDB, then they have gone a long way to defining its purpose and understanding what is actionable information as opposed to merely data. This purpose will guide the thinking and logic throughout the projects, for example, what should, or should not be included in the CMDB.

Although correct, I would add that what should or should not be included in the CMDB will likely evolve over time as all processes mature.

4. Don't get hung up on database

A principle reason the CMDB disguises itself on the pages of an asset management RFP is because it’s a high-profile buzzword that’s easier to justify. However asset management is more akin to an inventory audit, while a CMDB is about relationships among physical or logical items that comprise the service IT delivers to the business. More importantly, it’s about the impact a break in those relationships has upon users.

OK, yes but it's more about providing context for assessing the impact of Change Management in order to prevent those "breaks" associated with changes.

5. Clearly define an end-state
Just like a purpose is required to set the vision for the project, a CMDB also needs to have a clearly defined end-state. An end-state can serve as a trigger point to move a project into the next phase of implementation, for example once you’ve successfully modeled your SAP application in the CMDB, you move on to other critical applications such as CRM or order processing. Both the CMDB designer and user need to be included in building consensus around this point and it boils down to answering one simple question: how will you measure success?

First, the is technically no "end state" for the CMDB. It is an ever evolving repository for IT Service Management related data.

Secondly, since the CMDB is solely a tool for providing information to management and other processes about IT Services, the measure for success should be determined by whether it provides accurate, timely and useful data that is required by other processes (namely, Incident, Problem and Change Management, to start.)

The data/information requirements are likely to change over time as these processes mature and others are brought on-line.

6. Allocate enough resources

It’s an understatement to say that projects need executive sponsorship and successful CMDBs need a CIO-level sponsor. A committed executive level sponsor can ensure the project is properly staffed with the right resources. This does not mean you need your CMDB vendor to bus in an army of consultants, but on the other hand, the chances of success diminish if the project is assigned to an IT operations staff that also has a day-job, like keeping the lights on.

Also, allocate the Right resources!

7. Just enough CMDB
Forrester Research advocates a methodology called “just enough CMDB.” This can be accomplished by focusing on a critical service, a given domain or even a line of business. Take a top down approach and avoid trying to model every service or application in your enterprise. Choose carefully because early success will help garner the support and acceptance required to roll the CMDB project to other areas.

Make sure that the "just enough" approach also includes enough information necessary for management to base their decisions on. Not all information is good information.

9. Don’t let “perfect” get in the way of “good”
ITIL tells us that change management process is important for continuous improvement. For example, if you find a process is producing suspect data, identify that area as problem and come up with a plan for correcting it. However, keep an eye on the big picture: a service approach to IT management that delivers higher quality to the business. Don’t spend 80%of your time fixing 20% of the problems.

Data integrity is the number one rule of a "successful" CMDB. Suspect data does not contribute to the bigger picture of quality IT service. If you can't trust it, you can't manage or control any of the other processes that depend on this data.

10. Don’t wait to get started

That technology will continue to change and evolve is a maxim, but not a good reason to delay a CMDB project. Most large organizations have enough raw materials—some combination of a service desk, enterprise monitoring, asset management, or discovery—to begin building a CMDB today. With these tools installed, there are enough data elements to begin relating the data into the constructs of service. By virtue of having these tools in place, IT also has some degree of process. Through the course of integrating these pieces, IT organizations will continue to enhance the discipline and rigor to their change and configuration process.

11. Beware of specious advice given by inexperienced vendors and consultants looking to sell you products or services you don't need.

Michele Hudnall is currently the director of service management for BSM vendor Managed Objects.

To read Ms Hudnall's article in it's entirety, visit: ITSMWatch

No comments: