On-Premise's Wasted Development Efforts - Who Misses It?

I was talking with one of the analyst firms this week about SaaS, and one of the analyst's questions was "which of your costs can you leverage across your customers?"

The answer is: SaaS takes advantage of economies-of-scale for many costs of operating the software, including the production infrastructure, operations costs, upgrade costs, and many support costs.  Instead of each customer incurring these costs separately and duplicatively, a SaaS provider leverages these costs across all customers, greatly reducing the cost of ownership for each customer.

For example, a Fortune 500 customer's installation of an enterprise application requires about a half of a person for database administration - installing and maintaining dev/test/prod, performing backups and recoveries, applying patches, monitoring and tuning, performing upgrades, etc. So 50 enterprise customers pay for about 25 database administrators in total, whereas a multi-tenant, single-version SaaS provider uses a fraction of the database administrators to deliver the same or better administration quality.

But just as interesting, I told her, are the costs that are completely eliminated by the SaaS business model. Chief among these are the costs related to "porting" - i.e., making the software run on different platforms and supporting hundreds of platform permutations.

In an on-premise software company, when a new version is ready to ship, the development isn't actually completed - the software has to be ported to all the databases, application servers, and operating systems that the company supports. For an enterprise application software vendor, this includes all the major databases (Oracle, SQL Server, DB2, Sybase), the major application servers (WebSphere, WebLogic, Oracle AS, Jboss), and a dozen or so operating systems.

A SaaS provider, by contrast, runs only on its "reference port" - i.e., the platform that the software is built on, tested on, and operated on. This avoids a huge amount of effort, delay and complexity in several areas:

• Porting effort: Developers really don't like to do porting work, as this is a frustrating and low-value "just get it working" effort. It's also not enough just to port to another platform, often the software must be ported to multiple versions of the platform, further multiplying the effort. Installation scripts and release notes also have to be written and maintained on each port for each version - and all this effort is completely obviated by SaaS.
• Maintaining port and version compatibility matrices: With all of the software versions and various platform versions, someone has to keep track of which combinations have been confirmed to work and are supported. This is a non-trivial task, as thousands of combinations are possible and hundreds are typically tested and supported -- here is an example of a resulting compatibility matrix. With SaaS, the compatibility matrix is reduced by a couple of orders of magnitude, at least, and the customer doesn't have to worry about any of it.
• Supporting the various ports: Once the software gets out "into the wild" - i.e., installed at a customer site - whatever platforms and versions combination that the customer choose must then be supported by the software provider. And since customers really don't like to go through the hassle and cost of upgrading (which breaks what's already working), they'll stay on old versions of the database, application server, and your software for as long as possible. So when the customer calls with a problem with the software, the on-premise software vendor has to re-build the old versions of platform software to try to match what the customer is running, apply patches and customizations, and try to reproduce the issue. This is all wasted effort compared to supporting SaaS software, where the vendor already knows the software version, platforms, data, configuration and usage patterns - all automatically.
• Building abstraction layers: When building application software that runs against several different relational databases, eventually the engineers will write an "abstraction layer" that generates SQL that every database can understand, in order to insulate the application from the many differences among the databases. These abstraction layers must be developered and maintained across all the various platform types and versions, a significant effort that is simply unnecessary with SaaS.

All this wasted effort - greatly increasing cost, delay, and complexity  - is eliminated by SaaS, enabling SaaS vendors to apply a far higher percentage of their development effort on new functionality and value to customers, and lowering the total cost of ownership for customers as well.

Who misses this wasted effort?  Certainly not SaaS developers - I can't imagine asking them to do low-value-add and unfulfilling tasks like porting our code to various databases, writing abstraction barriers, or diagnosing bugs in 3-year-old versions of our software.

As usual with SaaS, there are not only cost advantages, but also increases in value to customers.  Related to porting, running on only one platform and one version allows SaaS vendors to provide far better support of the entire SaaS solution.

Another key aspect is that on-premise software vendors must write to the "least-common-denominator" of the platform software, and cannot take advantage of any helpful features or aspects of any one platform - while SaaS can and does take advantage of their chosen platform's distinct features to deliver more value to customers in terms of performance, functionality, and cost of ownership. This will be detailed in an upcoming post.