In-Depth

Are ASPs unsinkable?

• By Barrie Sosinsky, C. Thi Nguyen
• January 1, 2001

Application Service Providers—normally referred to as ASPs—provide applications through a service model. When you are a client to an ASP, applications are delivered to you as a service. Some might say that ASPs offer software for rent instead of for sale, but this is not accurate. ASPs are not simply providing an alternate mode for you to finance your purchase of an application. One might imagine the traditional mode of getting an application—purchasing a license for that application—as rather like buying a car. You go out and buy the thing. It is yours. You have to keep it filled with gas. When it breaks down, you have to fix it, or go find someone whom you can trust, and pay them to fix it. When the car dies on the road, you have to go out and buy a new one.

To understand the ASP concept of application as service, you might imagine that, rather than buying a car, you engage a transportation service. With the service, a car is always there when you need one. You do not have to worry about the gas, or the maintenance, or even replacing a car when it gets old. Now imagine that the transportation service tells you that they can do this for less money, in the long term, than you would spend on owning and maintaining a car on your own.

This is the ASP idea: subscribers will pay a fee, either on a fixed-rate, per-month, or per-transaction basis, and the desired application will simply appear on their computers. The subscribing enterprise does not have to worry about infrastructure, deployment, maintenance or upgrading. They simply pay the fee and use the application. The ASP industry's hope is that, in the final calculation, engaging an ASP to provide an application or a service that helps you deploy your app will be lower than the total cost of ownership of that application's development and deployment in-house. In the ideal ASP world, subscriber enterprises would largely outsource their IT departments. Except for simple desktop maintenance, all IT needs would be handled out-of-house by the engaged ASPs.

Sorts of ASPs
Behind the scenes, there are many varieties of companies in the ASP marketplace. Some companies lease infrastructure, others provide management. Some companies, called ASP enablers, seek to provide all the nuts and bolts for ISVs seeking to market their applications as ASPs. Other companies, called aggregators, build ASP solutions by buying pieces from more specialist ASPs. Others do it all in-house.

In practice, the ASP marketplace has become very specialized, with many new players starting up in a crowded field, each trying to carve out a niche for themselves. You can certainly find an ASP that will rent you a software suite, such as FutureLink.net of Irvine, Calif., which offers Microsoft Office to clients, as well as applications running on Windows Terminal Server and MetaFrame—a pure ASP, so to speak. As the ASP market has developed, pure ASPs are just a small fraction of the activity. As an example of specialization, consider a company like Data Return, Irving, Texas, that specializes in hosting Microsoft BackOffice applications on equipment that they manage at one of the big collocation sites such as Exodus. Data Return is an example of an AISP, or an Application Infrastructure Service Provider. More specialized still are companies like StorageNetworks, Waltham, Mass., which is a Storage Service Provider or SSP. StorageNetworks provides enterprise-class storage over dedicated private networks (fibre fabrics) to dedicated storage servers that the company manages for clients.

While you can certainly deploy thin-client applications at an ASP successfully with dial-up speed connections, it is the coming ubiquity of fat pipes or broadband connections that make ASPs intriguing as an industry-wide model for IT application deployment. The software industry is entering a new era, probably about two to three years away, of not only making full applications and application suites available as a hosted model, but also providing access to components that provide services to the applications that developers will build based on these components. You see that trend exemplified in Microsoft's .NET project, as well as in Oracle's Web business applications. In short, all of the benefits of an ASP—faster deployment cycles, lower staffing requirements, rightsizing of enterprise infrastructure and the ability to scale quickly when needed—are going to be available not only in hosted solutions, but in your development projects as well.

For many IT projects, ASP involvement makes sense. If you are a developer, then working with an ASP is in your future as well. It's only a matter of time. This article will focus on the benefits and risks of choosing to engage an ASP as a partner in your development projects and considerations for developing and deploying enterprise apps that are candidates for outsourcing.

The promise of ASPs
ASPs can do for corporations what thin-client computing can do for desktops. The advantages of the ASP are like the advantages of thin-client computing, multiplied. In traditional distributed PC computing, applications exist locally. They must be maintained and updated individually, which has a high manpower cost. Desktop PCs must be powerful enough to run the applications when needed. But, since applications aren't running all the time, that expensive computing power frequently sits idle. In the thin-client model, applications are hosted in a central data center. Only a minimum of display information is sent to an end-user's desktop. Thin-client computing centralizes application residence, reducing the manpower required for maintenance and updating. It also centralizes computing power—the desktops need only be minimally powerful—reducing the amount of idle computing power in the enterprise.

Among the most commonly cited benefits of an ASP are:

Economy of scale: ASPs centralize the computing power and application residence of many enterprises. Since an ASP maintains data center class installations, has a very specialized IT staff and is in the business of generating an application service for a large number of different enterprises, the ASP gets the benefits of an economy of scale that they should be able to pass on to their customers.

