Taxonomy of SaaS Platforms


The advent of SaaS has ushered in quite an exciting (and still unfolding) age in the IT industry. By its very nature, SaaS brings ever more diverse sets of software functionality to a much larger audience. With this, however, has come a slew of new terms, old terms with new meanings, and new concepts. The single most important new concept, in my opinion, is the introduction of the SaaS Platform, or also known as an on-demand platform (full disclosure, Apprenda is creating a SaaS Platform). Nowadays, the word on the street ’platform this’ and ‘platform that’ but if we get down to the grit, what does ‘SaaS platform’ mean and how can we categorize different platforms?

In this post, I’m going to provide a simple definition of a SaaS platform (I’m sure I’ll expand on it in a later post). In essence, a SaaS platform is a software and hardware layer that allows the applications it hosts to be distributed in a multi-tenant, service fashion without having to explicitly engineer the distribution model. It can conceivably be thought of as the next level above the application server/application container (JBoss, IIS, etc.).; a ’super container’, if you will. As I mentioned, the industry is abuzz with the word ‘platform ‘, but do they fit this definition? This was a question I struggled with for a while, and the answer is, yes! The problem is, everyone is referring to the concept of platform from different angles. Some vendors have reclassified complex APIs as platforms (undoubtedly thanks to creative marketing), others have aligned and augmented these APIs with a vertical/horizontal ecosystem, while still others have defined something even more general. This creates a confusing message to the industry. My goal with this post is to detangle this message and break it down to a purer form. Each of these adheres to the aforementioned ‘SaaS Platform’ definition at some level, but they are different in that they aim to achieve different goals. For example, Salesforce.com has heavily touted its platform for some time now. Initially, the platform was a robust API that allowed other vendors to tap into Salesforce.com’s powerful application model and build added functionality into it. Later, Salesforce.com moved away from this and created something known as the AppExchange, which became an ecosystem for CRM-aligned SaaS applications built on their platform. Recently, Salesforce announced a new, more powerful platform named Apex that supersedes all previous notions. Notice anything? They called each one of these a platform,
and to some level, rightfully so. The concept of platform has transcended the deliverable, scorching a path through multiple implementations. Similarly, companies including NetSuite and WebEx have announced intentions to release or have already released platforms of their own. All of these platforms vary in form. This variation allows us to generally bucket each platform into 4 broad classifications:


(bigger)

The nesting in this quasi-Venn diagram serves a purpose, but I’ll get to that in a minute. The breakdown is relatively simple:

  1. Product-centric SaaS Platforms – A platform that relies on a core application or product for consolidated data and/or functionality. This type of platform is very much a hub-and-spoke system where the product lies in the center and platform tenants (other applications) tap into and extend the product. While a ‘marketplace’ may form, the more formal public ‘ecosystem’ concept generally may not exist. Examples include API-linked SaaS applications like RightNow and Taleo.
  2. Vertically Aligned SaaS Platforms – A platform that attempts to consolidate common functionality for an industry vertical and provide that functionality as a commodity to its tenants. This allows for an ecosystem to develop around a niche market with the platform provider at the center. Ecosystem strategy and goals may be influenced by the providers needs.
  3. Horizontally Aligned SaaS Platforms – A platform that attempts to consolidate common functionality for a horizontal. This allows for an ecosystem to develop around a niche market with the platform provider at the center. Ecosystem strategy and goals may be influenced by the providers needs. Examples include Salesforce.com’s Apex and WebEx Connect.
  4. General Purpose Platforms – These are platforms that aim to consolidate SaaS functionality and provide value-added services for tenant applications to tap into. Their goals tend to be delivery-oriented. Generally, ecosystems within this category are not dependent on the provider, but rather the platform provider may act as an aggregator with no underlying goal other than success of the application providers residing on the platform. Apprenda’s upcoming SaaS platform is an example.

The classifications help identify the ‘out of box’ experience, and generally also helps shape implementation expectations. As I mentioned, the nesting is also important; it identifies containment and overlap potential. An application platform (product-centric) can be built on top of an existing vertical, horizontal, or general purpose platform. Similarly, a vertical/horizontal platform and ecosystem may develop within a general purpose platform.

I plan on expanding on this taxonomy in the future, so definitely feel free to comment!

Information and Links

Join the fray by commenting, tracking what others have to say, or linking to it from your blog.


Other Posts
SaaSBlogs.com: Most Popular Articles of 2006
Forget Web 3.0 – Let’s Talk Software 3.0



Write a Comment

Take a moment to comment and tell us what you think. Some basic HTML is allowed for formatting.

Reader Comments

Thanks for the article. It was quite usefull and understandeable even to not-so-technical person (like me ;-))

I hear about some SaaS Enables for ex. OpSource. Under what category you will categorize their platform ? Probabaly General Purpose Platforms…?

Hi. Well, I don’t think they directly fit the platform definition described in the article. Here is a link describing their Optiaml On-Demand service:
http://www.opsource.net/solutions/ds_optimalod.pdf

Really, their value proposition is based on outsourced operations for your SaaS business (servers, staff, support). They do not provide a software layer that provides you with SaaS tenets like multi-tenancy and data partitioning, the vendor needs to develop that.

Good post! As you suggest, the SaaS saga is “still unfolding”. Right now we are at the stage where SaaS is displacing the old work horses in large and medium scale enterprises. But ultimately it will not be about replacing horse carriages by cars (although that will happen), but about making a Model T affordable to a whole new class of buyers. I believe that the focus in SaaS will gradually move away from selling to large and medium enterprises to selling to networks of micro-firms. Growth, innovation and value creation will happen at this new edge. Do keep this transition in mind as you develop your taxonomy.

