A lot has been said about what Software as a Service is and is not – and we’ve been part of the noise. I really feel however there is something bigger going on. There is a tsunami coming and SaaS is only one of many waves.

People have said SaaS is:

• A delivery method enabled by the spread of low cost broadband
• A technical architecture (multitenancy) that provides higher efficiency and lower costs (in the best implementations anyway)
• A business model led by direct responsibility for service to end-users
• An alternative to the traditional capital investment model of software licensing
• A low cost way to take advantage of applications and services for SMBs
• Gaining acceptance in enterprise business
• A potentially disruptive business model that could end the dominance of traditional software vendors
• An opportunity that allows new players to “level the field” against intrenched industry leaders
• A flash in the pan that will eventually morph into some other even cooler marketing-led hype.

I would say all of these things are true – and more – or less. In another way however, these observations miss the point. An illustration might help:

Business as Usual

In the “traditional software vendor” business model, the buyer is the ultimate customer. If the buyer is a company – no matter how large or small – the buyer is the filter between the people who use the application and the vendor. If you add in a sales or service channel, a secondary source, the relationship with end-users becomes even more tenuous for software vendors.

Think about that.

Most buyers don’t want to be constantly involved with their vendors and the bigger the company the buyer represents, the more that is true. So, if a vendor relationship comes down to a purchase and maybe a license renewal every two or three years – fine. Near renewal time, there are opportunities to push for new features, fix nagging problems, and maybe switch to a new application. Just as often, renewal periods are time to leverage the “choice” to change to get better terms. Even more importantly – renewals are generally concurrent with new product versions so that vendor sales and buyer interactions are orchestrated. Marketing and sales insure that the conversation at renewal time is more about the “new features in this version” rather than the new features needed by specific groups of end-users.

So how is SaaS different?

Power to the End-Users

In the SaaS business model, the “wall” provided by the buyers between end-users and the software vendor is nearly eliminated. SaaS is a service relationship and the vendor is directly responsible for “user experience.” The buyer enables subscription or transaction payments on an expense basis and turns the operational relationship over to the software vendor. Software-delivered-as-a-Service. Oh….

Now the daily concerns about why the application doesn’t quite meet expectations can go directly from the end-user to the vendor and in most cases – since this is outsourcing in reality – the buyer expects nothing less. Put that beside the truth that high renewals are key to survival as a vendor in a SaaS business and you begin to see something important. The software vendor – to be successful – needs to consider a new way of operating.

Enter “agile” product development and “the agile business architecture” stage left.

The same wave that is gradually taking hold in software development is now being adapted to service-based business operations. Except – we haven’t really acknowledged it yet. How does a SaaS vendor insure retention and stay ahead of competition in the dynamic world of the Internet? By eliminating the artificial renewal period version change, proactively engaging with end-users (support), mining the business intelligence that is now in their hands (aggregated usage), becoming the face of a service instead of a label on an install CD (social media and marketing). By co-opting competition and finding ways for them to join in (APIs and marketplaces). By eliminating long design cycles in favor of a system that can embrace continual, targeted improvement and that responds to a changing landscape. By becoming truly Agile for the same reasons the idea has taken hold in development.

The truth is that the problems that became apparent when outsourcing first hit customer service in consumer goods are just as important when an application becomes a service. A service provider who ignores the end-user’s context, that can only respond when you have reached the head of the queue and then only read from user manuals isn’t going to win at SaaS. Creating more hurdles for the end-user to jump over so you have less interruptions during the design cycle doesn’t make you more agile. Being Agile is about flexibility, response to change, and finally responsibility for success at a very individual level.

In a world where Moore’s Law is an accepted reality, where even GM has to downsize to become more competitive – we also have to accept that change is now the constant and we have to rethink how we organize and work. The principles behind the Agile Manifesto are being applied to successful business more and more every day. Because we – at Scio – believe this is a critical subject you can expect more about agile business architecture and for SaaS vendors – how it can be enabled in the application itself – in the future.

As anyone who follows me knows – I use Twitter and TweetDeck to watch the “virtual conversations” about SaaS happening around the ‘net when I can. Today some time was freed-up by a conference call that was delayed so I fired up TweetDeck and took a look around. Imagine my surprise when I read a meme had started around a blog post touting single-tenancy for enterprise SaaS applications.

I’m not going to link to the original post – the writer has his reasons for pushing the idea – they are not entirely wrong, his context is different than mine and most readers of this blog. But I strongly felt the “take away” that might be given to people considering developing a SaaS application was shortsighted to say the least. Without getting into “religious wars” over a complex subject – let me first say that single tenancy does serve as a reasonable tactic for ISVs in some situations:

• Limited instances for a group of large clients that require hosting and will pay the cost differential for an application that really has no direct future as a fully developed SaaS app.
• As a short term response to market pressure and provide an alternative to a competitor’s offering.
• As a beta of a future SaaS application to “get a feel for the market” in a specific vertical where the ISV has not had an offering before.
• …and similar short term, limited implementations with narrow specific goals
• Or when you are using a PaaS like Apprenda’s SaaSGrid that actually leverages a single tenant .Net application and provides hooks to services that can enable the application to operate as multitenant and scale properly.

