If It's Not Broke, Break It

In my last entry I covered some of the challenges that legacy storage vendors have when adding new capabilities to a storage system not designed to support them. At some point though, does it make sense to start fresh and leave the legacy platform behind, basically breaking what isn't broken?

Capabilities like deduplication, thin provisioning and automated tiering can be added to a storage system via third parties, and many of the vendors have their own development efforts to add them. The challenge is when you require backwards compatibility on a new storage system or storage software, you limit the developer and can end up with awkward workarounds. At some point in the lifespan of a product, suppliers should realize that they need to start fresh. In storage hardware and software this should happen more frequently that it does today.

How long you extend the life of a hardware or software product from a development perspective depends in large part on the flexibility of the original foundation. We have storage systems whose software is based on 20 year old foundations. At some point, no matter how good the foundation, the customer may be better served by taking the combined knowledge of the organization and starting with a clean slate. A fresh look at leveraging the most modern development tools and techniques, with a clearer vision of what is coming and needed in the future should lead to better, easier to use, and more capable storage systems.

I'm suggesting that suppliers should part with the conventional wisdom of "If its not broke don't break it" and do just the opposite: break it. I don't understand the resistance to this strategy. If the supplier doesn't do it, someone else will. That's where startups come from, often founded (and funded) by the people that started the original company. It makes more sense to give creative people a place where they can reinvent things, instead of forcing them out the door. Starting over and doing the work internally can't be more expensive than buying the startup to get to the features that you couldn't add in a logical way to your current platform.

From a customer perspective, customers typically buy for two reasons; capabilities of the product and the service that they will get from the organization. While backward/forward compatibility is important and you want to be able to add new features to existing products, at some point most users realize that they will need to go to a new platform with new interfaces and capabilities. They do this all the time when they decide to move from Vendor A to Vendor B. All I am suggesting is they might rather move from Vendor A-1 to Vendor A-2 so they can keep the same service organization. I think this also then solves the innovators dilemma that plagues larger vendors. Just admit upfront that you are going to reinvent yourselves every ten or so years