ASPs - Lethal Sting or Valuable Resource?
Recent publicity concerning the numerous dot-com failures notwithstanding, computer industry pundits are pushing Application Service Providers ("ASP"s) for all their worth. In this model, a firm accesses leased software via the Internet, the ASP then takes care of upgrades, bug fixes, virus checking, maintenance, backup, etc. This seems very attractive and may even save firms some money.
However, it is very likely that in the next year or two there will be a shakeout among ASPs similar to the avalanche of dot-com failures. A recent article in Forbes magazine estimates that up to 90 persent of all ASP startups will fail. There is no guarantee that a firm will pick one of the "winning" 10 percent".
Issues relating to the ASP approach can be grouped into two major areas: infrastructure and functionality. Infrastructure issues include speed of access (bandwidth), security of access and security of the firm's data (since in the ASP model, the data resides on an ASP server not in-house). Functionality issues boil down to the question: will it work acceptably in terms of what users are accustomed to?
Speed of Access
Newer network connections typically run at 100 Mbps (older networks may still be at 10 Mbps). This is roughly 2000 times as fast as a 56Kb dialup line and 400 times faster than a 512K DSL connection. The fastest internet connection available, a T3 line, is likely to cost several thousand dollars or more per month for a fifth the speed of a network (prices vary sharply depending on specific local areas and phone companies). And this on a good day. When the provider's server goes down or the connection is clogged and slow, you will not be able to access your applications and data. Think of the reaction when the server in your office has a problem. Then consider your current access to the Internet: would you trust mission critical data to even an improved version of it?
Even T3 lines bog down under major access loads. A few years ago, a major law firm was using a T3 line to link their e-mail system from one building to another. The connection had to be abandoned after vociferous complaints from the attorneys about speed of access.
The security issue that has received the most attention is the security of your data from hackers or thieves. Will your data be on a dedicated server (perhaps not); how will you know who has access to your most confidential data (you won't); will the data physically be housed at your ASP's site or at the site of some server farm run by major ISP subcontractors or phone companies? Hacker attacks can also take the form of Denial Of Service attacks such as those that routinely bring giants such as AOL and Yahoo to their knees for hours and even days at a time. If hackers can crash the AOL servers, they can certainly do it to an ASP's server. What, if any, provisions will there be for accessing your data if the ASP goes down? In general, these issues have not been addressed in ways likely to satisfy law firms.
Then there is the question of accessing data in the event of a dispute with the provider. Suppose the ASP cuts off service over a dispute, the way Time Warner did briefly with ABC/Disney. Whether the dispute is resolved in your favor or not, you could still be without your data of a substantial period of time.
Finally, what about professional liability in the event client confidentiality is breached? Law firm e-mail messages are increasingly carrying the same sort of disclaimers traditionally associated with faxes. Will every single wordprocessing document have to carry a similar warning?
There is a second level of security concerning who has access to your data. The standard format of passwords is simply not very good security. In the future, look to "smart cards" and biometric security (such as fingerprint readers) to authorize entry to your data. In addition, java-based programs are likely to be somewhat more secure than Active-X/VBA based programs given the rampant security problems with the latter.
What level of functionality will be available? In a culture where users complain about having to make an extra mouse click or two, what will be the reaction when it takes two minutes to access information or save a change?
There are currently three approaches used by ASP providers: "build it from scratch", "web-enable" existing applications, and a hybrid approach.
ASPs taking the build-it-from scratch approach are most likely to fail, even on the largest scale. Recent failures include Red Gorilla, whose clients for its time tracking and expense modules included Adobe Systems, NBCi, and Office Max. Red Gorilla closed down in October 2000 and customers' data remained in limbo for two months or so. Another notable failure was HotOffice (a full-fledged office suite) which continued to be promoted as "best of breed" even after it closed up shop last December.
"Webifying" existing applications is the approach most likely to succeed for several reasons. First, users are familiar with the interface and functionality. Secondly, software makers can control what features are available, essentially allowing a client to decide where its comfort zone lies in the tradeoff between security of its data and full functionality. This approach is likely to be most successful for accounting, expense tracking and similar packages.
Lastly, programs based on an "internet data store" approach are likely to be successful in areas such as document management and litigation support. In this scenario, a firm places selected elements of its data store on the ASP's server where they can be accessed either by anyone with a browser or with a module of the software (depending on the application).
There is no doubt that the ASP model will meet with some success. But "doing it right" will require careful research and obtaining satisfactory answers to the questions outlined above.
About our author...
John Heckman is the Principal of Heckman Consulting, specializing in software integration for law firms. He publishes a newsletter, "Computer News for Law Firms" John can be reached at (860) 395-0881 or by e-mail at email@example.com.