No one needs a CMDB

… Did I just write that? But it’s true. No one needs a CMDB for itself, or a CMS, or an SKMS. Even an outsourced service provider whose client has written “must have a CMDB” into the contract doesn’t need the CMDB itself. Anything will do as a CMDB, to avoid contractual penalties. The client has no external standard to hold the provider to. So they write, or should write, more specific terms to give the desired control. And so should organisations trying to improve configuration management for business value rather than compliance.

What good, specific objectives or contract terms are there for a CMDB, or more accurately a configuration management improvement project?

Here’s one.

Poll around for definitions of a CMDB/CMS/etc. Among the answers, you’re bound to get things along the lines of “a central database for managing IT” or “the one source of the truth for ITSM processes” – and this concept is an important one. ITIL version 3, and many tool vendors, help out by recognising that this “central database” is not (can almost never be) a single database, but a collection of (“federated”) systems. Nevertheless, principles of Master Data Management still apply, and there needs to be some central management of what data exists where and which point is the master source.

By counter-example, consider an organisation with a good central database of CIs, which drives an auto-discovery system. Devices discovered but not in the CMDB are flagged for action. Devices not on the network can be flagged as “in stores”. The user department charge-back is calculated on number of devices in use (not in stores – obviously) – all good so far – but the guy who prepares the charge-back bills checks the auto-discovery system and charges for devices flagged as “in stores” but which were in fact active on the network. Logical – but no one else in IT knows this detail and lots of effort is wasted debating with user department heads why they are being billed for the wrong count of devices.

This example does not represent any one organisation – but it’s not fictitious.

In this case the billing person has created and managed his own data on what gets billed, and this data is not visible or auditable by the IT department as a whole. He gets his job done, and in fact gets a bonus for increasing IT department cost recovery. But configuration management has become weaker.

In another example (of not having a single source of ITSM data), consider a company with comprehensive registers of desktop and server hardware, and comprehensive records of software licences and internally-released software – but no correlation of which applications run on which servers. Again, this is not a fictitious case!

Analyst A gets on with her own mapping of applications to servers, because one of her projects demands it. She builds it in a spreadsheet based on weekly extracts from the server and software registers. Meanwhile, Specialist B is doing exactly the same thing, in a Microsoft Access database, correlating server element management system reports with software modules discovered on those servers. Both are working on the best tools they know. Both are doing the right thing according to their job objectives. But they are duplicating work, wasting a certain amount of effort – and by not communicating their results across the IT organisation, losing value that other teams could get.

Now, everyone needs to record their own data to get work done at some time or other. It’s possible that every ITSM tool out there started off as somebody’s private tool for doing something useful.

But, without stifling innovation or creating bureaucracy, what a configuration management project needs to do is set up the policy that all data records are known about and managed in the context of common goals. This doesn’t mean official registration of pilot or prototype efforts. It does mean official registration, and alignment of best master data sources, for all efforts that are then used as part of delivering IT services. Silo data should not be tolerated.

And to make it happen, some central role will be required – a Configuration Authority, perhaps. An ideal person to fill this role would be have some exposure to data modelling, and be good at communicating – selling, negotiating and facilitating.

I would even make the case that setting up such a policy and role is the first thing that a configuration management project should do – not mapping CI types, not going out and discovering data sources.

And not procuring, building or implementing a CMDB.