ASPs failed ? but are now making a comeback

FUTURE TECH

Application service providers went wrong in several respects.

Some five to six years ago, Application Service Providers (ASPs) were one of the hottest categories in software.

They would transform the way software would be delivered and create a win-win situation for customers and software vendors. That dream did not pan out. ASPs were lumped in the basket of internet failures "� along with online pet food stores and b2b exchanges.

Unlike the others, though, ASPs are now making a comeback "� and for good reasons. I believe that the ASP business is where search was in 1999 when Google strode on the scene "� ripe for new entrants to come in and change the rules of the game. But first, let us walk down memory lane to understand the promise of ASPs and then analyse what went wrong in the first wave.

ASPs offer applications over the internet using their own servers to customers, who pay a regular fee for the use. For companies, there is no need to own either the application or the underlying infrastructure.

For service providers, it helps them aggregate a large number of customers, providing economies of scale. Using the internet as the distribution medium, ASPs can reach out to customers globally.

Wikipedia outlines the advantages: software integration issues are eliminated from the client site; software costs for the application are spread over a number of clients; and vendors can build more application experience than in-house staff.

It also mentions the disadvantages: the client must generally accept the application as provided since ASPs can only afford a customised solution for the largest clients; the client may rely on the provider to provide a critical business function, thus limiting their ability to handle that function to that of the provider; continuing consolidation of ASP providers may cause changes in the type or level of service available.

ASPs promised a world where software would be delivered over the internet; customers would have to pay a monthly service charge rather than a large upfront payment, and vendors would have great scale in offering the services to business globally "� much like Yahoo, Google and MSN have done for consumers in every country of the world.

On paper, the ASP idea looked like a great win-win for everyone. So what went wrong?

An October 2002 article in "Baseline" summarised what went wrong with the business model of ASPs: "The idea was that the customers, then primarily dotcoms, would be freed of purchasing and maintaining software and could use their dollars elsewhere, perhaps to bolster their marketing budgets and build their brands. And the rent would provide ASPs with a steady source of income...But two things went wrong.

First, there were few companies that thought renting was a good idea. Most wanted to own an asset as important as software and they were not about to turn over anything that controls their critical business processes to an outsider. Second, the internet stock market crash wiped out most of the customers.

John Hagel's book "Out of the Box" (published in 2002) has an extensive discussion on ASPs, what the early companies did wrong and how it can be done right.

He writes: "ASPs in many respects presented a false start in the efforts to break out of the enterprise straitjacket. In particular, few of them adopted Web services architectures as their technology platform. Instead, they attempted to build businesses on the internet using traditional technology architectures. This proved a significant flaw in the early ASP model."

Hagel then discusses the reality of the first wave of ASPs:

Product complexity and lack of flexibility: Traditional enterprise applications were designed to meet the complex needs of a large enterprise. Small and medium-sized enterprises rarely needed the full complex functionality embedded in these applications. As a result, the applications proved unwieldy in smaller enterprises "� they were slower and more complicated than necessary. [Also,] applications designed using conventional technology architectures presented major challenges when businesses tried to customise them or connect them with their existing applications.

Product performance concerns: Within the firewall, CIOs had much better control over performance. Outside the firewall, they worried about both technical and corporate performance.

Vendor performance concerns: ASPs were new start ups, with a very limited track record. CIOs found that ASPs had very limited operating history to provide reassurance that their management processes had been tested successfully in high-volume, mission-critical environments.

Challenging vendor economics: Customer concerns about ASP performance and the lack of compelling product benefits contributed to much higher customer acquisition costs than anticipated. Sales cycles were also longer than anticipated.

As a result, ASPs found themselves caught in a potentially life-threatening economic bind.

Hagel's key point: "The internet is not simply a new distribution channel. It often requires a fundamentally new set of products and technologies if a business is to exploit its full potential...Web services architectures are the key to unlocking the full business potential of the internet."

That is the starting point for rethinking ASPs. But there's a lot more to ASPs than web services. We also need to rethink about the markets they address. As I will explain in the next column, the big opportunity for ASPs is the long tail of enterprises in the world's developing countries "� what I call the SMEEMs (small and medium-sized enterprises in emerging markets). They have been largely unaffected by the internet "� other than email usage and in some cases have a minor web presence.

The software they use for their business remains almost identical to what they used five or more years ago. [In India, this is limited to mostly pirated copies of Microsoft's Windows and Office, and Tally for accounting.] They are the weak links in the information value chain and the next big opportunity for software vendors.

Rajesh Jain is managing director of Netcore Solutions Pvt Ltd. His weblog is http/www.emergic.org. He can be contacted at rajesh@netcore.co.in