Home
 > Research and Reports > TEC Blog > The ASP Decision

The ASP Decision

Written By: P. Hennigan
Published On: December 6 2000

Introduction

About every eighteen to twenty-four months the technology industry identifies the latest in a long line of silver bullets that will simplify the delivery of technology's benefits to the business world. The ASP model has recently enjoyed that distinction and the accompanying hype. Unfortunately, wading through the hype to determine if this particular silver bullet can bring value to your business is an arduous task. This article provides some simple guidelines for determining if you should consider the ASP model along with thoughts on selecting an ASP.

Why an ASP?

If you believe the marketing hype, the ASP model will solve all the software development, delivery and maintenance problems that businesses have consistently struggled with. While that can't be the case, the ASP model does present an attractive option given the right situation.

The existence of the right situation depends on how well you have defined your business functionality need, the IT resource constraints you face, and the cost issues you must address. A few questions can help determine when that situation exists.

What is the nature of the business functionality you need to deliver?

  1. Will it require significant customization to use an existing ASP offering?

  2. Does the functionality need to be integrated with existing systems?

If you answer yes to these two questions, then the ASP option may not offer the best option. Although it is evolving, the ASP model is based on the economics of delivering similar functionality to multiple customers with minimal integration. As soon as you start discussing significant customization and integration you step out of the ASP model into the systems integrator model.

This is not to say that any customization or integration needs should prevent you from examining ASP options. Most ASPs can handle some customization, and their offerings may routinely support basic integration with enterprise systems. However, significant customization or integration usually means you are faced with a full-blown systems development and integration project.

If you are considering the ASP route for mission critical functionality, proceed with caution. This may be unavoidable with start-ups, but established companies should experiment with the model on less critical functionality until the market shakes out.

Does an ASP deliver functionality that you need but can't deliver alone due to resource constraints?

An ASP can help you address many of the issues those resource constraints present. Whether the issue is time to market pressure or skill constraints, an ASP may offer a feasible solution. That solution carries forward for ongoing maintenance. The ASP model minimizes the resource you will need to devote to the ongoing maintenance of the functionality.

The ASP option doesn't eliminate your need to manage the delivery of the functionality. Managing the delivery of the ASP service is a critical function that you can't skimp on.

Do you lack the capital to purchase and install the software required to deliver the functionality?

The ASP model is a rental model. It has lower entry costs than a purchase or build-your-own option. If you need the functionality, but can't afford the capital to purchase it, the ASP option will provide you access.

This does not mean that the ASP model guarantees the lowest total cost of ownership. Much of the ASP hype focuses on the cost savings picture, but that picture does not clearly show whether the ASP option will generate less cost over the life of the application.

Selecting an ASP

Selecting an ASP is no different from selecting any other type of service provider. Your selection criteria should be aimed at answering the following three questions:

  1. Does the ASP's offering meet your business requirements?

  2. Will the ASP be around as long as you expect to need it?

  3. Can the ASP deliver the functionality at your required service levels?

The first question reflects the simplest and most important principle: clearly define your requirements before selecting a solution to meet them. If you don't, you can't adequately answer any of the questions. Also, when you are defining your requirements, think beyond your current needs. How might your business strategy impact your needs several years out? What's the minimum duration for which you need this relationship to last? If you can answer that question, then you only want to consider ASPs that will be around at least that long.

That brings us to question number two. However, given the maturity of the industry how do you evaluate the viability of the providers you consider?

Although the industry is immature, you still follow basic due diligence procedure. You deal with the immaturity factor by setting your risk tolerance requirements at a level that doesn't eliminate all the players. The due diligence questions aimed at answering question two should include the following:

  • How long has the vendor been in business?

  • How long has it been delivering the specific functionality that you are interested in?

  • How strong is its financials-income statement & balance sheet?

  • What are its funding sources?

  • What is its market?

  • What are its growth plans?

  • How many customers does it have and how big are they?

  • How many customers has it lost in the last year and why?

  • What does it see as its competitive advantage?

  • What portion of its infrastructure is internally provided and managed?

  • What portion of its application portfolio is internally developed and managed?

  • Describe its alliances/partners? How are they funded?

