Building SaaS

SaaS Means Innovation, Delivered Continuously to Customers

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

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

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

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

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

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

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

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

SaaS Simplicity - Things That SaaS Customers No Longer Have to Worry About

In the past few months, we've been asked a couple of times about installing our software in a customer's data center. These were Fortune 200 companies, with large data centers in place and with thousands of IT people already running hundreds of applications. Couldn't they run our application as efficiently and effectively as a 150-person Software-as-a-Service provider?

In a word, no. It quickly became readily apparent that it made no sense at all to install our software versus letting us run it in our multi-tenant environment, when considering all the things that enterprise customers no longer have to worry about when utilizing a true Software-as-a-Service offering:

• Upgrade Headaches: Enterprise software requires a lot of other components in order to run - servers, storage, operating systems, databases, application servers, networking components, etc. Each of these components has a vendor who regularly releases new versions with new capabilities, bug fixes, and security improvements - and the customer has to decide whether and when to upgrade for each new version of any component.
  
  Each upgrade project involves setting up a test environment, re-implementing everything with the new component version(s), and testing the compatibility, functionality and performance of the new configuration. This upgrade pain is costly, complex, and risky.
  
  [On the consumer front, even with Steve Jobs' famed devotion to simplicity (subscription may be required), iTunes still gives upgrade headaches to its users. Every few weeks I get a message "A new version is available, do you want to upgrade?" at exactly the worst time - when I'm opening iTunes to listen to music. Sure, I'd love to go to the Apple website, download a 20MB file, click through all the upgrade instructions, restart iTunes (maybe even restart the entire computer), close any "what's new" and "you've just upgraded" messages, wait for iTunes to re-index or re-structure its library, and hope that the upgrade didn't break anything (which it has several times), all before I get to listen to any music. Sign me up!]
  
  Rather than forcing the customer to figure out whether and when to upgrade any component in the technology stack, enterprise SaaS continually increases the capability and value of its software through automatic (and free) upgrades. Enterprise customers and users of true SaaS offerings don't have to worry about upgrade timing, projects, costs, etc.


• Being Orphaned on Old Versions/Technologies: One approach to minimize upgrade pain is to delay all upgrades - this can defer the cost and risk of upgrades, but at the price of declining support, being vulnerable to more and more security risks, not being able to take advantage of new features or technologies, and eventually being orphaned when one of the vendors drops support on whatever version you're on.


• Software Incompatibilities: When a new browser version comes out or a new service pack is released, the new version must be incorporated and validated and tested across the entire technology stack - and unfortunately, new software versions always play well with every other system component.
  
  As one recent example, BEA released and recommended a new service pack for WebLogic, but it turns out that when a user with Internet Explorer 6 logs into a site with this service pack using SSL (and every e-commerce site uses SSL), then WebLogic takes over a minute to return each web page! Don't ask me how the market-leading application server doesn't work with the market-leading browser version, but unfortunately that kind of incompatibility happens all too often.
  
  Finding, diagnosing, and working around this kind of incompatibility problem - which can occur with any upgrade of any component in the technology stack - is a lot of effort and difficulty that SaaS customers don't have to worry about.


• System Operations: Operating the production environment (and the various test environments, more on that later) takes database administrators, sysadmins for the servers and storage, network administrators, configuration managers, etc. Even the most efficient IT shop will require 1 to 2 full-time equivalents to manage all the tasks on all the various components across multiple environments - applying patches, administering security, performing backups and recoveries, managing upgrades, following change-control policies, and coordinating every action. With SaaS, the customer avoids the cost and the trouble of all these activities.


• Additional Non-Production Environments: To manage the various upgrades and operations, several environments beyond production have to be set up and operated: development, test, stress-test, training, data-recovery, and disaster-recovery environments. This multiplies the operations efforts, complexity, and cost - all of which customers avoid with SaaS solutions.


• Diagnosing Technical Issues: When an error occurs, a lot of work has to be done to diagnose exactly which pieces of the technology stack participated in the error. If a web-service has a transaction error, was it caused by the application server, application code, XML parser, database, operating system, or JDBC driver problem? Or was it a point-in-time network or DNS issue? It can take days or even weeks to replicate the issue, track down the exact component that caused the issue, and convince the component's vendor that they are responsible so they start their own diagnostic and fix effort. SaaS vendors, on the other hand, are responsible for the entire stack - if an error occurs, the customer has "one throat to choke".


