CMDB is like a linked digital phonebook, and just as pointless for most

In the old days a phonebook was a list of names and numbers, like an asset database.

Now we have numbers on phones, with people search. Say I want to ring Gary at Safeness. I don't have a number for him but I know his company, and for others at that company I have the switchboard number. Wouldn't it be cool if people were linked to a company entity and we recorded the company numbers once for that entity so it could be found for everyone in that company?

Now we have the analogous equivalent of a CMDB (or a normalised database for the old farts amongst us).

So what percentage of us would get a productivity return from adding and maintaining those links between people and companies in our digital phonebooks, especially with companies spanning countries and multiple offices? Imagine yourself doing it. As compared to just working it out in our head on the rare occasions when we need to walk the relationships to find a number. And as compared to those of you who do it because they get off on being so organised and technical. I'm betting less than 5% of you - most of you would be sales people and headhunters - could show a real benefit: the Five Percent Club. The rest who claim a benefit are just rationalising your own neuroses (there goes another thousand readers).

Now, those anal folk who like maintaining pretty complexity for the sake of it can do so at their own expense on their own phone book. They don't have to show ROI beyond their own satisfaction. Not so a CMDB (in properly managed companies).

For most of us, a complex interlinked phone book isn't worth the effort. A simple list will suffice. So it is with configuration management: an asset database will do.


CMDB again?

Dear Skeptic, I think you are running out of subject... ;-)

I'll keep finding new ways

I'll keep finding new ways to get the message across until people get it.

I assure you I'm not running out. I have 90 ideas for posts - I just counted.



The CMDB conversation always intrigues me. CMDBs are very easy to design and maintain, if done correctly. However, in my experience, they rarely are.

In my experience, designers of CMDBs typically make the following mistakes or oversights...

  • They overcomplicate the CMDB data model, trying to design dedicated tables for each and every Configuration Item Type. This rarely, if ever, scales. Fundamentally, the best CMDB designs use Semantic Data Models that only have four (4) key tables: 1) Nodes, 2) Node Types, 3) Relationships, and 4) Relationships Types. (There are other supporting tables but not many.) This model scales to handle any and all Nodes and any and all Relationships. In truth, there are many different Configuration Item Types and trying to design dedicated tables for each and every type simply does not scale. For those that are not familiar with such Semantic Models, this type of solution is often referred to as a "Relationship Management" solution or an "Interaction Management" solution.
  • They set the scope of CMDBs to be too small, often leaving out not only other areas of IT but also their Businesses, which is an instant recipe for failure. The scope of a successful CMDB should always be the entire enterprise, Business and IT combined, and not just some small area of the enterprise, like Hardware Infrastructure. People who are experienced in good CMDB design understand that Business Configuration Management is even more important than IT Configuration Management and take all Configuration Management Types into account to create a truly scalable and useful solution.
  • They rely on highly Manual Processes to collect and maintain data in the CMDB, not understanding how to appropriately automate the harvesting of the Nodes and Relationships that make up a useful CMDB. If most of the data in your CMDB relies on mostly manual effort to enter and maintain the data, you're effort is probably dead in the water, before it starts.
  • They don't understand that Nodes and Relationships exist all over the enterprise can be easily harvested from different Sources of Record or Sources of Truth, with very little effort, to provide higher levels of value. To one of the key points of the original article, the homogeneous inventories of Configuration Item Types are often extremely powerful and do not exist (nor are they intended to exist) in the CMDB. Designers often make the mistake of trying to put and maintain such data into the CMDB, where it really does not belong.
  • They use the wrong resources to design CMDBs. Far too often, Infrastructure resources are trying to design, deliver and maintain CMDBs. More often than not, such resources lack the experience and required skills required to design advanced, modern, highly capable, and truly scalable solutions that can meet the needs of the broader enterprise in an efficient and cost effective manner.
  • They design and deliver solutions without their Business' and IT's broader consent and involvement, yielding solutions that often don't meet the needs of others even though they push their solutions on others.
  • They forget or ignore that the most important relationships to capture and manage are, most often, those that are further up the value and SDLC chain and which are closer to the Business and further away from Infrastructure Operations.

