What Your Vendor ISN’T Telling You About Their CMDB Tool

Many organisations believe a CMDB will solve all their problems. Once they have it in place they’ll have rock-solid change control, a strong basis for IT project planning, and a clear path for disaster recovery efforts.  And the thing is, that’s all true… in theory. But most of the time it just doesn’t play out that way. In fact, depending on who you listen to, as many as 85% of CMDB implementations fail altogether. Now I know what you’re thinking…  If the potential benefits of a CMDB are so high, why do such a large proportion of implementations fail? Surely these organisations would be willing to invest sufficient resource to get the job done properly? But that’s just it. How much resource is enough? And what is it exactly about the CMDB implementation process that causes so many failures? To understand, we need to consider the most important CMDB element: Relationships.

What a CMDB Really Is

Before we consider anything else, let’s think about the description we’re using. Configuration Management Database. To my mind, we’ve already hit upon a problem. Because what we’re looking for isn’t simply a database, it’s a relational database… we need to understand the multitude of interdependencies that surround our assets. To illustrate this, let’s look at two of the major benefits of a fully functional CMDB:
  • Greatly improved change control
  • Faster and more effective disaster recovery
Whether you’re planning a configuration change or recovering from a system outage, it’s an understanding of the relationships between your assets that enables your staff to act in a deliberate, effective manner. Without this understanding, there is simply no way to avoid wasting time and effort in identifying the best route forward. Worse, the risk of causing damaging and unforeseen side effects is far, far higher. Ultimately, if you have a CMDB with no relationship data, it’s nothing more than an asset register. A simple record of IT assets, perhaps with some additional detail such as service owners, version numbers, and update histories. Useful, certainly, but a long way from ideal. “Fine,” you might be thinking. “We need a CMDB that includes relationship data. Easy enough, we’ll just pick a tool with that functionality.” Sadly, this is where we hit a problem. In fact, this is where we hit the problem.

It’s Not About Functionality

When planning a CMDB implementation, most organisations consider two things: their current position, and the benefits they ultimately expect to reap once implementation is complete. Certainly they understand that the transition will require a level of resource, but they make one fatal error:  They assume the CMDB tool they procure will make the process simple.  Sadly, most of the time, they don’t. Imagine you were building your own CMDB tool in-house. How long do you think it would take to conduct a relationship mapping exercise across all of your assets? If you’re working in a large organisation, even getting started could seem a mammoth task. In fact, this realisation is one of the major reasons why very few organisations do build their own CMDB tool… they intuitively realise that conducting this mapping process manually would be tremendously labour intensive. But what they don’t realise is that most of the time, even with vendor-bought CMDB tools, the customer is left to figure out the population and mapping process on their own. Now, perhaps, you can see why so many implementations fail. Some grind to a halt when the scope of the work necessary is fully realised. Of those that are populated, many are later abandoned due to the prevalence of incorrect or incomplete relationship data. Let’s be honest, it doesn’t matter how good the tool is, if the population process doesn’t go smoothly the end result isn’t going to be a good one.   Which brings us to our second big hurdle.

Data Quality… Or Lack of It

Every organisation (and I mean every organisation) has data quality issues. And nearly every time an organisation decides it’s time to implement a CMDB, they also proudly proclaim their intention to conduct data cleansing exercises during the implementation. After all, it wouldn’t do to fill a brand new CMDB tool with inaccurate data, now would it?  But again, we hit a problem. Most CMDB tools don’t include any facility for identifying and resolving data quality issues. Once again, this exercise falls squarely on the shoulders of the customer. This would be a substantial task on its own, but when combined with a relationship mapping exercise it starts to become almost unmanageable. And sadly, it doesn’t end there.

The Reality for Most Organisations

OK, so we’ve discussed two major hurdles to CMDB implementation, but I suspect I haven’t yet hit upon your biggest concern. What if your asset data isn’t all in one place? What if it’s divided amongst all manner of spreadsheets, toolsets and databases? What if you’ve tried to combine them before, but the task was simply too big? I can tell you that you’re not alone. Many local authorities, NHS trusts and MSPs are faced with exactly this problem. They need to implement a CMDB tool, but the prospect of combining all of their disparate, duplicate-riddled, error-strewn asset data is too terrible to contemplate. The sad fact is that there’s a huge void between procuring a CMDB tool and having a fully functional CMDB… and most of the time customers are left to fill it themselves.  That is why so many implementations fail.  

Filling the Void

How, then, should you proceed? Your organisation needs a fully functional CMDB, but clearly there has to be a better way than simply muddling through the population process manually. The first (and most obvious) solution is to identify a vendor or tool that will conduct this process on your behalf. They’re few and far between, but if you look hard enough you might well get lucky. If you’re watching product demonstrations, you can grill the salespeople on this subject, hammering out precisely how much help you can expect to receive when it comes time to populate your new CMDB. But that’s not the only option. The second solution is to enlist the help of an IT service management integration company. The benefits of hiring expert help are substantial, not least if they have past CMDB implementation experience, and you should find that the process becomes more manageable when sensibly divided and planned. It’ll still be a substantial project, but most organisations are able to successfully populate their existing CMDB tool with expert assistance. But what if you simply can’t spare the resource to conduct a large-scale CMDB population project? What if you desperately need the benefits of a fully functional CMDB, but you’re on a strict timeline, or your IT staff are tied up with other projects? At CIHS we’ve dealt with these situations time and time again. We’ve helped clients with everything from selecting the most appropriate CMDB tool for their needs, to conducting full relationship mapping processes in their existing CMDB solution on their behalf. We’ve coached and mentored clients through the CMDB population process, and for other we’ve taken on the whole project as a managed service. Now we’ve decided we can do better. We’ve been hard at work developing a solution to fully bridge the CMDB population gap. We want to help you transform your disparate, non-standard asset data into a normalised, validated, relational CMDB.

Above all, we want to help you get your CMDB right this time.

So if you’d like to find out more, take a look at our CMDB white paper, or visit us at the Service Desk & IT Support Show (SITS) on the 8th & 9th of June, Stand 901. 

Pin It on Pinterest