The Universal User Interface

Have you ever taken a journey that ended up with you approaching a familiar district from a completely different direction and felt that it all looked different? I hope to give this feeling of jamais vu with this post, but with an architectural journey instead.

One of the holy grails of many enterprise architects is the universal user interface. With this, a company only needs to install one user interface on its end devices and this can be used for every application. In the last decade, many EAs thought about this and often came up with architectures that looked something like this:

This has a number of components:

• A view component to display the screens etc.. This could be customised by a look and feel specification that usually adhered to corporate standards.
• A component that handled the behaviour, i.e. validation rules. workflow etc.. The wish was also for a specification “language” that enabled this to be customised.
• A model of the data (echoes of the model-view-controller paradigm here). The structure could also be customised by a model structure specification to the application at hand. 
• Some local persistence so that the user could work offline (a favorite requirement from business users). 
• And finally, a communication component so that the universal user interface can communicate with the server.

So far, so good. In the last decade, a lot of thought was given by a lot of EAs in a lot of companies as to how a universal user interface (let’s call it a UUI) could be implemented. Various attempts were made to implement them. Often these resulted in failure as the skills necessary to build something like this were not in-house. Sometimes, external frameworks (such as Eclipse) were used to create user interfaces and these went some way to reaching the goal of a UUI.

And now back to a familiar district with hopefully a new view on it. I contend that we already have (or nearly have) the UUI and it is installed almost everywhere. Its called a browser and it’s come a long way from its humble beginnings as a mere viewer of information. Mapping current browser standards to the architectural model for a UUI clearly shows this:

Some of this has been there for a long time and is used extensively. HTML for the model structure is an example. However, this is changing. With single page application architectures this can end up just being a set of tags with class information that is processed by the CSS and JavaScript. 

Some is new. For instance, the local storage standards for IndexedDB and FileAPI are still not W3C recommendations. However many browsers are already supporting the current versions of these.

Understanding that the browser really is the long sought after UUI - jamais vu no less - isn't really widely acknowledged (try googling “universal user interface”). However, accepting this means that EAs can start thinking about the skills they need in-house to exploit the advantages of a UUI  they already have installed.

API Management - Towards a Reference Architecture

In one of my previous posts, I extolled over the virtues of opening up APIs over the web so that others can use them. A prerequisite for doing this was that an API management tool (a new breed of middleware) had been deployed. Although I gave a short - architectural- overview of what an API management system should comprise, I stopped short of giving a full reference architecture. My reason for this was that I couldn't find one - especially one that was vendor neutral (and a good reference architecture should be).

Not to be thwarted, I've set about creating one. Now creating reference architectures is tough and creating one for a relatively new topic such as API management is even tougher. So you should consider this post as a beta version for two reasons:

• As the field matures we will see a better understanding of what is really considered as API management.
• In my mind some important elements of a reference architecture are missing (better said, they haven’t been done - yet); elements such as the architectural principles, design patterns used and different viewpoints.

The reference architecture described here then, is mainly functional with some structural elements, i.e.:

As the reference architecture doesn’t exist in isolation, it is separated into three contexts:

• The consumers of the APIs
• The API Management itself
• The provider systems that the API Management interfaces with.

The API management itself is split into three main areas, each of which has a number of elements. The elements form a typical set of functions that API management vendors provide. Of course, some vendors provide more.

The Gateway provides the actual API to the outside world, typically as a REST like interface. Consumers are usually applications developed by end users or by other providers who are aggregating functionality (e.g. as mash-ups). Typical elements are:

Translation is often provided to translate internal application interfaces to something that can be used as a web API. Often, this is a translation between SOAP/XML and REST/JSON, but it can also provide facilities to translate data fields or filter the functionality provided by the internal interface so only a subset is available to external consumers.

Licence Key Authentication. Prospective consumers of an API usually need to first register - typically over the developer portal. After this they are provided with a licence key which they have to provide with each call of the API. This component checks the validity of the key and causes the gateway to refuse the request if it was not valid.

Throttling restricts the volume of calls that are made to the API from a particular licensee. For instance, a prospective consumer may have a obtained a free developer licence that allows to the API to be called only once a second. A “production” licence key could allows a higher volume of calls, but has a price tag.

Access Control usually works in conjunction with the provider's identity management systems to control access to the internal API using the identity information provided by the consumer application.

The Management subsystem forms the central management of the API. As such, it is usually the provider’s staff who use this. Typical elements are:

Licence Key Management is used to generate licence keys and determine the policies associated with them. If API usage is payed for by the consumers this also typically maintains who has licences and the licence type. This information is used later for billing.

API Meta-Data Repository contains all the information describing the APIs, i.e. their interfaces and data schema as well as policies associated with them This data is maintained by the provider, but made available to prospective consumers over the developer portal.

Life Cycle Management handles the complete lifecycle of the API: its creation, publication, versioning, deprecation and eventual retirement.

Billing monitors the usage of the API that is used for billing the consumers. It usually interfaces with the provider's own financial systems.

Analytics are typically provided to give information on how the API is being used.

The Developer Portal is a website that allows developers to find out what APIs exist, their details (driven from the information in the API Meta-Data Repository) and also their status (driven from the life cycle management).

Another essential function of the developer portal is for developers to obtain licence keys that they can insert into their own applications.

The developer portal can also provide:

• “How to” information to get a developer quickly up to speed in integrating the API with their applications.
• Means to try out the APIs.
• Social aspects such as comments and forums. 
• Publishing API details to public sites such as programmable web.

As I mentioned, API Management is an evolving field. If you think that some functionality is essential and I haven’t included it, please tell me.

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.

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.