I’m sorry, that storage hardware isn’t supported

Do you maintain two or more unrelated current-generation storage platforms? If you do, I bet I can guess why. The back story probably involves a critical line of business application, a software vendor, and a support specification that arbitrarily excluded the storage platform you already had in production. If this scenario hasn’t played itself out in your organization yet, you should be prepared to head it off before it does.

In a perfect world, a well-engineered environment is generally comprised of a single, highly redundant primary storage platform that serves the entire infrastructure. This is the only way you can wring maximum value out of your storage investment. A centralized configuration is easier and cheaper to scale, protect, and support than one based on disparate storage resources. Implementing purpose-specific storage resources outside of this strategy can only serve to make it less effective and waste limited capital and human resources.

Where things go wrong

Grandiose application hardware requirements rarely have very much to do with the actual technical needs of the application they’re attached to. In most cases, the detail, specificity, and rigidity of the requirements will be directly proportional to how important the application is to the survival of your organization. Unsurprisingly, the larger the chunk of money and control you hand the software vendor, the more comfortable it will be in pushing you around. If that sounds unbelievably asinine to you, it is, but I see it happen with startling frequency.

Applications that fit this description will generally enter your organization through the board room, so you’ll be lucky if you have input in the selection process. If this has already happened, you’re already behind the eight ball because getting a chance to dig through the technical specifications before anyone has signed a contract is critical to a favorable outcome. The software vendor will be much more willing to work with you and perhaps even modify its requirements and support matrix if you haven’t already agreed to buy the product. After that, you’re beholden to interests that won’t always match your own.

The core competency of a software vendor rests with the software it has written. Few software vendors work directly with server or storage engineers and, as a consequence, can tell you very little about what kind of hardware an application requires to run well. That won’t stop them from doing it, though. The hardware requirements for most lines of business software are often a combination of guesswork and fairly blatant ass-covering.

Best-case scenario

The best hardware requirements won’t include a particular piece of hardware or suggest a specific vendor unless you ask. Instead, they’ll spell out performance guidelines in terms such as average transactions per second per active user, maximum acceptable storage latency, and general capacity requirements based on your size and other application-specific variables.

If you can get these kinds of specifications, you’ll have the information you need to intelligently scale your existing infrastructure out to meet the long-term needs of the application. In these cases, you can generally assume that your vendor has done rigorous scalability testing and knows how the application will react under increasing load — all signs that you’re in good hands.

Standard operating procedure

Run-of-the-mill hardware requirements tend to be both too specific and too general — and  result in wasted capacity and unnecessarily high costs.

Such specs are born of ignorance rather than malice. If you are able to show the vendor that you have done the research and understand what you’re doing, it will be willing to support you in configurations that color outside of the lines. In the cases where the vendor sticks to its guns, there isn’t much you can do, other than get the executive sponsor in your organization to try some arm-twisting. The best you can do is get involved in the process early, because that’s where you can have the most impact on the form the final implementation will take.

Worst-case scenario

Here’s where things get ugly: The software comes shipped to you in a 42U cabinet full of server and storage hardware. Yes, the most difficult vendors to deal with are those that insist on bundling their software with hardware.

Unless the vendor has real hardware competency and a demonstrable need to deliver its solution in this way, seldom will your organization’s interests be served. You see closed, fully integrated solutions like this more frequently in the health care sector, where support requirements are understandably more stringent. Even in those cases, it makes sense to scrutinize what the vendor provides to see if you can deliver the same services by leveraging your existing infrastructure. Such integrated solutions are a thorn in the side of the IT personnel who have to work around them and should be avoided wherever possible.

The most effective way to keep your storage strategy on track is to communicate regularly with the highest levels of your organization. Make sure to sell the value of adapting current infrastructure to accommodate new applications and make clear that you want to be involved early as new applications are considered. And if you’re already supporting multiple storage systems, don’t despair. Start laying the groundwork for integrating your storage platforms during the next hardware replacement cycle. Primary storage is rapidly approaching commodity status, and it will be easier and easier to make this argument with stubborn software vendors in the future.

This story, “I’m sorry, that storage hardware isn’t supported,” was originally published at InfoWorld.com. Follow the latest developments in storage at InfoWorld.com.