The real reasons why DCIM is failing
Fri 9 Jun 2017 | Venessa Moffat
Venessa Moffat of Agile Momentum suggests why DCIM is struggling to take off despite being available on the market for several years…
Markets are generally considered mature when all the vendors offer a cohesive message about what a product or service offers. With DCIM, this is still not the case even after several years of it being around, so what is going wrong?
In 2010, Gartner predicted that by 2014, DCIM penetration would be up to 60%. In 2015, The Uptime Institute data centre survey showed that only 27% of those surveyed had purchased a commercial DCIM solution. This market is not maturing as we had expected it to.
Gartner, for its Magic Quadrant, defines DCIM as this: ‘Data centre infrastructure management (DCIM) tools monitor, measure, manage and sometimes control data centre resources and energy consumption of both IT-related equipment (such as servers, storage and network switches) and facilities infrastructure components (such as power distribution units [PDUs] and computer room air conditioners [CRACs]). DCIM tools are data-centre-specific, rather than general building management system (BMS) tools, and are used to optimise data centre power, cooling, networking resources and physical space.’
The pain points are fairly well documented and we are collectively starting to learn our lessons
The problem with this description is that for a DCIM implementation to be successful, software alone is not the answer – we need to understand and design our entire data centre architecture. We should also be looking at the right hardware, systems integration, consulting, training and staff skills, as well as internal organisational and process changes.
The promises made by various vendors, while not untrue, have given the impression that all organisations can reach DCIM utopia in a relatively short timeframe, it’s this flawed planning that has ridiculed many business cases and made a high percentage of DCIM customers disillusioned with the product that they have chosen. Not only that, but they could also feel locked into that vendor, and have footed a series of rather large bills to boot.
Software alone is not the answer
The pain points are fairly well documented and we are collectively starting to learn our lessons. DCIM implementation spans several aspects of a business, including both facilities and IT – neither of which are simple environments.
Firstly, DCIM promised to allow data centre managers to know exactly what is connected to what, and manage these relationships and dependencies. It also promised to help find available resources (rack space, power, cooling, network, IP addresses, etc), and all of this without being constrained by proprietary software.
Through DCIM operators hoped to overcome challenges with aligning their legacy and new systems as well as the difficulties in keeping track of changes and de-installations, which prevent a real-time understanding of what’s going on in a data centre.
Other pain points which DCIM sought to address included: Poor monitoring and aligning of legacy infrastructure resulting in significant financial losses; Critical gaps in management information between IT and facilities managers; Inability to perform accurate capacity planning; Inability to comply with internal and external regulatory audits; and a lack of standards-based, database connectivity, APIs, for integration with internal systems.
The flaws with the process
The programmes really fail because there are a number of common issues in our environments that haven’t been taken into account, and a number of common oversights in the implementation of the programme.
The most critical starting point is understanding the needs of your business. Work down from top-level business objectives, and only add in elements that directly link to business objectives.
Make sure to create a flexible architecture that can evolve, and only engage with vendors who will work with that
There is also no point in finding really expensive solutions if you don’t need half of the functionality. Avoid hype from vendors around promised benefits, and rather take ownership of the programme to realise the benefits when and where you need them. If you are deeply involved with this part of the planning, then you will uncover all the hidden costs, and be able to plan and set expectations accordingly.
It’s always important to consider DCIM as a programme, not a project. Set it up as such, assign roles and responsibilities and hold regular meetings. Set up the individual sub-projects with their own project managers too. Before the programme is initiated, you must also make sure that all your processes are documented and in play.
Additionally, these programmes take a long time to deliver fully, so you need to show value along the way, but that value has to match the business requirements. And finally, make sure to create a flexible architecture that can evolve, and only engage with vendors who will work with that.
If you can address the above points in your DCIM programme, you may become a future DCIM success, and goodness knows we need more of those!
[DCM-footer]
