Whilst figures vary, it is generally accepted that the potential size of the application outsourcing market is massive. Whether or not this potential is realised is uncertain, but what we can tell is that there are many forceful drivers pushing forward this model, in both the business and technical sense. The ubiquity of the Internet, the declining cost of Bandwith browsers as an accepted graphic user interface and the shortage of skilled IT labour all highlight the need for application service provision.

But firstly we should try to define an ASP. An ASP manages and delivers application capabilities to multiple entities from data centres across a wide area network. ASPs give a viable alternative to procuring and implementing complex systems. ASP customers are also able to control the cost of technology ownership.

The easiest way to get to grips with the model is to consider service provision in the offline environment. In essence, if you pay a low price each time you use a service, you avoid having to buy the service outright.

Online, the model is delivering applications over the internet (at its simplest). The ASP model can be more complex and may include hosting of software and data, value added services, network services, perhaps even concepts such as server hotels.

There are a number of unique selling points claimed by ASPs. These include professionalism through speciality and super reliability. Also ASPs can allow clients to get to market quicker because they can speed implementation and deployment. They relieve the burden on internal IT staff, they allow clients to focus on their core competencies they give clients access to technology in an affordable way and provide a single point of contact for multiple business solutions.

In terms of the split between bespoke and off-the-shelf services a rule of thumb is the 80/20 ratio i.e. 80% of the offering is off-the-shelf and 20% tailored (of course there is no hard and fast rule). The degree of standardisation allows economies of scale to develop without compromising services say the ASPs. By comparison to the old outsourcing model which was a one-to-one model, the ASP model is one to many; one ASP providing similar services to many customers. The less tailoring the ASP has to make to the services the more re-usable they are and the more lucrative. Essentially we are looking at the next generation of outsourcing, looking harder at business processes to identify applications which would be better sourced externally: As Scott Adams in the Dilbert Future would have it:

"in the future all work will be outsourced until all the work on the planet is being done by one guy"*

ASP and Traditional Licenses Contrasted

  1. The traditional licence

    Why have a licence at all? Licences are granted to permit that which would otherwise infringe rights.

    In the typical licence there are a number of aspects which are heavily negotiated:

    Firstly the scope of the licence itself. The licence may be characterised by time, geography, manner of use, customer base or other mechanisms. The licence may be sole, exclusive or non-exclusive, all of which are functions of price. The exclusive licence (only giving the right of use to the licensee) will clearly be more expensive than a sole licence and more expensive in turn than a non-exclusive licence.

    Software warranties will often be heavily negotiated. A licensee user should seek the normal warranties of title (Section 12, Sale of Goods Act and Section 2 of the Supply of Goods and Services Act) capacity to enter into the licence, a warranty that third party rights are not infringed and a warranty as to functionality. It is questionable whether a user will be able to secure a warranty as to performance as well as functionality. In addition the warranties will be likely to overlap with support obligations, particularly if the warranties only last for a certain period, say 90 days.

    Acceptance of the product and liability for failure will also clearly be key. Acceptance is the point at which the right to reject is lost and usually coincides with a payment trigger. Often a licensor will attempt to deem acceptance as occurring upon live use.

  2. The ASP Licence

The ASP Licence is a new flavour of technology licence. Indeed, the term "licence" is perhaps a misnomer. Instead we are looking at the agreement (in whatever form) between the ASP and his client. It is essentially a services agreement; a contract for receipt of services. Therefore, from the client viewpoint, the client will not want to pay until he has received services, after all this is not a supply agreement. As such performance is key.

The licence in question under ASP agreements will, by definition, be non-exclusive.

When looking at the licensing scope in ASP agreements often there will be no room for the client to negotiate with the ASP the scope of the existing licences for applications. This is because the ASP will have "productized" the offering and will not be able to vary the upstream licences without going back to those upstream third parties: a step which the ASP will be rather reluctant to undertake.

Security is a key issue in ASP licences, security of data and the principles of the Data Protection Act 1998 will be very important. Equally confidentiality will be of huge importance and the client will want to clarify the conditions for access into the ASP system.

Reliability and warranties will be very important and will dovetail into level of service issue. A question to ask will be what constitutes acceptable down-time? All systems require a certain period to be maintained and monitored and down-time may be unproblematic for the client provided that he knows in advance that it will occur.

