This page contains a Flash digital edition of a book.
FACILITIES DCIM


Choosing DCIM tools with these characteristics ensures that the business processes, data and methods will be in-line with the expected evolution of DCIM. Solutions lacking these attributes are likely to be dead-end choices. More than that, these attributes play a significant role in helping ensure the solution is effective today.


Pitfall 2: Relying on inadequate or mismatched processes


DCIM solutions are often sought by data centre managers to fill a gap in their operational processes. Vendors often sell them on this basis. Indeed, an effective DCIM solution will simplify, facilitate, and provide a clear view of what would otherwise be a very complex and diverse ecosystem of disparate facilities and IT systems. But this ability is still dependent on operators doing their part by following good processes to implement, operate and maintain the DCIM system. Even the best solutions do not eliminate the need for management processes. Poor process is a common cause of failing to achieve the desired value of DCIM.


The amount of operator effort and process will vary from one DCIM vendor’s offer to another. This is yet another point upon which to compare solutions during the evaluation phase. Knowing the specific operator requirements of a given solution typically means interviewing the vendor directly. Some vendors will even offer training programs on how to operate and maintain the management system. And it is


functional or not. DCIM systems have been touted as a tool for eliminating this sort of organizational behaviour. Sometimes the isolation can be so great that DCIM tools are unable to bridge this gap as there is neither commitment to use nor clear ownership of the system and its processes. When writing about the risk of data centre downtime, David Boston, President of David Boston Consulting, wrote “The potential for confusion and error is high. That’s unless the [facilities and IT] groups work together to clearly define detailed processes and ownership of key tasks.”


It is therefore important for facilities, IT and management to all work together early on and come to agreement on the adoption and use of DCIM tools in conjunction with their existing tools. It’s a mistake for management to decide to use a DCIM system without the buy-in from those who will be required to implement and operate it. All sides should be involved in the early evaluation phase to ensure everyone’s needs and expectations are met. Each group should come to see and understand the value of the proposed solution upfront. There also needs to be agreement and management support for committing the necessary resources to implement and operate the management system. All of this upfront discussion and buy-in ensures on-going cooperation and participation well beyond the implementation phase.


Owners for the tools and their associated processes should be explicitly named before the system is implemented and it is


The amount of operator effort and process will vary from one DCIM vendor’s offer to another. This is yet another point upon which to compare solutions during the evaluation phase. Knowing the specific operator requirements of a given solution typically means interviewing the vendor directly. Some vendors will even offer training programs on how to operate and maintain the management system


very important to ensure there will be sufficient resource (and the on- going discipline to use them) to meet the effort and process required. Here are four common DCIM-related processes that, if neglected, will undermine the functioning and benefits of the management system: £ Inventory/asset management £ System configuration £ Alarm integration £ Reporting for management or other stakeholders


Pitfall 3: Lack of commitment, ownership and knowledge


It would be obvious to most readers that a process without an owner or the resources to carry it out almost certainly dooms that process to failure. But, if this is obvious, why is it a common pitfall? The main reason results from the scope of DCIM together with the “silo mentality” that often exists within organisations. DCIM’s functions, tools, and effects span across both facilities and IT – two realms that have traditionally been segregated from each other. Given IT’s reliance on the facility for power, cooling, and space and given that IT is a customer (of sorts) for the facility, there has been much written in recent years about the need for these two groups to work together.


Management can be another “silo” in the organisation that if isolated can impair the effectiveness of DCIM tools. This lack of teamwork and communication can, of course, appear within any team - cross-


36 www.dcseurope.info I June 2012


recommended that evaluation and operation teams include people from all sides to help close any knowledge gaps. They should work closely with the vendor to understand all the requirements for making the system work effectively. Early involvement and consensus between facilities and IT should make on-going cooperation and coordination easier, making it more likely that the DCIM system is fully implemented, regularly used and, therefore, effective in delivering on its promises.


Avoiding the pitfalls


The ability of DCIM systems to automate and simplify infrastructure management can cause users to underestimate or not properly account for the effort still required on their end. To avoid the common pitfalls described when evaluating and implementing DCIM solutions: £ Your chosen solution should embody certain fundamental properties – scalable, modular, standardized, pre-engineered, open communication architecture with a strong vendor support structure.


£ The processes required for implementation and on-going operations needs to be determined, created and supported for the long term; focus on asset management, system configuration, reporting and alarm integration.


Facilities, IT and management should all be involved in the evaluation stage; they must come to agreement on needs, goals and implementation plans, as well as determine ownership for all processes.


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56