“Cloudwashing” is the currently rampant practice of taking an existing offering and labeling it a cloud offering, even if it’s not. The result is that there’s broad confusion and a dilution of the perceived benefits of true cloud offerings. The benefits of cloud applications and platforms are quantifiable cost savings, rapid time to value and innovation that drives the business. Many cloudwashed offerings cannot deliver these benefits and are merely a way for incumbent vendors to prolong their stranglehold over customers’ IT budgets.
A couple of weeks ago, we were at SIIA’s All About the Cloud conference, which was a great opportunity to connect with our peers in the industry. We decided to take the opportunity to ask these industry experts what they thought about “cloudwashing”.
The results were entertaining and illuminating. They ranged from bewilderment (”I have no idea what it is”) to supremely optimistic (”when you’ve been cloudwashed, you’re SAS70 compliant, have stable APIs…) to skeptical (”when a cloud vendor tells you that a project is going to take days and it take months you’ve been cloudwashed”) to IBM’s surprisingly honest response (”when you take an offering and get it ready for the cloud”).
If it’s this difficult even for industry experts to know when they’re being cloudwashed, it can’t be easy for customers. That’s why we’ve come up with a list of 3 simple questions to ask your “cloud” vendor to see if you’re in danger of being cloudwashed:
- Do all of your customers run on the same logical instance?
- Do I automatically get the benefits of new features or innovation without additional work (e.g. a physical upgrade)?
- Are your APIs stable from release to release preserving my customizations, extensions, and integrations?
If your “cloud” vendor can’t answer in the affirmative to each of these questions, you’re in danger of being cloudwashed. Time to grab your wallet and run!
P.S. Please share your favorite definitions or examples of cloudwashing with us in comments.