The Fuss and Hype over CMDBs (aka "myCMDB")

We may have finally reached the pinnacle of CMDB hype with Managed Objects' release of their new product, myCMDB.  While I have been somewhat of a fan of Managed Objects, this one just has me completely baffled.  The press release hype is talking about bringing 'Web 2.0' to the CMDB.  Huh?

It seems to me that this is indicative of a general trend to make the CMDB so much more than it was ever meant to be...and in so doing make it more and more difficult to actually make it work.  Managed Objects is certainly not alone.  It seems as though there is a virtual land rush out there to see who can cram the most different types of data into the CMDB.

Call me a simpleton, but here's my take on effective CMDB implementations:

1. Keep It Simple - CMDBs (and really the Configuration Management System (CMS) - so we can avoid this whole discussion of one really big CMDB!) should be a relational representation of the core and critical assets that IT utilizes to deliver services.  Each organization needs to determine how deep that needs to go to be effective, but there is a definite balance point that must be found.  The more detailed the data, the harder it will be to keep it accurate.  So, the key point is to get the level of detail just "good enough."  IT people are sometimes their own worst enemy here - once we get a hold of this, we want to put everything under the sun in this wonderful, magical database.  Remember that we can provide access to additional detail and related information through the federation model, but when we are talking about what should be considered a CI there must be relentless restraint to keep the data model as simple as possible while still delivering data relevant to the delivery of service - just good enough.
2. Relationship Trumps Granularity - I always find it fascinating that so much effort is put into defining CIs to an excruciating level of detail, but little effort is put into mapping the relationships between CIs.  The truth is that it is in understanding the relationships that the true value of a CMDB/CMS will be found.  I believe that a CMDB/CMS that defines CIs at only a very, very high level, but maps their relationships effectively will provide significantly more value to an organization than one that contains infinite levels of detail about each CI and its various changes in state over its useful lifetime, but which cannot describe the relationship between each CI and others in the delivery of service.  Get this one right and everything else will fall into place.
3. Process is Still Key - ITIL is all about process (well, v2 anyway).  But when it comes to the CMDB/CMS, it seems that we throw process out the window.  Yes, I'm a big believer in discovery tools and application mapping applications.  But when it comes to maintaining the CMDB, nothing will take the place of a rigorous process.  Anywhere that there is a change to a CI, process should dictate how the CI data is updated in the CMDB.  This should be a key process activity tied to Change and Release Management.  It should also be incorporated into the Standard Change process that might be executed as a function of Incident Management.  The key point, though, is that if your CMDB is falling out of sync, it's a process failure.  Can tools help?  Sure, but nothing can take the place of a well executed, well managed process.

In the end, IT and the many wonderful ITSM vendors must resist the temptation to turn the CMDB/CMS into something that is delivered in and for itself.  It's not.  The CMDB is nothing more than a tool that provides appropriate and relevant data during the execution of a process, in the delivery of a service so that those responsible for the execution and delivery can do so effectively and efficiently.  A well implemented CMDB/CMS is one that becomes virtually transparent.  The data you need is available when and where you need it to get the job done.  If you're having to interact with your CMDB data directly - "Web 2.0" or not - well, you're kind of missing the point.

Comments

[tsr]

Mr Araujo,

I have read ITskeptics blog and now yours, since this came to my attention, and I have some issues with your reviews.

I am intimatly familiar with the Managed Objects Product Suite, and your myopic review is to use your own words simpleton.

You don't understand its place or role in the integration platform that is Managed Objects. It is a small piece or solution to a problem thats vexed people for a while, um.. How do you improve your data? and we know that all data is crap, till proved otherwise, right? And as the IT skeptic is fond of pointing out that the wetwired individual is the place for that info, well it stands to reason you should appeal to him to play a key role, right?

In as much as your main three points:

1. Keep It Simple
2. Relationship Trumps Granularity
3. Process is Still Key

You show your naievity of and lack of experience with the Managed Objects Platform.

1. I'm a fond proponent of the KISS rule, Keep it simple stupid, and thats the only way to begin to make sense of a complex environment, where the relationships are all complex. This is step one with Managed Objects, the focus is quite simply on the Services that are Critical to You. And in most realities the stake holders are the sole repositories of this type of dependancy information. So again, why not leverage their expertise?

2. Understanding how technology impacts a service comes from having created the service model or logical picture of how your service/application looks and yields many of it's relationships or dependancies.
Often this is only as far as you have to go. And yes, it's a simple thought exercise. People just have to do the work. That IS the relationship. It's rarely more complicated than that. But thats whats complicated.... yes, a real conumdrum.

3. Process? You are going to knock a CMDB enabling data support mechanism on a lack of process? (granted, why not, you don't understand how the integration platform works.) I thought you thought the CMDB was a respository of information the other processes external or internal took advantage of, *ahem* which Managed Objects does nicely. Want to compare objects(CIs) to their historical baseline? to other objects(CIs)? See all their changes? validate the data against an active discovered segment of the network? puhleez. you begin to loose any credibility you may have had. ITIL is the process by which you decide how you want to take advantage of YOUR data, ie control your risk to unmitigated change. Now that you have the data, what usefull things would YOU like to do with it? Open an RFC to propose a change? Open an incident against a CI based on correlating a malfunction via real time monitoring, against a specific attribute, ie, an interface. And then look up all the CI's that have that same model of interface and begin to troll thru their alarm history for similar outages?

Surprisingly enough, I agree with your sentiment on a number of things, and in any other instance we would likely get along, but your review is malaligned and your conceptual grasp of how all the parts of the Managed Objects works lacks. It lacks depth of knowledge, comprehension, and for imagination.

So, Mr. I need an actively discovered cmdb, how do you improve YOUR data? How do you propose to inject the information that sits in the heads of the stakeholders into your cmdb to make it more meaninful? With REAL application and service dependancies? Cause connections from device to device don't always cut it. And Application modeling doesn't always cut it, cause there are always uniquely configured/architeched solutions that don't fall into a cookie cutter view of the world.

I should go on, but I shall not.

[The IT Skeptic]

tsr,

i contest your assertion that "in most realities the stake holders are the sole repositories of this type of dependancy information". Unless you have a myopic view of stakeholders as being the key technical people within IT, then I don't think that is true. to the stakeholders, a service is something that comes out of a pipe. they don't know jack about how it gets there. And the people who do know don't need facebook to check the data.

More debate at "ice the cake with bulls***" http://www.itskeptic.org/node/644#comment-3109

[tsr]

I am happy to provide a refutation!

skeptics != solutions

Alright,

MO doesn't need ingnorant fans. And neither does it need ignorant critics.
You question the wisdom of using a collective knowledge, or a tribal knowledge, and you question using a Database, since it's going to be out of date the moment you use it, and you question the wisdom of autodiscovery... I'm sure...

So, just what DO you believe? in Omniscient Discovery?

http://www.itskeptic.org/node/644#comment-3113

and

Hung up on SKMS? CMDBs?

John,

People, process, products and providers.

We need to talk about People though since it seems to be relevant to MyCMDB and skeptics and others disregard.

1. People; have always been the key reason a CMDB or ITIL or ITSM Project fails. You can't succeed in any of these ventures until the people who decide, and then drive the solution... care. And these are in fact different people. Ah...

http://www.itskeptic.org/node/644#comment-3114