Clutching the ASP... without the bite

Following on from his analysis last issue of outsourcing digital signatures, Brendan Scott looks at the complexities of outsourcing entire IT departments.

You may have heard of new initiatives to provide applications to customers over a platform physically removed from the customer's premises. These initiatives in one sense can be thought of as a form of outsourcing but in the common jargon the people providing these services are referred to as Application Service Providers or ASPs. The theory behind them is that an application is run on a central server which is accessed in real time to process data.

For example, one application that might be provided over such a service is word processing. Instead of installing large word processing applications upon each desktop within an organisation on the off chance that they will be used and, subsequently being required to commit support resources to ensure that those programs continue to work properly, a central word processing application is hosted upon a server with all end users accessing it through a common interface.

In previous years this might have been referred to as a "thin-client" arrangement. The key difference between application service providers and thin client applications is that in the former all of the functionality is provided by a third party, whereas in the latter all of the functionality is, generally, retained within the given organisation. The application service provider model throws up many of the issues faced by organisations who outsource a specific function as well as issues relating to records, storage and retrieval - so what are they?

If you don't have your records you have a greatly reduced ability to defend yourself in an action.

Imagine yourself in a position of someone wanting to make use of an application service provider's services. What you want to do is satisfy yourself that the ASP has the characteristics that meet your needs. Two key characteristics are those of speed and functionality. A good benchmark for each of these can be your existing applications, if the services that you are acquiring replicate them. For example, is the functionality of the service exactly equivalent to what would be available if the software were installed on your computer? Does the interface through which that functionality is accessed permit all of those functions to be available? Do things such as control and function keys continue to operate?

Application service providers give the opportunity to consolidate applications and data into one spot with the result being better, faster processors available to process the data. A little thought will show you that most computers in most organisations are vastly underutilised for the majority of the time - so much so that international researchers have requested the donation of computing time from individuals to process such things as astronomical and radio telescope data searching for signs of other planets or of intelligent life elsewhere in the universe! Of course, the goals of application service providers are to provide a service with more readily tangible results, but the principle remains true that for the same money an ASP can make use of economies of scale better than an organisation can. However, just because an ASP can spend its money more efficiently doesn't mean that it will. An ASP must purchase hardware to cope with peak usage times and must purchase hardware on a schedule which properly anticipates the lead times necessary for expansion of the operation in the future.

In addition to a load on processors, another key dependency is on the telecommunications infrastructure between the desktop and the place from which the services are provided. In effect, the weakest link in the chain will determine the speed with which the application can be accessed. This means not only that the ASP and the customer's internal networks must be sized and engineered to accommodate that arrangement but also that the third party supplies of network services are providing appropriate network services to meet the response time requirements. This will be more of an issue where the parties are relying upon a "public" network infrastructure as opposed to a leased line between their two premises.

PRUDENCE WITH RECORDS

The next thing that you would need to consider is your obligations to retain records and the prudence of retaining records. There are a number of reasons why a person must or ought to retain records of their business transactions. An important one is for taxation purposes but there are many others, such as workers' compensation and insurance requirements. Further, the fact that a corporation can be sued for quite some time after an event has occurred - anything up to six or twelve years depending upon the origin of the claim. This gives companies a strong incentive to keep adequate records of their business operations for an extended period of time. If you don't have your records you have a greatly reduced ability to defend yourself in an action. Where an ASP is performing the data storage function for the customer, the customer must ensure that storage function is properly aligned with the customer's own internal requirements, be they strictly required or merely advisable. It will be no good if the application service provider trashes all of their data after a period of 12 to 24 months. Equally, it will be of no use if the customer is unable to access its data on a regular basis either throughout the term of their arrangement or after termination. It is therefore very important that this is dealt with in the engagement arrangement.

An area related to this is that of privacy and security. The initiatives by the Federal Government on privacy in late 1999 give a company insufficient comfort to rely on them as their primary means of privacy protection. Therefore, in its arrangements with its ASP, a company must make specific provision for the protection of not only its data but also information about its usage of data and of its usage of the applications provided by the application service provider. If it does not want its competitors to know what software it is using to service its clients or how productive its use of that software is, it would be advisable to include specific provisions in its contract with the ASP to protect that information. Similarly, it may, depending on your level of paranoia, care to make allowances for the use of encryption between its internal network and that of the ASP.

You should also consider how the use of software will evolve within your organisation and whether the application service provider will be able to complement that internal development. For example, many companies today continue to use Windows 95 and Word 97 despite more recent updates of these programs being made available. There are a number of reasons for doing this, including compatibility, cost and training.

ASSET BECOMES EXPENSIVE

Moving from a traditional model to the ASP model will mean that fixed recurring costs for licensing in the nature of capital expenditure every two to five years will now take on more of a character as expenditure of a revenue nature through monthly or weekly payments to an ASP based on usage of an application. This may give internal incentives to change software usage practices which may, in turn, have a broader impact on the manner in which you do business. For example, if an ASP offers the latest version of software at the same price as a previous version there is an incentive to upgrade to that new software in order to receive new functionality at no additional cost. Under the old model, additional licensing fees would have been payable. However, this additional incentive should not be permitted to obscure the broader impacts that such an upgrade will have on the organisation, including such things as retraining users.

Like all other new models of doing business, the ASP model requires substantive consideration of its practical effects before the broad gambit of costs and benefits can be understood. The value of adequate advice at an early stage cannot be understated.

Brendan Scott (bscott@gtlaw.com.au) is a lawyer with the Sydney office of Gilbert & Tobin, technology lawyers.