Address risks of utility computing to take advantage of cost benefits

Feature

Address risks of utility computing to take advantage of cost benefits

Pay-as-you-go computing could suit some firms.

New business models within the IT sector have been relatively hard to find since the end of the dotcom boom a few years ago. However, in the past 12 months or so, a buzzword has emerged that has gained a huge amount of interest: utility computing.

Utility computing aims to make the provision of IT services as easy as obtaining electricity or water, where the flick of a switch or the turn of a tap can provide as much of that resource as is required. The customer simply pays by the hour, day or month, depending on the resources used.

Increasing numbers of companies have signed up to large outsourcing deals involving the provision of utility computing services, but the jury is still out as to whether suppliers will be able to provide services in a flexible, straightforward manner.

There are also legal considerations customers need to address before signing a utility computing deal.

Lack of clarity

It is important to be clear about what is being provided. "Grid computing", "organic IT" and "on-demand computing" are just a few of the terms used to describe the concept of utility computing, and suppliers such as Sun Microsystems, IBM and Hewlett-Packard all give a slightly different slant on how they will provide their services.

Although this lack of clarity is a sign of the immaturity of the market, it also suggests the need for customers to be specific in contractual terms about what they are procuring and to make sure they have sufficient detail about the service levels in the contract.

Supplier lock-in

Supplier lock-in could become a problem. Utility computing models suggest a long-term commitment to a supplier. The customer may be prevented from selecting another supplier with superior products or services, or from making changes without incurring liability for capital costs or for exiting the relationship.

Contract mis-management

Any customer of a utility computing supplier will need to manage its internal operations to be able to take full advantage of the opportunities.

Like any outsourcing deal, if the customer fails to manage the contract properly, the service may not achieve its stated business goals. This could lead to legal disputes about compliance with the contract.

Security problems

Security, as with any outsourcing deal, cannot be ignored. One of the key promises of utility computing is the fast, automated re-use of computing resources, but will suppliers be able to guarantee that data is "cleaned up" before disc space is allocated to someone else?

Although the supplier will need to be under obligation to ensure that each customer's data and applications are segregated from that of other customers, there may well be additional risks to those already faced by a business running data and applications on its own servers.

Customers will need to be quite clear about the security levels required and sufficient warranties and indemnities will need to be provided in the agreement.

Licensing issues

Most software suppliers operate on models whereby they sell licences for each product. The type of licence may vary but most often operate on either a per server, per CPU, or per user basis.

To function cost-effectively, utility computing requires that software licences be made available quickly and that licence fees are only charged while the software is in use.

This is different from the standard approach to licensing and will have implications that could affect the decision to opt for utility computing.

Peter Brudenall is a senior lawyer at law firm Simmons & Simmons

Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in February 2004

 

COMMENTS powered by Disqus  //  Commenting policy