Building SaaS

SaaS and the Innovator's Dilemma

Looking back on SaaS in 2008, the most interesting thing wasn't the inexorable increase in SaaS's market share, but the vocal backlash against SaaS from the large legacy on-premise software providers:

• First, Larry Ellison reiterated that Oracle won't be aggressively pursuing SaaS because it's not profitable enough.
• Then, SAP followed up on the delayed rollout of its SaaS offering, BusinessByDesign, with comments about needing to optimize it and automate the sales/delivery process so it could be profitable.
• Finally, Lawson CEO Harry Debes trumped everyone with the ridiculous pronouncement that the SaaS market will 'collapse' within two years after Salesforce.com misses its growth targets.

I wondered, if SaaS is such a big part of the future, why are the big players hesitating to jump into SaaS due to profitability concerns, and even dispraging it?

So I pulled down my copy of "The Innovator's Dilemma" by Clayton Christensen, and all was explained within a few pages:

"...despite established firms' technological prowess in leading sustaining innovations... the firms that led the industry in every instance of developing and adopting disruptive technologies were [new] entrants to the industry, not its incumbent leaders."

Very interesting.  Why don't the incumbent dominant vendors invest in disruptive technologies?

"First, disruptive products are simpler and cheaper, they generally promise lower margins, not greater profits. Second, disruptive technologies typically are first commercialized in emerging or insignificant markets. And third, leading firms' most profitable customers generally don't want, and indeed initially can't use, products based on disruptive technologies. By and large, a disruptive technology is initially embraced by the least profitable customers in a market."

So is SaaS a disruptive technology? Absolutely - SaaS meets all of these definitions:

"...disruptive innovations are technologically straightforward. They generally package known technologies in a unique architecture and enable the use of these products in applications... [that] previously had not been technologically or economically feasible."

"Products based on disruptive technologies are typically cheaper, simpler, smaller, and frequently more convenient to use."

"Disruptive technologies bring to a market a very different value proposition than had been available previously."

SaaS repackages software functionality onto a lower-cost multi-tenant infrastructure and a new delivery mechanism (via web browser over the Internet) that greatly improves the value proposition for the customer - faster time-to-value, lower infrastructure cost, and ongoing operating costs rather than huge up-front licenses.

For the SaaS vendor however, the economics are far less attractive than shipping CDs for millions of dollars - SaaS margins are lower than on-premise offerings, due to SaaS's up-front infrastructure investment and deferred subscription payments.

So the major ERP providers are looking at decreased profitability from SaaS offerings, and they are prevented by investor expectations from moving strongly into SaaS. For example, even though SAP has V2.0 of Business ByDesign ready, their CEO said that if they were to start pushing it, "we would be hurting our margin, and hurting our stock."

In addition, "The Innovator's Dilemma" states that incumbent vendors' org structures and skillsets (i.e., what they focus on and do well) are internal impediments to adopting a disruptive technology.

Finally, the ERP providers' most profitable customers don't want SaaS, which "The Innovator's Dilemma" says leads to long-term disaster:

"...the leading firms are held captive by their customers, enabling attacking entrant firms to topple the incumbent industry leaders each time a disruptive technology emerges."

So since he can't offer the SaaS disruptive technology, Lawson's Harry Debes instead puts down SaaS to try to delay SaaS adoption and his firm's inevitable decline. Harry has seen a lot of changes in the software industry over the years, but in comparing SaaS to service bureaus and ASPs he is ignoring two decades of Moore's law that have fundamentally restructured the economics of operating software for customers (i.e., personnel time is now much more important than hardware costs), which makes SaaS's time-efficient value proposition very compelling to customers. Plus, SaaS is lower-cost to deliver than the ASP offerings during the bubble, since SaaS is built for time-efficient configurability and cost-efficient multi-tenant delivery.

SaaS has a better value proposition and better economics for customers, leading to ever-increasing customer demand but lower margins for SaaS providers - the formula for a disruptive technology that topples the market leaders. So my view is that Lawson is much more likely to collapse than the SaaS industry, signalled by the brewing ERP backlash.

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.

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.

What Multi-tenancy Really Means

Salesforce.com is obviously the poster-child for SaaS, but it seems as if they may be breathing their own exhaust when it comes to espousing the multi-tenant hosted model.

As many observers have pointed out, there are many aspects of SaaS that may seem like religion, but that have very meaningful impacts on the customer's cost of ownership and value derived from the software.

"Multi-tenant" is short-hand for two key architectural components of a true SaaS solution: 1) single software version and 2) shared infrastructure costs. Both of these have game-changing benefits for both the customer and the SaaS vendor:

• Single Software Version: This means that all customers are automatically upgraded to the latest version. All customers not only get the latest innovations and improvements in the software, they also get unparalleled top-to-bottom support and avoid the risk of being orphaned on an old unsupported, unmaintained version. SaaS vendors only need to maintain one (current) version of the software, and every fix/enhancement goes to every customer. Multi-version vendors end up spending 70-90 percent of their development effort simply on maintenance, according to The Economist, as they fragment their maintenance efforts over more and more versions of the software and each fix applies to a small subset of customers.
• Shared Infrastructure: Multi-tenant allows multiple customers to run on the same infrastructure. Most people think of servers as the main infrastructure cost, but even more costly are the cost of database licenses and other infrastructure software, the 20%-per-year maintenance costs for all infrastructure components, and (most importantly) the operations personnel costs: DBAs, system administrators, network administrators, etc. Fifty customers, each buying and building their own infrastructure, would together spend an order or magnitude more cost than a shared-infrastructure SaaS solution. The customer gains from the SaaS vendor passing along a dramatically lower cost of ownership, and the SaaS provider can also provide capabilities that a single customer couldn't ever justify, such a hot-backup mirror sites, world-class scalability and performance, etc.

Think this doesn't really matter? Here's a very real example: A few years ago, a major U.S. technology manufacturer selected one of our competitors, a fake SaaS provider without single-version automatic upgrades or shared infrastructure. After four years, the customer was fed up: they had wanted a new approval feature and the fake-SaaS vendor was busy working on a new version for future customers and couldn't accommodate them. The customer wanted more reports and eventually had to internally build a datamart to create their own reports, the vendor couldn't implement internationally on the old version, and the system response times got continually longer as data volumes increased.

So we invited this customer to talk with some of our long-standing customers, and they heard first-hand what they had missed: in the same time period, our customers were able to take advantage of several completely new subsystems, international capabilities across all the major economies in the world, a whole new reporting and business intelligence system, and response times that decreased on average every year. And all for free - customers didn't pay any extra cost, allocate any internal IT resources for upgrades or pay any hidden costs.

The story has a happy ending - even though our competitor offered to upgrade the customer for free to their latest version, the customer is now our customer. After the whole decision process ended, the customer's Director of Procurement said "It wasn't even close, you blew them away." And we've stolen other customers from this competitor for the same reason.

Now, are we really that much better than this competitor? The short answer is that the SaaS business model is really that much better, both for customers and the software providers.