The first round of application service providers (ASPs) was a mitigated disaster.

Most ASPs originated in some form of a dot-com in the days when that added value to a companys name. The first ASPs were very proficient at doing what many other dot-coms were doing at the time, and that was raising capital and spending money.

There was often little regard for rational business plans and little indication of when revenue would be coming in the door. I must admit that I was involved in this first round of ASPs, so I speak from personal experience. Even given the meltdown of the dot-coms I still am very bullish on the future of the ASP technology delivery model.

In a prior National Underwriter article, the question raised was “To ASP, or not to ASP” (see NU, July 30, 2001). This was a good introduction to what I believe is the fundamental issue most businesses need to deal with today in this post dot-com environmentto remain competitive, or to not be competitive.

Whether a business is large, medium, or small theres a common thread to being and remaining competitivedo it faster, better, and cheaper (FBC). So perhaps the question of the day is “How can we best obtain what is needed to be FBC?” and thus be competitive in the marketplace.

Technology provides the capabilities necessary for most businesses to vastly improve their processes, workflows, etc., and to become FBC. However, most small- and medium-sized businesses often do not have the internal competencies and experience, or the funds to invest in the hardware, software, telecommunications and staff, required to obtain and utilize this technology.

The Internet and the original dot-coms facilitated the ASP delivery model. Via the ASP model, a customer has access to sophisticated software and transactions processing using only a browser on a personal computer. ASP customers dont have to be concerned about loading and maintaining software, nor do they need to own a “server farm” for storing their data.

The bottom line with the ASP model is that a business doesnt need to have all the technical competencies internally to have access to sophisticated business software and related systems. Thus, the technology can be easily obtained to become FBC and remain competitive.

We are now experiencing Round Two of the ASPs. These ASPs are real businesses with real business plans. Some have survived from the dot-com era, others have remained in business through mergers and acquisitions, and some new ASPs will be appearing shortly.

The experiences and horror stories from Round One are still around, and this has both negative and positive connotations. Those who believe all the “negatives” wont know there is a Round Two and wont take the time and effort to evaluate, or seriously consider, an ASP solution, even though it might be appropriate for their organization.

On the positive side, we can apply what we learned from Round One in our selection process by performing the appropriate due diligence.

As a start, here are some guidelines for evaluating ASPs and the solutions being provided:

Are the ASPs management and key staff experts in your application(s) or business needs? If not, the results will be unpredictable and you may need to find a different solution.

What is the ASPs funding position? If it is still a dot-com with venture backing, it is suspect to some degree, versus an ASP that is owned or operates as part of a major “brick and mortar” business.

Is the ASPs offering a true Internet application, a system that was designed for the Internet and developed with appropriate Internet tools? An older client-server system with an Internet front-end may look good in demonstrations, but it may not have the performance characteristics provided by true Internet applications. The functionality provided will also be lacking if the ASP is not using new technology capabilities.

Is the ASP an “industrial strength” operation? Where are the servers (hopefully not in a garage)? What telecommunication, networking, and routing facilities are being used? What is in place for disaster recovery, and are privacy and security issues adequately addressed?

Does the ASPs service level agreement meet your needs? Of course it would be nice to have up-time guaranteed to be 99.99%, but it is unlikely youd want to pay for that guarantee level. Be sure your requirements are reasonable, just as they would be if you had everything operating internally.

Does the ASP have appropriate customer support? Will there be someone available to respond to your issues when they arise (especially when the ASPs hosted environment is in a different time zone)?

Does the ASP have a pricing structure permitting you to pay for only what you use? When you license software for internal use, you pay for all of it, whether or not you use it. With the ASP model, you should be able to obtain a “pay for use” fee schedule, based on functional modules used and transactions processed.

Can you obtain your data at any time? This is a very critical, if not the most important item to insist upon. You should be able to extract or download all your data at any time you desire. Even if the ASP is maintaining backup files, you should maintain your own backups for a variety of reasons, including using the data in other applications or knowing you have it so you can change services and systems if necessary.

There are risks in most business relationships so hopefully the above list will help in reducing the risks involved when considering an ASP solution. Just as if the system was being operated internally, there should always be backup and contingent approaches to take if there is a disaster or major problem with the ASP.

Those who did not have contingent plans in Round One are the ones who have the real horror stories when their ASPs went out of business in the crash of the dot-coms.

Remember, the issue is not whether you should be using an ASP, but how to be competitive by being faster, better, and cheaper. The ASP model is one method to consider for achieving technology solutions that will enable you to achieve an FBC status far quicker than you could on your own with internally operated back-office solutions.

Sidney H. Simon is director of Product Management for

BenefitAmerica, a UnumProvident Company, based in Mountain View, Calif.


Reproduced from National Underwriter Life & Health/Financial Services Edition, November 12, 2001. Copyright 2001 by The National Underwriter Company in the serial publication. All rights reserved.Copyright in this article as an independent work may be held by the author.


Copyright 2001 by The National Underwriter Company. All rights reserved. Contact Webmaster