The Beetil Blog
Blog » The CMDB: Start small and keep control
It’s another chicken and egg situation. How can I do service management (incidents, problems, change, release, etc.) without a configuration management database (CMDB) to support and underpin it? Surely I need to implement it all in a big bang for it to work properly?
Well, no. There’s no point in having a full-blown CMDB unless you’ve got the processes and controls in place to ensure it is kept accurate. We’ve all seen the situation where someone starts gathering and maintaining configuration information with good intentions (e.g. servers and other hardware in a LAN), maybe in a spreadsheet, home-grown database, or even a proper ITSM tool. It all goes well for awhile, and it’s a valuable source of information. But then people don’t maintain and update the information, either due to lack of processes, or controls, or people just can’t be bothered, or they don’t even know the information is maintained. In the end you can no longer rely on that configuration information for accuracy and reliability, and while it might still be useful, you can no longer trust it, and you have to go and verify the information yourself.
If you start your ITSM implementation with Incident Management (which is typically a natural place to start, since you’re already managing defects right?) then you’ll pretty much have some sort of CMDB by default. Incidents are a type of documentation, and each Incident is a configuration item. You’ve got control of the Incident documentation and you can trust what’s there. Expand that by relating some Incidents together, maybe add in some change control and you’re well on your way.
The CMDB is only what you need it to be. It doesn’t need to be something daunting that’s impossible to implement. Start small, and only record what you can control – therefore ensuring it is kept accurate and up-to-date.
You only should be recording information and relationships that are important to the IT services of your business. Don’t record everything. As your maturity grows, then add more configuration items and relationships – but only if they’re important. Get in the mindset of thinking “if I want to update this, will it make sense to raise a Change to get the information updated?”. If the answer is “don’t be ridiculous!” then perhaps you shouldn’t be storing the information in the CMDB to start with.
Get control, and keep it under control via Change Management. Let it get out of control and the information and relationships are no longer dependable. Users won’t trust the data and will find other ways of recording what they need to record – further undermining the data you’ve carefully gathered.
Beetil started off with a pretty simple CMDB – in fact it wasn’t even referred to as such, even though the configuration items and relationships are there, and under control. Managing our services effectively was our first priority, and we didn’t need a full-blown CMDB to do that.
Coming really soon though to Beetil is a formal Config module – with of course a big focus on usability and ensuring the information and relationships are useful firstly for impact analysis, and later, asset management. We’re pretty excited about what we’ve got under the covers, and we hope you will be too once you get your hands on it!
Tags: Change Management, CMDB, configuration item, relationships, service management