Pity the sad fools tasked with buying a DCIM system

Data center management software procurement is a slow motion disaster

Pity the sad fools tasked with buying a DCIM system
Credit: Thinkstock

The purpose of dramatic tragedy is to teach us to avoid misfortune by showing a negative example.

With that in mind, I introduce our tragic hero. Let’s call him Jim.

Jim is a vice president of data center operations for a bank. He’s been tasked with finding a replacement for the company’s legacy data center infrastructure management (DCIM) tool set, which ran into a dead end for support and updates.

Jim manages a half-dozen data centers of various ages and design. The motley portfolio is the product of acquisitions and shifting management strategies over the past decade. Some of the sites are underutilized, others are coming up against capacity constraints, while still others are running on borrowed time and would likely require significant updates if anybody dared to evaluate them.

New IT deployment models for cloud and colocation are shifting resources away from internal budgets.

+ Also on Network World: Data center managers, it’s time to commit to those New Year's resolutions +

Jim’s boss has asked him to provide consistent metrics on cost, performance and service quality across the enterprise portfolio, as well as to figure out how to consolidate or decommission assets if possible. They need to provide the business with cost savings and management insights before Amazon and Equinix swallow them whole.

Jim’s internal infrastructure team might be able to compete on cost or reliability, but they just don’t have any data. An effective DCIM could help them transform IT operations from a cost center to an internal service provider. 

Jim diligently gathers analyst reports on the DCIM market. He reads white papers and attends webinars. He wades through brochures from the over 80 potential vendors in the market and narrows his list down to 10 providers. Finally, he gathers stakeholders from the infrastructure team to give input on a requirements document.

After slaving over a document for weeks (between daily fire drills and other management tasks), Jim emerges with a lengthy request for information (RFI) that he submits to the 10 vendors.

Jim is pleased. He is confident he has diligently defined his organization’s business needs and that will be met with equally rigorous and thoughtful responses from professional colleagues in the vendor community.

Sadly, this is the beginning of Jim’s downfall, his fatal error.

The torture of getting information from DCIM vendors and selecting a system

As responses to the RFI begin to roll in, Jim schedules conference calls for project stakeholders with the various vendors. Each call and demo might include up to 40 staff in attendance and could last two or three hours. The commitment puts the operations team in a further deficit on management and maintenance tasks, but Jim wants to get this right.

Months pass. During the time it took to schedule the meetings, one vendor has stopped selling the product and another has been bought. But Jim’s team has narrowed the list of providers down to three vendors.

Ten months into the vetting of the providers, the team struggles to get comparative pricing information. One supplier pulled itself out of consideration for some unknown reason. Faced with looming budget claw-back, Jim settles on a preferred vendor and begins the formal RFP process.

Upon receiving the RFP, the vendor’s sales engineer quickly responded with a technical proposal— drawn almost entirely from generic promotional materials. All of Jim’s team’s careful and specific requirements are met with marketing pap copied from sales collateral.

Jim’s procurement team would eviscerate this document.

Jim quickly responded to the vendor that this was not sufficient to go to contract. His vendor representative, after passive-aggressively trying to bully Jim into pushing it through, revised the document by pasting in some additional graphics and generic case study material.

Upon receiving the updated document, Jim’s boss begins looking for other job opportunities. They’ve both sold their executive team on the needfulness of this project, and this vendor specifically being able to meet their company’s needs. Their credibility—their careers—are tied to the success or failure of this implementation, and they can see it slipping through their hands.

In a last ditch effort, Jim reaches out to the vendor’s senior executives and gets on the phone with someone from HQ. It’s during this call that Jim ascertains that the engineer assigned to their project has a limited understanding of the product itself.

The person assigned to lead the implementation of this software can barely respond to the RFP. How is he supposed to ensure this project will meet all of his goals, to help him integrate his view of assets across multiple sites and disciplines, to help him bring structure and maturity to his IT infrastructure operations?

At this point, Jim starts polishing his résumé.

Inept vendor, lost job, terrible DCIM system

You know how this works out, right? It’s called a tragedy for a reason.

Jim somehow pushes the contract through because even a slipshod deployment is better than what they have now. He doesn’t want to lose this budget—or the years of effort documenting alternatives, defining requirements, gathering input and cajoling budget stakeholders.

Thirty-six months from the day that Jim started this project, he no longer works for the bank. He instead manages facilities for a high-tech marijuana growing operation in Colorado. Jim’s successor completed the implementation, but she’s pretty sure they could have spent a fraction of the money and staff hours manually collating the information they could have pulled from the existing BMS.

None of the advanced capacity planning stuff works. A lot of it runs on modeled nameplate data—not real conditions. The team keeps the software’s main dashboard imaging on the screen in case executives come into the NOC, but they rely on legacy tools and walkthroughs to maintain the site and plan moves-adds-changes.

None of the forty-odd staff who were sleeping through those conference calls two years ago has any interest in reviving the initiative. It’s career suicide. If you recognize the mistake, you own it.

The infrastructure team is exactly where it was three years ago, with disaggregated and incomplete information, and no way forward to realize the “data center transformation” that DCIM promised.

As Aristotle points out, a true tragedy should evoke pity and fear in the audience. We experience catharsis witnessing the pain of Jim’s spectacle of suffering.

To a certain extent, Jim’s failure was inevitable. He did everything the way it was supposed to be done.

According to Uptime Institute survey data, half of enterprise DCIM buyers do not achieve ROI on the purchase. Around 40 percent are now on their second or even third run at various vendors and approaches. Less than 25 percent of survey respondents have deployed any advanced features. And almost all of them have wasted years of staff time to achieve nothing.

Learn from Jim’s mistakes: The right way to procure a DCIM system

The few folks who do this right have thrown out the vendor’s playbook. As the ancient Greek suggests, know thyself.

Learn the lessons from Jim’s mistakes:

  • Define your requirements based on tangible and achievable goals. Like a lot of executives, Jim’s purchase was driven by a vague sense that they needed to get a handle on their operations but not much else.
  • Improve or implement processes that will support the tools, rather than searching for tools to support non-existent management disciplines and procedures.
  • In most companies, the data center (and IT as a discipline as a whole) are often accounted as an undifferentiated cost center to be absorbed by the business. But this practice cannot continue in the face of cloud adoption. Make sure you can achieve cost savings immediately.
  • Use an effective decision-making system to gather input, vet alternatives and come to decisions as quickly as possible before your team loses momentum on a project.

For the last decade, the data center industry has struggled to successfully adopt DCIM software.

DCIM promised to drive out data center inefficiencies, to help operators build a credible model for capacity planning, and to tie together the IT and facilities management teams.

Data center operators saw the potential to apply an organizational structure and visibility over the quagmire of controls, monitoring and asset management tools that had accrued over the years.

Yet, the path to reaping those benefits could not be realized by simply purchasing software. As the messy work of implementation began, many IT organizations found that these tools would be more difficult to implement and more expensive than expected.

Many also realized that DCIM was not capable of automatically addressing underlying management shortfalls.

DCIM promised to give IT organizations tools to transform their organizations. But that opportunity was also rife with the risk to overspend—and to underestimate the amount of effort it would take to deploy the tools correctly. Many IT organizations have waited, evaluating the market, considering the right time to make an investment. Others have already adopted DCIM tools, spending millions of dollars and massive amount of staff resources for a system that provides limited benefits.

The industry needs DCIM to provide the holistic view of data center assets, interdependencies, performance and capacity—and to translate that information into actionable management recommendations and behaviors.

But the procurement process is a tragedy.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Must read: 10 new UI features coming to Windows 10