In the mainframe era, Granger says, companies were not averse to using computer bureaus, which were antecedents of utility computing providers, "but with the advent of PCs and networks and the rising costs of telecommunications, the economic argument moved in favour of do-it-yourself". Today though, he says, the falling cost of communications is swinging back in favour of using utility services. That may be enhanced by the effect of using a utility pricing model on cash flow, so that an organisation suffering a slump in business, for example, would see its utility computing bill fall in line with its processing needs.

The sorts of pros and cons deliberations that exercise Granger are part of the reason that PA's McAulay predicts migration to a utility model will prove more evolutionary than revolutionary, with companies perhaps sampling Web services first, while keeping mission-critical computing such as process control in-house. In fact he believes that few companies would use a utility computer service (unless it was in-house sourced) for much more than 80 per cent of their processing. The critical final 20 per cent he believes would likely remain on in-house, dedicated infrastructure.

Right now, "people are flirting with utility computing in the short term to save costs", McAulay says. And for that reason he advocates companies try the utility model themselves, piloting some of the tools now available to allow them to share existing computer power or storage across the enterprise and see if the model works for them. "In the first instance it will be about the cost savings or spending avoidance because you are better sharing what you already have," he says.

But a CIO will need a deep understanding of the requirements of different business units, the time pressures on those units, and the business life cycles of the individual business units when implementing an organisation-wide utility model, McAulay says. "One of the best examples is an oil company, which has normally very distinct operating units, with each business unit addressing one territory; therefore the business life cycles of each are different. You might have your North Sea unit in decline, with radically different data processing requirements to offshore Brazil, where you are opening a new field.

"Ordinarily, traditional batch processing server resources can cope with the load from several different business units because the peaks in demand were different for each." (Traditionally, the high-speed workstations on geologists' desks sat idle overnight.) "However, for a four-week period we knew that there was going to be a peak in demand that could not be met by the batch server, so we connected all the unused workstations into a utility computing grid to perform processing tasks for the heavily loaded business unit overnight."

According to McAulay, it was a relatively trivial exercise because the processing required was essentially a batch process and ideally suited for packaging into smaller batches each running on a grid node, and therefore readily suited to a utility approach.

What this example highlights, however, is the need for extremely close communications links to be forged between business units and IT, perhaps demanding the creation of the aforementioned workflow manager position - someone who can identify when demand will rise, how work can be split into batches for processing on a utility grid, and also allocate priorities to individual processing tasks. This same manager might also be responsible for charging the business units for their use of the grid. McKinsey refers to such individuals as "demand managers", who would then liaise with operations managers (either in-house or in a third-party utility service provider) who supply the computer power.