Bacon Bits & SaaS: Imitatations are Tasty, But the Real Thing is Better

Nov 1, 2006 by Sinclair Schuller

Whenever I decide to go all-out on a baked potato, I have a few key requirements: sour cream, chives, shredded cheese, and bacon bits. Many people are content with imitation bacon, or eat it for health/religious reasons, but not me. I like the taste of the real thing. Without it, frankly, I can’t eat my potato. Let me correct myself, I can eat it, but I don’t feel like I’m really eating a true baked potato; I’m not getting the value I should be getting out of it because I’m experiencing a degradation in my realized utility (how’s that for mixing bacon, potatoes, and economics?).

The importance of this is in the recognition of true vs. imitation SaaS. I recently read two great articles: one by John Martin for Supply & Demand Chain Executive and another by Brain Reed of the Business Certainty blog (the latter provides a compound summary of the topic, including Martin’s article as a source). I wanted to write on the topic to reinforce the difference between true and imitation SaaS and highlight the importance of how real is better than imitation in terms of utility and value realized by the end users and SaaS vendors themselves. I find that SaaS is still many times confused with ASP, or that SaaS is not understood from the multi-tenant, single instance angle (which IMHO is a defining property of true SaaS).

So first, what is “true SaaS” and why have I so cleverly analogued (made up word) it to “real bacon bits”? Well, true SaaS is defined by the technical merits and architecture of a purported SaaS application. From the architectural point of view, true software as a service, as described by Martin, is one where vendors use “…the same production environment to support multiple customers.” While this is absolutely correct, let’s further that qualification by using the SaaS cliché of “single instance, multi-tenant” which equates to refactoring that sentence as “…a single production environment to support all customers.” Moreover, a true SaaS application must maintain an innate & acute awareness of the notion of a user at all times, isolating execution paths and data from one user to the other while being able to recognize the user “owning” the current execution path. Awareness is what will open the path to per tenant customization. Combining this with the previous notion of single instance, all designed via the SOA paradigm, we have a very powerful concept that transcends the technological “cool” factor and directly attacks the demons that exist to choke the life out of your bottom line. Why is the purity of architecture so important to bolstering the SaaS value drivers and why is it so important to business? Simple. Efficiency, efficiency, efficiency. While retailing popularized “location, location, location”, I think SaaS will find efficiency equally important (at least enough to repeat three times). SaaS, as a model, intends to build economies of scale by consolidating much of the grunt work associated with maintaining an application, while also outsourcing the hosting infrastructure, improving quality of service, and a slew of other benefits. In order to deliver value (real, tangible, sweet smelling ROI), however, vendors must strive for maximum efficiency so that savings can be passed on to customers. Single instance, multi-tenant, service oriented architectures allow the continual, fine grained exploitation of efficiencies required to make it happen. True SaaS allows a vendor to optimize the usage of the underlying infrastructure; in non-tech speak, true SaaS is what drives Cost of Revenue (COR) down and gross margins up. This leads to a stable foundation for executing long-term strategies. You don’t have to worry about COR going through the roof, or selling a product that is going to buckle under either load or functional weight, even at hundreds of thousands of users. You have a stable foundation for executing growth strategies for your company.

So, what is not “true SaaS”? (Please note I said true SaaS; many of these architectures allow for delivery via the SaaS paradigm, just not optimally) For starters, true SaaS is not a standard web application or standard application with a recurring pricing model and subscription management slapped in front of it. There is no notion of multi-tenant in this scenario and any claims to such a feat would be akin to claiming that OS/2 & Windows NT could be made multi-user by slapping a user login at boot. Anyone who has built an OS understands that there are deep, fundamental differences between a multi-user operating system and a multi-single user operating system (like Windows NT, where based on login you are “multiplexed” to your data and that’s about it). Next, SaaS is not inherently more beneficial or cost effective than perpetual license models. It simply opens the door to be more cost effective. Developers and vendors really need to understand this because done wrong, SaaS would turn out just as bad as its perpetual counterparts. Let’s not forget that a company looking to purchase a perpetual license need not pay up front, they can finance and amortize the cost over time. In order for SaaS to be more cost effective, SaaS vendors need to concentrate on exploiting the efficiencies and economies potential of the delivery model and passing the savings on to their end users. To do this correctly and to maximum capacity, a multi-user, single instance, SOA system is key. Efficiency is not a property that is easily attained through a traditionally architected web application, and even less so with a traditional client side application. If you look at Gianpaolo’s Simple Maturity Model, most standard web apps fall under level 0 or level 1. While they “work”, so does playing golf with a pack of Twizzler’s (only that it’ll take you the better part of a year on a par 5).

Trying to manage thousands of customers all through a multiplexed, multi-instance environment will prove to be more and more difficult as time goes on. By nature, a superb SaaS architecture is intended to provide you a foundational basis for your business model. Keep this in mind if you’re considering going down the SaaS route, particularly if you are looking for a SaaS enablement platform (make sure they help you achieve SaaS purity).