Specialised Support Centres

From EGI Knowledge Base

Specialised Support Centres (SSCs) will be created to provide continuity, cohesion and cost savings to the user communities currently served by European grid projects, and establish collaborations with specific ESFRI projects to set up the relevant services for these communities;

Continuity means supporting the central long-term services established by these projects – e.g. Application database, repositories, documentation, use cases, ongoing processes of evaluation of "external" general software tools, etc.

Cohesion is an ongoing necessity currently fulfilled in part by MoUs and other collaborative efforts; the SSC structure will solidify these efforts in a manner that will be formally acknowledged at the EGI level.

The result of the structuring of collaborative efforts by the European projects via SSC services will be an increased awareness of duplications of effort within the domain of an SSC, which will allow for the streamlining of existing services and either a redirection of effort into the creation of new services (if needed) or a net cost savings in terms of human and information resources.

It is clear that a one-size-fits-all model of an SSC cannot be constructed, as each community has its own specific requirements. It is already apparent that different kinds of service will apply to communities whose primary virtual workspace is grid-based as opposed to those who will be served by large research infrastructures (e.g. ESFRI), and for whom EGI is expected to provide a seamless integration with grid services.

In what follows, we provide general guidelines and qualitative estimates that can be of use for the relevant experts in planning a particular SSC. It is of course understood that these are to be adapted for each specific case.

Contents 1 SSCs: A First Approximation 2 SSC "Blueprint" 3 Evolution of SSCs 3.1 Science Gateways 3.2 SSCs and Large Scientific Infrastructures

[edit] SSCs: A First Approximation

The kind of effort which may be required to implement an SSC is described below. Note that some services are relevant specifically to grid-centred communities, while others are more general.

• A team to build and maintain a European-level scientific portal and provide varying levels of interfacing with national gateways that share the same purpose. This interfacing could be limited to a link to the national portals, or it could be more involved, depending on agreements with the individual NGIs.
• Front desk services for new communities.
• VO services: representation, creation counseling, support and development of specialised tools, site testing support, SAM test repository; general VO management and interaction (if required) with national VO managers.
• Application porting support; application porting case studies; "help desk" for application developers.
• Direct user services. Creation and maintenance of FAQs, use cases, how-tos, specific documentation and mini-tutorials; free demonstrations for new communities; identification of common problems affecting users, notification of relevant people (e.g. operations or middleware developers), and following the problem to resolution.
• Central “interdisciplinary” services:
  1. Technical coordination. Coordination of the interactions between users (usually application developers) and middleware developers. Coordination of the interaction between users and operations; typically related to the provisioning of core VO services or computing resources.
  2. Application database. Supplying an application database that allows applications to be "registered", permitting people to search for similar applications and contact the authors for guidance.
  3. Selection of software packages that can help application developers use the grid infrastructure, but are not (at a given time) part of the core Middleware distribution(s). Similar to / an extension of the EGEE RESPECT program. This service in particular will be crucial in driving/assisting the evolution of the UMD.

It is important to note that these services are in any case subject to evolution as the other EGI services (operations, middleware) also evolve. For instance, as services become more stable and user-friendly, it is natural that less effort will be required to support users dealing with help desk issues; as more communities are brought under the umbrella of SSC services, the effort employed in the creation and maintenance of common services (e.g. repositories and databases) will decrease, etc.

For more detail on possible SSC tasks, please see UCS Tasks.

[edit] SSC "Blueprint"

What does it mean in an EGI environment (i.e. based on NGIs + EGI.org) to have Specialised Support Centres?

We assume that SSCs will arise primarily as required by the international user communities and VOs, although the model can be extended if there is an interest. These centres will thus have a European-level commitment and will work in tight collaboration with EGI.org, via a central team as initially sketched in the EGI_DS Blueprint. The detailed tasks and descriptions of the activities coordinated by the EGI.org central team are given in the UCS Tasks section (and related links), along with the description of the tasks fulfilled by the extended support teams in the global EGI environment.

Error creating thumbnail: sh: /usr/bin/convert: No such file or directory

The EGI User Community Services. The abbreviation "UCSC" refers to the team coordinating the UCSC and representing these in the TCB within EGI.org.

The SSCs fulfill a set of extended support services in the sense that they are endorsed electively by a subset of NGIs, and have a specific relationship with EGI.org. The characteristics of this relationship are still under study, but some guidelines are given below (see also the EGI Blueprint). On a practical level, the individual SSCs can be viewed as "satellites" of EGI.org:

The SSCs will be jointly supported by groups or federations of NGIs, EGI.org "project" funding, and other EC funding, in proportions to be determined (options: peer review, EGI PB, EGI technical boards, existing MoUs,…). An NGI can choose whether it wants to be a member of a particular SSC or not:

