While Dan Kaberon, director of computer resource management at Hewitt Associates, laughs when asked how many companies could benefit from a grid -- remembering how he had once insisted the business grid to be an oxymoron -- he now knows how to spot the indicators.

First, and most obviously, the application must be computationally intensive, he says.

Second, if a grid is to be a complement to a mainframe and not a substitute for one, the application in question must need relatively little I/O -- it cannot require frequent calls to a database, for example. Hewitt uses its grid like a giant, extra mainframe CPU and therefore leaves any busy I/O functions a grid application might require on the mainframe, porting only the calculation functions to the grid.

That doesn't mean an application can't have any storage requirement. For a grid-based print composition engine currently in development, Hewitt built network-attached storage using Network Appliance's Network File System (NFS). It needed a way for the grid, mainframe and any other systems to be able to access and write files centrally. However, no database is involved and the number of writes to the NFS are limited, says Tim Hilgenberg, Hewitt's chief technology strategist for application development.

Infrastructure also plays a big role in determining whether a grid is an apt choice for solving a business's computational problems. Before Hewitt's first grid application, the company already had much of the advanced infrastructure in place to support a grid split across its two data centres.

While a calculation engine, for which the grid was originally built a year ago, was Hewitt's first major production Linux application, IT had been experimenting with the operating system for some time and had plenty of Unix expertise. (The grid could have been built on Windows, too, Kaberon notes, but Linux performed well and cost less.) Hewitt also had advanced expertise in Web services, which it has been using extensively for more than three years to build portals for pensions data and other investment information. Good basic networking skills, such as understanding TCP/IP, also are critical, Kaberon says.

Culture counts
Beyond the technology needs are cultural ones. Hilgenberg underscores that a co-operative, creative atmosphere led Hewitt to success. The company has long since abandoned the kind of technology "silo" culture that so many other organisations still operate under today, Kaberon says. Their developmental team consisted of infrastructure and application folks working side by side, with their team leaders who were already experienced project partners.

Vendor help also is needed, Hilgenberg says. In-house folks, no matter how positive their attitude, will lack the experience, he says. By leaning on vendors to build a proof of concept first, a network executive will start with a workable design. Vendor partners therefore must be included from the inception, which gives them "some skin in the game" and makes them more willing to go out of their way throughout the entire process to make sure that you are successful, he says.

In Hewitt's case, they had the added bonus that IBM and DataSynapse were eager to create model grid projects that demonstrated the technology's use beyond university, government or life-sciences projects.