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.

Developing for the Cloud

I’ve recently come across two apparently unrelated articles that together imply a lot about how development for the cloud should be done.

The first refers to post by Steve Yegge. In this he explains how Amazon embraced service orientation and what that meant for the developers and the company.

The second article is from Simon Wardley in which he laments that current “enterprise” cloud developments have a product rather than a utility mindset, i.e.:

Unfortunately, many applications are designed with the best practice for a product world i.e. scaling is about bigger machines, resilience is about N+1 and in general the focus is on reliable hardware. Best practice for a utility world involves resilience, scaling and failure modes built around software i.e. design for failure, distributed systems and chaos engines such as Netflix's chaos monkey approach. There is an inevitable cost of architectural transition from one set of best practices to another.

Both of these provide lessons in how to develop for the cloud:

• Use SOA with clear contracts and a mechanism for handling contract violations. 
• Loose coupling between sub-systems is essential for business survivability in an unreliable distributed computing environment a.k.a. the cloud.
• Develop platforms, and with it the ability to continually extend what’s offered.

What's PaaS?

One of the models used to explain the cloud computing service offerings - derived from the NIST model -  shows the service models arranged as a stack. Implicit in this model is a usage hierarchy (explicitly shown in the diagram below) , that is BPaaS will use SaaS, SaaS uses PaaS to provide an abstraction from underlying computing resources and IaaS provides the basic resources. This seems to make a lot of sense to software architects who recognise a familiar pattern.  

  However, one of the problems I face when talking about PaaS is that many have different preconceptions as to what it is, usually derived from what is currently being provided by various cloud vendors. These range from:

Provided PaaS Services	Example Provider
A set of services for resource allocation in a IaaS service model.	Amazon EC2, Rackspace
Basic middleware and data storage services.	Amazon Web Services (AWS)
A set of application services.	Goggle App Engine (GAE)
Model driven development platforms in the cloud.	force.com
Application development framework for cloud computing.	vFabric, Heroku
A process development framework in the cloud.	Cordys Process Factory, IBM Blueworks Live
Platforms that provide a set of business functionality that can be built upon.	CRM functionality, platforms that provide document management and process automation etc..  PaaS at this level seems to be a underdeveloped model.

Looking at this suggests that the simple model as proposed by the NIST is, in fact too simplistic. So what should the model look like?  

One possibility I like, is to place the PaaS service model to the side of the others and show that they are used by two different roles, i.e.:

PaaS is then a set of functionality that can cover the development needs for the complete spectrum from IaaS to BPaaS, but in practice each cloud service provider will only cover a limited set.