Often these ASP agreements will be based on standard clauses or be entirely standard terms. If they are standard terms then consumer protection legislation becomes an issue. In particular it may be important to establish whether or not the contract with your ASP is for goods or for services. Recent case law has held that small pieces of software would be treated like a good and the implied terms for goods would apply, large contracts (characterised by a large amount of bespoke work) would be treated as services contracts and consequently the services implied terms would apply. However recent judgments have said that it does not necessarily matter whether "software" is a "good" or a "service" because in both types of contracts the implied terms of merchantible or satisfactory quality and fitness for purpose should be implied. A user has a right to expect that the thing being sold will do essentially what he thought it would do. This can be a relatively high standard for an ASP to follow.

As a footnote to the ASP licence debate, it is worth noting the activity of the ASP industry consortium (ASPIC) and specifically their best practice committee who have produced an SLA checklist available on aspindustry.org.

Making the contract

Often the contract will be entered into online. As such the point at which the contract is made is critical in web design terms. In designing web sites, designers (and ASPs by extension) should employ the "gate" design. This design means that when you get to the point at which you need to make a contract then the individual browsing the site should be faced with a set of terms which he cannot go past until he clicks the "I agree" button. It is key for this to occur in order to incorporate the terms at the type of contract. "Click-wrap" licensing of this sort is merely an extension of shrink-wrap licensing and standard to the IT industry (although the validity of the latter was doubted relatively recently in a Scottish case, and as such, developments in caselaw should be watched).

3. The ASP Service Agreement - tips for getting it right

So do you need a service agreement at all? Well clearly contracts can be entered into by performance and activity but in order to avoid the uncertainty of an implied contract it is best to enter into an express contract to realign the implied term liabilities.

Before entering into the agreement you should ask yourself how much bespoke work is required, what sort of service is needed and how change will be dealt with. From the ASP view point, the ASP will hope there is not too much bespoke work required in order to make the economies of scale work.

With regard to service, question whether the contract for hosting or just software provision? If data is hosted, what about delivery-up at termination?

Remember the business of an ASP is not primarily about technology outsourcing or even IT expertise, it is about service. That service may change and the contract will need to be able to deal with change, such as how to deal with upgrades to software applications. In this regard, what can the client expect, what can the ASP commit to and can the ASP push the cost of upgrades on to the client? It is a question of the available degree of negotiation.

With regard to terminating the maintenance elements of the agreement the client will need to take care to avoid lock-in. He will look to be able to terminate by notice, although this may not sit well where maintenance fees are being paid up front (particularly as a type of fixed contract may be established where annual maintenance fees are paid). However, there should be no transfer in terms of employees, assets or properties under an ASP contract and so it should be easier to escape the contract. Even small customers should be able to terminate without penalty if performance is poor.

On the subject of performance, the SLA is the crux of the ASP agreement. The term "SLA" is used in many contexts. Those in the industry use it as the term to describe the document which sets out their offering; a non-legal document perhaps a proposal. Lawyers would use the term more sparingly and ensure that the detail of the SLA is subsumed within schedules to a formal agreement.

From a customer point of view the customer should ensure that the SLA is "contractual". The SLA or the ASP agreement itself will need to demonstrate service levels which can be measured. The agreement will require a good management information system which can create reports which are updated frequently. Clear escalation procedures will also be necessary to determine anomalies within those reports as well as a clear and acceptable definition of down-time.

Service levels, if not met, may engender service credits of some sort - a financial or other penalty to make up for the loss of service. It will be crucial to establish whether service credits should be the exclusive remedy for the loss suffered. From the ASP s point of view a clause stating that service credits are without prejudice to the customer s other rights and remedies will be taken as double counting and unacceptable. A compromise position may be to establish that service credits are the exclusive remedy for the period during which service credits apply. Of course service credits are a form of liquidated damage, a pre-estimate of loss, and as such will need to be genuinely forecast, rather than spuriously determined, in order to survive judicial scrutiny.

Finally if a customer is expecting service credits why should an ASP not expect service bonuses? Similar, if reverse, considerations will apply.

So to sum up, the ASP model is a change of focus, but the principles remain the same. The key issues will be determined by the extent of negotiation and the key document will be the SLA (in its true contractual meaning) as drafted to reflect the degree of customisation required.

First published in MIS Magazine in January 2001.

* Adams. S. "The Dilbert Future", 1997.