Creating a maturity model for EOSC services
One of the first steps we took in work package 3 (WP3) in this project was to create a maturity model for EOSC services. The goal was to get a shared understanding of what an EOSC Service is and to have an easy method for evaluating services for EOSC compliance. The main question that this maturity model aimed to answer was: Is a specific service good enough to be included in the EOSC Service Catalogue?
A secondary purpose of this model was to motivate service providers to enhance the maturity of their services by providing them a model against which they can benchmark beyond the basic EOSC compliance.
EOSC-Nordic has delivered an update to the initial version of the model. The initial version has also served as a basis for the work of another European project, EOSC-Pillar. Hence, in this blog article, we will report on three models (two versions developed by EOSC-Nordic and one created by EOSC-Pillar).
The first version of the maturity model was introduced in the first deliverable from the WP3 working group. It contained five separate sections, and each section listed several criteria, which were supposed to be satisfied by service to achieve one of the maturity levels: minimum, intermediate, or high.
We collected most of the input to define the criteria for this first version of the model from FitSM (Federated IT Service Management), the EOSC Rules of Participation Working Group, the FAIR Principles, and the EOSC Service Provider Onboarding process.
The work with the maturity model continued and resulted in the second deliverable, where the focus of the work was on mapping EOSC prospective service providers and candidate services. Several selected service providers participated in the initial service inventory. We asked them to assess the services using the first version of the service maturity model. Based on their feedback, a new, improved version, version 2, of the service maturity model was developed and was used to update the list of possible answers to each question/criteria. Then, the improved version was used to assess the services again. Some of the questions from the first section were broken into multiple questions or clarified. Some others were improved by using simplified terms to make questions more precise and understandable.
The maturity model was additionally modified and improved by the EOSC-Pillar regional project. In preparation for their deliverable, EOSC-Nordic’s maturity model (version 1) was used, and requirements for data repositories were added. These requirements were based on criteria from different publishers and organisations (CoreTrustSeal, COAR, NIH, ELIXIR, TRUST).
Table: Variations, in number of questions, between three versions of the maturity model
Service analysis outcomes from EOSC-Nordic and EOSC-Pillar
As mentioned, the EOSC-Nordic WP3 working group interviewed service providers that mostly covered compute, data storage, and data analysis type services. Service analysis outcomes have shown several already mature services that could be easily added to the EOSC catalogue.
While technical maturity and compatibility might not hinder onboarding service, in some cases, governance and funding are. Unfortunately, at this point, not much work could have been done on EOSC architecture compatibility, as no finalised documents were available.
In their work of analysing services, EOSC-Pillar has come to similar conclusions, i.e., services already comply with most of the maturity model requirements and are already ready to serve a broader user community.
EOSC-Pillar made an essential contribution in adding requirements for data repositories and analysing outcomes. In that work, they also noticed low compliance with the EOSC architecture. This is justified by the lack of guidelines and documentation on the EOSC service integration side.
Sustainability and future work
Collaboration between EOSC-Nordic and EOSC-Pillar resulted in an essential contribution to the maturity model. Data repository requirements are a significant development of the maturity model that makes it a convenient tool for evaluating a broader range of services.
The following important steps should focus on EOSC architecture compatibility and evaluation of the integration of services into EOSC Core to make the maturity model even more relevant for the service providers in contributing with their services to EOSC.
During EOSC Future Provider Days, EOSC Core development and its roadmap were presented. In the EOSC Core presentation, a significant focus was made on the aspects of service integration with EOSC Core. This is very important for developing the last section of the maturity model, as mentioned by both EOSC-Nordic and EOSC-Pillar.
This blog is the first post in a series of blog posts by WP3.