SaaS Design Principle: Socialize the Process

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

In a typical enterprise, users make a business process work in spite of the applications they are using by: 

• Warning other users downstream in the process of problems that are coming their way. 
• Asking users upstream in the process as to why something has happened.
• Collaborating with each other to solve problems. 
• Seeking out who can give them advice, or giving advice themselves.

Traditionally this is done using media outside of the application (telephone , email, walking down the corridor etc.), reducing business efficiency. 

However, many users are using cloud products to organize their own social life - for instance: using Facebook to arrange meetings, using Google Docs to set up club fixtures, sharing calendars with their spouse. As such they are expecting to see these types of facilities in the application that they use at work. This also has business advantages, especially when viewed in the light of how businesses are run these days: 

• Processes are becoming more automated, meaning the users tend to only see those cases that are difficult and cannot be handled by the automatic process. This leads to a collaborative problem solving approach. 
• More users are working from different locations using mobile devices. As such, they lack to usual means of communicating with their colleagues. 
• More processes are being run across different companies, different geographies and different time zones. As such it can be difficult to know who to contact when an issue is raised. 
• More customers are looking to interact directly with a company using a wide range of devices and platforms (and for many e-mail is history and post is a fossilized dinosaur). End customers are effectively becoming  users, in that they interact directly with the business processes. 

As such cloud based applications have to build in what Geoffrey Moore has called Systems of Engagement. Typically, many in enterprise IT are mired in the system of records mindset which has been the dominant model for enterprise IT in the last decades. However, as Geoffrey Moore says:

 “...the thing to register about systems of record is that they are mostly and largely complete, particularly within larger organizations. Are they perfect? No. But these systems of record are no longer a source of competitive differentiation for organizations. They are a necessary condition of doing business.” 

Systems of engagement however : 

"... begin with a focus on communications. ... These communication capabilities will also be complemented with new collaboration capabilities."

This leads us to our next design principle for SaaS architecting: 

Users involved in a process should be able to communicate with one another.

And here “users” are also customers and partners as well as the typical staff member. 

As to be expected, this has implications for the design of SaaS applications. Rather than just using basic communication services, architects of such systems should carefully think about: 

• How collaboration can be made effective by integrating the social features with the actual processes (for example, setting the context of a chat or collaboration around a business entity such as a specific customer, a specific product, or a particular process etc.)? 
• How users communicate with one another?
• How can the user base contribute to best practices, for instance by assigning user generated content (a typical hallmark of social aware applications) to process steps? This can also provide valuable feedback on how the application could be approved. 
• How to identify and contact the experts you can turn to for advice. 

This makes a SaaS application a very different animal to what typically exists within the enterprise today.

SaaS Design Principles - Use Data to Add Value

Continuing on from my previous post I’m going to start the first SaaS principle with a statement (according to TOGAF this is the correct way), but then I’ll get a little more informal. First the statement:

Data (or aggregations of the data ) should be made, in a controlled way, available to other users of the service or related services. 

Amongst all the talk from prospective SaaS consumers about how secure is my data, this is actually one of the major ways in which SaaS providers can differentiate themselves.

In the consumer space we are all very familiar with this. The well known “other customers who bought this also bought....” bring both extra value to the provider as well as the consumer. We all accept that to do this, the provider has aggregated data from other consumers and made the results available to others.

How though, could this translate to the enterprise world? Here are a few ideas:

• A logistics service collects metrics concerning the frequency of deliveries to individual locations. An aggregation of this data can be used to provide help to the transport companies in where they provide transport.
• A credit rating agency provides an SaaS offering for retailers to check the credit rating of consumers. The aggregated data on the financial transactions can also be used to capture spending trends.
• Data from business travel services can be aggregated and used to improve the service.

PAC have provided a good example of this in their blog and have linked with this two trends: cloud and big data.

In order for this to really work the SaaS offering needs to be trusted by the consumers and building that trust is one thing a SaaS provider has to take into account. This is a subject in its own right.

 So far we have concentrated on aggregated data, effect having made the assumption that data from different users is isolated from each other, i.e. the hallowed multi-tenant principle. However Stefan Reid from Forrester has suggested that actively sharing data with more that than one tenant can allow enterprise to set up a business network, enabling - as he says:

 “... business partners, exchanging goods and money, to collaborate and share data real-time on a single cloud platform based on trust-relationship-models rather than by mapping and exchanging B2B-data.” 

 This is not so futuristic as it first seems. Many firms today are sharing data for simple processes in the form of Google Docs. For instance, firms in a partnership can use the built in collaborative facilities to prepare a joint proposal. Stefen, however, goes further with the idea and suggests that data that is usually regarded as sensitive can actually be shared to reduce external process costs.

Seeing and exploiting these possibilities has consequences for the SaaS application architecture as shown below:

Firstly the data collected needs to be available to any analytic system being performed on it. This if course has security and trust aspects. Secondly, as large amounts of data may be being collected the storage requirements can increase significantly. Having collaborative tenancy areas also increases the complexity. And not to forget the speed at which the analysis needs to be performed has a large effect on the architecture of the application - the quicker it needs to be, the more parallelisation needs to be built in.

Sharing data is one way of exploiting the cloud. But what about the other side of the coin, the business processes. How can a cloud based solution bring extra value to business processes? This is to subject of our next design principle.

Principles of SaaS

Over on InfoQ you can find a recent presentation from Anne Thomas Manes that covers what needs to be considered when building applications that should run as SaaS, i.e. how do you make an application “cloud aware”. The presentation had a surprising architectural focus in which Anne took the a set of desirable cloud characteristics such as elasticity and on-demand and then derived a set of principles from these, i.e.:

• Latency Aware
• Instrumented
• Failure Aware
• Event Driven
• Parallelizable
• Automated
• Consumption Aware 

From these she went on to show the patterns that enable these and the anti-patterns that get in the way. One of the themes that ran through the talk was that architectural decisions made in the design can have large impacts on the costs incurred in running the SaaS application - using the wrong pattern can be very expensive!

I was particularly interested in the principles. As far as I can see they’re a good set and I’m glad that Anne has succinctly described them. My gripe though is that they only address what needs to be done in writing a SaaS application. They don’t cover what needs to be designed in so that the application actively exploits the advantages to be gained by running it in a cloud. It is a bit like saying that a car should have wheels. True, but to be able to exploit the potential rapid transit times offered by a modern road infrastructure you need to design in that the car is quiet and stable at high speeds.

This kind of thinking is especially acute in the enterprise IT world, where many are only looking at moving their existing applications “as is” into the cloud (this is implicit in Annes talk), rather than looking to see what extra potential a cloud based solution could bring. Effectively they are not asking the question “Who could be the customer for my SaaS solution?” and defaulting to thinking that it is the same as before, i.e. their own staff.

With this in mind I’d like to explore in the next posts some of the design principles that could be - or should be - built into SaaS offerings so that the migration into the cloud can bring something extra.