In the 5 part series of posts to come, I will use the term CMS versus CMDB when describing what needs to be done. Where I use CMDB, it will typically be when describing previous efforts I have been directly involved in or to maintain a historical context. The fundamental and architectural approach which Glenn O’Donnell and I recommend in our book “The CMDB Imperative” is that of a Configuration Management System (CMS) not a Configuration Management Database (CMDB). So, you may be asking yourself, as someone recently asked me, Why is it that you called your book ‘The CMDB Imperative’ instead of ‘The CMS Imperative’ when you and Glenn are such strong proponents of a CMS?

The best way to answer this question is by quoting our book:

“We must be clear about one important detail regarding the CMDB phenomenon. ITIL practitioners hate the term CMDB. We hate it because it connotes an incorrect perception about how the CMDB should be built and used. Of course, this begs the question of why we chose to write a book about something we hate. We love the concept, we just hate the name. The concept is profound and is central to any IT organization striving for operational discipline. Every IT organization needs a CMDB, and most have probably built several in the past under different names, but there is enormous confusion around the concept and much of this confusion stems from the name itself. We wrote a “CMDB Book” to help clarify this confusion and in future editions, hope to reference CMDB only in a historical context.”

‘The CMDB Imperative: How to realize the dream and avoid the nightmares’ Page 21

We believe that many foundational elements of a CMS are implementable today even if the system as a whole might be a bit of a challenge with the available vendor tools. Some argue that the CMS is a panacea and not only unrealistic but also unnecessary because its’ functions can be accomplished solely through process efficiencies and human resources.

Although those are two components that need to be addressed, I obviously disagree with exclusivity of that mentality and believe that it is hindering progress. Let’s get past the “it can’t be done mentality” and start offering real solutions versus simply more hurdles.  Anyone who has worked for a large organization realizes that there are inherent complexities, volumes of data and changes that come with being a large firm and the only way to approach a Configuration Management solution is with a federated model like a CMS. If a CMDB approach was the solution, wouldn’t we have we seen more success stories?

The bottom line is that the CMDB, as it was originally described in ITIL V2 and how people thought it needed to be implemented, must go and the CMS supported by Management Data Repositories (MDRs) must surface. The five part series of blog postings will seek to dispel some myths and clarify some confusion but most importantly, I hope that it will provide insight and encouragement for all of you to push forward with your Configuration Management initiatives.

Part 1 of the CMDB Blog Posting Series will be published in one or two days once I do some final editing.