SaaS Design Principle - Let Your Customers Leave

I wanted to finish off with the last principle, but in light of the news of the closure of Google Reader (and the storm of protest it has brought), a new principle seems appropriate.

Let’s image the following – fictional - news report from the future:

“Date 14 March 2018, 09:01. As Sally Bowles (34) came in to work yesterday, she signed into the corporate account of the popular SellTeam Inc. CRM system to see the following message. “SellTeam CRM will not be available after July 1, 2018”. “I was shocked to see this” she recalls, “all my contact data was on it”. Christopher Isherwood, who is the CEO of the Fortune 500 Company, was also not happy, “not only is the data important, but we had spent a lot of money and time integrating it with our other systems.” Laurence Harvey, who heads up the internal IT group added, “ We picked a SaaS solution so that we wouldn’t have to continually install new versions. We were not expecting this though. ”….. A SellTeam Inc. spokesperson explained “SellTeam is currently concentrating its efforts on our new automated sales products and is withdrawing older services such as CRM” in reference to its controversial robot salespersons: SelBots. “

Now, I've posted in the (deep) past about the problem of what to do when your SaaS is no longer available - in the 5 years since I first started listing enterprise service providers a large number of them had disappeared. This seems to me to be an “issue” that we will have to confront in the future, both as provider and consumer. As I have been taking the PoV of the SaaS provider in this series, this leads me to a (new) principle:

Give means for users to move to another system. 

Seem paradoxical. Why would you want your customers to move somewhere else? The traditional way is to try and achieve lock-in. But as SaaS consumers become more savvy (very probably after having a few bad experiences) they will be demanding that movement to another provider is possible - a kind of multi-sourcing strategy as found in the manufacturing industry.

Migration - Architectural Aspects

This has a number of architectural considerations. Firstly you need to provide an export facility that that allows the user to export their data and import it into another system. This implies that standards are used. But you need to be careful here. Plenty of technical standards exist , but exporting a data so that it can be imported directly into another system means that a standard based on the semantics of the data needs to be used. For instance, you can export the feeds in Google Reader to a standard format appropriate for describing feed subscriptions called OPML. This can then be imported into other feed readers (note that Google have formed a group - the data liberation front - who looks specifically at how you can extract your data from Google products). If, however, you have a SaaS application dealing with - to use my previous example - soil samples, you’ll have to develop your own standard.

The above though is the pessimistic viewpoint. It may be that others may want to migrate to your system. Here its also important to provide a means to import data and adopt a standards based approach.

The other consideration is to cater from those who have integrated your SaaS with other systems. This is a tougher problem, but basically comes down to ensuring that the APIs are standards based - at least at the technical level (e.g. REST/JSON), but also at the semantic level and also uses standard integration patterns.

With that I come to the end of this short series on SaaS design principles. The purpose was to show that the pure technical principles as covered in the first post are necessary, but not sufficient if you want to exploit the potential that the cloud model gives you.

An overview of the series is:

1. Principles of SaaS
2. Use Data to Add Value
3. Socialize the Process
4. Easy to Use
5. Open Interfaces
6. Let Your Customers Leave (this post)