Even as I post this, I am wondering what will emerge from
Pandora’s box…
A comment that I received in a recent post was why I
didn’t write more about the CMDB, or configuration management database.
Without a valid answer I replied back to the person and
asked if there was something specific that they wanted to see. They wanted to
know “should I or shouldn’t I implement a CMDB?”
In my experience I have seen this activity received with
groans, excitement and confusion. In many cases all of these feelings have been
exhibited during the course of the team discussion of “should we or not?”
The trouble is more often than not the reason that this
even comes up is that through a tool implementation there is a component of
service or infrastructure which is mapped against CI’s (Configuration Items)
and this needs to be addressed in one way or another.
The problem with looking at this as an output from a tool
is that there is little consideration on how this process or activity will be managed
by the people in the organization. Remember the people; they are important in
making this work. Far too often the reason that this process doesn’t work well
(or at all) is that we only looked at it as a means to an end from a tool
perspective instead of the perspective of people, process and technology
If I could offer some suggestions I would take it back it
the beginning and look at the scope of what we are going to manage in our CMDB.
No two organizations are going to look at this the same so I won’t tell you
that there is a silver bullet on this one. In some cases you might want to look
at your critical services at the beginning. Whatever you choose remember that
keeping it simple will allow you to successfully manage this in the beginning
which will produce some check in the ‘win’ column. If you attempt to boil the
ocean it will likely work in your favor.
With a scope established you should be able to tie this
in with your change management process. Keep in mind that like your change
process there are activities in configuration management that need to be
managed by people to a certain degree. Have some way to regularly review the
CI’s for accuracy. This will not only allow you to see where they may be issues
in the configuration management process but also if the inputs and output to
this are also having challenges.
I can already hear you. “our tool does this
automatically, so we don’t have to worry” while to a degree this may be true,
trouble more often enough is that the tool will automate what we tell it to do
and if we don’t fully understand what it is meant to do in the first place
(process and people) we wont tell it the right actions to take. Which is why
performing regular audits of your data is important to continually improve.
To summarize, think with the end in mind. Decide what you
want to get out of the CMBD in the initial stages. Keep the scope small and
don’t let the scope creep. Ensure that this process is tied into other service
management processes so that where it applies the usage and value can be
recognized acrros various areas within IT. Lastly, report on the success that
you get as well as noting the issues and making corrections.
While a CMDB can be a daunting task, being pragmatic with
how you look at this will ensure that you can achieve your goals.
Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn
If you like
these articles please take a few minutes to share on social media or comment
Labels: CMDB, CMS, Configuration Management, ITIL, ITSM, SACM