Ten Reasons Why DCIM Might Be A Dead Camel In Motion


Andrew Waterston, transformation executive/independent consultant
(with extensive technical, commercial and financial experience in both the public and private sectors), explains why he believes data centre infrastructure management (DCIM) is a dead camel.

Andrew Waterston

Data centre infrastructure management tools are like a camel, the horse designed by committee. Camels can be really useful in hot places but are far from easy to ride and have a tendency to spit and bite without warning. From the DCIM vendor perspective, sales have always been difficult, the oasis of big budget DCIM users is drying up and the venture capitalists, that own some camels, are thirsty.

Here then are 10 reasons why I believe DCIM is a dead camel.

1. What is the user need? – Facilities management, security, M&E engineering, IT hardware and physical network engineering, all have a view as to what they need from a DCIM tool. As management responsibilities grow, and as Infrastructure as a Service (IaaS) morphs into Platform as a Service (PaaS), MoSCoW requirements analysis for DCIM is growing ever more diverse and complex, with more users than ever. These are often weighted by the user who shouts loudest. DCIM vendors desperate for sales overpromise and then have to bastardise their already complex products during implementation to meet the ‘shouty’ user need.

2. Make mine vanilla? – DCIM means different things to each user and there are no standards that allow them to easily compare the vendor offering to their needs. It also makes interoperability and integration difficult.

3. Questionable vendor neutrality – Some DCIM vendors have seen DCIM as a means to integrate and increase sales of their own hardware. This creates the perception of lock-in and further increases the number of stakeholders in the software design process, adding to complexity.

4. Monolithic architecture – Many DCIM tools have evolved over time or through acquisition and lack the open source components and micro service design of a modern application. This makes them really difficult to change and upgrade at pace, or to integrate with modern service management tools. In addition, some of the older DCIM tools are constructed around legacy databases, further adding to complexity, integration challenges and maintenance costs. In a world where management focus is on this month or possibly this quarter’s results, obtaining buy-in for a complete rewrite of the application, particularly when analysis of the user need makes it difficult to understand what the result should look like and revenues are down, is challenging. Will the customer base buy the replacement or look at alternatives instead?

5. Implementation challenges – When something is as complex as DCIM, implementation is an expensive and lengthy process. I have heard of several large scale implementation failures recently, often due to the failure to start with trusted asset data and a robust change process.

6. Support, maintenance and upgrade costs – Once implemented, the ongoing costs of DCIM are considerable. What happens when a major upgrade is announced that will require a new implementation project to be established to recreate all the bespoke elements implemented first time around in the new tool? What will need to be sacrificed to find the budget? Is complete replacement a better alternative? These are the questions the large organisations that were early adopters of DCIM are now asking themselves.

Network servers7. Cost – In the large, complex organisations with the biggest budgets, and the greatest need for DCIM, it is often easier to get traction (executive focus and internal resources) for a complex, expensive project than a cheap one. DCIM solutions are reassuringly expensive to buy, implement and run so fit the bill, especially if there are lots of ‘shouty’ users to influence the executive. However, those organisations are now struggling for budget, have been burnt by failed implementations and undelivered promises, and cannot justify the return on investment.

8. Outsourcing – Legacy infrastructure outsourcers striving for operational efficiency were some of the adopters of DCIM, though they are now faced with the challenges outlined above. They face another challenge too; the asset information contained in the DCIM is exactly what their customers need when they want to transition to another provider. They need to balance operational efficiency with DCIM replacement costs and the potential risk to revenues.

9. Cloud – As more organisations migrate to the cloud their own need for DCIM disappears. Will the cloud providers buy DCIM? I suspect the large ones will have created their own low cost alternative.

10. Low cost alternatives – DCIM gained some early traction in large organisations but the need in the majority of the IT industry remained. These users questioned what they really needed, and found some point solutions in freeware, low cost asset management platforms, power monitoring Apps and spreadsheets. As these solutions evolve with micro-service architecture, RESTful APIs and HTML5 front ends, integration becomes easier.

Given these problems I wonder if Gartner will drop DCIM from its magic quadrant and possibly even its hype curve (as something that never really made it out of the trough of disillusionment).

Should DCIM stand for ‘Dead Camel In Motion’? Does it know it’s dead, and at what point do you stop flogging the dead camel?


  • Show Comments