GCJ: Tell us a little bit about IT buyers' thought process, and the challenges that Grid will face in trying to make it on their priority lists.

Enterprise IT buyers generally follow six golden rules:

1- If it's not broken, don't fix it.

2- Don't touch it, you'll break it.

3- If you touched it and broke it, it will cost more than you think and take longer than you think to fix it. And if there's any component of the application supported on a mainframe, it is quite likely that someone will have to be brought out of retirement to fix it.

4- Good enough is good enough. If you strive to implement each and every function that someone has dreamed up, the business will have changed enough to make many of them irrelevant and unneeded. This means, of course, that the people who worked on it will be viewed as having wasted both time and scarce resources.

5- Don't touch anything unless people are screaming. If they aren't screaming, see #4. If they are screaming, see #2 and #3 in order before doing anything.

6 - Five to ten years from now the organization will look back at everything that IT has accomplished and will believe that not enough was done.

The biggest uber trend right now in IT is that organizations are looking to cut costs at any cost. And this isn't just hardware and software costs. This also includes staff-related costs, application administration costs-all the costs related to an IT solution. The organizations are not short-sighted enough to think they can save money by taking one solution out and plug in another that does exactly the same thing ... because there are significant costs with re-training, conversion and implementation. And the net result might be that moving to the "lower cost solution" may actually be more costly when one views it for the first 4-5 years of operation. So if it's not broken, they don't fix it.

GCJ: What does this mean for Grid?

A lot of what the Grid community is talking about adds up to one or more violations of those golden rules regardless of how significant the improvements to one component of the application system might be. Many of the IT people I've spoken with say "if they [the Grid community] find a way to take what I'm doing and host it on this kind of distributed computing architecture without me having to do anything to change it except roll in some new hardware, copy files over and start, that's one thing. But until they do that, I'm not going to be interested in re-hosting old applications. I might be interested to use technology to host new applications, but the old applications are going to stay where they are."

So if we look at where we've seen the most interest in distributed computing solutions using virtual environment software - where Grid would fall - quite often enterprises are looking for places where either through a requirement to comply with regulations or the value of the modeling is so great that it's worth any effort to get it, they will build an entirely new distributed computing solution. Entirely new applications are also areas that the Grid community might be well advised to consider.

GCJ: What are some early examples where enterprise users are deciding that Grid is an attractive route?

We see this in financial services, where they're conducting risk analysis, where they're doing designs of certain financial instruments, and trying to determine if they'll make money when several different economic and financial scenarios are considered. They run key stocks and bond values against the range of what's likely to happen in the future, and determine possible outcomes in terms of profitability. Monte Carlo scenarios are examples of this type of work that's being done with Grid in financial.

We also see similar tools used in the pharmaceutical industry, where they're looking at very preliminary results of tests, and trying to determine whether or not a particular pharmaceutical is worthy of more investment. The sooner they can cut a program that will not bear fruit, the more money they save, and the more money that can be invested in big money makers.

We also see it in transportation industries where they're trying to optimize the use of equipment or staff by running simulations and algorithms. An aircraft can only be flown so many flight hours before it must be taken to the maintenance facility. The ideal situation is to create routes for each and every aircraft so that the final trip within the final hours allowed by regulations takes it back to the maintenance base - so it doesn't have to fly empty and use the fuel and the pilots for something that does not produce revenue. A similar calculation optimizes use of pilots that have agreements with unions that say they can only fly so many hours straight in a given 24 hour period and in a given week - they want to make sure the last flight takes them home, and the same could be said for the cabin crew. So they want to crank through every reasonable scenario and reduce the costs as much as possible.

You can see an awful lot of these things have to do with significant cost savings that can only be realized by comparing thousands of different options and selecting the best from that group. If you can split the task into multiple independent searches or tests that can be run on inexpensive machines, you can do more tests in a given time, and thus be more effective in the deployment of your product or service.

GCJ: Why would enterprises evaluate open source approaches to Grid?

Using open source tools to construct a Grid is encouraging, because it means that the software acquisition costs may be lower. It doesn't necessarily mean, however, that the staff related costs of administration, development, implementation, support are lower - and often times, those are the biggest costs when taken as an aggregate. If we look at a typical cost of ownership study that IDC has done, hardware and software when combined are typically under 30 percent of the 5 year cost. Staff related costs range from 50-70% of the 5 year cost. And quite often, the more highly distributed a computing solution is, the higher the staff related costs are, unless steps have been taken to develop sophisticated provisioning and management software that presents a unified image even though it's distributed machines. Using open source software that's powerful, but may not have a pretty user interface and may not have courses available at technical training institutes - the net result may be that you save money on software but spend more money than you needed to on the staff-related costs.

GCJ: How familiar do you think key enterprise decision makers are with the Globus Toolkit?

My sense is that the technical decision makers have probably heard of it, but many may not have used it. The business decision makers probably think that Globus is a travel agency. It is unlikely that the business decion makers have ever heard of it. Education of the market is clearly a need going forward.

GCJ: Is the perception that the different Grid standards bodies are working together in a cohesive way?

The process is probably viewed as mystical by the technical decision makers, unless they are focused heavily on distributed computing architectures, and then it is possible that they are aware of different standards organizations and how they interact with one another. The business decision makers probably have no idea whatsoever about standards bodies and what they do. They're busy running their businesses. They know they want a computing solution that is built by one vendor or supplier to be interoperable with that supplied by another, because they know that allows them to play one vendor against the other, and that competition results in better prices and terms and conditions. But that doesn't mean they pay much attention to the standards themselves - much like automotive drivers don't focus much attention on the standards groups that design the oil that keeps an automatic transmission running properly. There are standards on how it should be made and the viscosity and the temperature sensitivity - but I doubt many drivers know or care about that, they just assume it's been done. There are times that the distributed processing community are looking primarily at increasing the horsepower without thinking about what's hitched to it. Many of the HPC people are excited by how many computations per second they're able to achieve in certain specialized applications, knowing full well that may not improve the performance of an enterprise resource planning piece of software-because those types of software products typically have a large number of interdependencies, and it's very difficult to segment them into separate units that can run on separate machines. Usually the type of segmentation that's possible is separating the user interface from the applications rules processing, and that might be segmentable away from the data management layer, which might be separated from the storage management layer. But it may be very difficult to take the database apart and have several DB engines each working on part of the requests.

close window