Let me also say that as Bob Warfield of SmoothSpan pointed out recently – multitenancy in itself is not a solution to all architectural problems for SaaS applications or a guarantee the application can be maintained and operated efficiently. Or – as a friend at OpSource recently pointed out, “A single instance of a multitenant application that just keeps growing forever without the ability to spread across infrastructure intelligently is actually less reliable than a single tenant architecture.” You will know this is happening when you and everyone else using an On-Demand application is suddenly caught dead in the water without a lifeboat by a system upgrade. Even a multitenant application needs to be able to seamlessly operate across several instances to be scaleable, maintainable and reliable.

So to address the most common FUD (Fear, Uncertainty and Doubt) thrown at multitenant SaaS architecture:

• Cloud Computing has solved the problems SaaS application developers need to think about by making it a simple job to put a new instance online as needed and abstracting the “servers” under the application.

Cloud hosting options are in themselves good alternatives for deploying SaaS applications. There is a lot to like about an abstracted infrastructure. Cloud hosting is mature enough for enterprise IT to consider as an alternative to deploying on their own internal infrastructure just as they consider outsourcing other aspects of maintenance and support. But – as an alternative to a multitenant architecture it doesn’t solve the major operational problems posed by individual implementations for each client. For a version upgrade – how long will it take to bring each individual instance through testing and QA up to the current version? Will you be able to move all client instances to the new version in a coordinated way or will the fact that each client has a separate instance lead to a number of “orphans” that fear change and lag by one or more major versions? Will the overhead you face actually prevent you from applying necessary patches and bug fixes until the next “major upgrade?” And what about subscriptions, implementation of instances, payment settlement, self-service, and monitoring of usage? Most cloud-based infrastructure doesn’t address these operational issues and they will all cost you money in terms of overhead as a SaaS ISV even if they don’t cause any support issues and subsequent subscription losses.

• Most multitenant applications use individual database instances for every client so the idea of a truly multitenant application is a myth. Enterprise clients want data isolation and abhor the very idea of “blended data.”

It is certainly true that many SaaS applications have been developed with an architecture that provides an individual database implementation for each client. Whether it is is “most” or not is an unknown – SaaS vendors seldom actually disclose their underlying architecture. However, to extrapolate from the fact that many services are implemented that way because it is what “clients want” is simply silly. First – the idea that single implementations for each client are inherently “more secure” is an answer from a marketing team that has nothing else to say. If there are security risks in the environment surrounding the databases or the way the databases are implemented – single implementations will not lower them unless you believe that by being just “one tree in a forest” you have somehow “spread the risk.” Second – single implementations are inherently less maintainable (see above), have higher overhead costs and are more likely to have delayed implementations of necessary database tuning, patches and upgrades. Delayed implementations mean less security and lower reliability. Third, application upgrades almost invariably require some changes to the database or at least a cycle of testing and QA. Individual implementations mean every instance needs to be updated, tested, and perhaps rolled back if there is an error. It also means a loss of transparency and that some clients may resist upgrades if they are aware of the isolation as a “strategy” (again see above). If this results in database inconsistencies between versions you can end up with application “orphans” again and no easy way to isolate the clients involved without forking your development (and if you don’t know what that means in terms of headaches you’re in over your head).

• Big clients are very concerned about upgrades and want strong control over version migration, especially for applications that are used broadly across the enterprise.

This is certainly true when clients have the primary responsibility for end-user support and system maintenance because the application is locally installed. It is very short-sighted however to believe that a client organization won’t expect the SaaS vendor to accept responsibility for a large part or all of the end-user support and provide embedded training and self-help. This is service offering after all. Would your HR department expect IT to solve problems if Expedia didn’t place a travel reservation for a company executive? SaaS is a form of outsourcing and should be sold as such. If your business model is based on the belief that you can somehow just host the application and leave the support and change control to your customers you should take a moment and read Ben Kepes recent article on the idea that SaaS is just an extension of the old ASP model.

• A SaaS application cannot match the look and feel of their client’s environments or provide ways to be easily customized to fit client operations.

The idea that SaaS applications are somehow required to be “cookie-cutter” with little flexibility is based on a very limited knowledge of current development patterns (or just plain lazy development). Yes, a single code base is a key to maintainability, testing, QA and reliability in a SaaS application. But that doesn’t mean that flexibility cannot be built in from the ground up. It does require understanding what clients might want. It requires allowing a certain amount of “self-service” or at least apparent application “hooks” that services can exploit. On the flip side – if you customize individual instances the risk that a customization will cause incompatibilities rises exponentially in relationship to the number of different customizations. So, as an ISV you have enabled professional services and disabled your operations and reliability.

Finally – the idea that a SaaS application and a premise-based are the “same” should raise flags if you have followed some of the marketing ideas we have written about in the past. Being on the Internet gives applications an entirely different context – if they are not exploiting that idea I would question how much value the SaaS implementation is really giving customers or the vendor.

So – in the end the old adage is true – beware of advisors only carrying hammers to fix problems. They are very likely to believe every problem is a nail…

Addendum –

• The “single-tenancy meme” spread across blogs recently too – read more about the subject in Bob Warfield’s article on the SmoothSpan Blog. It is a well-written response to the misconceptions that have been springing up.
• Bob Warfield of the SmoothSpan blog and I will be talking with Jon Hansen on his PI Window on Business broadcast April 30th about SaaS and cloud-computing and you’re welcome to join us. You can read more from Jon on his blog too!
• The replay of the broadcast is now available on Jon’s site.