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.

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.

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.

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.

The SaaS Customer Ownership Experience

I was reading an AMR Research note this morning about Oracle's Fusion progress, and one of the first points was that Oracle is doing double development: building out functionality for existing customers while in parallel building the "brand new Fusion platform".

So I got to wondering, how much effort is Oracle applying to each of these two efforts?

Software companies, like any company, will invest in product development based on the expected revenue return - no new revenue means no new investment.  This leads to a truism of on-premise software companies:  They are always working for the next customer.

This is because licensed on-premise software companies grow their revenue and profitability through new customers.  The next potential customer is making a product evaluation based on the software functionality, and will give a big check to the winner.

But what about maintenance revenue?  Well, customers of licensed on-premise software are locked in - they fork over the 20% maintenance every year because they have no choice.  It doesn't matter if the software has a new release or not, if new functionality is there or not, or even how bad the support is, 99% of the customers pay the 20% each year.   Since there's little risk of losing revenue, existing customers' needs are lower priority.

So the on-premise software company's resources - both product investment and sales efforts - are dedicated to getting the next customer. As soon as the contract is signed with the new customer, the nice salespeople and those amazing technical people that made the software sing and dance will start to dissolve away like they're in a Star Trek transporter - they're being transported to the next potential customer. And the customer is stuck with a license-fee bill for a CD of software that hasn't been installed or implemented yet, much less deliver business value.

SaaS providers, on the other hand, have to earn their customers on a continuous basis, since customer usage and adoption determines the SaaS provider's revenue.  SaaS vendors actually help customers increase usage and adoption.  Since the customer can leave at any time, the SaaS vendor must continuously work to keep them happy with the software's functionality, value, availability, performance, support, and overall business value.

This continuous accountability to customers leads SaaS providers to invest in functionality that makes customers satisfied.  This investment has an immediate positive revenue return - if the provider doesn't invest in current customers, they will quickly lose revenue.

Even more importantly, most SaaS providers grow within their customer base - in our case, about half of our revenue growth is from increased usage and adoption within our enterprise customers.  So we have to prove out our value with every new group of users, so they recommend it to the next set of users. 

This forces investment where the increasing revenue comes from - both existing customers and new customers for SaaS providers.  So, as a customer buying software, which would you prefer - a software vendor who forgets you as soon as you sign their contract, or one who continuously works to keep your business and increase the value they deliver to you?

Software Support in the New Era

"Software support" is an oxymoron for on-premises enterprise software.  By the time the business customer installs the on-premise software, gets it connected and running with the database/application server/operation system/monitoring system/etc., creates and opeartes parallel development/test/regression environments, customizes the software to fit their business, determines how to operate the software (monitoring, backups, performance tuning, etc.) and figures out how to use it to benefit their business, the customer knows a lot more about the software in a "real-world" context than the software vendor who created it!

Plus, the on-premise software vendor has no idea how the software is configured, what customizations and system integrations have been performed, the data in the system, etc.  This makes it very difficult for the on-premise software vendor to "support" the software they originally shipped on a CD.

Case in point:  Yesterday, we ran into an issue with BEA Weblogic, where it created an invalid WSDL for a web service we were writing.  I called up BEA, and got the age-old first question:  "What version on you on?"  Then "What service pack? Any patches? What operating system?  What OS version? Which database...?"

BEA needed to replicate the issue in their environment (an error in the customer's environment isn't very helpful to an on-premise software vendor), so we had to write a generic test that demonstrated the error, and email it to them.  They promised to try to replicate the issue and get back to us...

I'm not picking on BEA in particular here, just pointing out how difficult it is for an on-premise software vendor to support a hundreds of software versions and dozens of platforms that their software runs on (each platform component with many more versions), in customer environments where the vendor has no idea what's happening.

If/when we get a response, I guarantee it will be one of the following answers:

1. You need to upgrade to our latest version
2. It's not our software, it's the operating system/database/driver/etc.
3. It's due to a customization, or your code
4. Sorry, we can't replicate the issue
5. A fix is scheduled for the next service pack/version

The common element of all these answer is, of course, they don't fix the problem!  So the only path for enterprise software customers is if a bug is found, work around it, because the odds of the vendor providing a fix expediently is about zero.

SaaS is, of course, completely different - the SaaS vendor is responsible for making the entire stack work together, the SaaS vendor knows the configuration/data/usage pattern already, and when a fix is created it is deployed to every customer, automatically.

An SaaS support anecdote:  We're an SaaS vendor with close to a half-million users, and I called a user yesterday who had several long response times, to find out her intention with her use case.  She didn't report an issue, in fact she had found a workaround already, but I noticed it because it showed up in our monitoring of user issues.  It looks like the issue was the result of a fairly rare combination of user roles, so I wrote up a ticket and the fix will be in the next patch.

Can you imagine Oracle or Ariba calling a user to investigate a performance issue that the user hadn't reported?

A mature SaaS solution has monitoring built in that tracks and notifies the vendor of any errors the user receives, reports that fail, long-running response times, etc.  And the SaaS vendor proactively finds and fixes issues because they know that user satisfaction, adoption and usage are the primary drivers of their revenue and profitability.

This is a big beneficial element of the SaaS customer ownership experience, one that most buyers don't realize they will get when they evaluate a SaaS solution.