Are ASP Applications Right for You? Part 2: Decision Criteria

  • Written By:
  • Published:

Are ASP Applications Right for You?


Executive Summary   

An Application Service Provider (ASP) provides an outsourced application to a firm, freeing the firm from hardware costs, training on the system operation, installation and system operation itself. Originally, ASP applications focused on a fairly narrow functional scope, however, as the market matures, the functionality the applications address is growing. It is now possible to contract for virtually any service or group of services required by a company.

The ASP frees the client organization from many, if not all of the tasks associated with the software such as hardware procurement and upgrades, software configuration, bug fixes and enhancements. Clearly, as we move forward, ASP applications will take on a larger part of the load of suitable applications.

Virtually any application where functionality is consistent across multiple organizations is suitable for an ASP to provide, however, whether that application is suitable to be implemented by an organization is based on the requirements and operations of that organization. It's important to know not only what the application does, but who the target market is and how current customers utilize the system.

About this note:
This is a two-part note. Part One discusses the decision factors in determining if an ASP application should be considered. This part details the criteria for making this decision.

Decision Criteria   

Whether an application is best implemented as an ASP provided application or service, built in-house or purchased generally depends on the same criteria as what would be used for outsourcing a function or process, among them:

  • How critical is a system is to day to day business operations?

  • What are the failure recovery requirements for the system?

  • How critical are performance requirements for the application?

  • How specific its functionality is relative to the requirements of other organizations desiring the service?

  • What are the cost savings over the development period of an internal system vs. the perceived life of the system?

Each of these areas needs careful consideration and are generally addressed to some extent in the contract and/or terms of service of the ASP.

Critical Systems   

Systems critical to the business operation are considered to be poor candidates for ASP applications, primarily because of concerns over the loss of control over critical data. While internal security may have less staff than a particular ASP, the priorities and focus of the staff is controllable.

While ASPs generally provide security as good as any company on the Internet, by using their software, hardware and operations facilities a company is relying on the ASP's ability to monitor and repair bugs in an expeditious manner. These bugs may be resident in the ASP's software or in the applications purchased from third parties. In the period of time between implementation and the time the bug is identified and a patch released and applied data is at risk. It is advantageous to keep all of these time periods to a minimum.

The initial time period (between implementation and discovery of the bug) is proportional to the number of users on the system and the complexity of reproducing the bug. The second time period, between the first verifiable instance of the bug and the production of a patch or software patch is related to the resources of the software vendor in which the bug occurred and the priority of the software vendor in investigating the bug. In general, the large, well known software vendors release patches fairly quickly, while open sourced software takes longer. Finally, the third time period, from release of the patch to the installation depends on the resources of the ASP, who must request the patch and test its installation and the operation of their system under the new software.

In most cases the ASP's monitoring and implementation resources will equal or exceed those at the implementing firm simply because it is their core business. Even when this is the case, there are situations where a specific bug may affect a minority of the ASPs users or, where regardless of the ASPs capabilities it is wise to not risk liability for loss or disclosure of data not under the firm's direct control.

Failure Recovery Requirements   

If an application has very strict requirements for recovery in the event of a failure, the nature of ASP applications may make them more complicated to recover. Simple recoveries such as hardware failure generally can be recovered easily by an outside service. Complex recoveries, such as may be caused by a latent bug related to data that brings down the system are generally more complicated. In this case, familiarity with the application is less important than familiarity with the data, something that is difficult or impossible for an ASP to achieve at the same level as the company using the system.

Performance Criteria

The shared nature of the services means that performance may be an issue. To operate cost effectively, many ASPs operate multiple companies across the same load balanced servers. In this case, operations and transaction loads at one company may affect the performance of the system for another.

Specific Functionality

If the functionality desired from the ASP application is essentially the same as other companies' use of the application, then each firm already on the system has acted as a "test group" for use of the system. This would make the confidence level higher for successful cutover and operation. If, however, the functionality differs even slightly, then the fact that other firms are on the system should be discounted appropriately and a test period prior to launch utilized to verify system performance.

Cost Savings   

Initially, the cost to get an ASP application implemented is less than the cost of development plus the cost of operation, and it comes to market faster. If a system is such that heavy ongoing maintenance is under consideration (e.g., shipping costs and telephone rate calculation services), the cost benefit may stay positive for some time.

Eventually, however, the cost of utilizing the ASP will exceed the cost of development. How your firm handles this event is an important consideration for whether or not the service is initially implemented as the solution to a business issue or as an initial implementation to cover the period during which an internal application is developed.

Is an ASP Forever?   

If this question is posed to an ASP provider, the answer is a resounding yes. They are organized to be able to meet the common requirements of their user base, and at first glance, the system does everything you want it to and more.

In reality, ASP's should be considered IT software tools, similar to word processors or browsers. In this respect, they can be utilized as a software platform or interim solution while internal development is in process to develop an in house solution. Care should be taken to ensure that the Terms of Service and/or contract do not prohibit this activity and that common functionality is not deemed confidential and proprietary.

Organization Responsibilities   

From an IT standpoint, ASPs are convenient and replace some, but not all of the systems development work. User requirements still need to be collected and an initial development schedule prepared in order to assess the cost savings of selecting an ASP.

The ASP provider will take care of the hardware and software implementation, but the software still needs to be integrated into existing systems, a cutover plan developed, internal users trained on the application, an integration test plan created and executed, and depending on the application, custom documentation created.

ASP Selection   

Once a decision has been made concerning the suitability of an application for ASP, the following questions should be considered in selecting an ASP application:

  1. What hardware is utilized?

  2. What is the upgrade path and implementation timeframe for hardware upgrades required for performance?

  3. How many firms share the hardware platform?

  4. What third party software is used?

  5. What software version is each of the third party applications?

  6. What is the process for monitoring for software bugs for third party software? What is the procedure for alerting clients of bugs that may affect the service?

  7. What is the process for monitoring for software bugs for internally developed software? What is the procedure for alerting clients of bugs that may affect the service?

  8. Is there an online bug tracking mechanism for clients to review and to prioritize fixes to internal software?

  9. What companies are currently using the system?

  10. To what transaction load is the application "rated"? Have these results been audited by a third party? Are transaction loads for your company's peak hours available? What percent of capacity must be reached before a hardware upgrade is automatically triggered?

  11. What is the current software version of the application software?

  12. What is the release schedule for future releases?

  13. When an upgrade ready for installation, is it made available to internal IT members for some period of time for testing prior to installation on the production system?

  14. What is the total uptime for 24 hours and for the hours comprising your company's peak usage period?

  15. What are the policies for scheduled downtime?

  16. Is there a "staging" system with essentially the same configuration as the production system? Do internal procedures require third party software patches to first be installed and tested on the staging system prior to installation on the production system?

  17. Are detailed cutover plans prepared with pre-identified failsafe points for all software upgrades/installations?

  18. What are the procedures for requested enhancements? How are these prioritized?

  19. What are the contract provisions? Are any restrictions placed on in house development that would prevent an internal development replacement program in the future?

About the Author   

Miles Szczurek ( has more than 20 years experience in the Information Technology, Trading, Clearing and Risk Management areas for futures exchanges, derivatives clearing organizations, cash forward markets and B2B exchanges. He played a significant role in a number of firsts; the implementation of the Chicago Mercantile Exchange's SPAN risk management software which has become the industry standard, the implementation of the world's first international electronic trading system and implementation of the first exchange in the deregulated power industry in the US.

Miles is a founding partner of the Appenture Group (, located in Chicago, Illinois. The Appenture Group is a full service Internet Technologies development organization providing software components, project management services and software development services nationwide.

comments powered by Disqus