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:
- What
hardware is utilized?
- What
is the upgrade path and implementation timeframe for hardware upgrades
required for performance?
- How many
firms share the hardware platform?
- What
third party software is used?
- What
software version is each of the third party applications?
- 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?
- 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?
- Is there
an online bug tracking mechanism for clients to review and to prioritize
fixes to internal software?
- What
companies are currently using the system?
- 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?
- What
is the current software version of the application software?
- What
is the release schedule for future releases?
- 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?
- What
is the total uptime for 24 hours and for the hours comprising your company's
peak usage period?
- What
are the policies for scheduled downtime?
- 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?
- Are detailed
cutover plans prepared with pre-identified failsafe points for all software
upgrades/installations?
- What
are the procedures for requested enhancements? How are these prioritized?
- 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
(miles@appenture.com) 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 (www.appenture.com),
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.