ISVs must isolate their applications from today’s SaaS platforms to benefit from the improved SaaS platforms expected in the future.

Data storage is very reliable, but still has unexpected and catastrophic failures. That is why you backup your data. You must plan for when things go wrong. It will almost certainly not go wrong in the way you expected, but it will go wrong—sooner or later.
I have seen my fair share of data disasters over the years so I use a variety of media and archive cycles for local backups. For offsite backups I use Jungle Disk. Jungle Disk is a remote storage solution built on the Amazon Simple Storage Service (S3) for data storage and the Amazon Elastic Compute Cloud (EC2) for block-level file updates and other services.
As a “production” user of Amazon Web Services, I follow with interest the increasing acceptance in using Amazon’s S3/EC2 as a SaaS platform. It now seems to be the default assumption that Web 2.0 startups will use Amazon’s platform from day 1 to save a lot of money. Of course, they are also happy to leverage Amazon’s reputation: “If it’s good enough for amazon.com then it is good enough for our users...”
This is all well and good—until the SaaS platform fails—and it will—and then it’s your fault!
If you cannot provide your application services to your customers then it is always your fault! It will not matter what unusual and totally unexpected event has struck your SaaS platform provider.
If your customers cannot get at their data then it is your fault. The trust relationship you have invested a lot to build with your customer will be damaged. It is you that is going to suffer the consequences, not your SaaS platform provider.
It goes without saying that it makes absolutely no sense for you to try to build and run your own SaaS-capable data center. You must depend on one or more external suppliers for your SaaS platform.
To gain the trust of your customers, the level of service you commit to your customers will be higher than that offered to you by your SaaS platform provider.
This “SaaS Trust Gap” between what you must offer your customers—and what your SaaS platform provider offers you—is one of the major risks you must manage to survive and profit from the shift to SaaS.
The right choice of SaaS platform provider is therefore critical to your success.
As the market for SaaS platforms develops they will become increasingly reliable. However, they can never be 100% reliable. For the short term probably. In the medium term probably. But in the long term, no. There are just too many things that can (and will) go wrong.
Assume for the moment that your SaaS platform is unreliable. How can you still provide a higher level of service to your customers than that provided to you by your SaaS platform provider?
The basic concept is the same as you are using today with storage arrays. Simply assume your SaaS platform is unreliable and architect your SaaS infrastructure around this fact of life.
At this point you might object that your provider commits to 100% uptime. They have redundant power supplies, redundant Internet connections, fail over this and that.
While 100% uptime might be their stated goal, even the leading tier 1 data centers have major outages. Even Amazon’s widely-used S3 has not been immune to occasional downtime and claims of lost data.
Even if your deployment platform provider really was 100% available, that does not always help your customers. There are a lot of “moving parts” between your SaaS platform and your customers desktops. You will never be able to guarantee100% end-to-end uptime.
So, what do you do?
In the ideal word there would be a standard for SaaS platforms and a range of suppliers competing on price and availability. You could then develop and manage your applications independent of the underlying deployment platform provider.
This ideal world would make it easier to move from one SaaS platform provider to another in order to improve service to your customers, and to reduce your risks as SaaS platform providers gradually catch up with the commitments you are already making to your customers.
The current market for SaaS platforms is too immature, however, for such a standard to have emerged. And, based on past experience, it is pretty unlikely that anything will happen anytime soon.
We are still at the stage of proprietary platforms, each with their own proprietary interfaces and architectures. We have the well-known players such as Amazon, IBM, Microsoft, Oracle, Salesforce.com etc, plus OpSource, SaaSGrid, FlexiScale and a range of smaller players.
I think the solution to this problem of depending on proprietary SaaS platforms is essentially the same one you have successfully applied to a whole range of technical problems in the past: abstraction.
In the same way that you developed a “database abstraction layer” or a “platform abstraction layer”, you should consider adding a “SaaS deployment platform abstraction layer” to your application architecture.
There are already some SaaS platform technologies coming to market which are clearly moving in this direction.
Take the Amazon EC2 platform as an example. The Amazon EC2 architecture makes it possible to manage and run instances in a flexible, reliable and cost effective manner. However, the way in which you need to interact with the Amazon EC2 “management system” is fairly complex and proprietary.
To address this problem SaaS platform vendors such as RightScale and CloudScale are developing technology that abstracts away the details of the Amazon EC2 platform.
While the current focus is on making it easier to use EC2, the same approach can be extended to make your SaaS applications independent of the underlying SaaS deployment platform.
The market is driving towards “Cloud Computing” and “Utility Computing”, but those clouds and utilities will never be 100% reliable. An often-used analogy compares cloud computing to the electrical grid. We need to bear in mind, however, that more than 100 years later we still have blackouts from time to time!
A competitive market for SaaS platforms will emerge, but to benefit you will need to:
http://isvsurvival.com/trackback/38/
Hi Andrew,
Good article. I agree with your thoughts. That is why ISVs that are planning to adopt SaaS due to customer pressures need to think of SaaS as a multi-dimentional approach that tackles:
- technology
- business
- marketing
- operational
- cultural
All these aspects are equally important to a successful SaaS strategy. You can read my thoughts on this at:
http://sumanchaudhuri.wordpress.com/2008/01/30/multi-facets-of-the-multi-tenant-architecture/
Hi Suman,
Thanks for your comment.
I agree with the points that you make in your post.
What makes the switch to SaaS so disruptive for ISVs is the impact on everything the ISV has done in the past.
One of the main reasons users like SaaS is that they do not have the hassle of building and maintaining their own IT setup. With SaaS the burden clearly shifts to the ISV, who now also has to write the software and keep it up and running.
Multi-tenancy is a method ISVs can use to reduce their costs. The users, however, do not care! As long as they can get the software service at a fair price, it works and can be used when they need it, then they are happy…
The technical features and benefits we are used to talking about when selling business application software go away. In the past we often found someone in the user’s own IT group who cared about the bits and bytes. With SaaS this (rightly) drops away.
Users do not care about technical details of how the software is implemented. That is a concern for the ISV, not for them. This is good. It is a positive sign of the IT business maturing.
SaaS will drive this maturity even faster, as the emphasis rightly moves away from “software” and towards “service”, where it belongs.
2 comments
Join the conversation on article “ISVs will always take the blame for SaaS platform downtime”.