Taxonomy of SaaS Platforms

Dec 27, 2006 by Sinclair Schuller

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!

read more

What is SaaS? The Answer is Rooted in the End User

Dec 1, 2006 by Sinclair Schuller

Wow, talk about a (relatively) hot topic! Recently, a web of blog posts full of coined terms, rebuttals, and re-definitions was spun by some of the blogs I frequent. I recently read articles by Dan Farber, Phil Wainewright, David Terrar, Thomas Otter, Nick Carr, Dennis Howlett, and Vinnie Mirchandani (whew, monster list!) that discussed the topic of “What is SaaS?” After sitting it out and thinking about what I read, I figured I would finally jump in.

    One thing I noticed was the frequent mingling of concerns and perspectives when it came to the debate. In my mind, SaaS can be looked at from one of two perspectives that define the economic, use, and definition boundaries of the distribution model: End User and Provider. When we are trying to define SaaS, we need to understand that the basic definition comes from the End User Perspective, not the Provider Perspective. In terms of a purist definition, this perspective is relatively void of implementation concerns (which should be filed under the Provider Perspective). This makes it difficult for me to agree with the concept that there is a SaaS litmus test whose primary indicators stem from the Provider Perspective. Recently I blogged about “imitation SaaS” and “true SaaS”, but I should have defined the terms to indicate implementation approaches. The article does this, but alas, the two prevalent terms fail to highlight the provider perspective as a context. To summarize the notions of perspective, I mocked up the following diagram:

(bigger)

On the left, I’ve outlined the End User Perspective and summarized some of their concerns; on the right you’ll find the Provider Perspective and their concerns. The diagram has taken the liberty of stating that generally, the End User takes on the work of defining SaaS and their expectations of SaaS, and the provider takes on the brunt of implementation. The concerns from each perspective tend to align with the respective goals. Generally, a customer will look at SaaS as a new way of acquiring software functionality (notice, I didn’t say software). Many of them (particularly those on the far end of the long tail) may not care about how it’s done, as long as their needs (and therefore their definition of SaaS) can be satisfied. Wainewright and Mirchandani (the latter through a comment on Nick Carr’s post) both seem to take position that definition is predominantly a customer’s responsibility.

    The Provider has the goal of implementing SaaS. Can they participate in the definition? You bet. SaaS, however, is an economic concept whose purpose it is to provide value to the end user. As such, the purity of definition should not be adulterated by architectural/technological concepts (a nicely done taxonomy was presented in Gianpaolo Carraro’s Saas and Biology post). Architecture and technology can definitely modify/skew definition, but by no means can it supplant/provide the definition of SaaS. Please note this does not diminish the importance of the Provider Perspective. While the End User says “I Want”, the Provider is the one that says “I have, for $X per user.” If you look at the diagram, you’ll see a gradient “Realized Value” in the middle. Value is defined by the End User needs (positive movement to the left), and how well the Provider can meet or “implement” those needs (positive movement to the right). The further left the End Users go, and the further right the Provider goes, the greater the value. Who is the value for? Both. Once the End User community has reached a relatively stable definition of SaaS, the provider can continually improve upon the ability to implement and deliver. This leads to a lower cost basis, which means that either the Provider passes the buck on to the End User, thereby generating even more monetary value for them, or puts in their pocket creating a larger margin. In my opinion, the most successful providers will leverage multi-tenant, single instance because it provides maximal efficiency and value derivation; it helps the right arrow go far right. The notion of self-service support, multi-tenancy, customization, etc. all bring SaaS to the next level, but they don’t define the paradigm. That said, I think an evolutionary process will weed out many of the sub-optimal architectural/technological/business model implementations, leaving only the most efficient as the dominant approach.

Having the Provider Perspective define SaaS is like the Provider saying “You want” which is great if Provider’s are used car salesmen. So let’s not define SaaS as “multi-tenant this”, or “architecture that”. Leave the root of the definition up to End User needs. Providers, use an implementation that allows you to expand both explicit monetary and implicit functional/paradigm value.

read more