Were you a victim of cloud washing? Did you purchase an enterprise SaaS (Software as a Service) application and find that it was not quite as promised?
Following the pioneering lead of Salesforce, NetSuite, and a host of others that created applications that changed how the enterprise are viewing their IT application portfolios, many traditional applications companies have rushed to roll out SaaS versions of their products without fully thinking through how an application architected to work in a traditional corporate IT environment might need to change to fit far different SaaS implementation requirements.
Turning a traditional application into a SaaS is not as easy as it looks on the surface.
One major difference between a SaaS product and its traditional counterpart is the sales and costing model. SaaS, of course, is generally sold on a subscription base, either by the seat or by the month. Users have the flexibility to purchase only the services they need, but they also do not actually own the licenses, just the right to use the software for as long as they have contracted for the services.
Enterprise customers switching from an on-premise model need to pay close attention to the contract language on what is or is not included in the service. On the vendor side, the supporting infrastructure has to be designed to support usage fluctuations without impacting customers’ experience; outages due to insufficient capacity are not tolerated in a world where customer loyalty is measured in nanoseconds.
Vendors who also sell their products as full licenses to their traditional customer base need to rethink their models when switching to a SaaS model.
Where traditionally there are many opportunities for selling upgrades, maintenance contracts, add-on feature packages, and professional services, purchasers of SaaS software, for the most part, assume upgrades, systems patching, high availability, and maintenance are automatically included in the service.
While third party vendors have turned SaaS customization and configuration into a multibillion dollar industry, smart SaaS vendors have wisely incorporated the basic tools into the product. For example, Salesforce has a vast array of features for their CRM platform, but anyone who has ever attempted to configure it knows that it requires a dedicated staff application developer or a third party integrator such as Bluewolf to build it right.
Another area where traditional application vendors often stumble is not investing in re-architecting their products to take full advantage of cloud architectures’ flexibility.
A traditional application that relies on the underlying IT infrastructure to provide resiliency, redundancy, and high availability needs to be rebuilt to take full advantage of virtualization, PaaS tools, and cloud abstraction. This often means moving more functionality into the application itself.
Ultimately application vendors need to create SaaS offerings to remain competitive, and enterprises need to watch out for cloud washing to avoid being burned by half-baked products that aren’t really SaaS.
