SaaS Blogs

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.