Building SaaS

Does SaaS Matter?

I re-read Nick Carr's "Does IT Matter?" last week, and it seemed to me even more relevant than when it was published four years ago. In particular, it spurred thoughts about SaaS's long-term value and viability in a commodity-IT world.

The major premise of the book seems very SaaS-friendly: Nick's thesis is that IT innovations are increasingly easy for enterprises to replicate, so that competitive advantage from IT is fleeting and not worth the price to create IT innovations internally, or even to pay an early-adopter price premium. As a result, vendors are becoming the major source of IT innovations, making innovations available to all enterprises, and IT prices quickly gravitate to the most cost-effective way to deliver the IT capabilities.

With a shared infrastructure and innovations quickly leveraged across its entire customer base through automatic upgrdes, SaaS is both a major driver and a major beneficiary of Nick's thesis. By eliminating a customer's up-front license costs, infrastructure outlays and benefit-delaying implementation projects, SaaS greatly reduces the adoption cost of IT innovations and capabilities for enterprises.

In addition, while SaaS doesn't eliminate switching costs, if a SaaS solution isn't meeting the enterprise's needs it can be turned off and replaced for far less than an aging on-premise solution.

In short, SaaS makes IT innovations easier, faster and lower-cost to adopt. This pushes IT innovations more quickly throughout the economy, greatly increasing the innovation's overall economic impact, though potentially reducing any unique technololgy advantage for any particular enterprise customer. As a SaaS provider, this works for me - our technology has a bigger impact economy-wide, much more cost-effectively and more quickly than if we sold on-premise software.

With that said, SaaS does matter to individual enterprises in one major way: Enterprises that aggressively adopt SaaS will achieve more benefits (from free ongoing upgrades) at a far lower cost of ownership than enterprises that dogmatically stick to on-premise software. SaaS adopters will pay less, have more flexible expense structures, and avoid throwing capital down the rat-hole of bespoke infrastructures.

All enterprises have to do is select true SaaS providers, avoiding SaaS pretenders that will leave them behind on old versions or with lesser capabilities over time than true SaaS providers. That's the subject of my next post.

More Saas Simplicity: Additional Things That SaaS Customers Don't Have to Worry About

Enterprise software buyers learned over and over again that buying on-premise software is just the first step on a long and winding road to actually improving business results via the software. While the on-premise software vendor can recognize revenue for the entire up-front license fee, declare victory to Wall Street and send its salespeople to Hawaii, the customer is just starting the multi-month/year effort of paying the implementation consultants, assembling and configuring the technology stack, and learning how to operate the on-premise software and its supporting technologies.

With SaaS, of course, the reverse is true - the SaaS vendor is responsible for making the software work to the customer's liking and the software's adoption and business results, while the customer is freed of all the worries of on-premise software ownership. In a previous post, I outlined some things that SaaS customers no longer need to worry about, including:

• Upgrading the software and technology stack
• Becoming orphaned on an old software version
• Solving infrastructure software incompatibilities
• Operating the infrastructure and software
• Maintaining multiple non-production environments
• Diagnosing technical issues
• Building technical expertise for the software
• Enduring cost surprises

Since then I've collected even more unhappy elements of the on-premise ownership experience from various analyst reports and articles and blogs, and as a summary, here are some additional things that SaaS customers no longer need to worry about:

• Shelfware, with Maintenance Fees for Unused Software: Companies end up with shelfware when 1) they pre-buy more licenses than they need in return for a higher up-front discount, or 2) the software doesn't go live as broadly as anticipated. Customers typically still pay for maintenance each year on these licenses, even though the licenses aren't being used.

  This is a big painpoint for CIOs, as they have to send cash each year to vendors for software that is not even being used. On-premise license contracts are engineered to make sure that maintenance costs "ratchet up" with additional licenses, even if some licenses on other modules aren't in use. At one point, Gartner estimated that almost half of CRM licenses were not implemented - is it any wonder that Salesforce.com was the first breakout SaaS company?

  Even worse, although you've committed to the vendor and bought more up-front than you needed, it turns out that the vendor will ignore you if you have significant shelfware (subscription required). If there is no up-sell opportunity then you can't get the attention of the salespeople for information, access or support assistance. Counter-intuitively, the vendor will be much more attentive if they sell less up-front and have the opportunity to sell you more.

  With SaaS, of course, the vendor and customer are much more aligned - the customer only pays for the capacity that is being used, and since more users mean more revenue for the SaaS vendor, SaaS vendors are motivated to provide great service and ensure you are getting the benefits that you need from their software in order to drive expanded usage.

• Platform Changes When Upgrading: It's expensive and disruptive to upgrade on-premise software, so upgrades are done very infrequently. And upgrading doesn't just mean a new version of the on-premise software, it often means upgrading the entire technology stack - the database, the servers, the operating system, the system integrations, etc. So everything the customer has learned about operating, performance-tuning, and maintaining the on-premise software now has to be re-learned... another hidden cost of on-premise software.

