cables in a data center

Extra, extra! DCIM vendors recently discovered something earth-shattering: customers just need a tool that is easy to use and flexible so that it can adjust to a set of specific problems in their Data Center… Further, it seems that customers have been mostly unfazed by all the psychobabble, acronym changes and other gimmicks that DCIM vendors have been using.

Seriously though, with this startling discovery, you may start seeing a shift in rhetoric. But, as we know too well,a change in tone doesn’t automatically translate to an improvement in the product.
So, if you ask a DCIM vendor about their approach to flexibility you may get something like: “Our holistic big-data cloud-enabled hyper-engine with interdependent DCSM-IPAMITIL modules maximizes flexibility through synergistic meta-xml SDNs to monetize your patooty“.

Translation: “Here is some McKinsey BS that we hope makes you dizzy,” It’s a well-known postmodernist tactic: when in doubt, obfuscate with big words. At the end of the day, the tool they’re describing is actually as flexible as a block of granite.

The Demise of Rigid Structures

One way data center infrastructure management tools become rigid is when vendors pile up feature on top of feature after having started out as a basic tool to do, say, floorplans and racks. DCIM tools that morphed from a series of acquisitions may also have a structure that is hard to customize.

What do we mean by rigid? Let me entertain an example: a tool that literally has a table in the database called ‘Racks’ that is related to another table called ‘Floors’, with a set of specific fields like ‘FloorNr’, ‘SquareFt’, etc. is rigid. And rigid is bad, because it imposes a hierarchy (racks must be children of floors), it implicitly assumes a finite set of entities to be modeled in the data center (racks, floors) and it makes the customization of fields complicated. Also, the code and the search engine are too coupled with the data store.

How do vendors of such rigid systems “customize” them? Well, let’s continue with our example: now the customer needs to model individual rooms in each floor with more custom fields, so the vendor adds another table called ‘Rooms’ with some lovely ‘field1, field2, field3’ database fields with some extra foo in the code to cope with the exceptions in the business rules and so on. In essence, to make the square peg fit in a round hole they bang on the edges until it fits. Hold on, I need to go get a Zantac.

To add insult to injury, these ‘improvements’ hammered into the code all come with their UI cousins: more ugly forms, more ‘settings’, more steps in the process, more warning messages and so on. Godzilla becomes harder to maintain, buggier and each new feature exponentially increases the complexity.

This may all seem very technical and architecture specific, but rest assured: it has a trickle-down effect into feature release cycles, support and more. As a customer you then realize that the system is hard to use and something as basic as requesting a new device type from the vendor takes weeks or months. Ultimately, we end up with the current state of affairs: a DCIM software landscape littered with shelfware.

Our word of advice: PowerPoint slides and an RFP response are near worthless. Test the product and do a proof of concept using your own data, even if it’s just a few racks.

What In the Tool Should Be Flexible?

Everything. At least in principle. Of course, I am not saying the tool needs to allow so much hacking that you can turn it into a video game, because then you would have a development framework and not a DCIM tool. But, If you really want it to sing, flexibility is a liiiiitle bit more than just stuffing a bunch of tables with a few bonus fields. You know, those ‘Field1’, ‘field2’, ‘field3’ fellas (but hey, you can rename them! Woohoo!

With over 100 customers and thousands of users, here are some of the main requests we’ve had,dcim-flexibility-infographic related to flexibility:

  1. Objects, Properties and Their Rules:
    ability to create any new type of object- -regardless of its use, nature or purpose – with unlimited properties and my own business rules
  2. Hierarchy and Diagrams:
    ability to create my own diagrams with the same degree of freedom as in a drawing package like Visio or netViz using my own hierarchies and parent-child relationships
  3. Hardware Modeling:
    complete flexibility in modeling the more complex objects – like racks or devices
  4. Cables/Circuits:
    ability to design my own cables and circuits, from layer 0 cables to layer 7, define its fields, associations, connector types and business rules
  5. Automation and Discovery:
    ability to create custom adapters to external systems, including some legacy non-commercial database and ability to map any private MIB to any custom field in the system
  6. API, Importing and Integration:
    provide an open schema and API – web services, RESTful – with the ability to integrate with virtually any other system
  7. Reporting, Scripting:
    ability to create my own reports, dashboards, custom functions, aggregated fields, and so on…

Let me be clear: our customers want to do all of the above themselves. So, if you are a customer and need one or more of the items above, ask the vendor point blank: “can I do these things myself or do I need to send you a purchase order for services every time I need a change?”

Notice something else that’s interesting: none of the bullet points above involve the term DCIM. Ah, I know what you are thinking: “but if the software is so generic then in order to do specific DCIM-ish things it would involve too much customization.” Worry not, my friend.Having a flexible tool does not mean more customization work. More flexible means just that, more flexible. A proper tool will be pre-configured so that it works in a way that is consistent with standard DCIM requirements. Then, after implementing it, you can easily change things where your implementation deviates from the norm. Back in the day (before PRINCE2 robbed the term for its own purpose), we called this the “Management by Exception” principle.

Talk is Cheap – Show Me the Code

Paraphrasing my fellow Finn Linus Torvalds, and with a lot of “Sisu“, in subsequent blogs we will cover points 1 through 7 above – with real examples and videos – so you can see for yourself what real flexibility is!

Stay tuned!

 

About Jan Durnhofer

As CEO / Product and Engineering Manager, Jan joined Graphical Networks with the purpose of creating the most advanced DCIM and IT visualization company in the market.