ASP: A Model in Search of a Market

Application service providers (ASPs) promote the appealing simplicity of resolving a complex quandary in a single stroke. They know that companies question investing the time and money to buy and install software that might be obsolete or inadequate for users' needs before the enterprise-wide rollout can be completed. And how can IT professionals convince users to embrace new software when every upgrade seems to bring as many headaches as benefits, especially in the beginning of the upgrade cycle?

ASPs had the solution: software sold as a service instead of a product. Companies could have the latest, greatest software at a fraction of the price and cut support costs as well. Hey, this isn't really a new idea—you've heard of time-sharing and outsourcing, haven't you? The only difference is that ASPs would share software instead of hardware.

But the ASPs' plans haven't worked out. According to a study by Organization and Technology Research (OTR), a European think tank and consulting group, the ASP market will actually shrink by 60 percent to less than $874.1 million by 2004 rather than grow into a multibillion dollar market by that time, as the most optimistic forecasts contend.

The organization's survey of 150 companies in the United States and Europe suggests that the ASP model won't succeed. Many companies simply don't want ASP services, and for good reason. For small and midsized enterprises, the potential savings of moving to an ASP model are small at best, and in many cases, probably theoretical.

But an exclusive analysis of data provided by reveals another problem: ASPs have defined their market area too broadly. Companies that call themselves ASPs offer services in dramatically different software segments. Graph 1 shows percentages of ASPs that offer or intend to offer services in enterprise-process applications, information-process, and individual-process applications.

ASPs' most popular area is information-process applications: data mining, Web hosting, storage, simple e-commerce (basic transaction services), and complex e-commerce (transaction services and supply-chain management). Graph 2 shows the breakdown of ASP service plans in this area.

The numbers further show that simple e-commerce piques the most interest, followed by Web hosting and complex e-commerce. This configuration makes sense—most corporations are new to e-commerce and Web hosting. These often labor-intensive functions can easily be conducted remotely.

Graphs 3 and 4 reveal the breakdown of intent in the other two broad application areas. Graph 3 reflects the intentions of ASPs in enterprise-process applications: enterprise resource planning (ERP), customer relationship management (CRM), human resources management (HRM), and related applications.

Except for CRM, ASPs don't enthusiastically embrace this area, nor should they. ERP and HRM were well-established enterprise applications before the Internet grabbed the corporate mindshare it has today. Moreover, successfully implementing these applications often requires re-engineering business processes, increasing the risk of relying on a third party for software services.

Graph 4 shows ASP intentions to provide individual-process applications: desktop productivity tools, collaboration tools, email, and graphics. ASPs show less interest in these areas than in the information-process space, with the notable exception of email.

ASPs have marketed themselves as all things to all companies, and now that approach has become troublesome. Indeed, some folks in the industry want to jettison the term ASP in favor of xSP, in which the customer fills in the x. Others seek to develop a more specific nomenclature—promoting the term "commerce service provider," for example.

The greatest areas of opportunity, both for ASPs and companies interested in ASP benefits, appear to be applications created by the Internet—email and e-commerce. Attempts to integrate the Internet into existing applications look far less hopeful.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.