User Community Services
From EGI Knowledge Base
Here we describe the set of services for Research Teams (RTs) which fall under the headings of Application Support, Training, and Technical Dissemination. We also provide a scheme for determining when a service is most appropriately fulfilled directly at the NGI level vs. when a federation of resources in the form of a Specialised Support Centre (SSC) is more convenient.
We also discuss how the SSC format can strengthen collaborations between European projects.
The key to the success of EGI lies in the stabilisation of services that are currently built in large part on a competitive project basis. While some projects may have a natural finite lifecycle, many are initiated to provide a permanent service to a community (e.g. medical imaging, meteorology, digital repositories, etc.). While the effort to optimise and then maintain these services is expected to stabilise in the long term at levels well below the initial project effort, the lack of continuity among successive incarnations of a project (or successive projects aimed at supporting a certain set of results) often entails a heavy loss in terms of resources and intellectual capital, as repositories risk shutting down, specialised manpower migrates elsewhere, VOs disappear, etc. Recovering from this fractured scenario requires extra effort in training new personnel, reactivating services or building new ones, etc.
(figure m: a project-based landscape)
From an EGI perspective, it is immediately apparent that the landscape depicted above lacks durability: once a given project is finished there is no apparent way to reinvest its results. In the complex EGI scenario, and in an ecosystem which involves a few dozen nation-states and international VOs, it makes more sense to encourage collaborative efforts among projects throughout Europe. An SSC should provide the effort necessary to stabilise the relevant set of services for their scientific communities, in a process like that depicted below:
(figure n: Evolution and stabilisation of SSC services) N.B.: The height of horisontal bars represents community coverage, not manpower.
As the infrastructure becomes more generalised, the number of SSCs may be expected to increase. These centres, however, should make their best effort to be inclusive and offer reliable common services to new projects, rather than expecting that each project will create its own SSC; in this latter case, there is a risk of missing out on the benefits that a collaborative environment can offer, failing to learn from earlier experience, complicating the evolutionary process of the services offered by the infrastructure, multiplying project management effort, and so on.
A specific case is currently being studied which involves the Life Sciences community. The initial hypothesis for this case is to establish a specific SSC to (a) support the transition from EGEE III to EGI for the EGEE Life Sciences cluster plus several collaborating projects, and (b) initiate a collaborative effort with one (or two) ESFRI projects to plan the EGI integration with these infrastructures. This is of course a very early hypothesis, which will require extensive further study and adjustment as all parties involved refine their thinking on these issues; for this case study, one could very well imagine that some Research Infrastructures will have their own SSC if they extensively use EGI as their computing infrastructure. The Life Sciences SSC could host the Research Infrastructure services for some time and then help it to run a separate dedicated SSC. See Proposal for a Life Sciences SSC.
