ASP Myths and Misconceptions
By Art Williams
August 5, 2002
The ASP market is no longer an ill-defined novelty. The value to customers has been demonstrated, and market estimates suggest strong growth. Despite this relative maturity, the ASP business model remains plagued by numerous myths and misconceptions. We discuss, and hopefully clarify, 14 of them below.
| Read and React |
| "As attractive as it might be to outsource critical business activities, until ASPs demonstrate sustained profitability, the risk of financial difficulty will slow uptake. This is particularly true of ASPs that target large customers. Large customers are understandably risk-averse. A surge in new customers is likely to accompany sustained profits." Give us your feedback in the ASPnews Discussion Forum |
Myth 1: ASPs should/must better articulate their value proposition
Not true. The ASP value proposition is simple and well-understood. Namely outsourced application delivery is almost always better, faster and cheaper. Unfortunately, the value proposition is strategic. What controls the rate of ASP adoption is less the numerous strategic benefits than the very serious tactical barriers or hurdles. These barriers include sunk costs, anxieties associated with control and ASP financial uncertainty. These issues are utterly critical to ASP adoption and growth, but they are fundamentally independent of the strategic benefits.
Myth 2: Web/WAN delivery is central to the ASP model
Not true! This is a case of misplaced emphasis and change over time. It was certainly the generally held preconception that the Web, or more generally wide-area networks (WANs), constitute an enabling technology for ASPs. As both vendors and customers have come to realize and appreciate that the value of ASPs is technical focus and skill sharing, many ASPs, including all enterprise ASPs, now offer on-site solutions in which the relevant hardware, software and jobs remain on the customer's site. On-site offerings have little to do with the original preconception and strategic value proposition, and everything to do with skill sharing and reduction of tactical barriers to adoption, especially sunk costs and jobs.
Myth 3: The ASP model is based on application rental (as opposed to purchase)
It is true that one of the benefits of ASP outsourcing is the predictability of the expense. But, the predictable expense need not include rental of the application license. There are three principal components of a software investment, the license, implementation and ongoing administration. They can be, and are, bundled differently by different independent software vendors (ISVs), ASPs and system integrators. The principal complication of ASP revenue model is compensation and motivation of the salespeople involved. Everyone benefits in the long term from the annuity model, but the up-front implications can affect motivation.
Myth 4: The ASP Market is intrinsically new
The point here is that revenues already going to ASPs and additional revenues representing ASP growth do not represent new spending by customers. In fact, they represent a cost/spending reduction. ASP revenues are a portion of existing budgets. Like other forms of outsourcing, ASP revenues represent a diversion of resources from internal to external consumption.
Another aspect of the ASP market that is not at all new is the outsourcing of software-related services that do not provide competitive differentiation. (See myth 7.) A decade ago, it was common for enterprises to write software. Just as the unshared cost of writing software proved prohibitive, sharing the cost of running software will be as common in a few years as is today's outsourcing to ISVs of software writing. Note that neither the writing nor the running of software provides competitive differentiation.
Myth 5: There are many ASPs
There are, in fact, many ASPs. However, ASPs are even more varied than the software they run. Typically, only two or three ASPs are suitable for the needs/desires of any specific customer.
Myth 6: IDC has demonstrated that ASPs reduce costs
IDC has addressed the issue of the cost effectiveness of ASP outsourcing twice, first in their much-quoted ROI report and subsequently in a study commissioned by Oracle. While both studies are valuable and accurate, neither isolates the cost comparison of greatest interest. If we decompose the total software investment into its three fundamental components license, implementation and ongoing administration then the first study mixed all three components, and the second mixed the second and third.
The three components are very different. The first concerns the functionality of the application itself: can it solve the business challenge in question. Implementation and ongoing administration are also very different. Implementation is much more industry-segment specific, even customer specific, whereas ongoing administration is necessarily much more focused on the technology of the application and its supporting infrastructure.
The most compelling assessment of the cost reduction achieved by ASP outsourcing is that offered by Oracle. The saving was estimated in two ways that serve as a consistency check. First, Oracle asked its hosting customers to estimate the cost of the insourcing alternative. Second, Oracle asked its conventional software customers to estimate the cost of outsourcing the running of the software. The two procedures yield consistent results, with estimated savings greater than 50 percent by both routes. The savings estimated by Oracle are somewhat larger than those predicted by other ASPs for their customers.
This is at least consistent with the relative infrastructure homogeneity permitted by the comprehensiveness of Oracle's application offerings. Oracle stresses the benefits flowing from hosting software that they design, write and support. That is, Oracle stresses benefits that are effectively unique to Oracle, those of compressing the support chain. Note that the magnitude of the savings is more important than our ability to analyze and understand them; they are large.
Myth 7: Critical business processes should not be outsourced
This is the most important misconception of the ASP context. It is core processes that should not be outsourced. Precisely because they are critical, critical processes should be performed as well as resources permit.
If outsourcing a critical process means better, faster and cheaper performance, then outsourcing should at least be considered. The important difference between core and critical processes is that core processes provide competitive differentiation, whereas critical processes do not, despite their criticality. An artist can go to the deli for lunch (outsourcing his food service), but he cannot outsource his painting. Medical surgery is a more instructive analogy. Few of us even consider having a personal surgeon. We share one with other patients.
Myth 8: Control: Enterprises must control critical processes
Control is a widespread and legitimate concern among potential ASP customers. It takes several forms. The most prominent is: Whose fire gets fought first? ASP outsourcing implies becoming dependent on resources shared by multiple customers. The firefighting example is instructive. Because system availability is so crucially important, a customer doesn't want to be competing with other customers when his system is down.
Fundamental to this discussion is availability. First, availability is almost always higher with an ASP. More relevant to the competition for fire-fighting resources is the fact that availability is quite high, independent of who runs the application. Outages are sufficiently rare that, providing they can be kept statistically independent, two customers will simultaneously need fire-fighting resources extremely rarely. (The significance of statistical independence is that the probability of two outages is the product of probabilities of either. The product of two already very small numbers is a yet much smaller number.) Just as few of us can justify a personal surgeon, few of us can justify a personal fire department.
As unlikely as a competition for shared resources might be, customers are much more comfortable if they are provided with a window into the fire department. More generally, operational transparency can approximate control. Corio is leading the effort to provide effective transparency. An elaborate Web application allows customers to pull the fire alarm, and to monitor the deployment of (named!) resources as well.
Myth 9: One-to-Many; ASP profitability precludes customization
ASPs depend strongly on a one-to-many efficiency, but it is not the form standardization with which ASPs are often tarred. The standardization on which the ASP model depends is that of infrastructure, that is, not standardization of the application. Infrastructure standardization permits engineers to design and troubleshoot across multiple customer accounts, because the accounts use a common infrastructure. ASPs fundamentally use the same hardware, software and skills as employed in the insourcing alternative; the reason that they are dramatically less expensive is that engineers can administer systems much more effectively when the infrastructure is standardized. They know exactly what's out there. Furthermore what's out there is the version of the hardware and software with which they are most experienced and familiar.
The unimportance of customization ASPs is most clear when it is accomplished by configuration, in which case the customization is merely a subset of the data on which the application operates. Customers differ from one another primarily by their data. Even when customization is accomplished by code, such code is a small fraction of the system administered. In the increasingly rare case when substantial customer-specific code is required, ASPs charge a premium. Note that the creation of the customization, that is, the implementation is, in fact, strongly customer specific. The services of ASPs and system integrators are very different.
Myth 10: ASP value rests on staff superiority
While ASP staffs are often more focused and experienced with the applications on which they specialize, it ain't necessarily so. In-house staffs often have long, focused experience with their system. The profound difference between in-house and ASP staffs is that the ASP staff is shared by multiple customers, whereas the cost of the in-house staff is borne by one business. The importance of this distinction is particularly clear in the analogous context of medical surgery. That is, few of us can justify a personal surgeon. Additionally, for ASPs to suggest any flavor of staff superiority can be offensive to potential customers. So, while often true, claiming staff superiority is both potentially offensive and unnecessary.
Myth 11: Modern, Web-enabled and Web-Services Application Architectures are Critical to the ASP Model
This is fundamentally, but not completely, untrue. It is untrue to the extent that the important comparison concerns who runs a given application, the in-house staff or an outsourcing vendor (ASP). The architecture of the application is common to the two alternatives, and is therefore fundamentally irrelevant to the comparison. It subtracts out of cost/complexity comparisons. Having said that, it is also true that there are numerous advantages to the newer architectures. In particular, Web-based applications are much less expensive to administer and support. Of special importance is the fact that they eliminate the need for client installation and support. Applications exploiting Web services can be very powerful, but few exist. The principal implication of these architectural differences today is the importance of customer appreciation of the cost, complexity and availability implications of the architectural differences and the corresponding willingness to pay accordingly.
Myth 12: Writing software is intrinsically more profitable than running software
Software is often held up as uniquely profitable, because of its negligible manufacturing costs and volume-independent development costs. There are, however, costs other than manufacturing and development, in particular support and sales. While development costs may be independent of revenue, sales and support costs are not.
Ongoing services, like those of ASPs, require a single (in principle) sale. The incremental profitability of an ASP contract renewal is very attractive. Patrick Curran of Great Hill Partners, a Boston-based venture capital firm, has collected data showing that service providers offering ongoing (annuity) services enjoy capitalization-to-revenue ratios more than ten times greater than those of providers of in-and-out services. ISVs often break even with license revenue, and rely on maintenance contracts for most of their profit.
Myth 13: Financial uncertainty is eliminated by cash sufficient to cover burn
As attractive as it might be to outsource critical business activities, until ASPs demonstrate sustained profitability, the risk of financial difficulty will slow uptake. This is particularly true of ASPs, like Corio, BlueStar Solutions and Qwest Cyber Solutions, who target large customers. Large customers are understandably risk-averse. A surge in new customers is likely to accompany sustained profits.
Myth 14: If the essence of the ASP model is skill/guru sharing, then IBM and EDS win
While containing some truth, this statement ignores important differences. First, ASPs exploit one-to-many efficiency (See Myth 9.) more than the traditional outsourcers can. By offering only one or a few applications, ASPs can maintain a significantly more standardized infrastructure, which allows scarce and expensive skills to be highly leveraged/shared. IBM and EDS have traditionally assumed responsibility for whatever the customer has deployed. This is a very different, and less cost-effective, proposition. Note, however, that the traditional approach is less disruptive. It is the zero-breakage solution.