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:
- 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.
- 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.
- 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.
