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.
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.
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.
is the nature of the business functionality you need to deliver?
it require significant customization to use an existing ASP offering?
- 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
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.
ASP deliver functionality that you need but can't deliver alone due to
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.
lack the capital to purchase and install the software required to deliver
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.
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 is no different from selecting any other type of service
provider. Your selection criteria should be aimed at answering the following
the ASP's offering meet your business requirements?
the ASP be around as long as you expect to need it?
- Can the
ASP deliver the functionality at your required service levels?
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
us to question number two. However, given the maturity of the industry
how do you evaluate the viability of the providers you consider?
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
- How strong
is its financials-income statement & balance sheet?
are its funding sources?
is its market?
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?
does it see as its competitive advantage?
portion of its infrastructure is internally provided and managed?
portion of its application portfolio is internally developed and managed?
its alliances/partners? How are they funded?
three addresses the key issue.
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.
components of the delivery infrastructure do you directly provide? Indirectly?
- For components
is their customer base and how do you compare with other customers?
is your SLA with that provider?
- For all
infrastructure components regardless of who is delivering them:
the procedures, methodologies, and tools addressing:
the current infrastructure capacity and any growth plans.
is the staffing by function within the ASP?
are its staffing growth plans?
What is the process for handling changes to service?
will own servicing your account?
staff will be working on your account?
is the problem notification process?
are issues escalated?
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
Service Level Agreement
As you construct
the SLA, you need to think about three major aspects: scope, mechanics,
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
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?
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.
Peter E. Hennigan
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.
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.
Hennigan can be reached at: