Our company has had trouble improving our security and performance in our IT environment. While researching ways to fix this, I came across this blog written by Bakman on the topic. He really hits the nail on the head. Today's CMDB is simply too shallow. I was wpmdering if any of you have come to the same conclusion as well. If you would like to read Bakman's argument on this topic here is the link it is pretty helpful.

This is true. This is a symptom of the fact that everyone tries to model CMDBs using tree based data structures. It becomes too costly and ineffective to appropriately address a very deep tree in a relational DB model. As a result, tree structures quickly break down, especially one you have a situation where you have two parents that have the same child or where a CI has a dependency on itself.

A far more appropriate way to handle this is through a graph based data model which, if done properly, opens up all types of new issues with the DB, as traditional relational data modeling is not intended to efficiently allow for such an implementation. It requires modelers to think a totally different way.

This is why implementing your own CMDB will always break down as your enterprise grows. To get to the right depth requires a significant amount of data modeling/design experience and ongoing dedication. And, this is "just" for the data model. Then you have to also build an engine and a presentation layer that can work properly around all of it.

I hate to say this, but it's also a clear example as to why I recommend that infrastructure resources, who typically do not have formal and advanced SW design and development experience, really avoid trying to design and implement their own CMDBs (or applications/tools in general).

Guerino1,
my company does not have yet a CMDB only an Asset DB. Thinking about creating useful CI, I wonder how you'd do this. We are using OVSD as the soft support for the Incident/problem/change process. I find your view with search engine and presentation layer very interesting. Do you know how this can be done and if there is a soft that can do that?
Also, how far would you go in details wrt the CMDB. What is the right balance between a useful CMDB and a waste of time of keeping it very detailed? I don't want to end with people spending 70% of their times by updating a CMDB.
I'd appreciate your view on this.
Best Regards
Seb

You're not going to like my answer to your question but you did ask... You shouldn't be building a CMDB. You shouldn't even be attempting it. A useful one is too complicated of an undertaking for an enterprise whose business is not explicitly to "build and sell" CMDBs. If your company is not in the business of building and selling them, I highly recommend that you do not waste your enterprise's highly expensive resources. Either use spreadsheets or a simple Access database to address your needs for an Asset Register/Inventory or, only if you're large enough and can justify it, buy a real one.

We do know how to do what you've asked, as it is the foundation for how we build the CMDB that we sell. It's not easy to explain what the right mix is and I apologize but it's definitely not a short conversation. Building a real CMDB is very complicated to those that haven't done so, before, and that's assuming they have all the advanced skills and experience necessary for highly distributed and multi-tier design and implementation. It's interesting to see how few people that undertake a CMDB implementation have this appropriate experience. This is probably why we find so many companies "begging" to help get them out of the CMDB messes they've created. It's very common to find many hardware/infrastructure people, that lack this critical experience, trying to design and build their own CMDB and this almost always results in a very limited solution that an enterprise has a very tough time getting out of. If you build a solution that has severe limitations, then you will adapt your enterprise to leverage those limitations. In other words, you will bend your good enterprise around a bad CMDB, ultimately making the good enterprise worse than it needs to be.

As for integrated search, business rule engines, and presentation tiers, etc... these are all pretty complicated and time consuming material that someone designing and building a CMDB should already have answers for (as they have nothing to do with a CMDB but everything to do with solid distributed development) and this is exactly why an enterprise shouldn't be building their own CMDB. If an enterprise doesn't cleanly understand this material and how it immediately applies to its model, people are only wasting their enterprise's time in trying to learn it. You're better off finding experts that already do know it and already have implemented a high grade CMDB that you know they will continue to service and expand, so you don't have to.

The biggest mistake an enterprise will make is to try and model a hardware relationship tree, as it exists within a machine (server, desktop, etc.). The minute they do this, the CMDB is virtually useless to the rest of the enterprise (SW Developers, Business Analysts, Executives, etc.). A CMDB, at it's most basic level, is three dimensional (4 dimensional if you do it right and take into account time). Most people trying to design and implement a CMDB will always default to a two dimensional model. This is where the limitation gets built in that will ultimately cause a failure in its capacity and ability to perform the way you will really need it to.

Also, we find that if the CMDB is a stand-alone tool, where team members must go to "explicitly" to add and maintain information, it will almost always fail in the enterprise that implemented it. In a world where there is a new tool for everything you do, people are tired of going to "yet another tool" (YAT). While many technologists are always thinking about "automation" and "integration", it seems that the art of "reduction" seems to have faded away. It astonishes me that an enterprise would allow YAT in their environment rather than drive the architects to eliminate tools and infrastructure, ultimately reducing their footprint.

My belief, based on real experience, is that it is not easy to build simple applications, in this day and age. As a matter of fact, building advanced software that is simple to use and maintain is a very complicated and highly expensive undertaking. It's hard enough when you apply it to the business domain (vertical market) of your enterprise, let alone to something like a CMDB that has nothing to do with your core business. Why waste your enterprise's valuable resources on something that is not your core business, when you could buy a better one for far less than it would take you to do it, yourself?

a view from the back of the circus parade: don't buy one if you're not going to (invest some thought /design& implement processes) on keeping it up to date.
A CMDB that is standalone, as Frank said, that is not related to e.g. changes, is a Sad Thing.
I am so jaded that I would almost settle for a CMDB just populated by links to all the various places where the information is stored, if that's where it IS kept up to date.
/Sharon in Regina
ps. up-to-date to me means 'includes the ability to find some historical data' too. Gee, I am demanding!

It's an interesting paradigm that the world has been allowing itself to succomb to. If you think about it, over the last 10 years or so, the world has just really "started" being introduced to distributed computing. As a result, enterprises are developing "pockets" or "silos" that focus on specific point problems (For example: Project Management or Change Managmeent or Incident Management or Etc...) Enterprises tend to address these point problems with point solutions (i.e. a dedicated tool that solves only that problem domain. In other words, they go buy an Incident Management tool for Inc. Mgmt., a Project Management tool for Proj. Mgmt., etc. This means every time a domain grows to a point where processes can't be manual, a company implements "Yet Another Tool" (YAT)! In other words... "Tool Spam"!

The number of operational silo pockets is very large, as they correlate to each and every possible operational process an enterprise uses to run itself (both vertical, which is aligned with their core business, and horizontal, which is more of a commodity space, like ITIL). As a company grows and the silo pockets require attention, the enterprise starts to think "Gee, we should buy a tool for that!" and... they do! This results in exactly what you alluded to: "Tool Spam"!

Because there are so many tools to use and because the tools are limited by license costs, architectures, data model limitations, limited or no APIs, etc., it becomes natural to create organizational silos around these tools. Here's where the fun starts... Some operational silos will need information from other operational silos. For example: Inc. Mgmt. will definitively need asset information from the Asset Mgmt. silo. Now you're costs get even crazier, as you build an integration between the two systems. What most enterprises don't want to come to terms with is that every integration you build is, itself, a new application you must maintain! More tool spam/YAT!

As more and more tools get rolled out, workers start to suffer from "YAT syndrome"... "Don't tell me I have to use another tool!!!!"

This is why our business model is working. We've taken approximately 50 different areas and collapsed them so that, as you recommended Changes are in the same system as Assets, and Products, and Incidents, and Projects, and so on and so on. This collapses everything down into one system, eliminates all the extra/excess infrastructure and maintenance costs, and ensures that data is all in one place and easily shared by everyone. So if the Asset Management team creates and manages their Assets in the system, the Change Management teams and Incident Management teams, who need them, instantly see and have access to all Asset information.

To your point and to your frustration, this is why many enterprise ITIL implementations are usually very limited and stop far short of truly implementing everything that is recommended by ITIL. Too many complicated and poorly integrated tools that take many years to prepare and roll out, extremely high internal expertise to roll out and maintain, and extremely high costs to roll out and maintain. And, in the end, you get nothing more than tool spam... YAT. Everyone implementing ITIL "must" worry about implementing the supporting tools and technologies, which highly distracts from what's important... "the processes". So what we've done is gone into business to provide the best "out-of-the-box" tool platform so that it eliminates the need for an enterprise to spend so much time, money, and effort on a tools strategy. They just turn the platform on and run... and the only thing they have to focus on is process. This shaves many years and many millions of dollars off of most company's ITIL implementation.

Here's a thought... If it takes you 2 years and multiple millions of dollars to roll out 3 or 4 ITIL disciplines, what if you eliminate the complexity of tools from the equation by leveraging existing tools at hundreds of thousands of dollars, instead of millions, and allow yourself to roll out 8 to 10 ITIL processes in the same time period and, at the same time, simplify your overall environment by collapsing all data into one repository, reducing the number of databases you have, reducing infrastructure, reducing SW, reducing SW licenses to manage, driving storage way down, etc.? It's too simple if you think about it...

Allow me to throw a wrinkle into the equation - the third corner of the triangle: people. Each opertional silo developed its products based on its own needs. Who are we (the IT dept) to tell them that their product should change to accomodate other groups/more info?
*aging rapidly and in need of a hug*
/Sharon

Allow me to throw a wrinkle into the equation - the third corner of the triangle: people. Each opertional silo developed its products based on its own needs. Who are we (the IT dept) to tell them that their product should change to accomodate other groups/more info?
*aging rapidly and in need of a hug*
/Sharon

I think the answer to this is "you are IT". If the business is blindly dictating tools and IT just does exactly what the business wants, then IT adds no value. You're just an order taker. There's no need to have it and you might as well just outsource the whole thing to a country like India, who can effectively take and manage the same orders (and much more) for one fifth the cost.

If, on the other hand, you lead by example, you're going to show the business and those other IT silos that "the bigger picture" (i.e. the enterprise strategy) is more important than their tactical and myopic needs. Now, I don't pretend that doing so is easy. But, there is a way to do it effectively. If IT doesn't show the business that they have better tools and solutions, of course the business will just go off and do whatever it wants to. However, if IT "fixes itself" and implements better solutions that can also be leveraged by the business, then the business (or at least these operational silos) will look to IT for help and value add. They will more willingly follow recommendations rather than dictate expectations.

Fix yourself and lead by example to draw the respect of those you wish to sell to. People buy what they believe will help them. If they can't find something to buy, they try to implement it themselves. If they look to IT and IT doesn't have a better answer, you lose. However, if they look to IT and IT does have a better answer, you win. If IT, themselves, is spamming the enterprise with tools, then the example you set is YAT or tool spamming is acceptable. The question is: "Is tool spamming the example you want to set?"

BTW, if your enterprise doesn't have a centralized group that's looking for optimizations across silos, in this day and age, you have a much bigger problem than the implementation of ITIL. Such a group is usually the Enterprise Architecture group or the Technology & Process Strategy group or the office of the COO.