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.

[ No primary storage strategy is complete without a storage virtualization plan. Check out SAN and NAS virtualization under the hood. ]


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.