Building SaaS

SaaS and Electricity Economics

Over the holidays I read Nicholas Carr's new book, The Big Switch, which explores how "information utilities" (including SaaS) are fundamentally changing the economics of computing, and also Empires of Light, which traces the clash between Edison's direct-current electricity platform and the (eventually winning) alternating-current platform promoted by Westinghouse and Tesla.

Reading them with SaaS in mind, several important concepts emerged:

• The power of standardization: Early AC generators ran at different frequencies and voltages; the first large-scale AC generator at Niagara Falls ran at 25 hertz and 2200 volts (before step-down). Customers' motors and lights had to be designed and built specifically to match the power plant, resulting in extra engineering costs per customer and also additional operational efforts (maintaining and upgrading each disparate system).
  
  The parallel in the IT world is that there are many competing computing platforms (hardware, operating systems, databases, programming languages, etc.), which increases the engineering and operational efforts of corporate IT shops who must run software across multiple platforms. So IT shops have tried to simplify and standardize by requiring all software to run on a single platform, but this simply pushed the complexity and overhead onto the software providers, who have to port their software to multiple platforms, multiplying their testing and support efforts.  This causes a huge amount of wasted effort for each software provider.

  The IT standardizations that benefit customers are common data formats (HTML and XML for applications) and data transmission protocols (TCP/IP), not platform mandates. With SaaS, the SaaS provider can select the best platform to deliver their software service, and the customer incurs no additional complexity or maintenance overhead, eliminating wasted effort for everyone.

  Standardization eliminates wasted effort

• The power of efficient remote transmission: Edison's DC system could only service customers within a mile of the power plant, across thick and expensive copper wires, whereas AC could easily be ramped to high voltages and efficiently transmitted across many miles, allowing a single station to serve many more customers. This had two effects: fixed costs and capital were apportioned across many more customers who were served, and per-watt costs were much lower with fewer larger and more efficient power plants, compared to a power plant every few square miles.
  
  Similarly, multi-tenant SaaS enables a single software infrastructure to support many customers, rather than a separate infrastructure per customer.

  Remote transmission enables economies of scale

• The value of scalability engineering: Tesla invented many electricity-related devices, the most important probably the AC induction motor, and received many patents. However, he didn't actually deliver his inventions to end customers because he didn't engineer the entire end-to-end solution, as Edison and Westinghouse did. Over time, even though he was recognized as clearly the most innovative scientist involved in electricity, he couldn't attract capital to his ventures because he didn't deliver working product or revenues.

  The real impact of electricity was delivered by Edison (whose company was merged to become General Electric), by Westinghouse, and by other engineering-focused firms. Over the course of several decades their firms designed and built ever-larger and more efficient generators, electric motors and light bulbs - forever changing manufacturing and the way people lived after sundown.

  In a similar way, on-premise software providers deliver just the software functionality - the software is built, demo'd to prospects, and burned onto a CD. SaaS starts with this requirement, and adds on the ongoing engineering effort to operate and scale the software, the platform and the computing infrastructure. This is one of the key reasons that most on-premise software providers cannot successfully transition to SaaS - they simply don't have the many additional needed skillsets.

  As Joel on Software says, "the market pays for solutions to gnarly problems." Joel uses this to justify why he offers his software on-premise, where the gnarly problem is figuring out how to install and support his software across a myriad of customer computing platforms. But unfortunately solving this problem ends up being low-value to customers; customers only pay for high-value gnarly problems, and fewer and fewer want to create their own custom-built high-cost infrastructure to run software that's just like everyone else's.

  Joel goes on to say that good design is a gnarly problem in software, which it is. But once that's tackled, the new gnarly problem - and the one that actually delivers the value to customers and users - becomes how to quickly and efficiently serve ever-increasing numbers of users around the world with geometrically-growing amounts of data, continuously and without hiccups. That's a real feat of engineering, scaling up software many orders of magnitude over time, and it provides ever-increasing economies of scale to SaaS providers and their customers.

  Scaling SaaS operations is the core of ongoing software value delivery

