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.
Nice piece Ryan. First hing I always ask every client / potential client is: "So, why do you want to do Config Mgmt?". Based on their answer, I usually have a good idea of their chances of success. There are many times where I advise them to not do it simply because Config Mgmt really isn't what they want and/or want to invest the resources into. Many times they simply want basic inventory lists and possibly minor aspects of relationships but don't want to or don't have intentions of putting in place all the Config Mgmt governance that is required. I prefer they don't call it Config Mgmt so as to not further harm the term.