Key takeaways from 19 research and infrastructure institutions: Part 5 – Infrastructure and Sustainability

Over the past few months, we have taken a closer look at 19 research and infrastructure institutions from Germany, Europe and North America: their history, governance models, funding sources, strengths, potential blind spots and opportunities. These institutions vary widely: some have existed for decades, whilst others are still finding their footing; some enjoy secure, long-term funding, whilst others move from one project phase to the next. In this six-part series, we examine the findings from this analysis most relevant to the establishment of a German Research Software Institution.

When setting up a new digital research infrastructure, there is a strong temptation to want to do everything in-house: your own website, your own identity management, your own repositories, your own training platforms. This approach is understandable, as having complete control seems like the most direct route to quality. In practice, however,

this approach usually proves to be the most expensive, slowest and most fragile. A recurring finding across the institutions studied was that sustainable infrastructure is rarely built through complete self-sufficiency. Instead, successful organisations tend to rely on modular, interoperable and shared services, developing components in-house only where this creates clear added value.

A particularly impressive example comes from the National Research Data Infrastructure (NFDI). As part of the initiative for shared base services, an outstanding approach was developed: central services are provided jointly for 26 consortia. This not only saves money but also creates interoperability from which every single consortium benefits. Furthermore, a mindset is established that can be applied to other areas: whilst what everyone needs can be provided by a single entity, it can be developed and maintained as a shared resource.

Another example is the Next Generation Sequencing Competence Network (NGS-CN). Within this network, four university sequencing centres coordinate their services so that researchers encounter the same quality standards, pipelines and data flows across all projects. If one of the centres goes down, for example due to equipment failure, the others can take over without researchers having to change their workflows. This operational resilience is based on deliberate agreements, shared interfaces and a culture in which the sites see themselves not as competitors but as nodes in a shared network. Similar forms of coordination appeared across several institutions examined, suggesting that resilience is often an organisational achievement as much as a technical one.

A third finding emerging from the analysis concerns the long-term maintenance of existing software. The analysis suggests that one of the most common weaknesses in research software ecosystems is not development but maintenance. The UK’s Software Sustainability Institute (SSI) maintains a Maintenance Fund worth £4.8 million. This is specifically designed to support foundational software packages used across many research fields but which cannot be funded by any single institution alone. In Germany, the development of software is funded through project grants, but its maintenance is rarely supported. As a result, valuable software often falls into disuse because its maintenance can no longer be accommodated within any grant application.

However, the analysis also revealed several recurring pitfalls that should inform the design of any future Germany research software institution. Institutions funded exclusively by public funds are often prohibited from providing their services to non-members – a key issue arising from state aid law. What may sound like a legal technicality has significant implications for scalability. A research software institution should therefore design its membership and service structures in such a way that it remains legally flexible without jeopardising its non-profit status. Furthermore, infrastructure should be conceived in a modular way, with defined interfaces that allow for interaction with other initiatives. It should be developed collaboratively where the need is shared by many. And from the outset, it should incorporate an explicit maintenance path rather than treating maintenance as a future problem.

Shared infrastructure is not a cost compromise, but a multiplier of impact. A German research software institution should be designed in a modular way, connected to other initiatives, and built with a clear path for maintaining foundational software long after initial development has ended.