In short, linear and homogeneous inventories of different Assets are a great start for managing oneself. However, as an enterprise matures, it becomes the inter-relationships between the items within such homogeneous inventories and those across heterogeneous ones that become important for faster reaction times and more proactive and strategic decision making. Eventually, all enterprises care about how people and things are connected together because such knowledge is power. This is why enterprises go to great lengths to implement things like CRM and Interaction Management solutions. However, you can't design, deliver and maintain a solution that caters to all forms of Configuration Management and all Configuration Item Types by using traditional modeling concepts. The only truly effective way to conquer this mountain is to use Semantic Data Modeling, which abstracts things into simple Nodes and Relationships. It's only when you get to such simpler models that you leverage very powerful visualization tools like to be layered over the model and the data and get to powerful decision visualizations like many of those at Visual Complexity.

So, while I agree that an enterprise must start with managing simple homogeneous inventories, like those in Asset Databases, such inventories quickly become inadequate when you need to understand mappings between constructs. A huge example of such a situation is when trying to get into understanding Total Cost of Ownership (TCO) and Chargeback Models. The minute you or your enterprise decide to go down such a path, knowing and understanding the relationships or mappings between entities, such as organizations, applications, and hardware devices, will become critical. At some point, you'll have to face the need for such mappings.

Anyhow, I hope this adds value.

My Best,

Frank Guerino, Chairman
The International Foundation for Information Technology (IF4IT)

when and how

Frank, you dont change my mind about when I'd attempt CMDB but you sure made me think about how.

When to Build a CMDB


As for when to build a CMDB... My vote is that enterprises "never" build a CMDB.

I believe enterprises should wait until they can't handle managing relationships between things in simple spreadsheets or MS Access Databases and then evaluating the path of implementing a true "Relationship Management" (i.e. "Interaction Management") solution, with the intent to use it to manage all Nodes and Relationships between such Nodes (and not just for infrastructure) in a Semantically indexed manner.

I believe that spreadsheets, MS Access Databases, and even Asset Tracking systems (for Infrastructure pieces of the equation only) work. However, if you don't have a vision, a plan and the wherewithal to solve this problem for areas of the business that go beyond applications and infrastructure, then I recommend "never" going down the CMDB path.

There are few things more disheartening than watching Infrastructure and Support Operations People struggle and sweat as they try and justify the extremely expensive costs and complex solutions needed to support the implementation of a CMDB that rarely, if ever, comes with a real ROI, a real revenue enabler, or ever solves real business problems for other areas of the Business and for other areas of IT.

Again, I qualify the above as my opinions.

My Best,


Frank Guerino, Chairman
The International Foundation for Information Technology (IF4IT)

I suggest to start with an

I suggest to start with an asset database, master its management and then look at the possible benefits for a CMDB for your particular situation.

When CMDB is mentioned I get to hear many generic benefits, and for many companies (special smaller/medium sized ones) these benefits you would realize in situations you face once every few years and even then you probably will make the same decisions by consulting your teams instead of the CMDB.

I wonder how ITIL can claim that CMDB is a proven best practice if it seems that there are very few real success stories. It seems people are more struggling with it instead of benefiting from it.

Osama S.

generic benefits

Osama you are singing my song! Thank-you, it's lonely being a CMDB skeptic.

Those generic benefits are often benefits of asset management anyway and do not require CMDB relationships.

I think your analogy falls

I think your analogy falls apart in the details. There is no doubt that a CMDB is complex and can be difficult, but if done correctly [that may be a big 'if' for many people] the difficulties can be mitigated through process.

Using your example, in an enterprise you wouldn't have an individual checking all the phone records on a regular basis, you would have processes around when someone is hired, when someone moves locations in the company, and when someone is terminated. Those processes help the flow of data so that it is reasonable and manageable. Ideally, you would get to a point where it might even be automated where the termination hits an integration point with the PBX/VOIP to automatically free-up the extension; similarly, on a new-hire that integration requisitions an available line.

Now extrapolate that to CMDB, yes if you had one person trying to manually maintain all of CI/Assets/Relationships on their own and for their own charter it would be impossible. However, if you have an adopted process where new Assets are entered into a system, a change management process that identifies updated relationships, and competent discovery tools for feeding in the relationships it becomes a lot more manageable.

manual data entry

Process and automation can contribute. But relative to the great different in scale between a phonebooth and a CMDB, I think it is negligible. To extend the analogy back at ya, there is no automated system that will capture the fact that Safeness Corp has one phone number for most staff but Gary works in the datacenter which has an unlisted switchboard number. There are all these complexities that can only be captured and maintained manually

Syndicate content