SaaS Architectures
A few months ago (wow... time flies) I blogged (here) about the SaaS ecosystem, briefly describing the different actors (ISVs, Enterprises, Hosters...), their main interests and challenges with regards to SaaS.
Based on that ecosystem, last week at SaaSCon, we introduced the different architectures that these different actors will need to master.
Let see at a high level, what these architectures are about:
SaaS Application Architecture:
The SaaS Application Architecture copes with the challenges of writing an application that is optimized for being offered as a service. Commonly referred by Fred as the 3 headed monster that haunts any SaaS ISVs, the challenges are:
Multi-tenant efficiency:
One of the appealing factor of offering software as a service is to be attractive to the "long tail", i.e. the small and medium businesses, small shops in China, India etc. In order to successfully do so, one has to lower the barrier to entry for these new software buyers. A subscription model (as opposed to a up front perpetual license) helps, but from an architecture perspective to lower the barrier, it is critical to maximize the infrastructure (hardware, database, etc.) Multi-tenant efficiency is the principle that promote the optimization of the underlying infrastructure.
Customization (while being multi tenant efficient):
Being multi-tenant efficient often implies running a single instance of the code (or a pool of identical code instances); in this situation, customization cannot be done through custom code. Customization is performed via metadata and a metadata service. As part of the architecture, a design time (authoring) experience is needed for the creation of the metadata and a runtime engine (metadata service) is required for the application to behave according to the metadata.
Scale:
Typical "on premise" solutions are designed for several hundreds to a few thousand concurrent users. If now, as part of software as a service, you start hosting your software for all your customers then the number of concurrent clients will grow dramatically (e.g. 1000 customers with each on average 1000 concurrent users, could lead to a potential of 1'000'000 concurrent users). The application architecture has to take this into account.
More info about the application architecture can be found in these (previously referenced) two whitepapers Architecture Strategies for Catching the Long Tail and Multi-Tenant Data Architecture.
SaaS Consumption Architecture
If the SaaS application architecture copes with the 3 headed monster that haunt ISVs, the SaaS consumption architecture copes with the 2 headed monster that haunts any SaaS-embracing enterprises. I discussed some of the ideas behind the consumption architecture here, but as a quick refresher, the two heads of the monster are:
Integration
Described in my previous post as "the mise en place", this is about making both the "on premise" and the "in the cloud" services "ready for consumption / ready for composition". This is not dissimilar to the notion of an integration broker or "external service bus" as a joked here.
Composition
Often touted as the ultimate goal for enterprise IT, composition enables the creation of context aware, role specific, user centric applications by assembling and wiring a collection of base assets. A successful SaaS consumption architecture, will need to have a strong composition part. Without going too much into the details here, elements required as part of the composition part are: data aggregation, process orchestration, eventing. Composition is a key topic and to this effect, we are working on a full paper on this, but it won't be ready for another few weeks. I will try to have a post specifically on composition before then.
It is interesting to note, that no later than this evening, I was exchanging emails with my colleague Norman (who leads Marketing in our group) about how appropriate (or not appropriate) the word consumption was in this context. I tend to agree with him that consumption is not very inspiring or exciting. Anyway, term apart, consumption architecture and enabling composition of "on premise" / "in the cloud" is what enterprises need to nail.
Delivery Architecture
It is still unclear how many heads this monster has... but one thing is sure, it haunts any hoster or telco interested in hosting software as a service. Many believe that the delivery architecture is mainly around service management (or operational aspects); things like provisioning, access control (SSO), management (logging, SLA monitoring...), metering (usage tracking, billing). Although these aspects are critical, it is important to include in the delivery architecture "upstream" aspects (marketplace, ratings, ranking, order entry…) and "downstream" aspects (support, usage patterns, business intelligence…). We are currently planning visits to forward looking hosters and telcos to further understand this space and the architectural challenges related to the delivery architecture. If you are a hoster, telco or any other entity working on a service delivery platform, get in touch! I'd love to have a chat and plan a visit.
Aggregation Architecture
Finally, due to the infancy of this discipline, I think the monster is still hatching out of his green egg. Challenges will be of course plenty, but it is not easy to formalize them in a generic way as the end goal and offerings of an aggregator are not fully understood yet. This said, this is an area of great interest and if done properly could create a lot of disruption in the software business. So stay tuned here.
That's it for now, I hope this helps clarify the different perspectives that each actor of the SaaS ecosystem has, and as usual, fore more details on all this, please go to our MSDN SaaS center.
Comments
Anonymous
December 30, 2006
Just for fun, I looked at the blog engine stats and compiled the Hit Parade of the blog entries I postedAnonymous
January 15, 2007
Must read Gianpaolo’s BLOG at My 2006 SaaS Posts Hit Parade . In case if you feel that you need moreAnonymous
March 24, 2007
I've described several times in the past that service providers (typically ISVs) and service consumers