• Aging Software: Many on-premise software customers decide not to upgrade because the upgrade project cost is too high or the innovation too low from their on-premise providers (see also "The Oracle Syndrome"), because the on-premise vendors are swamped by supporting a bazillion software versions and infrastructure components. These customers now have to worry about further issues with "aging software", or being charged more for support, or even being abandoned with no support and old formats you can't read any more. SaaS, on the other hand, delivers ever-green software, with innovations and improvements delivered continuously to all customers.

• Licensing Shenanigans: Buying on-premise software involves many frustrations when trying to figure out how many processor licenses to buy, how to license for development and test and failover and disaster recovery environments, how to coordinate with different licensing semantics for the database/application server/operating system, what flavor of maintenance and support to get for every component, etc. In addition, on-premise licenses don't tend to be transferable or flexible if the customer wants to use the licenses in a sister company or overseas, etc. While SaaS doesn't solve all of these problems (and some SaaS providers seem to want to keep complex licensing), the basic SaaS pricing unit (a user or a usage transaction) includes everything, no shenanigans or Excel spreadsheets required.

• Multiple Instances and Versions: In many companies, ERPs and other on-premise software couldn't immediately handle the flexibility and configurability and scalability needed to support the entire organization, so the implementation consultants installed multiple "instances" of the software, multiplying the costs to operate the software. For example, some of our customers have dozens, even hundreds, of instances of their financial software.

  Not only do multiple instances and versions multiply the costs of on-premise software (see below), it greatly complicates getting consolidated enterprise-wide information. Expensive data warehouses are constructed to overcome this issue, which adds further costs and delays to getting consolidated data from on-premise software. These days, of course, the implementation consultants are selling huge "instance consolidation" projects - yet another additional cost of ownership for on-premise solutions.

• Internal Support Staff Costs: I read a fascinating study on ERP staffing ratios by Computer Economics, which underscored just how much big companies are paying in personnel costs to support on-premise software operations, upgrades, customizations, and testing. For each ERP user who used any module, the top-quartile performance had one support person for every 50 users, which represents close to $200 monthly support costs per user. Notably, while ERP systems have much more broad-ranging functionality than most process-focused SaaS solutions, support costs actually did not change based on scope of functionality implemented, as different users typically used different ERP modules - so the HR module had about the same support costs as the sales module, financial module, etc., and these support costs were linear by module. With SaaS solutions, almost all of these customer-incurred support costs go away.

  In addition, the study found that on-premise support costs increased dramatically based on the amount of customization, the number of instances installed, and the number of versions installed. True SaaS solutions don't have any of these cost-multiplying elements, which further leverages the vendor's support efforts and reduces the total cost of ownership for the customer.

• Performance Tuning: Keeping the system humming is a key part of operations, especially as usage and data volumes grow, and as new capabilities and use-cases are utilized. Every application architecture performs differently and requires different and often abstruse skillsets to tune. For example, why should customers have to become experts in a Java virtual machine's thread management or garbage-collection schemes in order to scale some purchased software?

  SaaS providers offload performance tuning and system scaling efforts from customers, including stress-testing, capacity planning, system refactoring, and proactively tuning every element in the infrastructure. In addition, SaaS providers can tune much more efficiently and effectively than any one customer, because the provider's efforts and knowledge are leveraged across many clients. Since performance is a key part of the user experience, SaaS providers are highly motivated and focused on keeping performance high so usage growth and customer retention are high.

• Waiting for Quality: The fact of life for on-premise software is that the vendor doesn't really know how customers are actually using the software, so they have to wait until the first version is installed by customers use before they start getting accurate feedback on software issues. So a new functional release can have an unacceptable number of bugs, which has led to the conventional wisdom in many IT shops is to wait for the service pack or dot-release before upgrading to a new on-premise software version. The separation between on-premise software providers and their customers' installations means that the providers simply do not have the information needed to test the software effectively.

  By contrast, SaaS providers know every customer's data, configuration, and usage patterns, and as a result they know exactly what tests to run to ensure software quality. Since SaaS providers get immediately feedback on any quality issues and their future revenues depend on today's user satisfaction with the software, SaaS providers are again highly motivated to ensure that every new release is of high quality. Customers, in turn, also gain the benefits of new features and innovations right away, rather than having to wait for the bug-fixing service pack before upgrading.

The common factor is that a SaaS vendor's motivations are much better aligned with the customer, since the SaaS vendor's revenue is tied to the customer's satisfaction, retention, and software usage.

By contrast, on-premise licensed software vendors are motivated to "take the money and run", and actually prefer that the customer never installs or uses the software - the vendor already has the license fees, and now would rather not get any costly support calls. While the customer wants to gain value from their purchase, their on-premise vendor is secretly hoping they don't - one more thing that on-premise customers have to worry about.

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.