Building SaaS

Why On-Premise Software Vendors Can't Innovate

Vinnie Mirchandani started a firestorm with his observation that "in existing Oracle internally-developed and acquired products in the last 5 years, Oracle’s enhancements have been anemic."

How should we measure innovation for enterprise software? I think it should be measured by customer business impact - not press releases or software demonstrations or even what's "available for download" from the vendor's website, but what is actually used by customers and how much it improves their business results. After all, enterprise software is all about streamlining business processes and enabling enterprises to do things they couldn't do before.

And this is where on-premise software (not just Oracle) falls woefully short. It doesn't have anything to do with talent or effort, there are thousands of hard-working, smart developers at Oracle and other on-premise software companies.

No, the reasons for lack of innovation are endemic to the on-premise business model and the on-premise customer ownership experience. (Bob Warfield starts the list on his blog). The bottom line is that on-premise vendors can develop all the code they want, but because of the high hurdles to upgrading to actually use the new software, most customers can't or won't upgrade for many years, so any "innovations" remain on the distribution DVD and have zero impact.

Why can't on-premise software vendors innovate? Because:

• Development talent is wasted maintaining old versions: since customers don't upgrade, the vendor must support old - even ancient - versions of their software. And upgrades must work with many old versions... again multiplying the effort to write upgrade and migration scripts.
  
• Development talent also wasted porting to multiple platforms: porting the application code to multiple databases, operating systems, and application servers requires a significant amount of development work and time, not to mention significant testing and documentation efforts, and also further multiplies the technical support efforts.
  
• Multi-platform support constrains innovation to the least common denominator of the various platforms: it's hard to be innovative when you're focused on making every new feature work across multiple versions of four different databases.
  
• Long release cycle times reduce ability to innovate: All the porting, multi-path upgrades, and testing efforts mean that releases are very slow in coming - maybe a release a year at most. By contrast, even SaaS applications that have been around for a decade can release new functionality every 3-4 months because all these wasted efforts are eliminated.
  
• On-premise vendors lack intimacy with how customers use the software: On-premise vendors have no idea what the customer's business processes, configurations, setup or data looks like. In addition, they are shielded from customers by the system integrators who perform the lengthy implementation projects. Innovation involves applying technology to solve customer needs, but since on-premise vendors are somewhat blind to how their software is used in practice, their ability to innovate is severely hampered.
  
• Customers don't upgrade: Even when some modicum of innovation is achieved, customers must upgrade for the innovations to have impact, and upgrades are infrequent because they are so costly to customers. For example, even after two years of availability of Oracle E-Business Suite Release 12, less than 5% of customers have upgraded to it.

This is the core issue with on-premise software's lack of innovation - existing customeres, who have committed to the vendor's software, get trapped for years and years on their go-live version with static capabilities, ever-declining support, and no-value maintenance fees, until they decide to disrupt their business and undergo a costly upgrade project.

Of course, SaaS doesn't have any of these issues - that's why it's a better way to build software and deliver innovation to customers. Most enterprise customers don't yet understand the benefit they receive from ongoing innovations delivered by SaaS, without upgrade headaches or costs. But this is changing as enterprise customers experience SaaS's ongoing innovations first-hand.

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.

Measuring Developer Productivity

Joel on Software, as usual, has a great post about software development with a lot of truth in it - in this case, about the impossibility (and even inadvisability) of measuring software development productivity.

As Joel points out, measuring software development productivity is a subset of the problem of measuring knowledge worker performance, which is prone to gaming once a quantitative metric is applied. (In a Dilbert strip, when the programmers were awarded $10 for every bug they found and fixed - even if they created the bug - Wally says "I'm going to write me a minivan this afternoon"!).

But gaming aside, the even bigger reason knowledge worker productivity is hard to measure (and manage) is: How do you measure knowledge worker output, or more importantly, value?

It's especially hard to measure the value of a software developer's work, since there are so many variables that confuse activities with software value, as The Parable of Two Programmers deftly demonstrates.

One of the great things about running a Software-as-a-Service development group is that the software's value is a lot more readily apparent than with on-premise software. With SaaS, the feedback cycle is so quick and direct (through immediate usage by all customers) that many of the components of software value are apparent very quickly - the software's robustness, maintainability, usability, and performance.  All the elements that go into software quality are fully visible to the developer and to management within days, giving excellent insight into each developer's productivity (i.e., value per day) and improvement trajectory.