Deployment only happens once: A tremendous amount of the total cost of ownership of an application occurs in deployment. When an enterprise purchases a license, it must plan deployment, purchase infrastructure, install infrastructure, train its IT staff on maintaining the application and actually install the application. An ASP only has to go through this process once, establishing a modular offering that they can apply as a template.

Deployment may be seen to be a terrific barrier to project completion and success in many enterprises. Employing an ASP as an infrastructure partner can have the effect of shortening deployment time (not to mention lowering deployment costs), which translates into a faster time to market. What most managers do not realize is that the shortened time to market provides a return on investment not at the beginning of the project, but while the application is at its maturity. For a significant commercial product, the addition of several months at the time of maturity can outweigh all other factors.

Let's consider a hypothetical example of an Internet commerce application that starts off at zero income and grows to $12 million in the first year. The company has a 25% compounded annual growth rate for four years. Every year the company upgrades its electronic storefront, and every other year the company does a major server upgrade. In the years of initial deployment, the company is able to save four weeks of time (years 1, 3 and 5), and in the interim years (years 2 and 4) the company saves two weeks by hosting their infrastructure at an ASP. (Table 1 shows the results.)

Based on these assumptions, over the course of a five-year period, the company would grow from $12 million to $29.3 million, and would earn $98.5 million in total. Given that the company was able to save 16 weeks or approximately 3.5 months of deployment time, the net additional revenue or ROI that the $12 million company should be able to achieve over five years is $8.5 million (3.5 months/12 months x $29.3 million). We make this calculation based on the assumption that the revenue is realized at maturity, and not during ramp-up. If you further assume that a company spends about 15% of revenue on the IT equipment that is used to generate that revenue, then this calculation recaptures about 61% of the cost of the equipment, which is added to its bottom line as ROI.

IT manpower savings: Instead of replicating an IT staff across many companies, ASPs centralize manpower. There are two benefits to this. First, instead of employing lots of IT generalists, as the license/ownership model tends to encourage, ASPs can employ a smaller number of specialists. Second, the most expensive, capable IT specialists tend to be underutilized in the present model. Major problems rarely occur. So, in the present model, two scenarios can arise. First, companies hire specialists and pay a fortune for them to lie around and flex their massive know-how a few hours a week, and spend the rest of their time doing things that a much lower-level IT staff member could do. In this scenario, companies waste their money, and specialists feel like they are wasting their time. In the second scenario, companies do not have specialists on staff, and when big problems crop up, they have to hire outside consultants. This takes time—for them to find the consultant and bring the person in, and for the consultant to become familiar with the company's system. ASPs use specialists efficiently. Since ASP specialists watch over the apps of hundreds of enterprises, they are always busy and always working on interesting problems. And, unlike consultants, they are already in-house and familiar with the ASP's infrastructure and set-up.

It is difficult to find highly qualified IT staff today. And even if companies could find and retain them, the economics of how much time and effort they would save argue strongly for adopting a shared staffing resource. Considering that each IT administrator costs a company about $150,000 in burden costs, the savings based on staff reductions that an ASP might offer are significant.

Infrastructure is utilized efficiently: It is called right-sizing. With pooled resources, ASPs reduce the idle time on expensive infrastructure. An ASP is more likely to allow you to scale when you need to, and, just as important, scale back once the resource is no longer needed. IT spends a considerable amount of money on equipment and people that never get used. ASPs help you avoid the guessing game. In calculating your potential payback, consider the loss of revenue that could be caused by lost transactions due to not being able to scale, as well as the waste that could be caused by having scaled too large. ASPs offer you right-sizing insurance.

Higher availability: In theory, an ASP should be better at what it does than you are. That means that ASPs employ technologies that are difficult for companies to support. For some ASPs that means multipathing their communication lines over several Internet service providers or backbone networks. ASPs may offer you options like load-balanced redundant server farms or clustered solutions that are complex to support. So in theory an ASP should have significantly higher availability than your company can achieve.

What is an extra 9 added to the uptime percentage worth to your company? That depends upon your company's transaction level and your business' sensitivity to disruption. Table 2 shows the number of hours associated with each different level of downtime, and extrapolates the value for a hypothetical $12 million business.

Let's consider the effect of this hypothetical $100 million business that runs at 99% uptime a year and switches to an ASP that achieves a 99.5% or better uptime (update numbers appropriately). In this instance, the company would save $950,039 in lost transactions or $7,125,292 in fully appreciated losses per year. The gain in revenue for the fully appreciated loss would therefore be a net ROI to the company of 7.1% of its gross revenue.

Shortcomings of the ASP model
As we have said before, the advantages of the ASP model are like the advantages of thin-client computing, multiplied. But, the disadvantages of thin-client computing are also compounded in the ASP model. In thin-client computing, when you centralize computing power, you make that center utterly critical. If it goes down, then the application goes down for everybody. When you hire an ASP, you're centralizing your computing, then putting that center somewhere else and giving that center to somebody else to watch. Not all is rosy in ASP-land, so be careful whom you choose as your business partner.