Of course, there are many differences between delivering electricity and delivering information technology, one of which Nick Carr points out - electricity customer must plug in a device at the end-point for electricity to be useful, but software can be hosted centrally and not require any specific end-point device (i.e., consumed with only a browser and screen). The other big difference is IT's need for server-to-server information communications, which takes a lot more coordination than aligning the 60-cycle phases of electricity.

Nevertheless, over time, SaaS will prove to be one of the "information utilities" that Nick Carr describes, simply because it delivers far higher value to customers at a fraction of the cost of on-premise software.

SaaS Means Innovation, Delivered Continuously to Customers

Innovation - ongoing and continuous innovation in software functionality, infrastructure and capability - is SaaS's biggest distinctdive benefit to customers over the long term, and it's almost always overlooked by SaaS buyers.

On-premise software simply cannot deliver innovation to customers because of a triple-whammy of on-premise innovation shutdown:

• Maintaining many old versions on a myriad of platforms: As explained elsewhere on this blog, on-premise software vendors have to dedicate an enormous amount of resources to maintaining old versions of their software, across lots of computing platforms. Rather than focusing upwards 70-90% of development resources on maintenance as on-premise vendors do, SaaS providers can dedicate 80+% of their development resources on new features and value to customers.
• IT's no-change philosophy: Once on-premise software is up and running the customer's data center, it is beholden to the IT philosophy of minimizing changes - if something works, lock it down. This is entirely appropriate for internal IT because upgrades can involve huge re-customization and re-testing projects, so the application's ROI goes down the more frequently upgrades are performed. In addition, if the IT group invests in improving the software's capabilities, it only benefits one company, which means very few improvement projects return a sufficient ROI. Joel on Software describes the frustration of being an IT worker who has to stop improving in-house software built for a single company, which ensures the software is barely sufficient in terms of functionality, performance and usability.
• Decade-long upgrade cycles: Another result of single-company ROI and painful upgrades is that on-premise software is rarely upgraded, staying on old versions for 3, 5, or even 10 years, so even delivered innovations take forever to deliver benefits to the customer base. [This also causes frustration from the on-premise vendors' developers - they work on a cool new feature or value-add technology, and the majority of customers won't be using it for many years.]

Bottom line is that customers and users don't gain innovation benefits from their on-premise software providers, forcing many IT shops to invest in their own R&D labs. Even if the on-premise software vendors actually start to deliver on their talk about innovation, the fundamentals won't change - it will take many years for the majority of customers and end-users to gain any benefits.