Note that the SSCs do not affect the general relationship between EGI.org and the NGIs. It is expected that an NGI will provide a means to support its users, either directly or via an SSC, which is the typical choice for international VOs that have "pre-SSC" structures in place. These should evolve into actual SSCs which would have the following characteristics:

• The articulation in SSCs will provide flexibility to the EGI ecosystem, minimising the load on the central EGI.org (hence the NGIs’ “membership fee”), and allowing the NGIs to support the parts of the system that are closest to their interests and would benefit most from federation of resources.
• An SSC can be hosted by an NGI that has (or can host) the appropriate resources and European-level commitment, under a specific agreement with the other member NGIs and EGI.org.
• There is no obligation for an NGI to be part of any SSC. An SSC can (and should) have a mechanism to allow new members to join at a later date, or – if appropriate – to allow a community within an NGI to make “partial” use of its services, which would be properly acknowledged by the relevant NGI.
• The formation of SSCs will be carried out under assessment by the EGI governing bodies of proposals submitted by federations of NGIs and the relevant VOs. These plans should include timetables for the evolution of the SSC and resource estimates, for which we give some guidelines below.
• An SSC can be formed for a particular scientific area (Biomed, Astro, Archaeology, …) but it may also be formed for specific user needs. Examples of SSCs can be drawn from the characteristics of the European Projects discussed elsewhere in this site – e.g. there could be a Training SSC or an SSC for interoperation with massively parallel applications (in collaboration with DEISA/PRACE), etc.

The manpower for the SSCs will be provided by the interested NGIs with EC co-funding; from this point of view, the tasks fulfilled under the SSC umbrella can be classified as NGI International Tasks, as depicted in the Operations and Security section. A more detailed description of possible SSC tasks is given here.

The coordinator – or coordinating body – of an SSC should be an appropriate team proposed by the SSC and provided by an NGI, an institution within/associated with an NGI, or a team appointed (or selected) by EGI.org (which may reside in a member NGI). The ESSC team within EGI.org is obviously not a candidate for this role, since this team has an already heavy coordinating role and is not partial to any of the various specialisations. Furthermore, enlarging this team would require a larger workforce in EGI.org, which would affect the NGIs’ member fees. EGI.org however should specify general rules for the governance of SSCs, including mechanisms for ensuring that an SSC coordination body can guarantee the appropriate European-level commitment, beyond the specific availabilities of members of this body.

[edit] Evolution of SSCs

As a consequence of the business model proposed, the EGI technical system is an access infrastructure to resources – i.e., the infrastructure is constituted by a set of services organised in an NGI based environment. EGI.org, together with the extended support services provided by the SSCs, is an instrument for the NGIs to “better” provide these services; “better” meaning either more economical or with enhanced functionality or both.

[edit] Science Gateways

From the point of view of the user, the EGI (EGI.org + NGIs) should present itself as set of easy-to-find services, organised as thematic gateways that users can access by navigating directly to their area of interest and quickly begin their work. In other words, EGI should allow users to be just a few clicks away from their virtual workspace. Many SSCs are expected to expose their services – in particular those related to communication, user support, overview of related applications, etc., by means of a scientific gateway accessible in a transparent manner from the EGI website. A user friendly model of this “gateway” system is one where these areas are immediately evident in the main EGI web page:

(figure)

It takes only one click to see the list of gateways…

(figure)

…and one more click to access the gateway of choice:

(figure)

For these gateways, it is recommended that SSCs have a specific content management task overseen by a “specialised user” – a person who can identify with typical potential users from the community, and “catch” possible barriers for these communities, such as information portals unnecessarily hidden from users not bearing personal certificates.

[edit] SSCs and Large Scientific Infrastructures

Beyond the concept of EGI gateways, there is an expectation that EGI will offer services to large infrastructures that have their own gateways and who expect a seamless integration of grid services into their own infrastructure.

The prototypical case is the ESFRI projects. The scale and diversity of these projects immediately suggests that EGI should provide specialised services for them on a case-to-case basis, providing an EGI point of contact for each project and structuring an SSC in response to each specific case. For these kinds of SSCs, the ideal coordinator would be a team appointed directly by EGI.org in consultation with the relevant experts in the EGI ecosystem. The SSC coordinator can then take the leadership in setting up a dialogue with the relevant ESFRI counterpart to model the expected integration between EGI and the ESFRI project and provide a liaison with EGI grid planning and management.

The ESFRI communities will also require an organised effort to understand and represent user requirements and should be integrated in the process of responding to these requirements, as described in part here.