(Update: I've been having some problems with the images displaying. Reloaded them so hopefully it works now.)  

Architectural Decisions

If you are trying to implement any kind of architecture management you have to start documenting the architectural decisions you have made to keep future developers aware of the problems that were faced and why they where solved that way. But what information should be kept? One model I have used in the past is the Tyree-Akermann model (published in IEEE Software March/April 2005). This captures the issue, the alternative solutions considered and, of course, the decision itself. In addition, the model is extended with information that supports the decision (e.g. architectural principles, business factors).

This isn’t the only model that can be used. IBM have developed one in some detail and the ARC42 project has, as part of a software documentation template, developed an implicit model (only in German).

Now, one way to go, would be to consolidate the models to derive a "universal" architectural decision. However, since reading "Architectural Design Decisions as Reusable Design Assets” by Olaf Zimmermann (originally published in IEEE Software Jan/Feb 2001, but now available here), my thinking has been pushed into concentrating on using the decisions to provide a knowledge base for other architects, i.e. reference architectures.

Zimmermann’s paper proposes, that when creating a reference architecture, not only the component, connector, patterns etc. are documented, but also the issues that the architect has to solve together with the design alternatives available in applying the reference architecture to a real situation. These issues - complete with alternatives and recommendations - form a guidance model. This guidance model is then tailored to the project situation to produce a decision model and extended with the actual outcomes.The beauty of this simple scheme is that the guidance and decision models have the same structure making it easier to extract best practices from completed architectural documentation. Zimmermann goes into a lot of detail about this, but I have tried to summarize it with the following two diagrams:

1. The structure of the models. Although Zimmerman uses a SOA reference architecture as an example, the principle can be applied to any reference architecture as I’ve tried to show in the diagram.

2. A (simplified) process showing how the guidance and decision models are used in architectural design.

Two main challenges still remain though - getting your architects to document their decisions and setting up an organisation and processes that can actually extract and propagate architectural best practices.

Quantum computers - a commercially viable option?

Way back at the beginning of 2007 I posted a minimalist comment expressing some incredulity that a company - D-Wave - had been founded to develop and sell quantum computers. I've now just seen that they have sold one to Lockheed Martin for undisclosed purposes.

So when can we expect a quantum computing service in the cloud (a.k.a. QaaS)?

It's Alive

This seems to be the analyst's reaction to the Burton Group's claim, that despite previous doubts, SOA is alive (see David Linthicum's coverage on this).

In talking to clients there does seem to be a tacit acceptance that SOA principles (rather than the technology) are the way forward. However, many do not want to mention the SOA word, perhaps out of fear that the idea will be seen as another (expensive) technology fix, rather than as a partial solution to some of the problems (high costs, unresponsiveness to business demands, lack of innovation) that currently plague enterprise IT.

The SOA Roller Coaster

Joe McKendrick thinks that the SOA roller coaster has moved on and is now moving along the plateau of productivity.

The Internal Cloud

A few years ago we lived trough the rise of the web. For those working in enterprise computing this new world used a set of exotic technologies such as HTTP, HTML, Browser, web servers that had no place in the IT landscapes that existed then. As the business advantages of "e-business"  started became clear, many companies started embracing these technologies so that they too could compete in this space. Whilst this was happening, another, more subtle, revolution was taking place within the walls of traditional IT. The very technologies that powered a company's web presence started finding there way into the design of internal applications. IT managers started demanding that applications became available over a browser; the cost savings in not having to deploy to each client providing a powerful argument for this. Business departments started demanding portals for their own staff and web based interfaces for the growing number of homeworkers.  In the mean time these technologies have become commonplace in most companies and in the area of WS* based technologies have found their own niche.

We now faced with the next new thing - cloud computing. Although many are focusing on the advantages of "moving out to the cloud", are there already "weak signals" that  cloud technologies will become as commonplace in enterprise IT as e-business technologies have already become.

Let's have a look at some of these starting off with virtualisation. OK, this is no brainer as many are already adopting this today. However, virtulisation also leads to having large images for each virtualised application - a obvious cost factor when you consider storage. One way around this, and an idea taken from SaaS providers, is to have a strong form of multi-tenancy. In this model, core functionality remains the same (and is virtualised) but specific processes, rules and screens for different user groups are developed by configuring the core functionality, rather than developing new applications.

Cloud providers have also changed the way we think about databases. Many are under the impression that there is only one type of database and it's relational. However the rise of the NoSQL database has shown that other types of databases have properties that can be attractive for different types of application.

In order to achieve the levels  of performance and scalability that cloud providers need, they seem to have totally  abandoned the three tier architectures that predominate in post year 2000 enterprise systems. Instead, other architectures that either cache the data  or provide ways of directly manipulating objects as if in memory are standard. This has lead to a new class of  application server that performs the heavy lifting of handling  the distributed processing and data behind the scenes - examples include Terracotta, Gigaspaces, and Coherance. These types of application servers have already stated making in-roads into the financial services sector, due to the extreme performance requirements there. From an architectural viewpoint however, there seems to be a grey zone here between NoSQL databases and these "in-memory" techniques. 

The humble batch job can also expect a work-over, with techniques such as MapReduce and systems such as Hadroop gaining ground. 

Bringing this all together on the consumer side there is the architectural technique previously known as SOA coupled up with mash-up frameworks and associated standards. 

I'm pretty sure that eventually these kinds of technologies will become so pervasive in the typical IT shop that we will forget the cloud hype and just get on building systems with them. 

The Virtual Enterprise - Updated

Around 2005 I wrote a series of blog entries (starting here) asking if an enterprise IT could be completely covered by SaaS applications (the word cloud wasn't used then so I talked about a "virtual enterprise"). Gartner now predict that "By 2012, 20 percent of businesses will own no IT assets".

Disregarding if 2012 is the right time-frame, what type of enterprise could dispense with all of their IT assets. I can only assume one in which IT offers no competitive advantage.

Looking back on those old blog posts, I also noticed that a lot of the SaaS companies I mentioned either don't exist anymore or have morphed into something else. If you believed in 2005 that you could dispense with IT assets, then by now you would have realised that you need to be capable of moving your information assets to different SaaS providers and adapting your business processes accordingly. This is probably still true in 2010 and will be something to consider by the 20% of "IT free" companies in 2012.

Coding the architecture or architecting the code

Many have asked the rhetorical question „Should software architects code?” In my experience if you ask that question directly to an architect who does code you get a resounding “yes” and a look that suggests heretical attitudes in just thinking of asking. Ask the same question to an architect who does not code, you get a resounding “No” and are left with the impression that coding is somehow a menial task that real architects don’t need to get involved in.

Sometimes though, if I listen carefully or reflect on what I do or have done, I get glimpses of what software architects hope to achieve by coding. This leaves me with the impression that the question should be rephrased to “Why should software architects code?”

Let’s list some answers:

A software architect has to communicate with the developers in order to guide them in implementing the architecture. Writing code is the only way to communicate the intent of the architecture. Ultimately this comes down to the fact that no “language” exists to communicate architectural intent that is both understood by developers (who read it) and architects (who write it). Although UML goes someway to fulfill this need, judging by the number of architects who feel they should code, it doesn’t seem to go far enough in explaining architectural intent.

The architect has to ensure that the system being developed actually implements the proposed architecture. As documentation is suspect and may even not be there, the architect has to read the code. But wouldn’t it be more efficient to have a tool that extracted the architecture from the code so that the architect only needed to make a comparison? Unfortunately tools to visualize the architecture based on the code do not seem be mainstream, especially in the context of modern distributed software systems (i.e. the type of system we really would like to see the architecture for!).

Architects need to code to understand new components, frameworks, ways of doing things etc. Most artifacts that are intended for general use in the software world are, from the viewpoint of an architect, terribly documented. Instead of providing clear advice on where a component (or framework or library) can be used, what problem it solves and in what context it solves that, most documentation forces the reader to go through page after page of coding examples which only show how it can be used. In short, the how, why and where are not there.

And some just like coding. The problem with this is that the architect can find themselves very quickly on the critical path for development leaving little time for architecting the rest of the system.

Most of the above are about one thing - communication of the architecture - be it from architect to developer, developer to architect (via the implemented system) or supplier/vendor etc. to the architect. Software architects seem to be trapped like the prisoner in Plato’s cave. They cannot see the architecture, but only the shadows of it in the code.

Isn’t about time to change that?

Architecture that learns

I recently came across a rather old (1997) BBC series on architecture - buildings rather than software. The series - "How Buildings Learn " - concentrated on what makes a building adaptable to the continually changing needs of those who live in them. The parallels to software architecture are astonishing. There is even an interview with Christopher Alexander - that's right, the man who inspired the patterns movement.

The Pentagon Model of Service Contracts

Many have stressed the importance of an service contract model in specifying services in an SOA. But what should a service contract contain and what is its structure?

One model I have been using is what I call the the "Pentagon Model". No, this does not have any thing to do with the US Department of Defence, but comes from the broad shape of the relationships between parts of the contract (see the diagram).

The model starts with the premise that any contract is between a consumer and provider and is not directly associated with the thing that is the subject of the contract. Secondly the subject of the contract is the service operation rather than the whole service.

Let's illustrate this with an example. If you were implementing a CRM service then this may have operations such GetCustomer, FindCustomer. It stands to reason that each of these operations has a different contract due to the different interface and that they may well have different SLAs (searching for a customer probably takes longer that just returning one specified by a key value). However you may want to specify different SLAs for the service operations when they are called from the corporate network than when called over a mobile phone connection by a mobile sales force. Most definitely the security policies would be different in each case.

Changing the consumer is one thing, but why also have the contract depending on the provider? Well, you may have a number of providers for the same service interface. For example, the CRM service in Europe may have different response times and access policies associated with it than when accessing the same service interface, but using the CRM provider in the US branch. This is even more important when accessing sensitive information that may be subject to the laws of different jurisdictions.

This model is, of course, a simplification of a complete service contracts model. It starts to get complex when you have to model the policy structure and also have to take into the account that providers can be consumers. But it provides a simple framework to start thinking about service contracts.

Think about the arrows

When doing architecture reviews. I'll often point at one of the arrows on the architecture diagram and ask "what is this?". Depressingly I often get an answer similar to " Well, component A talks to component B". Rarely do I get an answer will actually explains:

• Why the components need to communicate
  
• What information is communicated
  
• What the arrow indicates (e.g. flow of information)
  
• What component initiates the communication
  
• How the information is represented
  
• What protocols are used
  
• What is physically used to transmit the information

In designing an software architecture I've always found it useful to think about what the arrowed lines actually mean as this often provides insights into how the design will actually behave. I was therefore happy to see that at least somebody else also thinks the same way and have submitted a software axiom ("Architects focus is on the boundaries and interfaces" by Einar Landre) to Richard Monson-Haefel's 97 Things. If you haven't come across this before, 97 Things is a set of "axioms for software architects by software architects" and should be published by O'Reilly next year.