In our previous blog, we started with an intro to How to Choose the Right DCIM Solution. We gave you a definition of DCIM and then enumerated different functions that usually fall under the large category of “DCIM”.
Alright: so you’ve identified some of the features you need from that list, and you start looking for vendors that tick those boxes, right? Not so fast.
Features-schmeatures
In this second article of the series, we will not talk about features. We will discuss something even more important: the underlying architecture and usability of the platform. These are aspects of both the software and the vendor that you must consider; these are things that go beyond a laundry list of must-have features. Here’s why: all the features in the world will be useless if the software is not securable, easy to use, open, or easy to deploy. It will turn into shelfware. So, let’s start with the deployment itself.
Easy Deployment
News flash: we don’t party like it’s 1999 anymore. This is 2015, where HTML5 is the norm and users don’t want to be or need to be installing yet another piece of software on their desktops to access DCIM data. So, for us, easy deployment essentially means no deployment at all! Of course, this can mean a SaaS solution for many (which we do offer), but SaaS is non-starter in many situations and for a number of valid reasons.
That’s why the vast majority of our customers choose to purchase a permanent license of our DCIM tool that will be hosted in their own network. So what about deployment in those cases? The server should be easy to install and end-users should have to do zilch. Because DCIM solutions are (or should be) diagram-rich and feature-rich, this probably means a solution that uses HTML5/SVG rendering (or similar) and requires no fat clients, no add-ons and no plug-ins. In other words: open a browser, log-in and enjoy a feature-rich user experience.
Usability
Fact: 90% of drivers think their driving is better than average. That is, of course, mathematically impossible. Yet, I am certain 90% of DCIM vendors would say their solution is easier than average. In another upcoming blog we’ll discuss usability and the importance of the proof of concept, since we are passionate and adamant about both, but let’s just say this: put the vendor to the test.
Come up with some sequence of operations, such as modeling a new rack type and new router type (and beware of those vendors saying ” oh, we’ll model that for you in a week” – more on that later), upload a floor plan, add a rack, move it somewhere on the floor plan, add a big router with some cards and a patch panel, and create 24 cable connections between the router cards and the patch panel.
Then, count the minutes (or weeks) this took to create. We could go on and on about usability (such as: ease of creating adapters, importing devices from your home-grown Oracle database, new report types, cloning an entire data center, etc.)…Point is: don’t take the vendor’s word for granted. Just because they say it is easy, doesn’t make it so. By the way, I am a fantastic driver, in case you had any doubt…
Flexibility
I can’t stress this enough, and it’s also related to the previous point. Let us summarize flexibility by saying that if any of the following questions triggers a no, that’s a problem:
a) Can you create new entities in the system (like, say, a door, or a chair)?
b) Can you add/remove fields, make them mandatory, unique, displayed, etc?
c) Can you model new device types and subcomponents in the catalog/library?
d) Can you create new report types or modify the dashboards?
And let’s cut to the chase: you means you. If the vendor tells you that they (as in not you) can do that, and this requires a consultant to do it, then it is far too inflexible already. If on top of that, to add insult to injury, they charge you for wanting to customize the tool to your liking, here’s our advice: run for the hills.
Open Architectures and APIs
You can’t rely on the vendor every time you need to extract data in a different way. You should be able to do it yourself – with ease. Which brings us to the topic of APIS…There’s a lot of talk lately about APIs, particularly in the DCIM field, and its availability from vendors. A lot of vendors are concerned that if they give away too much access to data, they risk giving away the recipe to their “secret sauce.” At Graphical Networks, we believe open data should be an important feature of the tool.
The importance of open architectures and APIs can’t be overstated. A DCIM tool that offers you the data you need when you need it and allows you to develop your own tools is far more valuable, long term, than one that does not.
Import / Export Capabilities
This is related to the previous point, but beyond just architecture, your solution should be able to expedite the process of getting data in and out of the system. Whether it’s for a bulk import process for the initial deployment, or to export a table or diagram to other formats so that the big bosses can see what’s happening, import and export features are a must. Ask the vendor if they can import csv files and excel spreadsheets, import maps from Autocad, import and export to Visio, export to Powerpoint and PDF and so on. Note: we are not talking about discovery or real-time adapters … yet. That comes next!
Easy Discovery and Adapters to Other Systems
Every DCIM vendor – and their mothers – will claim that they have discovery and ways to integrate it to other systems.
Unfortunately, this means diddly-squat without understanding the following:
a) What exactly does discovery mean?
b) How easy is it to create integrations?
In our opinion, if the end user cannot create integrations themselves, then it is too complicated. In this, we are quite adamant: there is no excuse for not having an integration builder or framework. At a bare minimum, the vendor should create connectors for you at no cost. Yes, at no cost. Charging for integrations is, in our opinion, ridiculous. Why? Because vendors are, in a way, already charging you for them in the licensing itself. The more integrations you use, the more stuff you bring in (or racks you use, or square footage you need to document, or whatever it is that counts towards the license).
In a subsequent blog in this series we will cover discovery and integrations in more detail.
Powerful Visualization
A picture is worth a thousand words. Your DCIM solution should have powerful visualization capabilities. If it is just a glorified database, the adoption will be more limited and eventually you will have to find a tool to supplement those shortcomings.
By visualization we don’t mean a few diagrams here and there to check it off from your bucket list. You, as the end user, should be able to create any hierarchies you want, model devices and racks your way, use any icons you want, upload maps and pictures of any type, change colors and rules according to your specs, etc.
We’ll talk more about this in a later blog as well.
Securable
Considering all the stuff we hear about security breaches and the ever increasing audience for Data Center Infrastructure Management functions, you should count on a solution that offers a granular, multi-role security scheme supporting Active Directory, SSL and the whole nine yards.
KISS and Other Licensing Nightmares
You can rock and roll all night and party every day, but we would also advise you to always keep it simple. This goes for starting small, maybe with one data center or one specific problem you need to tackle but also with the licensing itself.
The worst that can happen is to acquire the tool only to find out it was missing this or that module. In our opinion, licensing should be based on something that is easy to understand such as rack or device count. Make sure the vendor discloses right away if there are ANY features that could be excluded.
That’s it for now. Next up: we’ll discuss the importance of determining if your organization is ready for DCIM.
Happy Documenting!
Photo Credits
Shelving
Timer
Data Center
For information about our network documentation solutions, click here.