Software On Demand: Attacking the Cost Structure of Business Systems

April, 2005

I’ve long been convinced that the “on demand” model for business applications has much to offer. Now, after listening in on a conference call with Timothy Chou, former head of Oracle’s On Demand business, I’m even more persuaded that we’re at the beginning of a major change in how business systems are sold, implemented, used, and maintained.

ThinkEquity Partners, an investment analyst firm, hosted the conference call with Chou. He presented more material than I can cover in this post, but I’ll summarize what I consider to be the major insights.

What Is Software On Demand?
First, by way of review, the concept behind software on demand is simple. Instead of a software vendor selling you a software license that you then implement and maintain on your own computers in your own data center, the software vendor hosts the system on its own computers in its own data center and sells you access to the system on a subscription basis. In a nutshell, software on demand turns software from a license sale to a subscription service.

There are variations in the on demand model. The vendor may host a separate system for each customer (the “single tenant” model). Or, the vendor may host multiple customers on the same instance of the system (the “multi-tenant” model). It is a relatively simple matter for most software vendors to deploy software on demand in a single tenant model. But only vendors that have specifically designed their systems from the ground up to host multiple clients on a single instance can host the multi-tenant model.

Oracle’s on demand offering is a single tenant model. Oracle has to build a separate instance of its E-Business Suite for each customer., on the other hand, is a multi-tenant system: many customers are sharing the same single instance of the system hosted in a data center.

In response to my question, Chou agreed that software on demand is really the return to a very old concept in business systems: the service bureau model of timesharing. However, he pointed out that in the old days, timesharing was a way to address the high cost of hardware, specifically mainframe computers. Today, the problem is not the high cost of hardware but the high cost of software, and especially the management of software. This is the problem that the software on demand model solves.

Changing The Cost Structure For Providers and Customers
Chou’s main argument is that the traditional cost model for software is broken. He says,

On the side of the customer, IT guys are spending 75% of their budgets managing installed systems, and the percentage is growing. At the end of the day, if we as an industry do not solve this problem it will be the end of software, because there won’t be any money left for customers to buy new software.

On the customer side, the total cost of ownership of business systems is heavily weighted toward ongoing support. Customers often worry about the cost of software licenses. But the license cost is dwarfed by the support cost. The rule of thumb is that a customer is going to spend four times the purchase price of the software per year to manage the software. For example, Oracle’s E-Business Suite costs about $4,000 per user. Therefore, the support cost is $16,000 per user per year, or $1,300 per user per month! Gartner reports similar numbers for SAP. This ratio is even true for applications such as email. This is why IT department budgets are dominated by the costs to maintain existing software systems.

But if I can come in and say, it’s not $1,300 per user per month, but $100, why would a customer not take my offer? Particularly if I can argue that I can do it better than he can.

If the cost structure for customers is unworkable, it is no better for vendors. Chou says,

On the producer side in the software industry today, we are seeing massive top line pressure. The days of million dollar software deals are over, there is increasing competition, and there is increasing pressure from the open source community. If a vendor cannot significantly alter the cost structure of the software business, there will be no margin left.

Chou breaks down the cost structure of a software vendor into three main categories and shows how the on demand model addresses each of them.

1. The cost of R&D, which is typically 15%-20% of the cost in a software company. However, much of a vendor’s R&D investment is swallowed up by work other than developing new functionality. For example, developers have to test against various configurations of operating systems and accommodate back-levels of various infrastructure components. Chou estimates that less than 5% of the R&D cost is actually spent on innovation.

2. The cost of support. This includes the vendor’s help desk and second level customer support to answer customer questions about how to set up and operate the application. Chou claims that prior to the PeopleSoft acquisition, there were over 4,000 support staff at Oracle, and “none of them are involved in building new stuff.”

3. The cost of sales and marketing. In a traditional software company, the sales force spends much of its time answering questions from the prospect’s technical staff regarding hardware sizing, infrastructure requirements, and other support issues. Chou also points out that when you are selling multimillion dollar software licenses, sales cycles tend to lengthen because a lot of money is at stake up front.

Let’s see how the on demand model attacks these three categories of cost for the vendor. A pure on demand vendor, such as, avoids many R&D costs because there is only one configuration of hardware, database, and software to worry about: the one that the vendor runs in its own data center. Therefore, the on demand vendor does not need to spend as much on R&D, because the complexity on the customer side is greatly reduced.

The on demand vendor also has lower costs of support, because many technical support calls are eliminated. Software on demand addresses this cost by taking over the support function from the customer and handling it with the vendor’s own staff.

Finally, the cost of sales for an on demand vendor is lower. Although software on demand still needs to be marketed and sold, most of these issues become moot inasmuch as the customer will not be hosting the system. In addition, because the up-front commitment is less, sales cycles are generally shorter.

Obstacles To Software On Demand
Chou says that many of the early objections to software on demand, such as security, have been largely overcome. Furthermore, CIOs these days seem to have less of a need to be “server huggers,” as he calls them—CIOs that want to be able to see the computer sitting in the corporate data center.

However, there is one objection against software on demand that still arises—the fact that software hosted by the vendor does not easily accommodate modifications. Chou’s response is that the on demand software providers today are doing a better job of allowing customers to make configuration changes without having to actually modify the software. But he also points out that CIOs really want fewer customizations. CIOs know how expensive modifications can be, and how much trouble modifications to packaged software can introduce. Ultimately, modification of packaged software is an economic decision.

Making TheTransition
Chou believes that most of the major traditional software vendors have not embraced the on demand model because it requires changes to nearly every aspect of their business. It is not just a matter of rewriting the application but of changing how software is developed, marketed, sold, paid for, and supported. He says,

This change touches every aspect of a software company, from sales, finance, R&D, distribution, and service. It’s not a simple shift, such as rewriting everything in Java. One of the challenges that the traditional guys have is not technical but organizational. The traditional guys have got to make the crossing, or they are finished. Many of them, including Oracle, have made a great effort, but they have to. The challenges are not insignificant.

In conclusion, Chou is not optimistic about the future of many traditional software vendors, and he thinks that many will probably not be able to make the transition to the on demand model. Therefore, the future of software requires new players. The economics of the on demand model are inexorable. Providers, such as, Webex, and Rightnow, are showing that the on demand model is not only viable but also thriving.

Some vendors fear that software on demand will just turn software into a commodity. But, as Chou says, “It’s not bad to be a commodity—it’s just bad to be in second place.”

For more development of these ideas, check out Chou’s book on the subject, entitled, The End of Software.

April 2005

For a more complete analysis of software on-demand, please see our report, Software On-Demand: Lowering the TCO of Business Systems.