English writing & News

Many of the early regional, national, and community Grid initiatives were built around the open Globus Toolkit. These were mainly the result of the growing world-wide community of Globus developers and users, the funding from U.S. government and industry to further develop the technology, and the leadership and evangelization of the Globus team. After four major releases today, Globus technology seems to be mature enough to be deployed by the "early majority" in research organizations and enterprises.

The following is the result of a recent study that evaluated and compared six major Grid projects around the world, to help the community to better understand, build, manage and operate grids, based on the experience of the early adopters.

During the last 12 months, we have analyzed the UK e-Science Program, the U.S. TeraGrid, Naregi in Japan, ChinaGrid, the European EGEE and the German D-Grid initiative. Our research, so far, is based on information from project Web sites, slide presentations, and from interviews with major representatives from these Grid initiatives. As an example, one of the earliest projects, with the highest funding volume and therefore one of the most important ones, is the UK e-Science Initiative. Major e-Science projects have been studied and key representatives interviewed from six e-Science Centers in the UK. The major focus of our research and of the interviews was on applications and strategic direction, government and industry funding, national and international cooperation, and strengths and weaknesses of the Grid projects.

As a result, we have compiled the following list of lessons learned and recommendations which may help others to successfully plan, implement, operate and fund similar Grid projects in the near future:

• Focus on understanding your user community and their needs. Invest in a strong communications and participations channel for leaders of that group to engage.

• Learn and keep up with what your peers have done/are doing. There is much useful experience to learn from partners.

• Instrument your services so that you collect good data about who is using which services and how. Analyze this data and learn from watching what's really going on, in addition to what users report.

• Plan for an incremental approach and lots of time talking out issues and plans. Social effects dominate in non-trivial grids.

• In any Grid project, during development as well a during operation, the core Grid infrastructure should be modified/improved only in large time cycles because all the Grid applications strongly depend on this infrastructure.

• Continuity, especially for the infrastructure part of Grid projects, is extremely important. Therefore, additional funding should be available also after the official duration of the project, to guarantee service and support and continuous improvement and adjustment to new developments.

• Close collaboration between the Grid infrastructure developers and the application developers and users is mandatory for the applications to seamlessly utilize the core Grid services of the infrastructure and to avoid application silos.

• New application grids (community grids) should utilize the components of the 'generic' Grid infrastructure to avoid re-inventing wheels and building silos.

• The infrastructure building block should be user-friendly to enable new (application) communities an easy adoption path. In addition, the infrastructure group should offer service and support for installation and operation.

• Centers of Excellence should specialize on specific services, e.g., integration of new communities, Grid operation, training, utility service, etc.

• We recommend implementing utility computing only in small steps, starting by making moderate enhancements to existing service models, and then testing utility models first as pilots. Very often, today's existing government funding models are counter-productive when establishing new and efficient forms of utility services.

• After a generic Grid infrastructure has been build, other projects should focus on an application or a specific service, to avoid complexity and re-inventing wheels.

• Reuse of software components from open-source and standards initiatives is highly recommended, especially in the infrastructure and application middleware layer. This leverages the power of the whole community.

• For interoperability reasons, focusing on software engineering methods is important, especially for the implementation of protocols and the development of standard interfaces.

• In case of more complex projects, e.g. consisting of an integration and several application or community projects, a strong management board should steer coordination and collaboration among the projects and the working groups. The management board (Steering Committee) should consist of leaders of the different projects.

• Participation of industry in this early phase has to be industry-driven. A blunt push from the outside, even with government funding, doesn't seem to be promising. Success will come only from natural needs e.g., through existing collaborations with research and industry, as a first step.