• Building Technical Expertise: The common thread of the last few "worries" is that with on-premise software, customers have to become experts in all the technology components - installing, configuring, testing, operating, and fixing every component.  Creating all of this knowledge during an on-premise software implementation project, at the end the customer knows a lot more about running the on-premise software than the software vendor!
  
  Why should a customer have to become an expert in all of this? They just want to use the software and gain its benefits, but until SaaS, the price to customers included creating and keeping up-to-date all the business-irrelevant technical knowledge that goes into creating and operating and upgrading the on-premise software and all the other components.


• Cost Surprises: The long-term cost of ownership of on-premise software is a big unknown, especially over the long-term. How much will replacement servers and storage cost in several years? How expensive will the upgrade project be in three years? How many technical problems will we encounter with this software, and how many people will it take to solve them?
  
  True SaaS greatly reduces cost surprises - there's one price per seat or per transaction or per month or whatever - and that's what you pay. [Of course, some semi-SaaS providers try to tack on extra fees (maybe they are on-premise or consulting vendors in disguise?), so look for pricing simplicity in SaaS vendors you work with.]

In short, enterprise SaaS largely wipes out these complexities, costs and risks for customers - all of which are irrelevant to the customer's business goal of obtaining value from the software. (In addition to simplicity, SaaS customers gain ever-increasing capabilities for the same price, with each automatic free upgrade.)

The irony here is that over the past two decades, large enterprises have gotten so used to managing these costs and these worries of on-premise software, that it's sometimes difficult to communicate how much simpler things are for them with SaaS. Overall though, when you think of all the things SaaS customers no longer have to worry about, it seems apparent that simplicity will continue to increase SaaS adoption and market share, especially in software segments where SaaS has inherent advantages.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Virtues of Building Software on One Platform

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

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

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

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

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

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

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

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

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

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

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

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

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

SaaS = Freedom from Upgrade Agony

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SaaS's Total Cost (& Value) of Ownership

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

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

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

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

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

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

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

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

Defining SaaS? Focus on the Business Benefits

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

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

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

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

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

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

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

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

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

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

Memo to the Skeptical CIO

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

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

To directly address the "Skeptical CIO" conclusions:

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



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



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



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

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

Why We Don't Offshore Product Development (Part 4)

So far I've outlined why we don't offshore product development from a customer's point of view - mainly because onshore development gives much better responsiveness and quicker cycle time. SaaS's collaborative, fast-response product development and maintenance processes don't lend themselves to overnight development.

Now for the "internal" reasons. These aren't as directly visible to customers but have big impacts on the team's productivity and product quality. Because of these reasons, we have found that we can develop higher-quality and higher-value SaaS software in Denver for the same cost as in India.

• The Collaborative and Creative Nature of Software Development: As described the last post, a customer-collaborative process increases the value of software through frequent feedback and course corrections. Just as importantly, the internal software development process benefits from close collaboration among product management, development, quality assurance, and customer-facing personnel.
  
  Collaborative refinement of specification and design will deliver far higher-quality software than rigidly following a spec. KANA Software, in their offshoring efforts, found "that our offshore developers often told us, 'Here's what we built, exactly as you wanted - but it won't work, and here's why.'"
  
  In addition, software development is different than product manufacturing because every software requirement is unique, and requires creative and learning problem-solving to get to the best answer. If you're making thousands of exact copies of a widget to a specification, then offshoring is great - but "software factory" is an oxymoron.
  
  In fact, some researchers have characterized software development as "artful making", as described in this excerpt from IEEE Software Journal: ("Software Making as Art"; Austin, R. and Devin, L., pp. 93-95, January/February 2003):

  "Artful making... has a recognizable structure. It’s iterative and thus involves doing and doing again... It de-emphasizes planning in favor of learning from experience. It delegates control to makers themselves, aspire to enhance individual and idiosyncratic talents, and uses the environmental uncertainty of ongoing change to fuel innovation... The difference between a good and bad system is not how well it meets the requirements you know in advance. Meeting requirements is a necessary but insufficient condition for producing an excellent system. What makes a system great is details that are not specifiable in advance—aspects that must evolve in the making... As long as our processes are structured for conformance to advance specs, we’ll have problems because software development’s essence is creation, not conformance."

  In short, software development is a creative, collaborative process, and offshoring breaks the short-cycle value-increasing collaborations.



