Troy's Blog

CMDB – Spruce Goose, Death Star Or Answer To World Peace?

Of all the processes described by ITIL none receives more attention and media hype than Configuration Management. For some, the Configuration Management Database (CMDB) represents the impossible juggernaut akin to the famous Spruce Goose. For others, the CMDB represents the Death Star, the ultimate weapon and tool of a dark and insidious master of a strange force bent on strangling the creative energy out of free spirited IT department. While for others the CMDB represents the ultimate panacea for all IT woes and the answer to world peace.

In my view, the CMDB represents a much more mundane but necessary concept that underpins the most basic issues of running a successful IT operation: You Cannot Manage What You Do Not Understand. I know I have said this many times on this blog but it is worth repeating again.

Most organizations deliver integrated services but manage IT as vertical domains at a device and component level as if these components somehow existed in mythical isolation. Don’t you find it interesting that during the project phase of the service lifecycle the entire service/system architecture is carefully modeled, diagramed and documented with painstaking accuracy at an application, infrastructure, and data level? During the project phases of build, test and transition these models are carefully managed and updated. (This is where the impressive Visio and architecture diagrams are created and posted on the walls of the IT department.)

However, the moment the new Check Processing, Deep Water Drilling or Mobile Messaging service goes into production we relegate these wonderful static multi dimensional diagrams to the status of impressive artwork and we return to the business of managing and optimizing each domain and component in isolation. No one bothers to maintain the documentation about the critical relationships of the complex systems and services in an accurate fashion above the component level. 

I continually see claims on the internet about the CMDB such as:

• It would cost way too much money and we could never justify the business case
• It would be far too difficult
• It would be much too complex
• It could never be in one single database (who said it should be)
• We would never have the political ability to achieve it

And yet IT builds and manages these complex federated systems for the business all the time. You would expect the bank to know all of the products and accounts you currently hold with them on a real-time basis. You trust that Boeing or Lockheed have a detailed relational database for each airplane down to the part level.

In most cases the IT departments that struggle with these arguments may not be ready to implement a Configuration Management process which is much more than implementing an auto discovery tool. It is my view in that until an IT organization understands what a service is and wishes to manage that service as such then there will be no will power or urgency to implement a CMDB. If the goal of the IT organization is to get a better handle on where individual technology components are, who has them and maintain basic information about their current state then leave your Inventory / Asset Management databases where they are, you don’t need a CMDB!

However, if you realize that a basic accountability for a service organization is to be able to articulate how IT components enable or disable a business outcome then you cannot hope to achieve this without an integrated CMDB which enables you to model how components relate to each other, how they in turn build systems which support IT services that are leveraged by business processes and services.

This topic I address further in the following posts:

• Not Ready for The CMDB
• CMDB as a Resort Condominium
• ITIL Implementation Roadmap (Configuration Management)
• The Federated CMDB Part 1

In summary, consider that the process of Configuration Management and your CMDB strategy is a difficult but necessary element of being a Service Organization. It is without a doubt a challenge to achieve but I would submit that the most difficult part of this challenge is based on culture and organizational change issues rather than technology constraints as some would have you believe. The implementation of Configuration Management is always done in multiple phases according to reasonable scope decisions and the update of this database through either manual or automated means is more akin to brushing your teeth than the uptake of a new and exciting hobby.

Configuration Management is not Rocket Science, the Spruce Goose, the Death Star or the answer to World Peace but it does represent a basic building block to support the move from a technology to a service centric IT Management approach.

Troy’s thoughts, what are yours?

“The Galaxy is a rapidly changing place.  There is, frankly, so much of it, every bit of which is continually on the move, continually changing. A bit of a nightmare, you might think, for a scrupulous and conscientious editor diligently striving to keep this massively detailed and complex electronic tome abreast of all the changing circumstances and conditions that the Galaxy throws up every minute of every hour of every day, and you would be wrong. Where you would be wrong would be in failing to realize that the editor, like all the editors of the Guide has ever had, has no real grasp of the meanings of the words “scrupulous”, “conscientious” or “diligent”, and tends to get his nightmares through a straw. ~ Douglas Adams “Song Long & Thanks for All the Fish”