Randy Kerns made a good point in a blog recently. He said that IT customers are looking for “best of need” solutions, not necessarily “best of breed.” The distinction he drew between the two was that best-of-breed solutions probably contain more features than the user needs at the time or would probably need in the future, and they cost more as well. Time frame is a key consideration, since the refresh cycle of IT products is often only a few years.
In a perfect world, users would buy products designed exactly for them (best of need). But in an effort to get their most important requirements met, they often settle for products that have more than they really need (best of breed), like more performance and more features — at more cost. Sometimes this is a “nice to have” vs. “need to have” evaluation, but not always. Sometimes what a customer needs isn’t available, at least not in a single product, a situation that represents an opportunity for VARs and integrators.
A VAR opportunity
A good integrator can design a system that’s a better fit for what the business needs and prevent them from having to buy much more. VARs can take a more general product from the manufacturer and customize its implementation so the user doesn’t need to buy a higher-cost, industry-specific version of the technology. Or they can take a base product and skip the higher-priced option offered by the manufacturer, instead using a third-party product to provide the “need to have” functionality.
An example could be using an OS or application-level clustering package to set up a redundant database server for high availability. This is certainly a “best of breed” solution, providing near-instant failover between servers. The database vendor’s installed base includes many customers that need this kind of high-performance feature; in fact, the vendor probably developed this option in response to those very customers. But if the need is for failover in a slightly longer time frame, maybe a minute or so, then a “best of need” solution could look different.
A second copy of the database application could be set up on a standby server and kept in sync with a third-party replication package that allows automated failover in a few seconds. It could even be used as a standby server for multiple applications, reducing the cost of a 1-to-1 failover configuration. Or the failover server could be run as a VM, depending on the performance and capacity needed and the risk preference of the users.
Sometimes, needs are met more cost-effectively by combining products instead of buying one vendor’s solution. Capable systems integrators can be very valuable in these situations by providing a different path to a (more) satisfactory solution.
Follow me on Twitter: EricSSwiss