• Far Lower Maintenance Effort With SaaS: Offshoring product development to India initially gained momentum with offshoring software maintenance to India. The first impetus was the Y2K effort, where lots of COBOL programs were shipped overseas for scrubbing to ensure that next-century dates were correctly handled, and in the process India built up infrastructure and capabilities maintaining software offshore.
  
  The second impetus was actually driven by the nature of on-premise software - over time, the on-premise software vendor has to maintain more and more old versions of the software on a myriad of platform software combinations (operating system, database, application server, etc.). The longer the software vendor has been around, the more maintenance effort there is, and The Economist has estimated that up to 80% of development effort and cost is absorbed by maintenance.
  
  Once offshoring became a viable option, on-premise software executives started saying "Why am I paying six figures to each of my senior developers just so they can create hundreds of patches each month? We can offshore maintenance and lower our costs by more than half, and if patches are a little lower quality or slower to be delivered, well that doesn't matter because our customers on maintenance are locked in anyway." Plus, developers liked being relieved of this effort because maintenance required them to work on 3-year-old code and repeatedly fix the same bugs across multiple versions, which is a lot of unsatisfying grunt work. So by offshoring maintenance, everyone was happy and maintenance fees became even more of a money-maker for on-premise software vendors.
  
  With SaaS software, maintenance is a much smaller effort because the SaaS vendor only maintains the current version, and whenever an issue arises the SaaS vendor already knows the customer's configuration, click-stream, and data - so issues are easy to diagnose. Working only on the current version also means the context is already there - the developer is fixing a bug in code that they worked on a couple of weeks ago (rather than years ago with on-premise). As a result of these factors, in our instance, maintenance is typically about 10% of the workload. In addition, maintenance is a key feedback mechanism on the quality of the software and UI design and implementation, improving our internal learning and consistency. So offshoring SaaS maintenance is simply a non-starter - it's a small part of the development cost and also has a lot of value to the development team that would be eliminated by offshoring it.



• System Engineering: Finally, development SaaS software involves a lot more than just adding functionality - since all users will be able to use the feature overnight, the software developer has to design and develop for performance, deployability, UI consistency, monitorability, diagnosability, maintainability, flexibility, enhanceability, etc. - a lot of "abilities" that helps operations deploy the software and monitor it, helps the developer diagnose and fix any issues quickly, and helps enhance the functionality for the next version.
  
  With on-premise software, many of these "abilities" are pushed to the implementation consultants or customers' IT shops to figure out. Others are deferred until the release is out and customers upgrade to it years down the road. The on-premise developer's goal is to get new functionality working well enough for sales to demonstrate it, since customers won't actually use the software in production for quite a while. By then, the offshore team is fixing issues.
  
  But SaaS is used immediately in volume by all customers with their varying usage patterns. So SaaS developers do a lot more than design and code functionality, they are actually system engineers - envisioning how users will use a feature in context, how their code will perform in the real world under load and with the other system components, and what likely directions the maintenance and enhancement effort will take.
  
  Many of the system "abilities" are unspecified in typical software requirements, and some are even unspecifiable as they are internal to the development process and not visible to the software users. Consistent with the creative process outlined above, the system engineering to address all these "abilities" requires highly knowledgeable and highly versatile developers who have the customer context and full range of understanding of how the software will be used, in order to make many judgments and tradeoffs among the various "abilities" when building a software feature.
  
  So while offshore development can develop software so that the screens behave correctly, attaining this level of customer-knowledgeable system engineering that incorporates all the abilities - critical for successful SaaS software - is close to impossible.



• Internal Design Consistency: Another implication of the "abilities" in the last point is that the resulting code needs to be internally consistent in order to maximize maintainability, and also to be compatible with all the non-functional components that make up SaaS software - the monitoring subsystem, configuration backbone, integration framework, etc. Using established design patterns which are supported by the underlying framework will result in more consistent and higher-quality software, since the design patterns and framework have been proven out through multiple maintenance iterations.
  
  We found out the hard way that a separated development team can get the functionality working right and pass all the software quality assurance tests, but under the covers use some new approaches that prove much more difficult to maintain and requiring significant rewrites. Fixing this issue with more training and constant oversight just increases the time and cost of offshore development, not to mention also decreasing the satisfaction of the local development team since they're reviewing checkins and writing emails and checklists rather than coding.
  
  With our local development team, design consistency comes from continual hallway discussions, ad-hoc design reviews, and real-time "ask the expert" queries of the subsystem owners. Sure, an offshore team can read the wiki and email their questions, but answering a question right when it arises with high-bandwidth conversation results in far better software, compared to a day-later email response.

In short, building SaaS software requires a fast-response, customer-knowledgeable, collaborative system engineering effort that also satisfies unspecified (but highly valuable) customer and internal requirements. Satisfying these requirements - and iteratively evolving an excellent system through artful making - cannot be done effectively across 12 timezones.