Potholes in your CMDB roadmap

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.


Sorting your cats into classes

Call me pedantic (you wouldn’t be the first), but I have found terms like category and class end up being used ambiguously, and interchangeably – and I do it sometimes, too! So I have decided to put a stop to this and define the way I think the terms should be used. And it all comes down to exlcusivity…

Class(-ify, -ification) – a given item can only be a member of a single class (unless it inherits from a super-class) and indeed it MUST be a member of a class.

Category(-ise, -isation) – a given item may concurrently be a member of multiple categories, or indeed of none.

So, the item’s position in the prime hierarchy or taxonomy, usually detemined by who owns it or who is responsible for it, indicates its class. Within the whole domain, this structure is generally relatively stable. It can change, just like organisations can restructure, but it takes time and effort and involves upheaval.

If you want to have alternative forms of grouping, like search tags, or secondary means of browsing items, you can create categories. Because they are optional, flexible, and can be multiple, there is more scope to refresh, restructure, add new structures and depreciate irrelevant ones.

“Each item must have a single class and may have multiple categories”

It seems so simple now. Maybe you already understood this definition – sorry if I’m stating the obvious. However, this reminds me of the day I learnt the difference between authentication and authorisation – the dark clouds of doubt just fell away. But then you should know by now that I’m a geek as well as a pedant 🙂