Implementing a Configuration Management DataBase (CMDB) is not a single action, but a gradual process that may take months or years to establish. Even after that, it is subject to change and improve like any area of your IT operations, especially as your business changes around you.
In many organisations there can be similar pitfalls when tying to create an effective CMDB, and the best way to avoid them is to be aware of them, and plan around them. Here are my top three:
1) Ownership and dispersed authority – the information that must be captured and held within a CMDB typically extends into the domains of many teams. Although one of these teams has overall responsibility for the “whole”, there are people in other teams who truly hold the knowledge and are aware when fundamentals change – it can be difficult to pin the responsibility on those other people for keeping their part of the database up to date.
2) Inequality of investment and return – by its nature, a CMDB is unfair to its various clients. The people who get the most out of the system do not have to put much effort in. Yet the people who have to spend most time putting the information in are rarely interested in getting anything out of it.
3) The value is in relationships, not data – many people see “automatic data feeds” as the nirvana for maintaining a good CMDB. Yes, it’s true that you can get rafts of detailed configuration information automatically imported in the blink of an LED, but that is only half the story. What SMS, Insight Manager and CiscoWorks can’t give you on a drip-feed is the richer knowledge about how systems interconnect and inter-depend. That’s stuff that IT folks typically carry around in their heads (or store on complex and un-referenced Visio diagrams that are never collated into a single repository). These system relationships are what let you analyse your ability to resist points of failure, to predict the likely impact of planned change, and to ensure that you really understand exactly how your customers make money using the iron you manage. If you manage Change, Configuration and Release, you are at the best point to keep track of such interdependencies over time, but don’t expect the machines to do all the hard work for you just yet.