SaaS Simplicity - Things That SaaS Customers No Longer Have to Worry About

In the past few months, we've been asked a couple of times about installing our software in a customer's data center. These were Fortune 200 companies, with large data centers in place and with thousands of IT people already running hundreds of applications. Couldn't they run our application as efficiently and effectively as a 150-person Software-as-a-Service provider?

In a word, no. It quickly became readily apparent that it made no sense at all to install our software versus letting us run it in our multi-tenant environment, when considering all the things that enterprise customers no longer have to worry about when utilizing a true Software-as-a-Service offering:

• Upgrade Headaches: Enterprise software requires a lot of other components in order to run - servers, storage, operating systems, databases, application servers, networking components, etc. Each of these components has a vendor who regularly releases new versions with new capabilities, bug fixes, and security improvements - and the customer has to decide whether and when to upgrade for each new version of any component.
  
  Each upgrade project involves setting up a test environment, re-implementing everything with the new component version(s), and testing the compatibility, functionality and performance of the new configuration. This upgrade pain is costly, complex, and risky.
  
  [On the consumer front, even with Steve Jobs' famed devotion to simplicity (subscription may be required), iTunes still gives upgrade headaches to its users. Every few weeks I get a message "A new version is available, do you want to upgrade?" at exactly the worst time - when I'm opening iTunes to listen to music. Sure, I'd love to go to the Apple website, download a 20MB file, click through all the upgrade instructions, restart iTunes (maybe even restart the entire computer), close any "what's new" and "you've just upgraded" messages, wait for iTunes to re-index or re-structure its library, and hope that the upgrade didn't break anything (which it has several times), all before I get to listen to any music. Sign me up!]
  
  Rather than forcing the customer to figure out whether and when to upgrade any component in the technology stack, enterprise SaaS continually increases the capability and value of its software through automatic (and free) upgrades. Enterprise customers and users of true SaaS offerings don't have to worry about upgrade timing, projects, costs, etc.


• Being Orphaned on Old Versions/Technologies: One approach to minimize upgrade pain is to delay all upgrades - this can defer the cost and risk of upgrades, but at the price of declining support, being vulnerable to more and more security risks, not being able to take advantage of new features or technologies, and eventually being orphaned when one of the vendors drops support on whatever version you're on.


• Software Incompatibilities: When a new browser version comes out or a new service pack is released, the new version must be incorporated and validated and tested across the entire technology stack - and unfortunately, new software versions always play well with every other system component.
  
  As one recent example, BEA released and recommended a new service pack for WebLogic, but it turns out that when a user with Internet Explorer 6 logs into a site with this service pack using SSL (and every e-commerce site uses SSL), then WebLogic takes over a minute to return each web page! Don't ask me how the market-leading application server doesn't work with the market-leading browser version, but unfortunately that kind of incompatibility happens all too often.
  
  Finding, diagnosing, and working around this kind of incompatibility problem - which can occur with any upgrade of any component in the technology stack - is a lot of effort and difficulty that SaaS customers don't have to worry about.


• System Operations: Operating the production environment (and the various test environments, more on that later) takes database administrators, sysadmins for the servers and storage, network administrators, configuration managers, etc. Even the most efficient IT shop will require 1 to 2 full-time equivalents to manage all the tasks on all the various components across multiple environments - applying patches, administering security, performing backups and recoveries, managing upgrades, following change-control policies, and coordinating every action. With SaaS, the customer avoids the cost and the trouble of all these activities.


• Additional Non-Production Environments: To manage the various upgrades and operations, several environments beyond production have to be set up and operated: development, test, stress-test, training, data-recovery, and disaster-recovery environments. This multiplies the operations efforts, complexity, and cost - all of which customers avoid with SaaS solutions.


• Diagnosing Technical Issues: When an error occurs, a lot of work has to be done to diagnose exactly which pieces of the technology stack participated in the error. If a web-service has a transaction error, was it caused by the application server, application code, XML parser, database, operating system, or JDBC driver problem? Or was it a point-in-time network or DNS issue? It can take days or even weeks to replicate the issue, track down the exact component that caused the issue, and convince the component's vendor that they are responsible so they start their own diagnostic and fix effort. SaaS vendors, on the other hand, are responsible for the entire stack - if an error occurs, the customer has "one throat to choke".


• Building Technical Expertise: The common thread of the last few "worries" is that with on-premise software, customers have to become experts in all the technology components - installing, configuring, testing, operating, and fixing every component.  Creating all of this knowledge during an on-premise software implementation project, at the end the customer knows a lot more about running the on-premise software than the software vendor!
  
  Why should a customer have to become an expert in all of this? They just want to use the software and gain its benefits, but until SaaS, the price to customers included creating and keeping up-to-date all the business-irrelevant technical knowledge that goes into creating and operating and upgrading the on-premise software and all the other components.


• Cost Surprises: The long-term cost of ownership of on-premise software is a big unknown, especially over the long-term. How much will replacement servers and storage cost in several years? How expensive will the upgrade project be in three years? How many technical problems will we encounter with this software, and how many people will it take to solve them?
  
  True SaaS greatly reduces cost surprises - there's one price per seat or per transaction or per month or whatever - and that's what you pay. [Of course, some semi-SaaS providers try to tack on extra fees (maybe they are on-premise or consulting vendors in disguise?), so look for pricing simplicity in SaaS vendors you work with.]

In short, enterprise SaaS largely wipes out these complexities, costs and risks for customers - all of which are irrelevant to the customer's business goal of obtaining value from the software. (In addition to simplicity, SaaS customers gain ever-increasing capabilities for the same price, with each automatic free upgrade.)

The irony here is that over the past two decades, large enterprises have gotten so used to managing these costs and these worries of on-premise software, that it's sometimes difficult to communicate how much simpler things are for them with SaaS. Overall though, when you think of all the things SaaS customers no longer have to worry about, it seems apparent that simplicity will continue to increase SaaS adoption and market share, especially in software segments where SaaS has inherent advantages.

Comments

[saas application development]

Nice points... great explanation....

[Lisa Amorao]

*perceived loss of control...

[Lisa Amorao]

I've been quite outspoken in my organization about SaaS and have cited the reasons you state here. These benefits are even magnified if applied to small or mid-sized organizations.

It doesn't make sense to me, but it seems the biggest objection to the SaaS [web-based] model is loss of control.

I think Phil Wainewright nailed it:

"SaaS providers have got to get serious about reliability and availability, and they’ve got to give their service level agreements some teeth. Enterprises won’t entrust their operations to external providers that can’t be relied on."

I think the big question is: what does it take to achieve that sense of reliability? There are some organizations put a much higher price tag on control than the convenience and cost savings from all of the items you mentioned.

[Chris]

Glad to see you're writing more articles. Really great stuff. Please keep sharing your ideas and experience!