Recently I've been very involved in several discussions around the roles of CMDBs within different sizes of enterprise organizations. For those of you that aren't familiar, CMDB stands for Configuration Management DataBase. There's been a lot written on the subject in the last 18 months and if you're curious a Google search will provide enough reading to get you to St. Patrick's Day.
Anyhow, I'm finding that very large enterprises are implementing and/or adopting CMDB systems and practices at a quick rate. However, smaller organizations including some small, mid-sized, and fairly large organizations are either just starting about CMDB or have put it out beyond 2008 and therefore aren't really thinking about it all - or at least not in those terms. Most of the companies I've worked with are implementing features and/or procedures that would be a part of a CMDB strategy without necessarily setting out to do so.
For me personally, in working with most organizations, we rarely use the term CMDB but we commonly discuss more tactical items that fulfill the role of a CMDB. I'll talk a little more about these items and how they fit into an overall CMDB strategy within a few days. If you have an experience in this area I'd love to hear your opinon.
Flame on...Josh
p.s. Happy New Year!!!
We are adding a custom property to Orion which is the Asset Tag, assigned to equipment for correlation with our CMDB. We are using Remedy for Asset, Trouble Ticket and Change Management.
Josh, I see that you said in another post that CMDB isn't one of youy favourite subjects (maybe because vendors have beaten it to death?) Anyway, here is my two cents.
I have gathered info on major incidents (incidents with severe negative business consequences) for the past 14 months. Given that there is no formal CMDB implementation the results are not a surprise. A breakdown of the causes of these major incidents are:
1. Configuration (31%) - invariably the root cause is the techie reluctance to create any documentation which has rolling repurcussions.
2. Component failure (29%) - what happens is that a component is used way passed it useful life (there is a perception that we are saving bucks by not buying a new one), people have forgotten to place components on maintenance, or haven't sufficiently protected the environment it is installed into etc, In most cases the techie doesn't know about the component until it fails.
3. Third parties (vendors and service providers) (26%) - when you finally receive an answer from the vendor the majority root causes are often human failure or error. Third Parties never admit to mistakes so the only due diligence is circumstantial evidence.
A CMDB strategy will not eliminate these major incidents or even reduce their potential occurrence. However, what it will do is dramatically change the times in the expanded incident lifecycle. Reduction in overall lifecycle times is where the business case lies.
Redpineapple,
This is great information and I appreciate you sharing. Also, just so I don't create confusion, I LOVE talking about the technical details of CMDB. It's the typical high-level mumbo jumbo that you read in all the trade rags that tends to put me to sleep...
Josh
Josh,
I was instrumental in getting our CMDB off the ground. Initially it was for servers but then grew to infrastructure devices. Basically if it had an IP then it was included in the CMDB. We still use Access as our CMDB since it is easy to maintain and is flexible and as the years have gone by took on new and various roles.
Our CMDB links to a variety of other systems such as patch remediation, End-of-Life cycle replacements, Asset management, down time tracking and a multitude of other functions. If you have a good CMDB the possibilities are endless.
Does this help at all?