CMDB - What You Need To Know

"Take care of the luxuries, and the necessities will take care of themselves." -- Dorothy Parker, an American writer and poet

Much is said about Configuration Management Database in IT information circles and literature. More or less, everyone agrees that CMDB is some kind of hub of all ITSM processes, but opinions differ on the scale of it's importance. From "nice to have because ITIL says so" to "first thing you have to do, without it nothing makes sense". Well, I am with this second extreme bunch.

ITIL is full of details and descriptions, but without a direct prescription how things should be done. Data model, relations, APIs? I don't blame them, technology is moving fast and things that will be possible tomorrow are imaginable by fewer and fewer people, so this vagueness in ITIL is given with a good measure of direct guidelines and freedom of interpolation. After all, CMDB became a kind of religion, even better, a Loch Ness monster parallel story: everyone is talking about it, and a very few people witnessed it. To some extent, one can agree with IT Skeptic that it can't be done by definition of Configuration Management goal:

"account for all the IT assets and configurations within the organization and its services"

ALL IT assets? What have you been smoking lately? There is a sniff of inconsistency here, since ITIL also talks about setting the level of CI control. So, what is it, ALL or SOME assets? Mouse, keyboard and web camera, or my precious USB mug heater, are they assets? Of course, we can give a better eye to this def, and read it backwards. ITIL is business oriented, and makes an (however large, still feeble) attempt to put a CUSTOMER in focus of poor over-worked sex depraved IT people. Not an easy task.

ITIL focuses on introducing order in IT, as a function of serving BUSINESS. ITIL mentions ALL assets, but in this context ALL means "as much as you irresponsible people can manage, and focus to those that are important for the business services to the ladies in the Accounting dept, or whatever dept. you signed your SLA with, without real understanding what SLA really means."

Every IT organization starting to deal with services quickly learns that it is not about Service Desk, Incident or Problem Management. It is WHAT you have, WHERE is it, WHO is responsible, HOW it works, WHEN is it going to die, and in WHICH way it supports our business. And approximately in that order. To every sensible IT guy it is obvious that CMDB can't be done, but that's something we HAVE to try to do. 30% is infinitely better then nothing, you can live with 70% and prosper for a long time. Take care of the luxuries first, cover the assets most important for your services, other CIs will fall into place with time and effort. A large US pharmaceutical company that implemented a new NW discovery tool found out that they have some 10.000 network assets more then they knew about. Have they survived somehow before that discovery? Of course. Have they found valuable resources and knowledge about their infrastructure that will help them be more agile and produce better decisions in the future? You bet.

Another thing. ITIL is IT oriented, and it covers basic best practices of IT organizations. Implementing ITIL is a first step in introducing organized structure to IT from bottom end, base of the pyramid. Above it, on the road to better understanding of business, stand methodologies which are not exclusively IT oriented, and they serve to connect IT to business even more, like BSC, SOX, COBIT, various project, work and performance management technologies. ITIL's task is to introduce first enablers of customer satisfaction. ITIL asks from IT to first form knowledge of their own business (CMDB) and then agree with Business on the best way to support it (SLM).

Views on CMDB and CI relations

I will discuss SLM and SLA later, and importance of Service Catalogs. For now, let me point out the evolution of structured thought: CMDB enables all 10 ITSM processes. It contains crucial information on CIs. Out of that info we start when we define basic components and IT services. Only then we are able to introduce the IT to Business and really listen to it's requests. That's why the Service Catalog resides in CMDB, or ON the CMDB, because it comes from the opposite direction. CMDB thinks bottom-up, and Service is defined top-to-bottom. So it is a crucial link from CEO to your network switch, from IT to Business. That's why in implementing ITIL, a common sense is to start with Service Desk, Configuration and Incident Management, and Service Level Management in parallel.

A number of possible problems can occur in CMDB life, aside from the obvious and mentioned in ITIL Blue Book. Integration with other ITSM tools is a very important one. I have seen some IT companies implement a stand-alone CMDB. Not sure what is the purpose of that. Also, CMDB deals with the data that naturally or historically reside in other applications, like ERP, HRM, Document Management, Asset Management... There is always a grey area or overlapping as some data wants to live in more then one place.

Main rule is: if there is a legal, financial, technical or strong cultural reason for a type of data to be referent in other systems, then periodical mirroring of data is performed (hourly or daily) to CMDB. Some data will be synchronized inbound to CMDB, (ERP people are particularly sensitive to their data) and some will be synchronized both ways, like contact data (mail, phone etc.) to and from Human Resources Management application. Some data will eventually be synched outbound, to Asset Management application for example.

A lot of it can go wrong in CMDB implementation. But, based on all the above and some more, having a CMDB conforming to ITIL recommendations, common sense and your business needs is a one of the hardest and most rewarded projects that an IT can perform.