Here are the main areas of concern:

Reliability issues: ASPs suffer from the same shortcomings as thin-client models. Centralize your computing power, and you increase the possibility for disaster. If the ASP infrastructure and IT staff is less reliable than your own staff would have been, then you'll suffer decreased productivity. The same table that we just used to calculate savings due to high availability can be used to calculate costs for downtime. Even if your ASP is exceptional, if the pipe between you and it goes down, you are out of business.

Most ASPs commit to a certain quality of service in their Service Level Agreements or SLAs. They often offer very little compensation for the potentially large losses that your company could suffer, and could bind you from breaking the contract. Pay special attention to the legal language in the SLA, and to your remedies.

Security issues: You are handing off your security to another party, and trusting that their experts are better than your experts, and you are collocating or pooling your data in, if not the same systems, the same location. Security is something that you hope would improve with an ASP, but it is harder to assess.

ASPs going out of business: When a company chooses an ASP, it runs the risk of the ASP going out of business. If the company is lucky, the ASP will warn it ahead of time, giving it time to transition away smoothly. Unlucky companies may find that the end comes with little warning; ASPs in the midst of horrific death throes can hide their financial woes in an attempt to keep their clients onboard. In such cases, the messaging server simply goes away, and enterprise resource planning software suddenly becomes unreachable. In the very worst case scenario, the company's databases, which were hosted at the ASP, are inaccessible for some period of time.

We've heard horror stories. ASPs are pioneers in a fledgling industry. That's why so many of them die with arrows in their backs. Stamford, Conn.-based GartnerGroup issued a report in August 2000 that predicted a major shakeout in the ASP marketplace. Says a GartnerGroup spokesperson, "The industry shift toward delivering software as a service has created a 'gold rush' stampede of vendors entering the ASP market, most of which have no idea of what it will take to survive for the longer term."

GartnerGroup predicts that 60% of the ASPs in business at the end of 2000 will be out of business by the end of 2001. By 2004, predicts Gartner, there will be only 20 full-service, enterprise-class ASPs, and fewer than 100 ASPs will offer point and product solutions. This reduction will come, predicts Gartner, through both bankruptcies and acquisitions. Pay attention to both the size of the ASP and to the partners it has acquired. Those are good indications of staying power.

If your company is very lucky, its ASP will survive. If it is lucky, its ASP will be acquired by a decent company and the provided service will be maintained with little interruption or trouble. If it is unlucky, its ASP will go bankrupt and it will be left without a boat to float on.

"Today's dot.com collapses will pale in comparison to the effect that the pending ASP meltdown will have on organizations that use these ASPs," states GartnerGroup VP Audrey Apfel. "When dot.coms collapse, they implode and have little effect on their customers and other industries. The ASP consolidation will have a domino effect, affecting business systems like ERP and accounting systems for companies that have outsourced these functions to ASPs. Then those failures can quickly spread the damage along supply chains."

Is an ASP in your future?
Every project that is a candidate for outsourcing should be plugged into a return on investment calculation. Do not kid yourself: ROI calculations are guesswork, just as income projections are for startup businesses. However, the process helps to identify the important factors in a project and to pin different ASPs down on how they would approach each aspect of deployment.

First, calculate: savings in staff, savings in equipment, potential impact of improved time to market and the impact of having more time to focus on your core business or other business opportunities. Then balance it against: costs for different levels of availability, risks due to contractual lock-in if the project is abandoned, risk due to partnering instead of maintaining control and potential impact on security (negative or positive).

Set standards for uptime and security and make sure the ASP will meet those standards. ASPs have a track record, so be diligent and check them out. Make sure that the ASP can handle your business and is not stretched thin. For mission-critical applications, especially those that will experience heavy usage at the same time across many enterprises—such as financial apps at tax time and e-commerce apps at holiday time—you might want to seek out a company that dedicates infrastructure to you and you alone. This, of course, will cost more.

Make sure there's an exit strategy. The "prenuptial" agreement is important when your company has become critically entangled with another. Make sure, if your data is to be stored in their data centers, that you know who owns the data.

Perhaps most importantly, make sure your ASP will survive or be acquired by someone who will survive. Pay attention to the ASP's business model. For example, many analysts predict that consumers will strongly prefer ASPs that charge per-month over those that charge per-transaction. This might spell trouble for per-transaction ASPs down the line. GartnerGroup's Apfel predicts that the ASPs that succeed will either be specialists in one type of solution, such as customer relations management or enterprise resource planning, or they will be aggregators. The safest bet, though not necessarily the smartest choice, is to buy from a big brand name. Microsoft and Oracle, for example, are both getting into the ASP game as software providers; names like Intel are going the AISP route. Even if one of these companies fails to succeed in the ASP game, they're certainly going to sell off their ASP clients to another reliable ASP, or face dirt on their good name.