Open discussion for defining "onboarding"

Andrea Mannocci's picture
27 May 2020

Open discussion for defining "onboarding"

  • By Andrea Mannocci

Dear all,
In the context of the INFRAEOSC-Call 5 projects, an open discussion of what “service onboarding” means has recently started, and a few definitions/observations have been suggested.
On this matter, another contribution has emerged during the just ended EOSC-hub week, where Owen Appleton brought forward another valid point of view in his talks.

Clarifying the meaning of onboarding is of paramount importance to have a common understanding of it, and to be able to identify the types of Rules of Participation that have to be introduced to regulate it. As this IG seems an ideal venue for this discussion, in order to get started with all of you, the three contributions have been collated and reported below.

Do you agree with them? Do you have alternative definitions/comments /suggestions?
Your contribution is really appreciated. By contributing to this discussion, you will also help the identification of a precise definition of the term that will be included in the EOSC Glossary. 
You will also indirectly contribute to the activities of the Rules of Participation and Architecture WGs.

Best,
Andrea
 

Def.1: The process of making a service available in a defined catalogue according to predefined criteria and procedures. Criteria are derived by a set of predefined rules, called Rules of Participation. The onboarding procedure includes a validation step. (Luciano Gaido, INFN)
Def.2: Connecting providers and their resources to EOSC such that they can be accessed by researchers and can build over core services. (Owen Appleton, EGI)
Def.3: Service onboarding is a process aiming at integrating an existing service into an operational context thus to make it possible for the operational context to “manage” the service and offer facilities on the onboarded service. The process includes (a) a submission step where the service provider issues a request for integration and provides the operational context manager(s) with all the information characterising the service offerings requested by the onboarding process; (b) a review step where the operational context manager(s) assess (with the help of tools) whether each candidate service is suitable for the integration into the operational context and approve or reject the request for integration; (c) a monitoring step where the suitability for the integration of the onboarded services (i.e. the services integrated) is checked over time. (Leonardo Candela, ISTI-CNR)

    2 Comments

  • Leonardo Candela's picture

    Leonardo Candela

    Date: 27 May, 2020

    Thanks for continuing this interesting discussion by this fora.

    I'll take the opportunity to further elaborate on a couple of aspects I tried to highlight.

    By stressing the fact that onboarding is a process it is possible to focus on the intent / goal first and then develop the steps that are needed to achieve the intent / goal.

    The integration attribute is there exactly to stress that by onboarding an existing asset (be it a service, a dataset, or anything else) it is intended that a relationship between the onboarded asset and the receiving context is established. How strong or demanding is this relationship depends from the onboarding intent / goal.

    The fact that onbarding is often associated with the concept of a catalogue might be misleading. It is certainly not the primary goal to me. Rather it is a sort of side effect of a successful onboarding activity.

  • Andrea Mannocci's picture

    Andrea Mannocci

    Date: 27 May, 2020

    Thanks, Leonardo, for your clarification; your comment anticipated a point I wanted to make.
    IMHO, it is important to move away from onboarding as a process dedicated solely to services.
    As you wrote and as per Owen definition, we should rather talk of "resource onboarding" (be it a service, a dataset, or other research products).

Leave a Reply