Considering an Application Service Provider

In trying to enhance the functionality of a site, it may sometimes be desirable to engage the services of a vendor to provide an application that is hosted on an outside server. This can work well, but success is dependent upon proper consideration of certain key factors.

The Application Service Provider model has been around for some time, and can be attractive for a variety of reasons. The initial cost may be less than buying or developing an application. The implementation timeline may be shorter, since buying and deploying additional server hardware isn't needed. And for certain types of functionality, such as job applicant tracking, out hosting is simply the normal method of deployment.

The first major decision is to determine if a particular area of functionality is appropriate for an ASP model. Not every application should be out hosted, for a variety of reasons. Some indications that a particular function might be a good candidate for out hosting are:

• The function is in a highly specialized area, and can benefit greatly from domain expertise that doesn't exist in your staff.
• The application has potential for overwhelming your servers during peak periods.
• The functionality is fairly well detached from other business processes, so that only minimal synchronization is needed with internal databases and other applications.

On the other hand, out hosting may not make sense if:

• The functionality is central to your business. If it is an area in which your staff should have domain expertise, hire or grow the expertise rather than mortgage your fate.
• The out hosted function is tightly integrated with some of your other business processes, requiring frequent synchronization with internal databases.
• No vendor can be found which handles both the application and the out hosting well.

Once you have decided an out hosted application may be a possibility, it's time to choose the right vendor. Much of the decision process, of course, is the same as for choosing any application vendor: choose one that meets your functional needs at a reasonable price. 

There are, however, a few additional considerations for engaging a vendor in the role of an ASP. For instance, when engaging an ASP it is very important to plan the end game. You may eventually decide to shift your business to another vendor, or even bring the functionality in-house. Since the ASP vendor may have a big chunk of your information on their server, make sure the contract contains a clause covering the graceful transfer of all data at termination of the service. It's not a bad idea to include terms outlining the expected service levels (response time, time for delivery) with penalties. When a vendor knows they are losing your business, they have little real incentive to be responsive unless it is written into the contract.

It is also prudent to make sure that you can mirror, synchronize, or periodically back up any of your critical data that may reside on the vendor's servers. Recent history with high tech companies shows that even a company that seems financially stable can disappear overnight, taking your data with it. If you at least have a copy of the most critical information, recovery will at least be a little easier.

As always, make sure that the needs of your target audience are going to be met. This means that you must test the usability of the out-hosted application, and see how well it can be integrated with other parts of your web site. Make sure that the application can be configured to provide navigation that is similar to the rest of your site. 

In addition, make sure that the changes to accomplish this are really just configurations, not customization. Pay attention to the implementation timeline, especially the amount of time needed after details are approved before a working prototype is in place. Remember, you can expect a similar timeline for changes if you update your site (and the application) in the future. And, it's not a bad idea to check the contract to see if there are any charges associated with changes to the configuration of the application. Even with careful planning, some changes will be necessary immediately following the launch of the application to better meet the needs of your users.

Does all of this mean that out-hosted applications are something to be avoided? Not at all. It simply means that an additional layer of complexity has been added, and that this additional complexity deserves careful examination to avoid potential problems.

The original work contained throughout this
web site is licensed by Elton Billings under a
Creative Commons Attribution 2.5 License.