Grid on the job

Automation know-how Outsourcing meets automation Organize to automate Grid on the job Danger in the new data center

When network executives think of grid computing, they often envision the supercomputer-strength computational resources needed for academic or government research projects. That's certainly how IT leaders at human-resources outsourcing and consulting firm Hewitt Associates once saw grid.

About 18 months ago, while working on on-demand computing and other advanced technology initiatives, Dan Kaberon, Hewitt's director of computer resource management, told IBM that no business applications existed for grid. But then he got to thinking about one particularly nasty IT-related business problem the Lincolnshire, Ill., company was coping with, and changed his mind. So after being a vocal naysayer of using a grid for business applications, "it was then up to me to find one," he says, with a laugh.

Working in partnership with Tim Hilgenberg, Hewitt's chief technology strategist for application development, Kaberon created a Linux blade server grid, ported portions of a troublesome mainframe application to it and reduced transaction costs by 90%. In the process, Hewitt demonstrated that grids can solve pressing business needs.

At issue was a mainframe-hosted application that performed complex pension calculations for 5.5 million of Hewitt's customers, many of whom work for multinational corporations that have grown through acquisitions. The pension application, written in Smalltalk running under Customer Information Control System (CICS) and DB2, uses input data such as length of employment, vested percentages, pension payout requirements (which grow complicated after acquisitions and reorganizations), performance of investments and other statistics. It then crunches those numbers to produce estimated monthly pension payments. Users also can perform what-if analysis to model various retirement options.

The application was very popular, but use would fluctuate wildly. Whenever rumors of workforce actions such as mergers, acquisitions or early retirement programs circulated, thousands of employees would go online at the same time to perform pension calculations, Hilgenberg says.

Obviously, Hewitt had no way of knowing when such murmurings would happen. "The application consumed over 1,800 mainframe MIPS and volume could double without warning," Kaberon says. Those big swings of volume "would consume huge amounts of computer power, and, at that time, all of that on a mainframe ... a very expensive place to run something as mathematically intensive as pension calculations," he says.

The application made an ideal grid candidate for another reason, too. Beyond a quick database query to collect the data needed to perform its calculation, the application required little interaction with other IT systems and data. "You could take your knife and cut out the application from the rest of everything without causing much complexity," Kaberon says.

Building a grid

With a grid, Kaberon and Hilgenberg hoped to offload the pension calculator's number-crunching from the mainframe onto Intel hardware - cheaper to buy, easier to maintain, fix, replace and manage, and requiring less-expensive software. So they asked IBM to help build a grid proof of concept for the pension calculation application. That first design "demonstrated we could build a successful production environment out of it," Kaberon says.

The two IT executives then gathered about 20 people from their respective staffs, plus engineers from IBM and grid middleware vendor DataSynapse, and formed a grid project team. Within three months, the team had built the pension calculation engine grid, which has been running successfully in production since September 2003.

The grid, which essentially acts as extra CPU power for the mainframe, was initially built with 10 IBM Linux eServer blade servers divided into two mirrored configurations placed at each of Hewitt's two Lincolnshire data centers, with a variable number of servers in use at any given time. The Linux blade servers run DataSynapse GridServer middleware, and Java-based middleware connects the grid to the calculation application on the IBM mainframe.

Here's how it works. A user fires up a browser and logs onto the Hewitt-hosted "Your Benefits Resources" site. On the pension information page, the user clicks on a link to calculate a monthly pension payment. That link initiates a call to a Web application running on a Sun Solaris server, which makes a call to the mainframe where the plan administration applications run. The mainframe-based pension calculation application collects necessary information from databases and, via a Web services connection, turns that information over to the GridServer middleware for dispatching of the number-crunching to the CPUs in the grid. The grid behaves like a giant CPU, calculating the numbers and returning the result to the mainframe. That result winds its way back through the Web services connections to the user's browser. If a user wants to play with the numbers - retirement next year instead of next month - the process starts afresh.

When factoring in the Intel-based hardware, Linux, the grid middleware and ongoing support, the cost of performing a pension calculation on the grid is 10% of what it had been on the mainframe, Kaberon says.

From one app to another

With such impressive savings and a better understanding of what constitutes a grid-worthy application, Kaberon and Hilgenberg soon found another IT problem where their months-old grid could come to the rescue. In this case, the problem involved an application that performed a printing composition job. Whereas the pension calculator shuttles a high volume of small but compute-intensive requests over to the grid to execute, the print composition application will break one extremely large computational workload into small parts, then use the parallelism the grid affords to complete the work faster, Hilgenberg says. This second grid application is now in early production.