In addition, the entire software development process benefits from fast customer-based feedback. For example, if Product Management prioritizes a feature that customers end up not using, the software developer challenges them with their future prioritizations.  This accountability helps ensure that Product Management is focused on features that will be used and provide the most value to customers. 

Another aspect that I regularly push is to get a feature in front of customers so we can see how they use it and give us guidance on version 1.1 within days or weeks, not years (as used to be the case with on-premise release cycles). A fast-turn SaaS development approach makes it cheap to fail, delivering more course corrections and customer-determined value while greatly decreasing wasted effort on unfruitful features.

So by continually applying the development team's time on the highest-value features for customers who are currently using the software, the product's value progresses as quickly and efficiently as possible for the development investment. By contrast, with on-premise software, the development investment yields little benefit for customers - feature prioritization is typically targeted at making software demonstrations compelling to the next customer, the several-upgrades-per-decade means that the feedback cycle to the software developer and manager is many years rather than weeks, and a huge percentage of development effort is wasted on maintaining old versions of the software on a myriad of platforms.

The most important part is that the SaaS development process leads to higher value to customers, more quickly and continually increasing over time. The additional value from SaaS after go-live gives customers ever-increasing business benefits, which is why the free ongoing ugprades of SaaS make such a difference in the customer ownership experience vs. on-premise software. Only an ERP practitioner could love the idea of living in the straitjacket of one software version for years and years.

High-Metabolism Software Development

There's an interesting anecdote in today's New York Times that underscores how Software-as-a-Service, through instant usage feedback and frequent updates, can quickly learn what adds value to real users and drive the software in that direction:

"For Jana B. Eggers, general manager of QuickBase, a division of Intuit, the software giant, looking at her market is as easy as clicking a mouse. QuickBase applications run over the Internet, so when lots of new users sign up for a trial, or existing users flock to a new feature, Ms. Eggers and her colleagues see the patterns instantly."

The article describes how Intuit saw that rather than small companies adopting QuickBase, large companies were using it for different tasks.  Intuit redirected their marketing and product development in that direction, leading QuickBase to be the "fastest-growing business unit in Intuit."

Compare this to on-premise software products, where it can take months or years for enough customers to upgrade and actually use the latest release to be able to discern how well the software works for customers in practice.  The feedback mechanism for on-premise software is also broken, since the vendor often doesn't work directly with customers but relies on implementation consultants to get the software running.

As an example, last year I interviewed a Quality Assurance manager from one of the big ERP software providers, who described a "bug-fest" project they were working hard on because the latest release of the software has so many bugs. Out of curiosity, I asked how much time had passed between the software being released (to thousands of customers) and the company getting enough feedback to discover that there was a bug crisis: "A year," she answered.

A year!  The ERP software version had been fully tested and put on a CD and shipped to all their customers, and it was a year until enough customers were actually implementing the software that feedback finally made it back to the on-premise provider that there were more than the usual bugs.

That is why customers usually wait for the first service pack of any major on-premise software release - no matter how much Quality Assurance the on-premise provider performed, their tests simply don't reflect the customer's configuration, data, or usage patterns.  The software has to get out into the real world to really get tested.

SaaS providers perform enormous amounts of Quality Assurance because if something doesn't work right, it quickly impacts their customers in 12 hours, not 12 months.  Fortunately, SaaS providers already know and can easily test all their customers' configurations, data, and usage patterns - it's all in the SaaS system, and it's all tested before the upgrade is implemented.

This high-metabolism product development - create a feature, get instant feedback, improve and extend the feature within a few weeks - is a new concept for product development overall, not just software.  No other business or consumer product has had the immediate relevant feedback, product agility instant deployment throughout the customer base to leverage this learning cycle.

SaaS providers who get closer to customers and speed up their metabolism will drive their products faster and more effectively in the direction the market values, creating a sustainable advantage over those behind or slower than them.  According to the New York Times article, Intuit has adopted this approach:

"'So often with software, developers expect a certain feature to be popular, but a different feature winds up being what customers want,' Ms. Eggers said. 'A lot of companies try to explain away these surprises. We embrace them.'"