After reading few articles, few blogs I came across lot of jargon… SaaS, SOA, service delivery platform, multi-instance vs. multi-tenancy etc. etc. most either talk about platform or about application but none about all this in one single article giving clear picture of what connects all these things…

What is still not clear to me is:

- When we talk about multi-instance vs. muli-tenancy, are we talking about the application or is it the platform too which needs to be multi-tenant
- Is it enough for just application to be multi-tenant in order to deliver successful SaaS application or is it so that underlying platform also need to be SOA oriented at the same time ?

I am not so technical person, so please if someone could clarify in simple words

Hi Vibjor,

I think your question will make for a great post and it would be nice to see Sinclair right one about it, but in the meantime here is a short answer:

In short, Multi-Instance is very different than Multi-Tenant. In fact when talking about SaaS, they can be discussed independently.

Let me start by clarifying a couple of terms for you.

Customer: A single entity that uses an application. It can also be considered an organization, company or group of people.

Single-Tenant Application: An application is considered to be Single-Tenant when it is build to handle one customer at a time. For example: Traditional software is written to be Single-Tenant because traditionally one would buy software and install it on premise to be used by the purchasing entity.

Multi-Tenant Application: An application is considered to be Multi-Tenant when it is built to handle many customers at a time. These types of applications are a lot harder to write than traditional applications because you have to take into account data separation so that each customer only sees their data, provisioning, etc.

Single-Instance: As the name implies, Single-Instance means that there is only one instance. In the context of Software it means that there is only one instance of the application.

Multi-Instance: Opposite to Single-Instance, Multi-Instance means that there are multiple instances of an application.

Now that the definitions are out the way, here is the answer: To achieve the best economies of scale and benefit from all the benefits of SaaS, a true SaaS application should be Single-Instance and Multi-Tenant. Meaning that one instance of the application should be able to handle more than one tenant (also known as Customer).

To specifically answer your questions, Multi-Instance shouldn’t come up when talking about SaaS except of when you are talking about having multiple instances of specific services for scaling purposes. In my opinion a SaaS platform should be able to handle the Single-Instance, Multi-Tenancy part of the equation as long as the application is written in a fashion that can allow for this, for example SOA.

For your second question: I don’t think it is a pre-requisite that the platform is written as SOA to achieve multi-tenancy for applications but again you would be lacking all of the benefits of SOA and depending on the goal of your platform it would be very hard to achieve the results if it is not SOA. What I mean by depending on the goal of the platform is that some platforms are meant to support one application and in this case you might be able to get away without writing it SOA but if the platform if meant to support more than one application then I think it will be hard to achieve the results and the scale necessary if it is not written as SOA.

I hope this helps and answers your questions and hopefully Sinclair can write a post about this.

Regards and have a Happy New Year,

Abe Sultan

[…] Regardless of whether one believes that Darwinian evolution is how the species of this planet came to be, most will agree that the premise and underlying structure of evolution is both powerful and to some degree measurable in the real world. One of the most important things to ask IS “Why study history and why attempt to understand the underpinnings of our origins?” The answer, in my opinion, is simple: we study history to mitigate risk in the present and future, and build on a foundation of measurable results. That said, understanding how SaaS came to be, and where it’s heading with the powerful concepts of the SaaS Platform and ecosystem. This complements one of my earlier posts regarding the categorization of SaaS, and I’m definitely looking for input as I view the unfolding of these definitions a communal effort. […]

[…] Phil Wainewright just posted a breakdown on SaaS platform/ecosystem flavors titled “What flavor is your ecosystem?” His breakdown is at a slightly different angle and a finer grain than my article categorizing platforms. The categorization seems to classify ecosystems and platforms based on implementation mechanism, which is an excellent categorization in its own right. At the end of the article, he states that “The most successful ecosystems will be those that offer the most popular balance between convenience and flexibility” which is a distilled and parallel version of an article I wrote awhile back regarding SaaS enablement selection and flexibility vs. transparency (It seems that according to Wainewright, convenience comes at a price, namely loss of transparency and a higher lock-in/coupling flavor with the enablement technology). I agree with Wainewright 100%. My bets are on flexibility. Although convenience can be a powerful thing, our industry has learned (I hope) from the effects of unnatural lock-in and random introduction of technologies that “go against the grain” already defined by the industry. The best solutions are those that get the job done with no added baggage. This does not, however, mean that convenience needs to be abandoned. Convenience can be delivered in a fashion that maximizes flexibility. […]

hi. thanx for the article..
however, the more i read SaaS and try to understand it, the more i got confuse hehe

so, what the difference of SaaS and ASP? is it in ASP the customer is treated as an instance? is it single instance or single tenant?
and my last questions are what are the model to deliver SaaS? and what the technology behind it??

if it to broad to discuss it in this blong,could u give me some links to extend my knowladge?
thanx u before

Hi, Thanks for the comment. ASP was generally a situation where an application was hosted single instance, single tenant. Imagine hosting something like Word or Excel and streaming it for a single tenant or subscriber and streaming it or simply slapping a web frontend and relaying functional requests. ASP can be categorized as SaaS. Today’s SaaS is much more flexible, much more tenant aware allowing for tenant customization, etc. and is generally web-native.

A good link is the Wikipedia article at http://en.wikipedia.org/wiki/Software_as_a_Service

[…] with Amazon’s EC2 or now with Microsoft’s Azure. For any long time readers, I wrote a taxonomy article a while back that distilled SaaS Platforms (which have materialized under the PaaS banner as of […]