CMDB Design 101

The Good Ol' Days

We all recall our heady days, before we knew that we needed a CMDB. Here's a little story to help remember that time. One day it happens that each time you start outlook on your laptop, you get an error and the application crashes. So you call the help desk:

[helpdesk] "Hello Mister Horrie - how can I help you?"

[you] "Hi, yeah, my laptop can't bring up outlook today. I kind of need it, so I'm hoping we can get this going quickly."

[helpdesk] "OK. Let me see, so this is the machine named tharris-lap-02 right?"

[you] "Ummmm - no, not really. tharris-lap-02 has been gone for a long time. This machine is tharris-lap-04."

[helpdesk] "Sorry - what do you mean by gone? I only have tharris-lap-02 listed for you."

You take a moment to reflect on the long and mostly happy life of tharris-lap-02. You remember the day that you presented it to your two year old son Bobby, and how happy Bobby was. At the time it was a 700 Mhz processor with 128M of RAM, and it blue-screened everytime you started microsoft word. So it was really only good for the scrap heap. You remember the happy pictures your wife took, of you working with the new tharris-lap-04 on the couch, while Bobby sat at your feet, banging on the keys of tharris-lap-02 with utter satisfaction. And then you remember a few months later, when Bobby had one of his first "big boy" cups of orange juice, and he carefully poored the whole cup into the keyboard of tharris-lap-02. He was feeding the machine breakfast evidently. The machine flickered through a series of interesting looking screenshots, as if its computational life was briefly passing before its monitor, and then it went dark one last time. Gone.

[you] "Well, its kind of decommissioned. Well, not officially I guess. But its gone. And I've had 04 for a long time now."

[helpdesk] "I see. Well here's what I need you to do for me. Go to the assets app off the corporate portal, and officially decommission tharris-lap-02, and then create the asset for tharris-lap-04 and assign it to yourself. Then call back and I can help you fix your machine. OK?"

Of course, anytime the helpdesk gives you a list of things you need to do for them, its a bad sign. But why didn't they know that tharris-lap-02 was long gone, and that tharris-lap-04 had been on their network for a few years? Because they lacked an accurate picture of their own IT environment. Therefore the users, and the IT staff, both had to eat the inefficiencies caused by that lack of knowledge.

The Good New Days

I'll now jump to some more detailed discussion of how to build a CMDB. If you're going to take away one aspect of CMDB design from this note, remember this - every bit of information in your CMDB is an investment, so invest wisely. I'll explain what I mean.

The CMDB is better than a simple database or spreadsheet, due to the added level of functionality that a mature CMDB provides. Specifically, it allows you to reconcile data from multiple data sources, it allows you to share that data with well integrated applications, and it allows you to pump data into the CMDB from external datasources with minimum fuss and hassle. Trust me, you want this level of functionality, and therefore it should be OK that you have to pay some processing for it. All these computational tasks are O(n) operations, meaning that their run times are roughly proportionally to the number of data elements being processed. Therefore more data takes more processing time, or it requires larger hardware to run, or in what ever form, it requires more IT investment.

Now back to the real world of an IT shop just starting to plan a CMDB deployment. Imagine this shop has a existing history of using automated discovery, likely called an IT Inventory application in this context. So this shop runs Inventory every day, and there are people who have staked their job on the fact that the results are detailed and accurate. Again, this data source does not have the extra CMDB functionality noted above, and so it is not a CMDB in itself, so it may be alot cheaper to generate a very big inventory dataset than to create a CMDB. But the folks who built this inventory datastore have come to love it like a child. They love every configuration item (CI), as a gleaming pearl that they pulled from an oyster themselves. No matter how seemingly insignificant a piece of data is, they wouldn't part with it.

The CMDB deployment planning starts, and the question comes up, just what CIs have real business value to us in the CMDB? The answer is obvious to the Inventory team - everything! Usually "everything" in this context means not only all hardware related CIs, but also all applications on every machine, and finally every patch of every software on every machine. Automated discovery (aka inventory) will routinely capture information like the fact that there are 23 device drivers on your server, and that some of these device drivers have up to 7 patches applied on them. Generally this information is useful for inventory as a way of tracking software compliance for certain profiles of users and their machines. But in the CMDB its questionable how valuable this information is, and if you really want to resource a system that can include all that info.

The dataset size for a given IT environment can vary up to 100X based on basic decisions on what you want to include in the CMDB. That's a huge range, and has nothing to do with what product you're using to implement such a CMDB. Imagine that you ask the IT manager in charge of the payroll application how many paychecks you're printing this week, and he says "Well boss, its a number between 1,000 and 100,000". This guy clearly doesn't know his job well. But that is the kind of range (100X) of dataset volume that a customer can effect by careful filtering (or lack of filtering) of CIs in his or her CMDB. Your CMDB might be between 1 million and 100 million CIs in size.

The Right Approach

Now I'll put a stake in the ground for best practices on such a deployement project. Start small, very small if need be, and consider growing later. This means the following: make sure every computer system (laptops, desktops, servers, loadbalancer and router) is represented with at least 10 or 20 CIs, and then add a minimum of critical software titles as needed. But ensure that the goal is to get something into production without big risks or large implementation overheads. Once its in production, you can start to get business value from the CMDB, and learn out to utilize this picture of your IT environment in your incident, problem, change and asset processes. When you need more detailed data you can access other datasources via federation. Then, overtime, you can have the occasional pow-wow where you say - here is another set of data, here is how much it would cost us to include it in the CMDB, and here is how much business value we think we'd get out of having it in there. But as a starting place - at least make sure that in the story above, tharris-lap-02 would disappear and tharris-lap-04 would appear - that's the obvious starting place. This is not just a BMC idea, but instead an industry standard best practice for ITIL and the CMDB. But of course, we like to believe that we thought of it first ;-)...

Happy holidays to all of you,

Tim