The SaaS model eliminates these problems.  [Actually, only true SaaS solutions qualify, beware of SaaS pretenders who don't actually deliver the benefits of ongoing continuous innovation.] The true SaaS model has three key characteristics that deliver innovation benefits to all customers, instantly and continuously:

• Frequent Automatic Upgrades: Upgrades are zero-effort for customers, they gain instant access to new capabilities and can turn them on whenever it makes sense for them. And since upgrades are deployed to all customers automatically, the entire customer base can start gaining benefits right away.
• High Investment: SaaS providerse can apply almost all their technology effort to new functionality and capabilities, since they only have to maintain one version and infrastructure. Even more importantly, innovation investments generate benefits across the entire customer base, so the SaaS provider can justify many improvements in usability, performance, functionality and configurability that a single customer could not justify.
• Fast-Cycle Innovation: SaaS providers know where to target innovations because they know how their software is being used by the customers and what the user experience is, in real-time. This allows them to target innovations that will most help the user population right now, and gain feedback in days about the uptake and impact of a new or improved feature. This quick cycle allows experimenting, refactoring, optimizing and continually improving the software's capabilities, keeping the solution fresh - both functionality and infrastructure. On-premise software, with its 18-month or more release cycles and multi-year upgrade cycles, has a feedback loop that is so long it's almost non-existent.

What does this look like in practice? Well, we have many Fortune 500 customrs who have been using our SaaS solution for over five years, and in that time they've received the benefits of (at no additional charge): internationalization with multiple languages and localizations to dozens of countries, a new always-real-time reporting module with WYSIWYG formatting in Microsoft Word, BPEL-based workflow definitions and execution, addition of Firefox and Safari as supported browsers, continuous performance improvements even as volumes tripled each year, and literally thousands of small improvements suggested by customers and users.

So, in contrast to SAP, which is commended because it only took 6 months to support the iPhone (and for a very small portion of its product set), our entire application supported the iPhone the day the iPhone was introduced.

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.

On-Premise Software Extortion... I Mean, Maintenance Fees

Amidst the hubbub about Oracle's lawsuit that alleges corporate theft by SAP is a key topic of the dispute, which is software maintenance fees.

The lawsuit's allegations are actually against SAP's TomorrowNow subsidiary, which provides maintenance services for PeopleSoft, JD Edwards and Siebel software.  TomorrowNow is promoting that it provides more responsive and higher-quality support for half the price.

TomorrowNow and other third-party maintenance providers have a willing buyer in CIOs who want to reduce the yearly 20% fee for "maintenance and support".

CIOs hate paying maintenance fees, because what do they get for this yearly tax? Well, for starters, they get telephone support with pretty much one answer: "Upgrade to the latest version".

Even when on-premise software providers actually provide a software patch, such as with the recent Daylight Savings Time patches, the patch doesn't come close to actually fixing the customer's issue on their system - the patch comes with instructions telling YOU, the customer, to download the patch, YOU create a test environment and copy over all your data and configurations, YOU apply the patch, YOU test everything to ensure it works as expected, YOU apply the patch to production, and YOU verify it works. Feel free to email us if you have any questions!

Also, make sure you keep track of all the patches too - and the order in which you implemented them - because whenever you call for support, the on-premise software vendor will ask YOU for a list of every patch you've applied to the system.

On the vendor side, maintenance and support is a highly profitable revenue stream, so on-premise software vendors guard it jealously - Exhibit A is Oracle's lawsuit. Software conferences are filled with sessions on how to maximize the revenue and profitability from maintenance fees.  Software contracts have all sorts of traps to prevent unbundling the fees or products to make the fees required, even if you're not using much of the software.

Some software companies simply live off maintenance fees - such as Computer Associates' highly profitable growth in the 90's from buying up dead software companies with captive customer bases and charging ever-increasing maintenance fees as long as possible. [Which raises a question: Is Oracle the next Computer Associates?  Probably not yet, but the parallels are ominous.]

Software-as-a-Service, of course, changes the entire customer ownership experience to both increase the value from ongoing software usage and eliminate the maintenance fees.

For regular maintenance - such as maintenance upgrades, DST fixes, infrastructure improvements - the SaaS vendor simply does it as part of the service.  Automatically-applied functional upgrades - every few months rather than every few years from on-premise vendors - provide ever-increasing value, again as part of the service.  All the customer-borne costs with on-premise software of creating new environments, testing, running the infrastructure - completely eliminated.

Saas support is much better too, as the SaaS provider is motivated to actually fix the issue to ensure the customer uses the software, and is responsible for the entire technology stack and infrastructure.

Finally, with SaaS software, if you're not using it, you don't pay for it.  No shelfware, and no contractual bundling that requires maintenance fees on shelfware.

Eventually, every software vendor will only charge for software that is used and is delivering business value, and will deliver real support and ever-increasing capabilities for ongoing charges. For now, look for true SaaS software providers for this.

More Virtues of Building Software on One Platform

In a recent post, I described how a huge amount of low-value effort was eradicated by the true SaaS business model - unlike on-premise software vendors who have to spend 30-40% of their development budget porting the software across many platforms like databases, operating systems, and application servers (and supporting ths software across many platforms and versions, and writing abstraction layers), the SaaS vendor can apply those resources to building additional software value for customers.

A related factor in building SaaS software is that we can optimize the software for the platforms. This may not seem like a big deal, but it has a lot of positive effects under the covers.

Analogies often don't work well with software and with SaaS in particular, but let's try one in this case. Imagine that you're designing a car, and instead of designing and optimizing it for one engine, you have to meet a requirement for car to work with four-cylinder engines from GM, Ford, Honda, and Toyota.

What would be the impact of this requirement? Here are a few that come to mind:

• You'd have to design the car's engine compartment so that any of the engines could fit with their preferred orientation - necessarily making the compartment larger than if designed for just one engine.
• If one engine had a unique high-performance feature, you likely couldn't take advantage of the engine-specific feature, but instead you would need to design the linkages to the "least common denominator".
• You'd have to thoroughly test the car with each engine - and do this every year as the engine manufacturers upgraded their engines.
• You'd have to train your dealers' service staff on diagnosing, maintaining and fixing every type of engine and engine version.
• For all the connections with the engine (e.g., transmission, gas, ignition, accelerator, climate control, exhaust, etc.), you'd have to design and maintain adaptors to each engine's non-standard connection.
• For Honda specifically, you'd have to design a special adaptor into your transmission because Honda engines run counter-clockwise rather than clockwise like every other engine provider - except for 2007 Honda 4-cylinder engines, which are their first to turn clockwise.
• You'd have to design the transmission so that it worked well with every engine's torque curve, meaning you'd have to create extra gears to compensate for one engine's low-RPM weakness and another's high-RPM weakness.

Now, this is obviously a ridiculous requirement in the automotive world, but it is typical of on-premise sofware that has to work with multiple databases and application servers. On-premise software vendors have to build and maintain all the connectors to all the versions of platform software that they support, leading to dozens of specific adaptors and hundreds of platform/version combinations.

As a result, the on-premise software is designed to the least common denominator for the platform components, and the on-premise software vendor can't take advantage of any special features or capabilities of one particular platform.

As one specific example, on-premise ERP packages typically don't utilize the integrity constraints in relational databases, because each database vendor has a different way of specifying constraints. This means that invalid data can be stored in the database if there's an application validation bug, leading to incorrect data over time.

This leads to problems like: Every time we integrate with a customer's PeopleSoft HR package, the customer assures us that there are no duplicate "People IDs", but when we actually get the data (e.g., 37,000 employees worldwide for one customer), there are indeed duplicates that we have to sort out on our end.

In practice, what does this mean for customers?  Since the SaaS provider designs and builds on one set of best-of-breed platform components, the Saas vendor can take advantage of the platform's unique capabilities and performance profile, leading to higher uptime and responsiveness, increased functionality, and lower cost.

So in addition to utilizing its chosen database's referential integrity constraints to ensure data correctness, SaaS vendors that utilize the Oracle database can also add Oracle optimizer "hints" to greatly improve performance in some cases.

Writing to a single platform also allows the SaaS provider to become an expert in that platform, how best to utilize it, secure it, tune it and operate it on behalf of their customer base. The SaaS provider can much better deliver and support and optimize their solution with this in-depth knowledge and experience on the platform.

In short, writing for one platform has many under-the-cover benefits for the SaaS provider and for the SaaS product that together provide a better ownership experience and value for customers.

SaaS = Freedom from Upgrade Agony

Well, sorry for the long delay between posts, we've been focusing a lot on getting a couple of releases out with an evolved architecture for the next 10x of growth. Our usage volumes went up by three times in 2006, and our data volumes more than doubled, so I had to knuckle down to stay ahead of the curve. First things first, as they say.

In catching up with other blogs, this one caught my eye about the pain of upgrades of traditional software, in comparison with SaaS.

Vinnie Mirchandani, one of the enterprise irregulars who comment regularly about enterprise software, says enterprise software upgrades "are like refueling in mid-air; they are usually risky and they are usually low ROI."

Why is upgrading enterprise software risky? Upgrading a major release often requires upgrading to more capable infrastructure components, which the IT organization (or their consulants) have to learn all over again how to install, configure, monitor, maintain, and tune. On the user side, mission-critical systems must be upgraded in a way that is seamless to the user communities, wtih no hiccups in system availability, data conversion and accuracy, system performance, or user training.

Why is upgrading enterprise softweare low-ROI? Mainly because the investment is so high - a significant upgrade project can take 18-24 months and cost tens of millions of dollars for the required data mapping and conversion, testing effort, infrastructure upgrades, re-customization, and user training.

It's no wonder that enterprises are so adverse to major upgrades and wait many years before upgrading mission-critical systems, which leads to another cost - the opportunity cost of not upgrading. What new innovations or business value are enterprises missing by not upgrading? This is impossible to measure, and maybe some enterprises are content to stay where they are at for many years. But I think that this is because the only alternative is the agony of upgrading.

Now that SaaS offers another path, here's one way to think about it - what if you could only use 5-year-old Amazon.com, Google applications, iTunes, web email, and Blackberry software? No gmail, no Blackberry browser or Google Maps, no iTunes videos, etc. etc. The new, unexpected, and continually increasing consumer value from SaaS-style upgrades is already apparent, and SaaS is starting to deliver this to enterprises.

Vinnie continues, "SaaS, with its continuous, in background upgrades, is showing customers the alternative to upgrade chaos. Additionally, SaaS vendors are far closely aligned to features customers are actually using and want to be improved in the future."

What's it like for IT groups or enterprises to be freed from the worry about upgrade projects, to not have that distraction and overhang of upcoming pain lurking out in the future? The progressive IT groups we work with have created a SaaS-oversight function that works with their portfolio of SaaS providers to coordinate system integrations, keep up with new functionality that is available each upgrade, and oversee security policies.

This new function delivers continuously increased value to the enterprise as new SaaS capabilities are turned on, the IT group is freed up to focus elsewhere on higher-value projects, and the cost of ownership for the enterprise is reduced substantilly. (Note this isn't simply cost-shifting, where the vendor simply absorbs all the costs of upgrading - with true SaaS, the vast majority of these costs are removed from the supply chain, since the SaaS vendor has only one data migration, infrastructure, and testing effort across all customers.)

On a personal note, late last year I had a couple of months where I was in significant chronic pain, and it prevented me from working as effectively on multiple fronts at once - it forced me to narrow my focus and drastically shorten my priority list. Eliminating that pain was freeing - I could do a lot more, and more effectively, without that loadstone.

For IT groups, my perspective is that being freed of enterprise software upgrade agony has the same effect - they can focus on other areas, direct their efforts to improving the business instead of spending months and millions to make sure the new version works like the old, and get rid of the straitjacket of half-decade-old software versions to deliver continuously more value and innovations to their user communities.

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.

SaaS's Total Cost (& Value) of Ownership

The SIIA put out a white paper called white paper "Software-as-a-Service; A Comprehensive Look at the Total Cost of Ownership of Software Applications" (subscription required), which analyzes total cost of ownership from the customer's point of view.

While thorough in parts of the analysis, the white paper curiously omits or de-emphasizes some key TCO elements in evaluating SaaS versus on-premise infrastructure:

• Platform Software: Costs are broken down into the on-premise software license costs, hardware costs, and personnel costs. But a huge cost is the platform software that sits under the on-premise software - the database software and application server software especially. While open-source can greatly reduce this cost, very few large companies run their CRM or e-Procurement systems on open-source databases or application servers. ["Database" is mentioned once on page 19 under SaaS but not under on-premise.] Oracle and WebLogic/WebSphere licenses cost many times the hardware these days, and the white paper correctly points out that SaaS providers can spread these costs across customers much more effectively than any single customer could.
• Storage: Similarly, storage and backup infrastructure are barely mentioned, and missing from the detail charts. High-performance, high-availability storage is a major cost of any infrastructure, and is even more leverageable across multiple customers than platform software.
• Multiple environments: While the production environment is thoroughly analyzed, completely missing are development and test environments needed for on-premise software, especially for upgrades. No IT shop only has the production environment running, they must also perpetually maintain and invest in development and often multiple test environments.
• Upgrades: Speaking of upgrades, one of the key costs of on-premise software is upgrading to a new major version, which usually requires a big IT project with lots of consultants to migrate the data, re-customize the application, re-integrate with new versions of platform hardware and software, and ensure everything still works as needed through extensive testing. As a result, companies typically upgrade very infrequently, remaining on an old version for years rather than trying to justify the cost of a big upgrade project. So with on-premise software, you can take your pick of two bad options - either wearing the straitjacket of staying on the same version for many years, or regularly paying for costly upgrade projects.
• Quantification: While offering a generic spreadsheet at the end, the report doesn't give any quantitative comparisons. For the IQNavigator application, we've done some comparisons internally that show that a typical large customer would pay about $200,000 dollars per year to host the application, even when leveraging an existing data center infrastructure. A competitor of ours who offered only single-tenant hosting started their hosting pricing at $250,000 per year (they have since left the market).

The net-net is that when these additional costs are included, the SaaS cost advantage is even greater, and SaaS costs are much more all-inclusive and foreseeable than on-premise software costs.

Even though the cost argument is compelling for SaaS, cost is often not the most important factor to the business buyer. While CIOs focus on cost of delivery, the business side focuses on the value delivered by the software and the software-enabled change program, which makes these SaaS value points even more compelling:

• Faster time to value: Weeks instead of months or years
• Ongoing free upgrades: This often-overlooked benefit means that customers gain ever-increasing functionality and value from the software, for no additional cost or effort.
• Top-to-bottom support: The SaaS provider supports the entire application environment, infrastructure and operations, not just their software.
• Cost visibility and predictability: hidden costs are largely eliminated, along with costly upgrade projects

These factors make up the entire customer ownership experience, and could together be called "Total Value of Ownership".

Potential customers need to evaluate which software vendors and delivery models will actually provide these benefits and a high value of ownership, but few do. We wrote a white paper called Why Technology Matters that analyzes all these elements to help software buyers to separate true SaaS from the SaaS pretenders.

Defining SaaS? Focus on the Business Benefits

Thomas Otter, a Enterprise Irregular software blogger who works for SAP, says he can't figure out what SaaS is.

His main complaint is "What is or isn't 'allowed' to be called SaaS seems so arbitrary" - does SaaS have to include multi-tenant, hosted, subscription-based, web 2.0-enabled, etc.?

SaaS isn't some vague concept that's hard to define - it's just that many definitions miss the point by focusing on the delivery method or infrastructure or software architecture or pricing, when the definition should be based on customer value.

SaaS is defined by the business benefits it delivers to customers - faster time-to-value, lower cost of ownership, and increasing value over time through ongoing free upgrades. Secondary business benefits include better support (since all customers are on one version of the software and the SaaS provider knows the user's data, configuration, and usage), easier deployment (since SaaS providers are paid based on usage, they are motivated to make the software easy to use and adopt), and lower hidden costs (no upgrade projects, patches to apply, databases to back up and restore, etc.)

All the key components of SaaS architecture and infrastructure - multi-tenant, single-version, shared infrastructure, fully webified, configurable, metered and actively monitored - simply serve to deliver these benefits.

Software offerings that don't deliver these benefits aren't SaaS - and there are many examples out there, especially on-premise software offerings that are hosted and pretend to be SaaS, called "Same old Software, as a Service" by Phil Wainewright. On-premise-only software vendors try to muddy the waters by adding hosting and subscription pricing rather than modifying their software to deliver faster time-to-value, lower cost of ownership, and ongoing free upgrades.

In fact, even well-meaning observers miss the point, as Nicholas Carr did in his comments on Thomas Otter's post. Nicholas brought forth Glovia as a SaaS example - a company with 1,000 on-premise customers but no SaaS customers, who just released a simpler version for SMBs hosted by Deutsche Telekom's T-Systems unit. This isn't SaaS, it's on-premise software trying to become SaaS by issuing press releases and renting a cage at a data center rather than re-architecting the software to deliver more value, as pointed out by Phil Wainewright who takes Nicholas to task.

Another counter-example to SaaS is the first-generation ASPs that emerged in the late 90's trying to host on-premise software. Thomas says ASPs were the same as SaaS, but I don't know why we have to keep explaining the difference over and over and over again. Here it is, once more with feeling: ASPs died because they offered no business benefits over on-premise installed software. They simply hosted on-premise software in an offsite data center as a single-instance installation, which didn't reduce the time-to-value, didn't reduce any cost of ownership (it required the same per-customer infrastructure and operational costs), and didn't offer any increasing value over time - upgrades were just as costly and painful and infrequent as for on-premise installations.

Thomas ends his post on a positive note, however, comparing SaaS to the old service bureaus, specifically ADP. Let's see, does ADP's software-enabled payrolling service offer fast time-to-value, low cost of ownership, and ongoing free upgrades? Yes - so that makes it SaaS, in my view. Payrolling is a back-office process so full web-enablement and end-user self-service don't matter as much, but the business benefits are compellingly SaaS-like.

And I can assure you that ADP's software is multi-tenant, shared-infrastructure, single-version, and frequently and automatically upgraded for free.

Memo to the Skeptical CIO

Skep: Thanks for your participation in the "Skeptical CIO" panel at the SaaSCon conference in San Francisco.

Phil Wainewright captured the key points of this discussion, which I wanted to address here since your and your fellow CIOs' conclusions seem to indicate that SaaS pretenders and the big ERP vendors are dominating the discussion about SaaS in your offices so far.

To directly address the "Skeptical CIO" conclusions:

• "[SaaS is] not any easier to implement and use. Nor should it pretend to be." Well, as a SaaS vendor, when we're asked by a customer to install on-premise, we simply say "Ok, here's the CD and installation instructions, please call us when your IT group has assembled and installed and configured the servers, database, application server, and other infrastructure for our application. Or, here's the SaaS implementation login which we can start using RIGHT NOW." SaaS eliminates all the time and effort (and cost) to cobble together the components for on-premise software installation, which for an enterprise application can take an IT group months - at least, that's what the business buyers tell us. Plus, most SaaS vendors don't get paid until the software is being used, so they've built their SaaS software to enable fast implementation and to minimize training.
  
  Aberdeen Group's surveys have repeatedly shown both that SaaS implementations are faster and that SaaS's dramatically faster time-to-value is the most important benefit to the business buyer (here's one of their studies in our space). So, I'm not sure why you dismiss this SaaS benefit - surely you and your colleagues have endured plenty of multi-year on-premise software implementation projects?



• "Vendors should stop harping on about how, if you don’t like a SaaS solution, you can just unplug it and go elsewhere. That’s ludicrous." This comment is accurate; this claim isn't one that we make. Switching a SaaS application is really a new implementation - much easier and faster with SaaS, but not trivial.



• "The cost model is not necessarily any better. Customers amortize upfront costs anyway." SaaS creates economies of scale by sharing infrastructure across many customers - and it's true that a large IT shop with a pre-existing infrastructure can gain many of the same economies of scale.
  
  The faster and much smaller implementation project is a real cost savings, however, especially for large enterprises. As RightNow Technology's CEO puts it, you'll save the consulting teams that "camps their tents in the parking lot for three years while they get your application to maybe work."
  
  Another cost savings of SaaS is far less obvious. Ask your on-premise software vendor, "How much of your company's time is spent supporting old versions of your software across all your infrastructure ports (databases, operating systems, etc.), and porting and testing each version and maintaining the compatibility matrix?" If they have a significant customer base and are truthful, it'll be a large part of their development and support effort - according to The Economist, "as much as 70-90% of what programmers do in a large enterprise software firm is maintenance: upgrades, minor enhancements and bug fixes". True SaaS solutions reverse this proportion - spending only 10-20% of development effort on maintenance - because only the current version is maintained on a single platform, and every fix is automatically delivered to all customers. So the vast majority of the SaaS vendor's development effort is applied to new innovation and customer value.



• "On-demand vendors shouldn’t bother to portray themselves as partners in achieiving business results. They’re just software vendors selling products." Well, this may be true for some vendors - especially the SaaS pretenders who are telling you that SaaS is just another "deployment option". According to Jeff Kaplan, "The first thing CIOs have to look at is how any SaaS system is truly architected. Some vendors are still selling legacy apps but simply hosting them and offering them at a different pricing model." For a checklist of questions to ask a potential SaaS vendor, see the whitepaper Why Technology Matters.

Again, thanks for your participation - hopefully this gives some perspective from a true SaaS vendor's point of view.  The bottom line is that SaaS delivers a better ownership experience on factors that business buyers care about, driving SaaS adoption for new purchases and putting CIOs in the position of leading its adoption or being left behind. Embracing and driving the key benefits of SaaS - lower up-front cost, faster implementation and greater vendor accountability - will lead to higher/faster ROI with lower risk for both CIOs and the business.