Service Design Guide

10.5281/zenodo.16306727 Funded by DFG as part of NFDI. Grant Numbers: 521453681, 521460392, 521462155, 521463400, 521466146, 521471126, 521473512, 521474032, 521475185, 521476232 Service Design Guide Susanne Arndt , Anette Ganske , Dorian Lehmenkühler Version 1, November 2025 1 Introduction .............................................................................................................................................................. 2 1.1 Purpose and Target Group of This Document .......................................................................................... 2 1.2 Service Design and the Base4NFDI Phases ............................................................................................... 2 1.3 Service Design Goals – An Overview ........................................................................................................... 3 2 Service Design – Approach and Outcomes ....................................................................................................... 4 2.1 Approach to Service Design .......................................................................................................................... 4 2.2 Service Design Documentation .................................................................................................................... 5 2.3 Service Design Aspects ................................................................................................................................... 5 3 Overarching Landscape and Goals ..................................................................................................................... 6 3.1 NFDI & Base4NFDI – Integration and Re-use ............................................................................................ 6 3.2 A Look Ahead – Basic Services and EOSC ................................................................................................... 7 3.3 FAIR Basic Services .......................................................................................................................................... 9 3.3.1 FAIR-enabling Services ........................................................................................................................... 9 3.3.2 FAIR Software and Software Metadata and Quality ........................................................................ 9 4 Service Design Aspects to Consider .................................................................................................................. 11 4.1 Procedural Aspects of Service Design ....................................................................................................... 11 4.2 User-related Aspects of Service Design.................................................................................................... 12 4.2.1 Accessibility .............................................................................................................................................. 12 4.2.2 User Experience and Ergonomics ....................................................................................................... 12 4.2.3 Service Documentation ........................................................................................................................ 14 4.2.4 User Training ........................................................................................................................................... 14 4.3 Technological Aspects of Service Design ................................................................................................ 14 4.3.1 Architecture – Components, Modules and Their Dependencies .................................................15 4.3.2 Interfaces, Data Formats and Communication Protocols ........................................................... 16 4.3.3 Service Performance, Health and Delivery ...................................................................................... 17 4.3.4 Testing ...................................................................................................................................................... 18 4.3.5 Service Security ...................................................................................................................................... 18 4.4 Communication-related Aspects of Service Design ............................................................................. 19 4.4.1 Service Website and Communication Channels............................................................................. 19 4.4.2 Change Management and Communication ..................................................................................... 20 4.5 Governanceand Compliance-related Aspects of Service Design ................................................... 20 4.5.1 Assigning Tasks and Responsibilities ............................................................................................... 20 4.5.2 Compliance ............................................................................................................................................... 21 4.5.2.1 Licenses and License Compatibility ........................................................................... 21 4.5.2.2 Personal Data and Protection ..................................................................................... 22 5 Conclusion: Don’t Panic! ...................................................................................................................................... 22 Image Credits ............................................................................................................................................................ 23 Base4NFDI Service Design Guide – 10.5281/zenodo.16306727 2 1 Introduction 1.1 Purpose and Target Group of This Document This document guides you while drafting your service design in the Initialisation Phase of Base4NFDI. It lists foundational aspects to consider and directs you to external best practice documents, assisting you in designing a sustainable basic service. It also points out the broader context of basic service development. You should gain awareness of it during the Initialisation Phase to prepare and plan for future integration tasks. REMEMBER: YOU DO NOT NEED TO IMPLEMENT ALL ASPECTS INTRODUCED BY THIS GUIDE DURING THE INITIALISATION PHASE YET! This guide introduces critical dimensions of service design to raise your awareness for them. You should familiarise yourself with these in the Initialisation Phase to avoid blind spots throughout the whole course of the basic service development (incl. Integration and Ramp-up). 1.2 Service Design and the Base4NFDI Phases Service design is located in the Base4NFDI Initialisation Phase and you must address it early on in your basic service development. It has a particular purpose within the Initialisation Phase but also has importance for the other two Base4NFDI phases. REMEMBER: During the Initialisation Phase, a prototype is developed. In the Integration Phase, the basic service must meet stricter requirements, enabling its use by other consortia's domain-specific applications and adoption by other Base4NFDI services. At the end of the Ramp-up Phase, these services must be ready for reliable integration into the wider infrastructure within and potentially beyond the NFDI and must be ready for reliable operation. In the service design process, you establish the foundational structure of your basic service. Based on it, you create your prototype and you update it when the prototype is tested and new requirements emerge. It contains aspects, like service security, that you must address and fine-tune when NFDI consortia integrate it into their services – in particular, when your service is ramping-up for long-term operation. Service design is important groundwork that you should not neglect. The Base4NFDI TA1 Team can support you with the service design and/or its documentation by guiding you through the process and by monitoring the service landscape to ensure that there are no blind spots. The Base4NFDI Service Stewards can assist you, identifying current technology trends within the consortia and their user bases. Base4NFDI Service Design Guide – 10.5281/zenodo.16306727 3 1.3 Service Design Goals – An Overview The service design process helps you to achieve the following goals for your basic service. Goal 1: You have identified all required components. Determine which elements you need to deliver the service – be it staff roles or technical and digital components. Make sure all components serve a purpose in relation to your stakeholders’ requirements. 4.3.1 Architecture – Components, Modules and Their Dependencies Goal 2: You are aware of all component interactions and necessary interfaces. Identify and document which interactions between the components are necessary to support user actions and define interfaces that enable a smooth flow of these interactions. Define how users can communicate with you or how you can communicate with your users. 4.1 Procedural Aspects of Service Design · 4.3.2 Interfaces, Data Formats and Communication Protocols · 4.4 Communication-related Aspects of Service Design · 4.5.1 Assigning Tasks and Responsibilities Goal 3: You have defined first quality attributes of your service. Specify first measurable indicators for service success as a minimum acceptable standard. Use these as your goals, to validate the developed prototype and to verify that service development is going into the right direction. 2.1 Approach to Service Design · 4.3.3 Service Performance, Health and Delivery Goal 4: You have located your service convincingly in the broader research infrastructure landscape. Identify areas of synergy, competition, and unique value proposition in comparison to existing research infrastructures. In particular, identify complementary services that benefit from integrating your service. Identify first interoperability goals to you need to achieve. 3 Overarching Landscape and Goals visualisation is continued on next page Base4NFDI Service Design Guide – 10.5281/zenodo.16306727 4 Goal 5: You know how to optimise your service, e.g. for usability and how to make it compliant with legal requirements and best practices. Include the user perspective into your design: Make the service simple and easy to use avoiding complex interfaces and user interactions. Think about training your users. Consider legal compliance standards early on, e.g. for accessibility, data protection, security, in order to create a trustworthy service. 4.2.1 Accessibility · 4.2 User-related Aspects of Service Design · 4.3.4 Testing · 4.3.5 Service Security · 4.5.2 Compliance Goal 6: You have documented your service design. Capture the service design in a comprehensive documentation. It shall guide your team during the service development as a common reference. Update the documentation when new requirements or user feedback from piloting and testing make changes in the service design necessary. 2.2 Service Design Documentation 2 Service Design – Approach and Outcomes 2.1 Approach to Service Design Your service design is the conceptual blueprint for the entire service, considering all relevant technical, organisational, resource and user aspects. Provide as much detail as needed to enable the construction of the service. The documentation of the design is needed to verify the design against the requirements and quality attributes. Service design, therefore, needs to start with addressing the expected and empirically collected functional requirements from the requirements analysis (your Deliverable D.TA1.1) 1 . Based on these functional needs as well as on the software and service evaluation (D.TA1.2), you should try to identify appropriate service components that can provide or enable the required functionality. In addition, try to define initial non-functional requirements (= quality attributes) for the service (e.g. speed/ efficiency of the system, performance, stability, maintainability, etc.) before finalising your service design and before planning the prototype. Quantify, and if necessary, contact stakeholders to specify them. Also define quality attributes for nontechnical services, e.g. acceptable time until externals request are answered. Choose the technology stack according to both types of requirements. Prefer established open source software. Try to document your concept visually using appropriate types of diagrams. Try to aim for a minimum viable product (MVP) to speed up development and to have a shareable prototype ready fast. Dissect the service into functional (= vertical) and 1 The deliverables are required to complete the Initialisation Phase; cf. Wittenhorst, T. et al. (2025) ‘Base4NFDI – Requirements for Completion of Initialisation Phase’. Zenodo. https://doi.org/10.5281/ZENODO.15020379. Base4NFDI Service Design Guide – 10.5281/zenodo.16306727 5 technical (= horizontal) layers in order to see how user features depend on specific technical components (e.g. API, middleware, data storage, UI), understand how the technical building blocks interact and break the service down into smaller parts that can be built and tested separately. This approach helps you to prioritise development and implementation tasks (also for nontechnical services!), to plan for iterations, and to reach the MVP sooner. If required, refine the service design by applying (further) quality attributes. Watch the scope of the design: Do not let it grow too big, insist on limits to non-functional requirements (in consultation with stakeholders), postpone any optimisation to a later stage of development, and aim for a prototype as soon as the draft of your service design seems sufficiently developed. Before moving on to the prototyping/ development of the service, check again for the consistency of interfaces between components, note boundaries of your system and assign responsibilities within your team. Plan for further iterations of redesign, design changes and more prototypes based on the later piloting and testing of the prototype. If you want to make sure the design is sound, have it reviewed by critical stakeholders. Remember: The Initialisation Phase is about testing the basic concept and providing the service as a first prototype, not delivering the full service! 2.2 Service Design Documentation The service concept must be documented in your reporting deliverable D.TA1.3 that should be completed as a first draft six months after the start of the Initialisation Phase. Think of this documentation as your roadmap for service development and as a planning instrument: Start with a high-level overview to be refined and updated in further iterations 2 . The design grows and evolves with iterations, revealing more details. Consider your proposal as a starting point for the documentation of your service design: Relevant sections can feed into your deliverable D.TA1.3. Make sure to track service design tasks in in the D.TA1.3 reporting task in OpenProject provided by TA1. Choose accompanying documentation formats that are appropriate for the kind of information you would like to model and that you can handle in the limited time of the Initialisation Phase. Consider which target groups need to understand the documentation of the design. Link any supplements and external documentation to the OpenProject reporting deliverable. Documenting the rationale behind design decisions may also help to prevent repeated discussions later. 2.3 Service Design Aspects The service design itself must consider a broad range of aspects already. The main dimensions of the service design are: ● architectural and technological service aspects (tools, frameworks and methods), 2 Iterations may be required e.g., when new requirements emerge or known requirements need to be refined based on piloting and testing of the prototype. Base4NFDI Service Design Guide – 10.5281/zenodo.16306727 6 ● the connection/ interaction of the service with other basic services and services within and beyond the NFDI consortia (on a technical and organisational level), ● processes and interactions between users, service and any service providers (e.g. user experience (UX), training, support structures, customer communications), ● service delivery resulting in a specific user experience (human-centeredness), ● resources reliable service delivery (e.g. hardware, human resources), ● legal requirements (e.g. the General Data Protection Regulation, GDPR). Which dimensions matter most also depends on the type of service you are developing. It is your task to set the right focus while this guide helps you to address all critical points. Your service is not primarily based on a technical component? The service design and its documentation should still try to capture its individual components, their dependencies, the context in which it is located, as well as initial quality attributes. 3 Overarching Landscape and Goals The development of basic services in Base4NFDI shall result in mature basic services that ● adhere to a common framework and shared quality standards, ● are relevant to a majority of NFDI consortia, and ● bring added value to the domain-specific services of the consortia. Ultimately, basic services need to contribute to the facilitation of Open Science and FAIR 3 Research Data Management (FAIR = Findable, Accessible, Interoperable, Reusable). 3.1 NFDI & Base4NFDI – Integration and Re-use The integration of your basic service into the NFDI landscape is a dedicated concern of the Base4NFDI Integration Phase 4 . However, think about the types of users or services that would benefit from your service already in the Integration Phase to plan the search for integration candidates and interested parties. You probably already gathered some of their requirements so that you can address these in the service design as well. The design of your basic service should also include some considerations about the re-use of the other basic services developed in the Base4NFDI project. These provide support in any tasks that your service may need, but are not at its core. For example, ● user authentication and authorisation are addressed by IAM4NFDI, ● terminologies are addressed by TS4NFDI, 3 cf. Wilkinson, M.D. et al. (2016) ‘The FAIR Guiding Principles for scientific data management and stewardship’, Scientific Data, 3(1), p. 160018. https://doi.org/10.1038/sdata.2016.18. URL: https://www.go-fair.org/fair-principles/ (last accessed: October 28, 2025). 4 cf. Schäfer-Neth et al. 2025 Base4NFDI Service Design Guide – 10.5281/zenodo.16306727 7 ● persistent identifiers (PIDs) are addressed by PID4NFDI. You can find a complete overview of all basic services on the Base4NFDI website 5 . Base4NFDI supports your project via dedicated events where you can learn more about the other basic services and can connect to the other teams. Integrations within the NFDI and Base4NFDI are mostly realised as service-to-service connections. Remember: You do not need to integrate these services during the Initialisation Phase! You should rather identify dependencies resulting from planned integration shaping your service and its components 6 . The NFDI infrastructure is the immediate context of the basic service development. However, ongoing initiatives on the international level become relevant as well: the NFDI engages in becoming a national node within the European Open Science Cloud (EOSC) 7 , 8 , 9 , 10 which brings further requirements to services developed in this context. 3.2 A Look Ahead – Basic Services and EOSC EOSC is a very dynamic environment. The EOSC EU Node (EEN) launched in October 2024 and the NFDI has recently accelerated its efforts to develop the national EOSC node for Germany. Conceptual documents are provided and updated continuously. The EOSC Federation Handbook may help you to get a first overview of what EOSC is, what its requirements are and how one can join. It describes the European Open Science Cloud as a “system of systems” and the federated architecture of the different nodes to be integrated into this system. It explains basic node capabilities required for the envisaged federation. Furthermore, it describes how services can join the EOSC federation from a legal and technical view. In the future, it will also define a set of policies that need to be followed by candidate nodes. The next planned update of the EOSC Federation Handbook is scheduled for October 2025. 5 https://base4nfdi.de/projects (last accessed: October 28, 2025) 6 NFDI working groups produce outcomes for infrastructure-related topics you should take note of, e.g. WG Overall Architecture in NFDI Section Common Infrastructure or TF Governance and Sustainability. The latter has recently published cornerstones for the operation of an NFDI service portfolio. Busse et al. 2025 define criteria for portfolio admission, Deschler et al. 2025 categorize financial needs of services which require funding. ● [Busse et al. 2025] Busse, C. et al. (2025) ‘Leistungsfähige Entscheidungsstrukturen für ein NFDIDienstportfolio – Impulse zu Kriterien, Entscheidungsverfahren und Portfoliomanagement’. https://doi.org/10.5281/ZENODO.16356842. ● [Deschler et al. 2025] Deschler, K. et al. (2025) ‘Finanzflüsse für Dienste und Aufgaben – Impulse zur Kategorisierung von Finanzbedarfen nach Leistungsarten’. https://doi.org/10.5281/ZENODO.16357819. 7 Cf. for example the EOSC EU Node: https://open-science-cloud.ec.europa.eu/ (last accessed: October 28, 2025) 8 Cf. https://www.nfdi.de/nfdi-is-part-of-eoscs-build-up-phase/?lang=en (last accessed: October 28, 2025) 9 For the integration of NFDI services into the EOSC EU Node see Lechowska-Winiarz, K.et al. (2024) ‘EOSC Beyond D15.1 Service integration plans of the Data Spaces and EOSC Nodes’. https://doi.org/10.5281/ZENODO.13152335. 10 Wetzel, T. (2025) ‘The NFDI Pilot node & the EB Sandbox’. https://doi.org/10.5281/ZENODO.15703050. Presentation held at the EOSC Beyond Webinar Exploring the EOSC Core Innovation Sandbox on June 19, 2025. Recording of the presentation: https://youtu.be/98opDJI91CU?t=1863 (last accessed: October 28, 2025). Base4NFDI Service Design Guide – 10.5281/zenodo.16306727 8 [EOSC Association 2025] EOSC Association (2025) ‘EOSC Federation Handbook’. Zenodo. https://doi.org/10.5281/ZENODO.14999577. ● Homepage: https://eosc.eu/eosc-federation-handbook/ (last accessed: October 28, 2025). Base4NFDI observes the EOSC development closely and tries to position itself to it, for example with the white paper by Bernard et al. 2024, which tries to define interoperability goals for the Base4NFDI phases 11 . [Bernard et al. 2024] Bernard, L. et al. (2024) ‘Base4NFDI Policy Paper: “Base4NFDI Services and EOSC: Guidance for Interoperability”, Version 1’. https://doi.org/10.5281/ZENODO.13946300. While you do not have to meet any requirements for EOSC compatibility and interoperability in the Initialisation Phase, yet, you should at least become aware of them. The aim with regard to EOSC during the Initialisation Phase is to raise awareness and be prepared. The whitepaper suggests the following timeline for EOSC interoperability: The TA1 team can support you with any questions. The Base4NFDI team will furthermore discuss possible integration objectives with you during the Service Teams’ Jour fixes so that you can add this to your planning and proposals for succeeding phases. 11 Furthermore, Base4NFDI will provide news items on this topic, e.g. “Base4NFDI Services and EOSC/International Interoperability” (URL: https://base4nfdi.de/?view=article&id=144&catid=8, last accessed: October 28, 2025). For all news items visit the Base4NFDI News Archive. Base4NFDI Service Design Guide – 10.5281/zenodo.16306727 9 3.3 FAIR Basic Services An important aspect to tackle early on is the FAIRness of the services – basic services should be FAIR-by-Design. There are several ways to addres~~s the FAIRness of a service. In the following, we present some approaches, how this could be tackled. Consider if any of these dimensions are useful goals for your service. The most important distinction one can make is that services should either enable or enhance the FAIRness of any research data they process (if applicable) or that they or their related resources should be FAIR themselves. 3.3.1 FAIR-enabling Services The following framework gives recommendations for service providers. These recommendations shall help them to improve their services to make them FAIR-enabling on a technical and a social level. A FAIR-enabling service would be one that increases the FAIRness of data it hosts or processes, or one that facilitates a specific FAIR principle. During the Initialisation Phase, the framework may help you to evaluate which measures could be undertaken to make your basic service FAIR-enabling and guide your future development in a way that your basic service will contribute to a FAIR research data infrastructure. Many of the aspects mentioned by this framework are good suggestions to follow for any service, not only those that try to enable FAIRness. They also touch upon aspects that are discussed in other sections of this guide (e.g. user experience, service quality, communication, legal). [Ramezani et al. 2027] Ramezani, S. et al. (2021) ‘D2.7 Framework for assessing FAIR Services’. https://doi.org/10.5281/ZENODO.6656431. During the FAIRsFAIR project, there were also some guidelines published on how to make a data repository align with the FAIR principles. These are useful even if the basic service you are developing is not a data repository. [Behnke et al 2020] Behnke, C. et al. (2020) ‘D2.3 Set of FAIR data repositories features’. https://doi.org/10.5281/ZENODO.5361952. 3.3.2 FAIR Software and Software Metadata and Quality If your basic service development includes software development, you are required to open up the source code of the service for reuse in a FAIR fashion. The following article provides an adaptation of the FAIR principles to research software and discusses how to increase the FAIRness of archived code. [Barker et al 2022] Barker, M. et al. (2022) ‘Introducing the FAIR Principles for research software’, Scientific Data, 9(1), p. 622. https://doi.org/10.1038/s41597-022-01710-x (in particular section 2). Base4NFDI Service Design Guide – 10.5281/zenodo.16306727 16 4.3.2 Interfaces, Data Formats and Communication Protocols A key factor for the reusability of a service is its application programming interface (API). Well document the API so that users, in particular other developers, can easily oversee the structure of the data provided by the service and the offered calls and actions. It should be clear which types of endpoints are available and which parameters can be set for requests. If available, implement a standardised API for the application area of a service. For web services, the Representational State Transfer (REST) architectural style could be adopted using standard HTTP methods to perform operations on resources, which are identified by unique Uniform Resource Identifiers (URIs). If no standardised, quickly implementable API is available, start with the API design early. For its documentation, we recommend to follow the OpenAPI specification. If you provide several versions of the API (which would be recommended if breaking changes are introduced that affect backward compatibility), document each version. Generally, keep the documentation up to date. If your service provides access to structured data, a SPARQL endpoint could be an alternative or supplement. A SPARQL endpoint allows clients to query the service's data directly using the SPARQL query language. This allows users to make very flexible requests and retrieve only the data they need with customized, to-the-point queries that are not limited to the pre-defined API routes (as with REST APIs). This is particularly useful for exposing data that follow the Resource Description Framework (RDF) model, as SPARQL is the standard query language for RDF. Here it is just as crucial as for REST APIs to have good documentation on the underlying data model, patterns and vocabularies that shape the knowledge graph, so that it is easier for users to utilize the endpoint. In both cases, you could consider employing tools that help explore the endpoints, like Swagger, Yasgui, visual query helpers or just valid example queries. [OpenAPI-WhatIs?] OpenAPI Initiative (no date) What is OpenAPI? URL: https://www.openapis.org/what-is-openapi (last accessed: October 28, 2025). [OpenAPI-Learn] OpenAPI Initiative (2023) OpenAPI – Getting started, and the specification explained. URL: https://learn.openapis.org/ (last accessed: October 28, 2025). [OpenAPI-Spec311] OpenAPI Initiative (2024) OpenAPI Specification v3.1.1. URL: https://spec.openapis.org/oas/latest.html (last accessed: October 28, 2025). [OpenAPI-Examples] OpenAPI Initiative (2023) Example API Descriptions. URL: https://learn.openapis.org/examples/ (last accessed: October 28, 2025). [KGI4NFDI 2025] KGI4NFDI (2025) Apache Jena, QLever, Virtuoso and Wikibase Knowledge Graph Guidelines. URL: https://kgi4nfdi.github.io/Guidelines/ (last accessed: October 28, 2025). The APIs should be as open as possible for easier integration to other services. Where openness is not possible, e.g. due to accessibility restrictions, implement proper authentication Base4NFDI Service Design Guide – 10.5281/zenodo.16306727 17 and authorisation mechanisms. It should be easy for legitimate users and use cases to gain access to the API. For reporting to DFG, user numbers and other KPIs are usually required. Please consider this in the API design if your service will have many programmatic requests. Any data provided or processed by your service should be offered in well-known, established data formats (e.g. json, json-ld) and common communication protocols (https, ftp) so that they can be easily processed by the majority of users of your basic service. Since scientific data need to follow high standards with regard to trustworthiness and reproducibility, mechanisms to support data provenance tracking should be implemented where appropriate. 4.3.3 Service Performance, Health and Delivery During service design, already think about the service performance and scalability: how can your measure these attributes and improve them when you roll the service out to communities beyond the initial test users? 15 In the course of the Initialisation Phase, try to become more aware of such non-functional requirements, define and document them so that you can achieve service quality for a growing user base and new usage scenarios. To be able to check the service health, plan for monitoring and logging capabilities needed to identify issues and unreliable service components: This also helps you to check up on and maintain the service’s availability. You should get a feeling of how many interruptions of the service are acceptable to your users and how much time it needs to be accessible. Reduce downtimes and make the service more robust, by planning in redundancies or load balancing algorithms to handle exceptional traffic, ensure scalability or to provide failover coverage. Once the service progresses and gains users, your own development activities should not reduce the availability of the service. Set up two to three separate environments on which the service can run – at least a testing and a productive environment are required. A development environment is useful in addition, if multiple developers are involved. Use a version control tool to update your code and handle releases (e.g. with semantic versioning). Use the test environment to mature new features and roll out only well-tested features to your users. If a release still negative effects the productive system, the tiered structure enables an easy rollback and resetting the service to a stable release. Where possible, implement automated workflows. When the service depends on third-party service components, analyse the risks associated with such dependencies and address them in your service design. Incorporate, for example, mitigation strategies or components that increase resilience and minimize potential disruptions. The design should already be robust enough to withstand potential failures or changes within those third-party components. 15 E.g., you could measure the response times, the number of requests the service can handle per unit of time, etc. For more suggestions on key performance indicators see the supplement notes_on_kpis.pdf (download) attached to Schäfer-Neth et al. 2025. Base4NFDI Service Design Guide – 10.5281/zenodo.16306727 18 4.3.4 Testing Providing a satisfactory service also implies testing. While testing and piloting (cf. Kuper & Plomin 2025) provides valuable insights for the functional service development and usability, more systematic tests are required to guarantee the overall functionality of the productive system. Consider implementing unit tests (testing of individual components in isolation) and integration tests (testing of interaction of components), automating such tests and dealing with the test results. Proper testing requires documenting and, if necessary, updating test cases and the expected behaviour of the service or its components. To perform tests, you may also require test data on which tests can be performed. With such documentation, testers will be able to evaluate whether a test was successful or failed, and to document the test results. Let tests target functionality and features, but also quality attributes of the service (e.g. performance) and system security. Changes to a productive service should only get clearance, once tests are successful, i.e. all critical remaining issues are resolved. This may require several iterations of testing and patching. [Myers 2012] Myers, G.J. (2012) The art of software testing. 3rd ed. Hoboken, N.J: J. Wiley & Sons. ISBN: 978-1-118-13315-6. 4.3.5 Service Security Self-developed as well as third party components must contribute to the overall information and cyber security of the service. Depending on the type of service and the data it contains or processes, there are different security requirements. Services for science should reach a very high level of trustworthiness and leave no doubt about the integrity of their data. When designing the service, try to identify potential security threats within your design and plan for countermeasures and mitigation strategies where such risks cannot be avoided. Even when prototyping, simple measures can already be implemented right from the start, e.g. enforcing strong passwords, multi-factor authentication, role-based access control following the principle of least privilege, limitation of requests permitted per time frame, input validation or data encryption for data exchange. In later phases within the Base4NFDI funding framework, you need to implement security measures that are appropriate for the required level of protection of the service and that are derived from a systematic risk analysis. Consider that the security of your service depends on your institutions’ overall IT security strategies. Follow the institutions’ instructions and recommendations by its IT experts. For productive operation, you should set up continuous security monitoring to identify security incidents and to respond to them in due time. Regularly monitor and update third-party libraries and frameworks. Many vulnerabilities come from outdated components with known security flaws. The topic of security is too broad to discuss in detail here. An internationally accepted series of standards to follow is the ISO/IEC 27000 series. If you need a structured overview and entry point to the topic, use the IT Grundschutz 2023 by the German Federal Office for Base4NFDI Service Design Guide – 10.5281/zenodo.16306727 19 Information Security (BSI). It gives a very good introduction to security-related topics, potential risks and requirements that must or should be met. In particular, you will find an overview of basic threats and a large number of building blocks to reduce or handle such threats. These address the technological as well as the organisational level. For software and web services we recommend the building blocks CON.2 Data Protection, CON.3 Backup Concept, CON.8 Software Development (in particular CON.8.A5 Secure System Design), CON.10 Development of Web Applications, DER Detection and Reaction, OPS.1.1.6 Software Tests and Approvals and OPS.1.1.3 Patch and Change Management and – if applicable – OPS 2.2 Cloud Usage and 2.3 Use of Outsourcing. For highly developed and professionalised services that are deeply integrated into their operating institutions, you should also consider if the service requirements are well aligned to ORP.3 Awareness and Training in Information Security. [IT Grundschutz 2023] Bundesamt für Sicherheit in der Informationstechnik (BSI) (2023) IT-Grundschutz-Kompendium. 6th edn. Köln: Reguvis. URL: https://s.gwdg.de/2O2p6v (last accessed: October 28, 2025). ● The download page for the document also links to related resources16: ○ checklists for all Grundschutz building blocks ○ a matrix plotting the potential threats against the building blocks ○ mapping of IT Grundschutz and related BSI standards to selected standards from the ISO/IEC 27000 series The BSI website offers to explore security topics from different perspectives, e.g. recommendations based on security targets, recommendations based on threats, or from the perspective of specific topics like AI, cryptography, or others. Include plans for the restoration and continued operation of your service after undesired events into your design: you can implement them in later stages of development. Focus on high-probability risks first, i.e. events that may likely occur and affect the availability of the service during “days as usual” without any major catastrophes or crises happening. 4.4 Communication-related Aspects of Service Design 4.4.1 Service Website and Communication Channels Your service design should also include communication-related aspects. Base4NFDI creates a project page for your service on the Base4NFDI website 17 , providing contact information, service description, info about project team, current funding phase and outputs as well as an overview over events related to your service 18 . In addition, set up a separate service 16 If no link is provided look for “Weiterführende Informationen (Edition 2023)”. 17 URL: https://base4nfdi.de/projects (last accessed: October 28, 2025) 18 See for example the Base4NFDI project page for PID4NFDI: https://base4nfdi.de/projects/pid4nfdi (last accessed: October 28, 2025) Base4NFDI Service Design Guide – 10.5281/zenodo.16306727 20 homepage. Base4NFDI provides a Mkdocs and a Hugo template for a GitHubor self-hosted page to promote your service. Base4NFDI can provide a domain for it. [Ritter et al. 2024] Ritter, X. et al. (2024) ‘Base4NFDI Website Policy’. https://doi.org/10.5281/ZENODO.14245434. Users of your service should know how to contact you, get support and receive information about the service. Establish channels to reach out to your users, e.g. in case of updates or errors or anything else they need to know. Define communication and support channels that you deem appropriate. We recommend setting up a mailing list but it may also be feasible to have a channel on the NFDI Rocket Chat to get in touch with your NFDI user base quickly. To reach users beyond the NFDI it would be feasible to set up social media accounts where users, who are not currently part of an NFDI consortium, a section, or a directly affiliated institution, may discover your service. You are also free to choose other, more elaborate pathways (e.g. a helpdesk) – in any case, you should actively monitor any channels you establish and be responsive to them. 4.4.2 Change Management and Communication An important part of your user-related communication concerns the announcement and management of changes –draft a strategy on how this will be handled for the basic service. Even in an early prototype stage, we recommend to notify users if changes are made to the live service (especially if these involve service downtimes). Try to anticipate possible consequences those changes may have on your users. If you are not able to do so (which is completely understandable), make users aware of planned changes in advance so that they have the opportunity to respond, adapt their own plans and estimate the time required to adjust. Wherever possible, try to enable backwards-compatibility. If this is not possible, provide comprehensible information about breaking changes. 4.5 Governanceand Compliance-related Aspects of Service Design In chapter 4.1 Procedural Aspects of Service Design, we already discussed workflow aspects – those relating to user-interactions and those relating to service operation. The latter are closely related to the governance of the service and its development. 4.5.1 Assigning Tasks and Responsibilities Sketch ownership, roles and responsibilities in the design and fill them by actual people in the development process – in particular when the service reaches a productive state. This enables you to enforce policies for the service development and have clear responsibilities for decisions concerning the service and any changes to it. A responsibility assignment matrix (RACI matrix) is a good tool to document these responsibilities for the service’s developmental and operational phase. It splits an operation or project into several tasks and distinguishes roles to be involved for different reasons. Base4NFDI Service Design Guide – 10.5281/zenodo.16306727 21 Role Task Role 1 (e.g. software developer) Role 2 (e.g. product owner) Task 1 R(esponsible) = person is assigned to the task and responsible for its completion A(ccountable) = person has ownership over the task and makes the final decision Task 2 C(onsulted) = person must be consulted before a decision is made I(nformed) = person must be informed that a decision has been taken Again, not all responsibilities need to be final in the service design draft or even by the end of the Initialisation Phase –update and refine them as the service matures. In the beginning, the focus may be more about development; at the end of the service development, it must also touch upon issues of sustainability like long-term funding, community governance, maintenance etc. In the early stages, it can guide the processes set up by you as a team. 4.5.2 Compliance Compliance with regulatory, legal, organisational and ethical requirements is a quality attribute of your service. In particular, we would like to bring your attention to 1) issues of licensing/ license compatibility, 2) the General Data Protection Regulation (GDPR) and 3) accessibility. The first two will be discussed in the following, while 4.2 User-related Aspects of Service Design already addressed accessibility. 4.5.2.1 Licenses and License Compatibility When re-using different materials or software for your service, make sure that their licenses are open, permissive and compatible (cf. Czerniak et al. 2025). The Licensing Assistant by the European Commission and its Compatibility Checker are useful tools to check if the licenses of components are compatible. If you want a more programmatic approach to ensure license compatibility of software from different sources, we recommend REUSE. [FSFE 2025] Free Software Foundation Europe e.V. (2025) REUSE Software. URL: https://reuse.software/ (last accessed: October 28, 2025).  API: https://api.reuse.software/ [Haerter 2025] Haerter, A. (2025) ‘FSFE REUSE: Einfache Lizenzund Quellenverwaltung für Software-Projekte. Vortrag bei der Gulaschprogrammiernacht 23’. URL: https://media.ccc.de/v/gpn23-268-fsfe-reuse-einfache-lizenz-undquellenverwaltung-fr-software-projekte (last accessed: October 28, 2025). [Haerter 2025b] Haerter, A. (2025) ‘Making sense of software licensing with FSFE REUSE: A beginner’s guide for open source developers. Post at fedora Magazine’. URL: https://fedoramagazine.org/beginners-guide-for-opensource-developers-for-software-licensing-with-fsfe-reuse/ (last accessed: October 28, 2025). Base4NFDI Service Design Guide – 10.5281/zenodo.16306727 22 4.5.2.2 Personal Data and Protection In the Initialisation phase, Base4NFDI will ask you to set up a website where users can learn more about your project and the service you are trying to establish. The website must be compliant to GDPR if visitors can use it to contact you, and thereby provide personal data. Ritter et al. 2024 provide guidance on setting up the page and on designing a privacy policy. Identifying all GDPR-related facts to be processed by your service is a unique undertaking – we recommend getting in touch with your data protection officer (DPO) when drafting the service design. They help identify all relevant aspects and can provide you with templates for a data protection concept and a data protection policy for your web service. It makes sense to start the data protection concept early to have sufficient time for clarifications with the DPO at your institution. The service design documentation should also elaborate how personal data – if any – can be protected by technical and organisational measures (TOMs), and how requests for the deletion of personal data will be handled. Implement data protection by design and default. 5 Conclusion: Don’t Panic! Service design is the process that creates, maintains and improves the value of a service for both service users and providers – accordingly, lots of groundwork for your service is covered by this very task. This guide’s intention is to help you navigate the jungle of service design aspects to consider. It is supposed to enable you to organise all processes, technologies and interactions that are essential for the delivery of your service. It shall prevent you from missing any important aspects. Remember: Service design should be performed throughout the entire lifecycle of a service – the design grows iteratively. Do not be too perfectionistic and do not forget: In the Initialisation Phase, you are supposed to make a service design draft that guides you and can be improved and detailed later. Use this guide to pick the most relevant dimensions for the type of service you are trying to establish and if you do not feel comfortable with any of the dimensions sketched here, see this as an opportunity to address them in your work plans in your Integration or Ramp-up Phase proposals. Base4NFDI Service Design Guide – 10.5281/zenodo.16306727 23 Image Credits Puzzle icon by Yudhi Restu on Flaticon User interface icon by Iconjam on Flaticon Best seller icon by Hazicon on Flaticon Cogs icon by Prosymbols Premium on Flaticon Usability icon by Bharat Icons on Flaticon Agreement icon by Uniconlabs on Flaticon