Central to IT Service Management is
the concept of a Configuration Management Database or CMDB. Throughout
my career I have been involved in dozens of service management/helpdesk
implementations and close to a dozen IT asset management
implementations. As the service management processes defined by ITIL
continue to be adopted as the de-facto standard in the US and around
the world, my company is being asked to help other companies develop a
CMDB. The ITIL process set, while becoming increasingly popular, is by
no means a new concept. However, I have yet to come across an
organization that can say they have an accurate CMDB. Why is something
so critical to the ITIL philosophy, so difficult to adopt? Furthermore,
is something so challenging worth the effort to implement? If so, why,
and how should you go about it?
I believe there are a couple of primary attributes of a CMDB that
make it very difficult to create and maintain. First, is the fact that
a CMDB has a very broad scope. By definition, a CMDB should contain
accurate information on every Configuration Item (CI) within the
organization. The definition of a CI can be rather broad in that a CI
can be any entity related to your IT Infrastructure against which
change should be managed. For each entity that your organization
defines as a CI there is a long list of attributes and relationships
that must be captured and maintained. Therefore, simply defining the
scope of a CMDB within your organization can be a massive effort.
Another huge challenge is the fact that CIs are typically owned and
managed by numerous different departments. Maintaining accurate
information on all these items, particularly the relationships,
requires significant coordination and cooperation between these
departments. Often, corporate management structures and cultures impede
this necessary cooperation. The ITIL processes seek to break down these
barriers, but doing so often requires significant organizational and
cultural changes that tend to occur slowly.
It is typical for IT organizations to believe they can overcome
these organizational and cultural challenges through the implementation
of additional technology. Technologists tend to understand technology
and thus are more comfortable tackling problems with technology than
through process. This is probably one of the biggest mistakes any
company can make, and yet it is repeated over and over throughout the
US corporate environment. While technologies are emerging that claim to
be able to automate the collection and maintenance of data for a CMDB,
processes cannot be ignored. This is evident by the fact that the
Configuration Management process, as defined by ITIL, has a direct link
to every other ITIL process.
At the beginning of this article I intended to answer the questions
of whether implementing a CMDB is worth it, and if so, why, and how to
go about it. If you?re not already asleep, you might agree with my
intent to get deeper into those questions in a follow-up blog. I will
say this on those topics however to fulfill the obligation set forth in
the first paragraph.
When considering whether to implement a CMDB review and consider the
benefits as defined by ITIL. Determine which of these benefits will
have the greatest impact and provide the greatest value to your
business. With business objectives clearly understood you?ll have the
direction you need to define the scope of your initial CMDB. This
involves defining your CIs, the important attributes to maintain, and
the critical relationships that must be maintained. Finally, focus on
the process for obtaining and managing this data and not technologies.
Technology should be sought to automate manual processes defined and
implemented where possible; technology should not drive the definition
of process.
—–