D7.7.1.1 Designing a Consortium Service Portfolio – NFDI4Energy's Criteria and Process for Integrating Services

Deliverable 7.7.1.1 DESIGNING A CONSORTIUM SERVICE PORTFOLIO – NFDI4ENERGY’S CRITERIA AND PROCESS FOR INTEGRATING SERVICES 24.11.2025 D7.7.1.1 Designing a Consortium Service Portfolio – NFDI4Energy’s Criteria and Process for Integrating Services Florian Kotthoff (https://orcid.org/0000-0003-3666-6122)1, Alexandro Steinert (https://orcid.org/0009-0005-7207-1005)1, Oliver Werth (https://orcid.org/0000-0002-6767-5905)1, Stephan Ferenz (https://orcid.org/0000-0001-9523-7227)1,2, and Astrid Nieße (https://orcid.org/0000-0003-1881-9172)1,2 1 OFFIS, Institute for Information Technology, https://ror.org/003sav189, Escherweg 2, 26121 Oldenburg 2 Carl von Ossietzky University of Oldenburg, Department of Computer Science, https://ror.org/033n9gh91, Ammerländer Heerstraße 114-118, 26129 Oldenburg Published by OFFIS, Institute for Information Technology, https://ror.org/003sav189, Escherweg 2, 26121 Oldenburg Acknowledgements The authors of this article have used various preparatory works from the NFDI4Energy to create this portrait, and references have been made where possible. Thanks to all those who are not named. The authors would like to thank the German Federal Government, the German State Governments, and the Joint Science Conference (GWK) for their funding and support as part of the NFDI4Energy consortium. The work was funded by the German Research Foundation (DFG) – 501865131 within the German National Research Data Infrastructure (NFDI, www.nfdi.de). License This document is published under the Attribution 4.0 International (CC BY 4.0). This license allows reusers to distribute, remix, adapt, and build upon the material in any medium or format, so long as attribution is given to the creator. The license allows for commercial use. Page 1 of 21 Table of contents General Information............................................................................................................................... 3 Summary........................................................................................................................................... 3 Deliverable within NFDI4Energy........................................................................................................ 3 Introduction............................................................................................................................................4 Relevant Works from other parties........................................................................................................4 NFDI4Energy Services.............................................................................................................................4 What is a Service?.............................................................................................................................4 What are the requirements of an NFDI4Energy Service?..................................................................6 How can aLservice become an NDFI4Energy Service?........................................................................8 How does a service benefit?..............................................................................................................8 Deprecation of the NFDI4Energy Service Status................................................................................8 Conclusion..............................................................................................................................................8 Page 2 of 21 General Information Summary Useful services that help researchers to better deal with their research data and software and make them FAIR are a key outcome of NFDI4Energy. However, deciding what qualifies as a service and which services should be included in a consortium's service portfolio can raise questions that an NFDI consortia has to be aware of. LBased on previous works from NFDI, EOSC, and other consortia, we present the current status of the selection and onboarding process for services into the NFDI4Energy Service Portfolio. We define what constitutes a NFDI4Energy Service and outline the requirements for a service to achieve full NFDI4Energy Service status. These requirements include legal clarity, operational readiness, documentation, user support, and interoperability with relevant standards for service provision. The NFDI4Energy Service Portfolio supports FAIR data management, aligns service understanding and development, and contributes to the broader NFDI strategy.LWith this work, we want toLdocumentLour service selection process, base it on clearly defined rules, and provide guidance to consortia that have not created a service portfolio yet. Deliverable within NFDI4Energy An NFDI4Energy Service Portfolio will list services that are developed within other Work Packages. These services are Best Practices Service (Task Area 1 and 8, short: TA1 and TA8), Competence Service (TA8), Open Research Knowledge Graph (TA8), Open Energy Platform (TA8), Simulation-as-aService Hub (TA5), Leibniz Data Manager (TA8), Anonymization Service (TA3) as well as Services that are developed outside the funded consortium. Page 3 of 21 Introduction Conducting research in line with the FAIR principles [1] is challenging, especially for those unfamiliar with open science. To support these researchers, NFDI consortia aim to provide useful services that improve research data and software management and help make them FAIR. However, determining what constitutes a service and which service should be included in a consortium’s portfolio can raise important considerations for the consortia. In this work, we will first review relevant works from other parties. Then we discuss the definition of services, as well as the requirements and processes to become an official NFDI4Energy Service. Relevant Works from other parties The NationaleLForschungsdateninfrastruktur (NFDI) defines the term „service“ and different categories of services in their White Paper: Interim Report References [2]. The purpose of a service portfolio on NFDI level is described as a selection of services that fulfill basic NFDI requirements and that are reliably available to researchers [3]. The NFDI outlines specific requirements for its future portfolio, including content, technical, and strategic aspects. On the European level, the service portfolio management of the EOSC Hub is described in [4]. They provide fourteen processes which are required to deliver well managed services. In the Service Portfolio Report of NFDI4Biodiversity [5], the consortium provides deep insights in their process of designing and maintaining their current service portfolio, which consisted of 80 services at the time of their report publication. They describe in detail their process of on-boarding new services and how they do quality assurance for services in their portfolio. The Text+ Consortium shows their rather different approach in their “Guidelines for adding Text+ Services to the SSH Open Marketplace” [6]. They provide a marketplace where users can registerLnewLservices after creating an account at the marketplace. These service entries will then be checked by moderators of the platform. This approach is rather bottom-up and sees the service owners responsible for creating good services. NFDI4Energy Services What is a Service? We follow the service definition proposed in the “White Paper: Interim Report Reference” of the NFDI [2]: A service in NFDI is understood as a technical-organisational solution, which typically includes storage and computing services, software, processes, and workflows, as well as the necessary personnel support for different service desks. It is important to note that a software or software package itself is not considered to be a service. It can only become a service when the software is hosted somewhere and can perform tasks upon requests. In NFDI4Energy, we use a technical-centric and a user-centric categorization schema for services. The technical-centric schema is the categorization of services based on the de.NBI service categories [7] with the extensions from [2]. These categories are shown in Table 1. Page 4 of 21 Table 1: Service categories from a technical perspective as defined by [2], [7]. Category Definition Database Software providing large amount of structured data to the user. Library / API Collection of pre-implemented functions for a specific task that can be accessed via a well defined interface.‐ Workflow / Pipeline Software that combines multiple tools / applications. They may be used locally or remotely via the internet. Tool / Application Software that can be downloaded and executed locally on the users' hardware. Support / Consulting Service with direct user contact for topics going beyond the support for the other services. Web Application Software that is installed on a server and can be used by users via a web page and the internet. *Data Curation If not included in support/consulting: “The activity of managing and promoting the use of data from their point of creation to ensure that they are fit for contemporary purpose and available for discovery and reuse. For dynamic datasets this may mean continuous enrichment or updating to keep them fit for purpose. Higher levels of curation will also involve links with annotation and with other published materials” [6] *Training Standalone training for self-study can be considered a technical service (usually a web application). Generally speaking, training materials often come in the form of specific measures or tutorials that are attached to a service and that are designed to improve the user’s service experience. Our joint understanding of training as a stand-alone service, however, is not limited to the above and includes materials designed for education in all fields of research data management. *Storage Provision of storage space for research data as a service to external users. Access is possible via web protocols. Noted with * are categories added by NFDI in [2] L From the user perspective, services can also be allocated to the different stages of a research data life cycle. Services can help in one or multiple stages: Planning, Production, Analysis, Storage, Access, and Reuse. Figure 1: The Research Data Life Cycle. This categorization helps to develop a User Interface for the portfolio with the idea of providing researchers the relevant services, depending on the stage they are currently in. Page 5 of 21 What are the requirements of an NFDI4Energy Service? An NFDI4Energy service is sustainable maintained with the necessary infrastructure and personnel, ensuring interoperability with other services through standardization. Since not all services can directly adhere to these requirements, we distinguish two stages for services: Candidates and full NFDI4Energy Services. The requirements for the Candidate Status are: A1: The service needs to be a service as defined above. It also needs to offer benefits for researchers, data stewards, or research software engineersLin the energy domain. A2: The service is maintained and provided by a member organization of NFDI4Energy in the NFDI association („Konsortium gemäß Satzung (KgS)“) (the service provider). A3:LThe service has already surpassed its conceptualization phase and is available as a prototype (TRL 3-4 or higher). We want to make sure that during the onboarding process, all stakeholders have a clear idea about the service. Therefore, the service already needs to exist in its first version. A4: If the service is based on software, the software repository is open source with a License approved by the Open Source Initiative [8]. A5: The service provider and representatives from the NFDI4Energy consortium agree on relevant services and standards that need to be consideredLby the proposed service. These specifications are discussed with the service providers based on a checklist (see Appendix).LThe specifications are a case-to-case decision, but in general the following requirements exist: 1. Services with user authentication should use services that allow the authentication with existing accounts, such as university accounts. This could beLensured by integrating RegApp via the IAM4NFDI Base Service. 2. Data Platforms should integrate a Terminology Service and offer Persistent Identifiers. 3. Services that produce data must be compatible with metadata according to the NFDI4Energy Metadata Standard. 4. Services should be interoperable with relevant other services from the NFDI4Energy Service Portfolio. Finally, the requirements agreed upon are verified and accepted by a service committee from the KgS. A6: Maintainers of the service commit to further develop their service, especially having in mind the work needed to fulfill the requirements defined in A5. The requirements for the NFDI4Energy Status are: B1:LThe service needs to be interoperable with relevant other services and relevant standards. Hence, the specifications defined in A5Lneed to be fulfilled. B2:LA clear legal status for all relevant aspects is needed. First, a Terms of Service needs to clarify how the service can be used. Second, if the service produces or provides data of some kind, it Page 6 of 21 needs to be clarified how this data can be used. And third, the codebase of the service needs to have an open-source license attached. B3:LThe service needs to be in operation - it needs to be more than a prototype. Hence, a TRL 7 or above is required. B4:LThe service needs to be documented. This also means that tutorials are provided within the Best Practice service of NFDI4Energy. If the service is based on software, this software also needs toLbe openlyLdocumented. To increase the findability of the service, it is listed on relevant platforms. B5:LA support needs to be available for users, meaning there is at least an email address available for users seeking support. B6:LThe Service providerLcommits to the NFDI4Energy reporting and provides relevant information and KPIs. B7:LTo ensure optimal performance and mitigate potential security risks, the service requires ongoing proactive maintenance and anLopenly documented, sustainable operating model for at least the next two years. B8: To ensure the secure usage of the service, appropriate application security measures need to be implemented. Service Providers need to state which sensitive information is collected, and which measures are taken to secure this data. The requirements for both stages are summarized in Table 2. Table 2: Requirements for the NFDI4Energy Candidate Service status and an NFDI4Energy Service status. NFDI4Energy Candidate Service NFDI4Energy Service A1: Service for Researchers in the Energy Domain L A2: Service Provider is member of NFDI4Energy KgS L A3: Service is available as a prototype – TRL 3-4 L A4: The software of a Service is open source L A5: Defining Requirements for Interoperability with other Services and NFDI4Energy Standards L A6: Maintainers want their service to become an NFDI4Energy Service and commit to further work L B1: Interoperability with other Services and NFDI4Energy Standards (Defined in A5) L B2: Clear legal status regarding usage of the service, the produced results, and the underlying codebase L B3: Service in Operation – TRL 7-9 L B4: Existing Documentation Pages L B5: Existing Contact details for support L B6: Commitment to NFDI4Energy Reporting L B7:LActive MaintenanceLand sustainable operating model L B8: Appropriate Application SecurityL L Page 7 of 21 How can aservice become an NDFI4Energy Service? As described above, the process consists of two stages. To become an NFDI4Energy Candidate Service, the candidate requirements must be fulfilled. In A5, the specifications are discussed between NFDI4Energy and the Service Providers. This ensures that the Service Providers get a rough idea of the work that needs to be done to become a full NFDI4Energy Service. It shall be noted here that this list only needs to be defined in a first version and can be adapted during the rest of the onboarding process. If the service fulfills these requirements, the service provider can contact the NFDI4Energy service coordinator, who will verify them and forward the service to a subgroup of theL“NFDI4Energy KonsortiumLgemäßLSatzung (KgS)”, the socalled Service Committee. This Committee will then vote by a simple majority on whether theLservice qualifies as an NFDI4Energy Candidate Service. By this vote, the committee also agrees on the defined requirement list. If approved, theLservice will be added to the Service Portfolio with a candidate status flag. To proceed, services must comply with requirements B1 through B8, as these will be subject to a review by the Service Committee. Following this assessment, the reviewed service and accompanying report will be presented to the KgS, which will then render a final decision based on a simple majority vote. The status of an NFDI4Energy Service will be reviewed regularly and can be withdrawn by a vote from the KgS. L Figure 2: Process of how a service can become an NFDI4Energy Service. How does a service benefit? Successfully completing the onboarding process and becoming an NFDI4Energy service holds several benefits. These benefits include enhanced visibility within the energy research and industry communities through online promotion, showcase events, and workshops, as well as overall NFDIwide recognition. Additionally, services that have undergone the onboarding review are entitled to utilize the "NFDI4Energy Service" label, serving as proof of their successful evaluation. Furthermore, the NFDI4Energy consortium will provide support in developing sustainable operational models for these services. Deprecation of the NFDI4Energy Service Status If a service no longer fulfills its defined requirements or is not properly maintained, its status within NFDI4Energy will be deprecated. The deprecation of a service's status is determined by KgS through a simple majority vote. Page 8 of 21 ☐LIntegration is in progress. ☐LIntegration is planned. ☐Not started yet. L L L L L RDMTraining4NFDI RDMTraining4NFDI is concerned with offering training in the knowledge and skills required for research data management (RDM) to all NFDI consortia. The training encompasses data, software, and machine-learning models, and is intended for the consortia’s staff, such as data stewards and trainers, as well as researchers within the respective communities. The core goal of this service is to develop a modular collection of foundational RDM training materials, along with documented, proven training formats and methods. By providing access to these resources, consortia can efficiently create their own community-specific adaptations of the training and build capacity rapidly. Additionally, the option of certification will be explored to establish quality standards and document the skills acquired by participants.L Does your service need to integrate / be interoperable with this service? ☐LYes. ☐LNo, integration does not make sense. ☐No, integration is plausible, but out of scope for becoming an NFDI4Energy Service. Explain: L L If the integration is required, how is the progress here? ☐LIntegration is complete. ☐LIntegration is in progress. ☐LIntegration is planned. ☐Not started yet. L Page 15 of 21 Compatibility with NFDI4Energy Services OpenEnergyPlatform A database where everybody can add, edit, and review data – as well as factsheets about energy frameworks and models. Does your service need to integrate / be interoperable with this service? ☐LYes. ☐LNo, integration does not make sense. ☐No, integration is plausible, but out of scope for becoming an NFDI4Energy Service. Explain: L L If the integration is required, how is the progress here? ☐LIntegration is complete. ☐LIntegration is in progress. ☐LIntegration is planned. ☐Not started yet. L L L L Leibniz Data Manager The Leibniz Data Manager is a CKAN distribution tailored for ResearchL Data Managment and was developed to support the aspect of betterL re-usability of research data. It enables FAIR and sustainable researchL data through a knowledge-driven ecosystem. Does your service need to integrate / be interoperable with this service? ☐LYes. ☐LNo, integration does not make sense. ☐No, integration is plausible, but out of scope for becoming an NFDI4Energy Service. Explain: L L Page 16 of 21 If the integration is required, how is the progress here? ☐LIntegration is complete. ☐LIntegration is in progress. ☐LIntegration is planned. ☐Not started yet. L L L OpenResearchKnowledgeGraph The Open Research Knowledge Graph (ORKG) aims to describe researchL papers in a structured manner. With the ORKG, papers are easier to findL and compare. Does your service need to integrate / be interoperable with this service? ☐LYes. ☐LNo, integration does not make sense. ☐No, integration is plausible, but out of scope for becoming an NFDI4Energy Service. Explain: L L If the integration is required, how is the progress here? ☐LIntegration is complete. ☐LIntegration is in progress. ☐LIntegration is planned. ☐Not started yet. L Compliance with NFDI4Energy Standards and Requirements Metadata NFDI4Energy publishes its recommendations for a standardized Metadata in Deliverable 4.3.21 – As soon as it is available, services need to comply with these Metadata recommendations. 1 NFDI4Energy Metadata document: https://doi.org/10.5281/zenodo.17549282 Page 17 of 21  Technical and Organisational requirements The software of a Service is open source: ☐Yes ☐No Explain: L There is a clearLlegal status regarding usage of the service, the produced results, and the underlying codebase: License of the codebase: ☐Yes ☐No Explain: L Terms of Usage: ☐Yes ☐No Explain: L Privacy Policy: ☐Yes ☐No Explain: L L The Service is in Operation, meaningLTRL 7-9 ☐Yes ☐No Explain: L Page 18 of 21 L There Service has Documentation Pages: ☐Yes ☐No Explain: L L There are Contact details for supportLavailable: ☐Yes ☐No Explain: L L There is Appropriate Application Security (also note if sensitive data is stored by the service): ☐Yes ☐No Explain:   Compliance with NFDI Standards – Only needed if Service wants to become an NFDI Service The service has clearly defined maintenance and update cycles, technicalL monitoring (availability, response times, etc.), regular securityA audits, and is operated in certified/sovereign environments. ☐Yes ☐No Explain: L L There are verifiable Service Level Agreements (SLA) between operatorsL and users (possibly also departments of the NFDI association), as wellL as transparent regulations on data protection, IT security, legalA certainty, and terms of use. Page 19 of 21 ☐Yes ☐No Explain: L L L The service has an openly accessible operating model with transparentL information on financial sustainability, legal ownership, and theL responsibilities of the service operators. ☐Yes ☐No Explain: L L L Appropriate technical and organizational measures to ensure theL confidentiality, integrity, and availability of the service and theL processed data are implemented (e.g. ISO or BSI Basic Protection). ☐Yes ☐No Explain: L Page 20 of 21