Question three addresses the key issue.

Can The ASP Deliver?

Can the ASP deliver the functionality at your required service levels? In order to answer that question you need to examine the operations of the ASP. Your examination should include the following major areas.

Infrastructure

  1. What components of the delivery infrastructure do you directly provide? Indirectly?

  2. For components provided indirectly:

    • Who provides them?

    • What is their customer base and how do you compare with other customers?

    • What is your SLA with that provider?

  3. For all infrastructure components regardless of who is delivering them:

    • Examine the procedures, methodologies, and tools addressing:

      • Systems Management
      • Change Management
      • Performance Measurement
      • Security
      • Disaster Recovery

    • Describe the current infrastructure capacity and any growth plans.

Administration

  1. Human resources

    • What is the staffing by function within the ASP?

    • What are its staffing growth plans?

  2. Change Management
    • What is the process for handling changes to service?

  3. Customer service model

    • Who will own servicing your account?

    • What staff will be working on your account?

    • What is the problem notification process?

    • How are issues escalated?

The examination of the ASP's operations will help determine if it can meet your service levels. The formal Service Level Agreement (SLA) will then establish the framework for managing the service levels and the relationship with the ASP.

The Service Level Agreement

As you construct the SLA, you need to think about three major aspects: scope, mechanics, and remedies.

  • Scope. Your SLA scope must be broad enough to address all the critical components of the ASP delivery model. A useful guideline is to include system, network, and application performance within the scope. This ensures coverage of the critical components, and provides a framework for end-to-end service levels regardless of whether the ASP directly provides all the delivery components.

  • Mechanics. The SLA mechanics are crucial to the effective management of the service levels and the relationship. You must define specific and measurable performance metrics. The SLA should include both the metric definitions and measurement process. Any debate regarding the metrics and their measurement should end before you sign the contract. The SLA should also detail the change process and issue escalation mechanics. Define now the process for making any changes to your service in the future. Likewise, define and document the process for handling issues. If the first level of operational managers can't satisfactorily resolve an issue, how quickly does it escalate and to whom?

  • Remedies. The final aspect of the SLA is the remedy. Unsatisfactory or untimely performance should trigger performance remedies. The purpose of discussing remedies is to first eliminate from consideration those ASPs that won't be able to deliver your required service levels and second to focus the selected ASP on meeting its guaranteed service levels.

The ASP model is not a silver bullet after all. It is another selection in the expanding menu of ways for businesses to access technology. The model brings with it the strengths and weaknesses inherent in any third party sourcing model. Organizations should look past the glitter, and seek to evaluate this model in a systematic fashion to minimize business risk.

About the Author

Peter E. Hennigan

Mr. Hennigan's experience includes more than twenty years in analytical, sales, financial and IT roles. As a Principal with Technology Contract Solutions (TCS) Mr. Hennigan focuses on helping clients minimize the risk and cost associated with their technology acquisitions. His recent experiences have included the financial analysis of a data center relocation for a major brokerage house, an analysis of the data center hardware and software contract portfolio for a large Midwest healthcare, the negotiation of a multi-year hardware break/fix contract for a large Northeast insurance company, and the development of an application development services agreement for a Northeast financial services company.

Previously, Mr. Hennigan spent over ten years in senior management positions in the Information Technology Department of the Liberty Mutual Group, a Fortune 100 financial services company. Mr. Hennigan holds a BS in Civil Engineering - Magna Cum Laude and an MBA from Syracuse University.

Mr. Hennigan can be reached at:
phennigan@technologycontracts.com

 
comments powered by Disqus

Recent Searches
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others

©2014 Technology Evaluation Centers Inc. All rights reserved.