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) 

SaaS Design Principle - Open Interfaces

So, you've transformed your enterprise application to SaaS and made it easy to use, do clever things with the data and has been “socialized”. What more could a prospective consumer want?

Well, if your consumer is itself an enterprise, it will start wanting to integrate your SaaS with it’s internal systems and also with the other SaaS systems that it’s using. Secondly others may have ideas of their own as to how to use your SaaS. To do this, you need to provide interfaces to your SaaS application that can be accessed over the web.

This bring us to our next principle of designing SaaS:

SaaS applications should provide functional programmatic interfaces over the Internet that can be accessed by consumers.

First a word about terminology. In the web world, the term “API” is used to mean programmatic interfaces that can be accessed over the Internet. In talking about APIs in the corporate world, I often hit misunderstanding, as many think of an API as a low level programming interface to, for instance, class libraries.

Exposing programmatic interfaces to your enterprise SaaS over the web brings advantages for you as a SaaS provider as well. They increase the attractiveness and versatility of the SaaS offering new opportunities to generate revenue and increase customer loyalty. Rememberer, this is the main difference to the enterprise IT view of the world - tuning your application into a SaaS means that you have to compete in the marketplace with others.

However, you have to take into account that for most corporate IT folk, their world is a cozy one, tucked safely behind the corporate firewall. Opening up applications to the outside world is a scary undertaking. Some have already tried opening up their applications with internal SOA initiatives. Although still behind the corporate firewall, they have had to face the challenges of setting up security policies, providing common identity management, handling service versioning, setting up service repositories etc.. SaaS interfaces, though, have to live in a much tougher environment with a larger number of users who are not under your control, who you have to motivate to use your interface and some of whom can be simply malicious.

This has given rise over to the last years to a set of products with the generic title of API management.

These usually provide two main features:

• A gateway to the application that provides a set of services such as heavyweight security, usage monitoring (needed to bill for the service) and control (who can use it) , conversion to and from commonly used web formats such as JSON etc.. 
• A means for developers to find and understand the APIs and register their usage of the API, usually called a developer portal.

SaaS Design Principle: Easy to Use

This is the forth post in a series on SaaS design principles. This post follows on from the principle described here.

Let’s imagine the following scenario:

Sue is a corporate user of a corporate system to record soil samples for possible toxins. She’s happy that she can use the system now as it took the IT department 6 weeks to issue her with the login. But she’s in the field a lot collecting samples and can only access the application when she’s logged on to the corporate network. As such she makes a point of being in the office on at the end of the month so that she can update it using the data she took in the field. However, this always takes longer than expected as to find out where where the data should be entered is difficult. 

Her boss is also not happy, as her staff are late in entering the data and skip lots of the information that she needs for reporting. 

 Both of these would leap at chance to use a SaaS solution that was, for them, easy to use. This is usually seen as a threat to corporate IT (see this article as an example of this meme). But if you have a easy to use soil sample application (or can build one), this could be the opening of a new market (I have no idea if soil sampling has any market potential, but if you do this and think so then good luck).

The emphasis here is on “easy to use”. Over on this video, Micheal King talks about the implications of difficult to use applications and how this lowers the adoption rate. Although the focus is on BYOD and mobility, it also applies the same to any SaaS application you are trying to create (Bring Your Own App?). The difference is that you are now providing that service (rather than being an IT department threatened by it) and as such have the accept the market reality.

This leads us to our next principle:

The service provided should be easy to access and use over a number of devices.

For any business wanting to develop SaaS offering, careful thinking has to be given to how the user interface is designed from both the technical and usability aspects. This is often something that is not really done well when developing internal IT.

So what are the issues that need to considered?



Device characteristics. Architecting an easy to use SaaS application means that you have to take into account and use the standard user interface functionality provided by the end device. This could be a browser, a mobile browser or a device specific user interfaces (e.g. an App). The architect needs to make the decision if a standard based approach is adopted (e.g. HTML5) so that the user interface functions on a wide range of devices, or if the native user interfaces are used, giving the user a more familiar experience, but with the increased cost of developing and supporting a range of devices. The amount of device screen real estate available is also an important issue.. This goes up with bigger screens, down with smartphones, up again with tablets, down again with mini-tablets. You have to take them all into account.

Interaction Styles. You have to cater for a variety interaction style that the end devices use, e.g.

• Mouse vs. touch screens. How long this dichotomy will last I don’t know, but I have the suspicion that mouse based interfaces will take a long time to die out. 
• Navigation through the application. The typical paradigms used for navigating a smartphone app are different to those used for a desktop application. 

Diverse Users.Typically not considered in enterprise applications, but important for SaaS offerings is that users can be from anywhere on the planet. This potential cultural diversity has to be taken into account so that the SaaS offering remains easy to use no matter where the user comes from. On-Boarding. The principle also talks about easy access. Having a marvelous UI that you can’t get at defeats (literally) the principle. As such allowing users to quickly on-board is important. However, for business applications this is more than just allowing a login with, for instance a Google account and a credit card number. You need to have thought out (both in your business model and the SaaS architecture) how can let users be associated with organisations, especially as you need to consider the basic SaaS principle of multi-tenancy and also the collaboration ideas described in previous posts.

On-Boarding. The principle also talks about easy access. Having a marvelous UI that you can’t get at defeats (literally) the principle. As such allowing users to quickly on-board is important. However, for business applications this is more than just allowing a login with, for instance a Google account and a credit card number. You need to have thought out (both in your business model and the SaaS architecture) how can users be associated with organisations, especially as you need to consider the basic SaaS tenant of multi-tenancy.

Handling these different aspects without rewriting the whole user interface code for each type of device and user requires some nifty architectural design or you find a framework that can do this (or some of it) for you.