You don’t want a CMDB, you want a CMS

The CMDB—Configuration Management Database—is fast becoming fashionable these days. The idea seems to be that if your IT environment is in chaos—if nobody is sure of exactly what IT you have, how it is configured or even where (or on what) it is running (that is, if you have limited configuration management)—you can buy a database (the CMDB) which automatically discovers what you are running and neatly documents it through “automatic discovery”. Hey presto, without changing your culture and practices, everything is suddenly Wonderful!

Well, sorry, it isn’t like that. Yes, you can collect information about what you are running with suitable software “agents” but how do you know it is complete? If we told you that some key systems were not attached to the network (and, therefore, not “discovered”) how would you check this? You have to do one manual survey, at least, and correlate what you find with any automatic discovery. And there’s another problem with automated discovery—it often doesn’t really delete anything, because if something doesn’t seem to be really out there, its host machine might just be switched off, so your CMDB grows without limit (which implies expensive management).

But, after some mucking about, you can come up with a huge CMDB, full of data, using automated discovery. Now, what do you do with it all? Well, do you know what it all means? Well, no, because it was collected by a robot and just called by whatever string, if any, was in what looked like a “name field” or something. If you’ve any sense, if you’re configuring anything important, you’ll go back to the spreadsheet or text file you’ve always used and which you understand fully (and which you’re sure is accurate). And the CMDB becomes a white elephant sinking under the weight of its unused, and increasingly out-of-date data. This isn’t a criticism of CMDB products or vendors, or even the CMDB concept, by the way; it’s really an “implementation issue” for the organisation.

In reality, a “configuration management system” (CMS) is what an organisation really wants, before it tries to build a CMDB (eventually it will need a CMDB). A CMS isn’t about technology, its about cultural maturity and a culture of “good governance” around managing organisational assets and their usage. And when you get down to the detail, it’s about managing the organisation’s metadata—information about its infrastructure and how it runs. You need to identify “configuration items” (CIs) that are important to you (not just anything is actually worth managing), the relationships between CIs, and the CI attributes that it’s important that you know about (again, not everything about a CI is important). The aim is not to populate (eventually) the biggest CMDB you can but the smallest that will let you manage your infrastructure properly and cost-effectively. And, where possible, an organisation should manage its CIs centrally but physically store the data out where it is being used (possibly in the text files or spreadsheets you’re already using), in a “federated CMDB”.

But we’re not interested in building a CMDB for now, we’re interested in the culture necessary for implementing, and using an effective CMS. Rochade metadata repository technology. This helps manage the organisational metadata around the CMS and can federate ASG’s own CMDB or other vendors CMDBs (or even in-house spreadsheets and vendor configuration files) into an ITIL v3 compliant “federated CMDB”. However, it seems to us that ASG’s key message in the configuration management space is its 4 level maturity model around the CMS; and the importance of metadata management to the CMS generally.

Oitzman visualises a journey, from Level 1 (Reactive) configuration management, where point solutions are deployed as and when needed; through Level 2 (Normalised), where point solutions are integrated and key metrics for “IT health” are provided to management; and Level 3 (Managed), where the complex relationships between IT assets are managed in the context of their impact on business services; culminating in Level 5 (Optimised), where services are proactively optimised for the delivery of business outcomes.

Each level corresponds to a level of general maturity in the organisation and ASG promises to provide both a solution that is appropriate to the level an organisation is now at and support for the journey to a higher level – if this will bring business benefit. At Level 2, which is where most organisations are today, ASG concentrates on delivery of management information through dashboards which bring together different sources. Oitzman thinks that a CMDB proper (as described in ITIL v3) is only really viable at Level 3 and higher. Attempting to implement a CMDB before the organisation is ready for it risks, at best, waste; at worst, it risks failure and a devaluing of the whole concept of configuration management.

At level 4 things start to get interesting and the CMDB integrates with all the other metadata repositories in the organisation—with the corporate data model, Enterprise Architecture models and so on. Oitzman points out that ASG already has a customer using Rochade for Enterprise Architecture-style business glossaries. One of the key messages coming in with ITIL v3 is that configuration management no longer exists in a silo; it is a vital part of IT governance generally and must relate to holistic business outcomes.

ASG has plenty of case studies on its web site if you want to explore its approach but it isn’t the only supplier of CMDB solutions of course. However, the important thing to remember, before you start looking at technologies and vendors, is to take a look at your own organisation and its maturity. What level of configuration management are you capable of, and what “business outcome” are you hoping to achieve with it?