There are many facets to the approach of cloud computing. One is the various and variations of business models that are available, another is the way different companies are approaching the cloud and how they are offering different services.
There are two primary approaches to offering cloud based solutions.
SAAS
The best known of these is Software as a Service (SaaS). The concept of SaaS is that a company (provider) offers a software product that is consumed and paid for as a service. Rather than downloading and installing software on computers, a customer would simply open their web browser, type an address and start using the software.
There are benefits of this approach. Obviously, the application is available on any device that has a web browser. This means that there is no software to be written for Windows, Mac and other devices – write it once and it runs anywhere.
There are also trade offs with this approach. These include latency (the time it takes for the computer to talk to the applications over the internet), disconnections (e.g. on a plane) and richness. Richness can be managed by using technology such as Flash or even Silverlight. However, not all browsers support these technologies (and I’m not just referring to certain tablets), so when these technologies are relied on, it can break the primary benefit of the SaaS approach.
Who is using this approach today? Many companies use this approach today including Xero and Google. In fact, the SaaS model seems to be driven largely by Google – which is hardly surprising given their strategy.
Software + Services
The other approach has been labelled Software+Services (or S+S). Software+Services emphasises the user experience and offline connectivity over portability. That is that this approach has a client solution that uses web services of some description (be it ReST, SOAP or something similar) to connect to a server on the internet which provides a service. In some cases, there may be a SaaS solution that fills the gaps in portability but the main solution is based on the client applications.
Benefits of this approach are that there is no problem with richness as information can be cached locally and manipulated by the user on their device. The client application generally has offline capability and is not sensitive to latency as SaaS solutions tend to be.
The disadvantage of this approach is that the client needs to be written for each platform being targeted. This may mean writing an application for Windows, Mac, Linux or the various i-something devices. Where this becomes a real problem is when an update is made, it needs to be rolled out to each of the applications in turn. This can make the development process cumbersome.
Who is using this approach today? Microsoft and Apple both tend to use this approach – which makes sense given both companies have a client business to build upon.
Hybrid
Increasingly today, solutions start as a SaaS model but then see the advantage of having the rich clients, but don’t want to maintain them. What to do? The hybrid solution provides a middle ground between these two solutions by building a SaaS solution and then building in an API. The beauty of this is that if a customer wants a client application badly enough, they can build one themselves.
The benefits of building an API are several: Firstly with critical mass (note that critical mass must come first) this can enable an ecosystem around your SaaS model, which means that people can build an applications and possibly sell it and make money for themselves or give it away to build their own reputation (and when they are smart, their own business). When this happens, your customers get the best of both worlds – they get your great SaaS application and the client apps for richness, but you don’t have to maintain it. Alternatively, if you want to build some limited applications, you are also free to do this.
The disadvantages associated with this is that you don’t control the user experience from end to end. This has a number of flow on effects. For example, your company logo/brand is likely to not be used in client applications (or perhaps it will). Another example is support. Customers may get used to a client app’s way of doing things and the developer may stop producing that application, which may cause end user confusion. Often customers don’t understand what services you do and don’t provide, so they may email your support facilities about a problem which is really with the client software they are using.
Who is using this approach today? Flickr, Twitter and a host of others use this approach extensively. Other companies use it to varying degrees – e.g. Xero has an API as does Toodledo and others, but in some cases finding applications is very hard – and in most cases is dependant on the target audience for that solution as well as critical mass.
What does the future look like?
At the end of the day, when we look at the current range of applications most used by end users, some of them work well as a client based solution and won’t go into the cloud very easily, others will disappear into a SaaS model very easily. There are applications that might need to change before it can make the leap to the cloud (ala Xero taking a direct connection to your bank account), but in some cases this might not happen easily or seamlessly. Some applications need device capabilities (e.g. GPS, scanners, etc) which will likely to necessitate a client approach. In saying this, there is no one model that will suit all solutions in all cases, however, we will, I believe see some trends particularly with existing application models.
Personally, I expect that the S+S and hybrid models will be generally more popular for the next few years. I see the S+S model potentially strengthening further over time as compelling devices and client delivery methods for accessing the cloud become more commonly accepted among users and drive the S+S model rather than the SaaS or even the Hybrid model. Watch this space.