Home �   ITIL�  Index

The Wheel Evolved -- So Too Must Your CMDB/CMS, Part I

Good things take time, but there must be value along the way, writes ITSMWatch guest columnist Carlos Casanova of K2 Solutions Group.
Sep 23, 2010

Carlos Casanova

The wheel is believed to have been invented around 8,000 B.C. in Asia but the oldest wheel ever discovered dates back to around 3,500 B.C. from Mesopotamia. In the time since, the wheel has matured from a simple plank rolling over a log to a highly engineered and sophisticated mixture of molecular compounds that allow race cars to travel at spectacular speeds on earth or roll slowly over the surface of Mars. Whoever it was that invented the wheel could not possibly have foreseen how it would be used in the future nor the tremendous transformations that it might undergo over the years but their design has stood the test of time.

Their first implementation was likely to address the challenge of moving a heavy object across a field or hauling materials to another village. They had a simple goal in mind for this creation called a wheel; solve the problem at hand and advance the solution later to address future challenges. This same philosophy must be adopted when embarking on your CMDB/CMS initiative (hopefully it won’t take you as long to evolve your CMS as it did the wheel). The road is very straight forward: Build your CMS to address your immediate needs and employ continual service improvement techniques to mature it as necessary.

I’ve spoken to hundreds of people over the years about the CMDB/CMS. Most find it shocking when I tell them that if they can solve their configuration management challenges with spreadsheets and pads of paper they should go ahead and do it so they can start delivering value right away. For some reason, many people believe they must implement a highly complex enterprise solution even if the problem they are trying to solve doesn't call for one.

The most basic element that you should focus on when beginning a configuration management effort is a clear and concrete understanding of the problem that you are trying to solve. As part of that, you also need to assess whether your organization is at a stage where starting with a simple inventory control type of approach will deliver value or if you need to place controls around more complex changes in order to deliver value.

Solve the problem

Without a full understanding of where you stand or what will deliver value to your organization, you are very likely to fail because you may have solved the wrong problem or provided a solution to a problem that did not exist.

If we revisit the example of the different types of wheel from above, what do you think might have happened if the race car driver was provided with the wheel meant for the Mars Rover or vice-versa? Although each wheel is on its own an engineering marvel, both would have been catastrophic failures because they did not address the right need.

Now that you have a sense of the problem(s) you need to address, you need to find out what materials are available to you and what might possibly become available in the future. It is important to do a high-level assessment of this before you start designing and crafting your solution.

This is vital because you may design an elaborate and comprehensive CMDB/CMS only to find out that all of the data in the environment is unreliable and/or incomplete or that cultural resistance to change will prevent the implementation of the full process.

Designing a sophisticated solution from the beginning is not the problem and is in fact something I actually encourage because it provides great insight into what “might be” ( which should be used in your sales and marketing campaign for configuration management). However, you need make sure you to set the proper expectations of what can be built and delivered in the near term and don’t forget that data quality and availability is a key element in that decision.

A phrase I like to use is "garbage in, garbage out" when talking about federation, data aggregation and reconciliation. Everyone needs to understand that the implementation of a CMDB/CMS is only as good as its governing processes and the foundation of data that it leverages. Without either, it cannot present an accurate or comprehensive view of the environment.

In my next installment, I will discuss foundational data sources and how to work with them.

Carlos Casanova is the president and solutions architect for K2 Solutions Group and the co-author of The CMDB Imperative: How to realize the dream and avoid the nightmares. Mr. Casanova delivers executive and practitioner level professional services, training and technology solutions that support the delivery of IT service management and knowledge management initiatives. He is widely published, an editor and writer for the itSMF USA Newsletter, treasurer for the itSMF New England LIG and president of the itSMF USA Sustainable 360 SIG. Prior to K2 Solutions, Mr. Casanova was a senior enterprise architect with MetLife where he was the visionary and manager for the first CMDB deployment and subsequently helped design its second generation, enterprise-wide ITSM platform.

CMS, CMDB, ITIL, ITSM, K2 Solutions Group