Let's Separate the Two Sides of the ASP Coin

It's been about four years since the first ASPs burst onto the computing scene. They were followed shortly by hundreds of other companies that figured they too could build a better IT mousetrap. Since then, we've witnessed dozens of permutations and combinations of providers come and go, trial-ballooning multiple acronyms along the way to try to distinguish themselves and win customer acceptance for their particular flavor of "ASP." Today, we're still stuck with the problem of a muddled — and now tarnished — ASP vendor category.

Summit Strategies has worked for quite some time to sort out and alleviate the confusion about different types of providers offering software as services, but it has been an uphill struggle (see Summit Strategies' May 2000 report, Bringing Order to the Chaos: Segmenting Service Providers in the ASP Ecosystem, and October 1999 report, Nothing-but-Net: Application Service Developers' Gold Rush). Over the years, it has become increasingly clear to us that, slight nuances aside, there are two distinct sides to the ASP coin. In fact, these two sides are so distinct that we believe continuing to lump them together does a tremendous disservice to both camps — and to customers weighing which type of provider will best meet their requirements.

The Traditional Side
On one side of the coin, we have the "traditional" ASPs. These vendors include independent ASPs, such as Corio, USinternetworking and Surebridge (see our July 2002 report, Corio, Take Two). Conventional independent software vendors (ISVs) that have created their own, direct ASP offerings, including Oracle, PeopleSoft and SAP, are in this category as well (see our March 2002 report, Traditional ISVs: Moving Along the Software-as-Services Curve). Although there is clearly a distinction between independent ASPs, which host and manage third-party solutions, and ISVs that host and manage their own products, these companies share some key traits. For example:

• They retrofit packaged enterprise software for Internet delivery.
• They aim to spare customers the burden of deploying and managing complex enterprise solutions. Unlike traditional outsourcers, these ASPs also promise customers visibility into, and control over, their applications and services.

• By deploying the same solution repeatedly for many customers, traditional ASPs can achieve "economies of skill." Through repetition and familiarity, they can help customers avoid mistakes and achieve return on their software investments more quickly.

• In the vast majority of cases, customers must purchase software licenses in the same way as if they deployed internally.

• The ASP typically installs and manages each customer as an individual instance, and will customize the application —down to the source code, if necessary — to meet customer requirements.

Although these two groups are likely to cross-fertilize each other in some interesting ways — such as through acquisitions, mergers, partnerships and development initiatives — today they are much more different than alike. Aside from the fact that both sides use the Internet to deliver software, they have few fundamentals in common. Each side could do itself — not to mention its customers — a big favor by more crisply defining its underlying business and development models, and, in turn, clarifying its end values for customers.

Tools:

Add aspnews.com to your favorites Add aspnews.com to your browser search box IE 7 | Firefox 2.0 | Firefox 1.5.x

Back to Analyst Columns