Was ist Forschungssoftware-Engineering?

Research Software Engineering (RSE) ist die Disziplin der Anwendung professioneller Software-Engineering-Praktiken – Versionskontrolle, Tests, Code-Reviews, kontinuierliche Integration, Dokumentation und langfristige Wartung – auf den Code, der der wissenschaftlichen Forschung zugrunde liegt. Wenn Sie jemals drei Wochen damit verbracht haben, ein Molekulardynamik-Analyseskript zu debuggen, das nur auf dem Laptop eines Postdocs läuft, oder versucht haben, ein veröffentlichtes Ergebnis aus einem Tarball von undokumentiertem Python zu reproduzieren, sind Sie bereits auf das Problem gestoßen, das Research Software Engineering lösen will. In diesem Artikel wird erläutert, was RSE ist, wie es sich von benachbarten Rollen unterscheidet, was ein Research Software Engineer tatsächlich tagtäglich tut und wie Sie entscheiden können, ob Ihre Gruppe einen benötigt.

Die Kurzdefinition und warum sie umstritten ist

Der Begriff „Research Software Engineer“ wurde im Vereinigten Königreich um 2012 geprägt, hauptsächlich durch die Arbeit des Software Sustainability Institute, um einer wachsenden Gruppe von Menschen einen Namen zu geben, die weder traditionelle Forscher noch IT-Supportmitarbeiter waren. Sie schrieben Code, der für die Forschung unerlässlich war, aber ihr beruflicher Werdegang, ihre Berufsbezeichnungen und ihre Anerkennung passten in keines dieser Raster.

Die häufig zitierte Arbeitsdefinition besagt, dass ein Research Software Engineer jemand ist, der Folgendes kombiniert:

1. Ein professionelles Verständnis von Software-Engineering – Design, Tests, Versionskontrolle, Deployment, Wartung.
2. Eine aktive Rolle in der Forschung – Beiträge zu Forschungsfragen, Publikationen und Förderanträgen, nicht nur die Umsetzung einer von jemand anderem vorgegebenen Spezifikation.
3. Tiefe Auseinandersetzung mit mindestens einem Forschungsbereich – genug, um die Wissenschaft, die Daten und die Einschränkungen zu verstehen.

Der umstrittene Teil ist die Grenze. Ist ein Bioinformatiker, der ein weit verbreitetes R-Paket pflegt, ein RSE? Ist ein Physiker, der Simulationscode für seine eigenen Arbeiten schreibt, ein RSE?

Ist der „Datenmanager“ einer Forschungsgruppe, der viel Python schreibt, ein RSE? Es gibt keine Lizenzierungsstelle und keine allgemein anerkannte Zertifizierung, daher wird die Bezeichnung pragmatisch angewendet. In der Praxis ist das Unterscheidungsmerkmal die Orientierung: RSEs behandeln Software als erstklassiges Forschungsergebnis und langlebiges Artefakt und nicht als Wegwerfmittel für eine einzelne Publikation.

RSE vs. benachbarte Rollen: ein Vergleich

Der schnellste Weg, RSE zu verstehen, besteht darin, zu sehen, wo es im Verhältnis zu den Rollen steht, mit denen es oft verwechselt wird. Die folgende Tabelle ist eine Heuristik, keine Taxonomie – reale Personen verwischen diese Grenzen ständig.

Verwandte: DataCamp — Interaktive Python- und Data-Science-Kurse, bei denen Sie direkt im Browser programmieren.

Dimension	Research Software Engineer	Traditioneller Forscher (der codiert)	IT / Research Computing Support	Data Scientist / Analyst
Primärer Output	Wartbare, wiederverwendbare Software	Publikationen und Erkenntnisse	Funktionierende Infrastruktur und Dienste	Modelle, Analysen, Entscheidungen
Code-Lebensdauer	Jahre bis Jahrzehnte; versionierte Releases	Oft an ein Projekt/eine Publikation gebunden	Lebensdauer des Dienstes; oft vom Anbieter verwaltet	Oft projektgebunden
Typische Fähigkeiten	Softwaredesign, Testing, CI/CD, HPC, Domänenwissenschaft	Domänenwissenschaft, Methoden, Statistik	Systemadministration, Networking, Scheduler, Sicherheit	Statistik, ML, Domänendaten
Bezug zur Forschungsfrage	Definiert und prägt sie mit	Besitzt sie	Bedient sie indirekt	Beantwortet oft eine gestellte Frage
Erfolgsmetrik	Akzeptanz, Reproduzierbarkeit, Zitate der Software, Nachhaltigkeit	Publikationen, Grants, Impact	Uptime, Benutzerzufriedenheit, Kosten	Business-/Forschungseinblicke
Karriereweg	Oft hybrid; manchmal permanent als Staff Scientist	Faculty / Postdoc-Leiter	IT-Leiter	Industrie oder Wissenschaft

Die wichtigste Erkenntnis: Ein RSE ist weder „ein Forscher, der zufällig gut im Programmieren ist“, noch „eine IT-Person, die bei Python hilft“. Die Rolle wird dadurch definiert, dass man die Software als Forschungsprodukt besitzt, während man gleichzeitig in der Wissenschaft verankert bleibt.

Was ein Research Software Engineer eigentlich macht

Die Stellenbeschreibungen variieren enorm, aber die Arbeit gruppiert sich in erkennbare Kategorien. Eine realistische Woche könnte vier oder fünf davon betreffen.

1. Erstellung und Wartung von Forschungssoftware

Das ist der Kern. Es umfasst das Entwerfen von APIs für Simulationscodes, das Refactoring eines monolithischen Analyseskripts in eine getestete Bibliothek, das Packaging von Tools für die Verteilung auf PyPI oder conda-forge und das Verhindern, dass Abhängigkeiten kaputtgehen. Für eine Molekulardynamikgruppe könnte dies bedeuten, ein GROMACS- oder LAMMPS-Analyse-Toolkit zu pflegen oder eine NumPy/HDF5-Pipeline zu schreiben, die Trajektoriendaten streamt, ohne Terabytes in den RAM zu laden.

Einen Blick wert: Coursera Plus — Ein Abonnement für von der Universität unterstützte Python- und Data-Science-Zertifikate.

2. Forschung reproduzierbar machen

RSEs sind oft die Personen, die environment.yml, pyproject.toml, Container-Images (Docker, Singularity/Apptainer) und Workflow-Manager (Snakemake, Nextflow, Common Workflow Language) in ein Labor einführen. Das Ziel ist, dass ein Ergebnis zwei Jahre später auf einer anderen Maschine von einer anderen Person regeneriert werden kann. Hier überschneidet sich RSE stark mit der Reproduzierbarkeitsbewegung und den FAIR-Datenprinzipien.

3. Performance und Skalierung

Wissenschaftlicher Code muss häufig schneller oder in größerem Maßstab ausgeführt werden. RSEs profilieren Code, vektorisieren NumPy-Operationen, parallelisieren mit MPI oder OpenMP, portieren Hot-Loops nach C/C++/Fortran oder verwenden Numba/Cython und optimieren I/O – HDF5-Chunking- und Komprimierungsentscheidungen können beispielsweise die Laufzeit bei der Trajektorienanalyse dominieren. Sie helfen Gruppen auch dabei, HPC-Cluster und GPUs effektiv zu nutzen.

4. Beratung und Schulung

Viele RSEs bieten Sprechstunden, Code-Reviews und Workshops an (Software Carpentry, HPC Carpentry, domänenspezifische Schulungen). Ein großer Teil ihrer Wirkung beruht darauf, dass sie Forschern beibringen, selbst besseren Code zu schreiben, anstatt alles für sie zu erledigen.

5. Beiträge zu Grants und Publikationen

RSEs erscheinen zunehmend als Co-Autoren und als namentlich genannte Personen in Förderanträgen, da Geldgeber mittlerweile einen Software-Nachhaltigkeits- und Managementplan erwarten. Das Schreiben dieses Plans, das Schätzen des Aufwands und die Verpflichtung zur Wartung sind typische RSE-Aktivitäten.

Wo RSEs organisatorisch angesiedelt sind

Es gibt drei gängige Modelle, jeweils mit Vor- und Nachteilen:

• Zentralisierte RSE-Gruppe (ein universitäts- oder institutsweites Team). Vorteile: gemeinsames Fachwissen, Karriereweg für RSEs, Fähigkeit, mehrere Projekte zu besetzen. Nachteile: kann weit weg von jeder einzelnen Forschungsfrage sein; Chargeback- oder Priorisierungspolitik.
• Eingebettet in eine Forschungsgruppe oder ein Labor. Vorteile: tiefer Domänenkontext, schnelle Iteration, starke Beziehungen. Nachteile: Isolation, keine Peer-RSE-Community, Risiko, dass der RSE zur allgemeinen „Reparier-meinen-Computer“-Ressource wird.
• Hybrid / Matrix. Eine zentrale Gruppe mit Mitarbeitern, die Projekten zugeordnet sind. Immer häufiger; erfordert eine klare Linienführung und Vereinbarungen zur Zeitallokation.

Das Vereinigte Königreich verfügt über eine besonders sichtbare RSE-Community mit einer jährlichen RSE-Konferenz und regionalen Netzwerken. Ähnliche Gemeinschaften gibt es in Deutschland (de-RSE), den Niederlanden, den USA und Australien. Die Society of Research Software Engineering (Society of RSE) wurde im Vereinigten Königreich als Berufsverband gegründet.

Verwandte: O'Reilly Learning Platform — Eine umfassende technische Bibliothek mit Büchern, Videos und Live-Schulungen zum Thema wissenschaftliches Rechnen.

Wie RSE mit Reproduzierbarkeit und Open Science zusammenhängt

Die Reproduzierbarkeitskrise in der Computerwissenschaft ist größtenteils ein Softwareproblem. Analysen hängen von spezifischen Bibliotheksversionen, undokumentierten Vorverarbeitungsschritten und Code ab, der nie veröffentlicht wurde. RSE-Praktiken adressieren dies direkt:

• Versionskontrolle und getaggte Releases ermöglichen es, die exakte verwendete Softwareversion zu zitieren.
• Tests fangen die stillen numerischen Fehler ab, die plausible, aber falsche Ergebnisse liefern.
• Kontinuierliche Integration stellt sicher, dass der Code auch nach Aktualisierungen von Abhängigkeiten noch funktioniert.
• Die Archivierung von Code in Zenodo oder Software Heritage gibt ihm einen DOI und ein dauerhaftes Zuhause.
• Dokumentation ermöglicht es anderen (einschließlich Ihrem zukünftigen Ich), den Code zu verstehen und wiederzuverwenden.

Die FAIR-Prinzipien für Forschungssoftware, entwickelt von der Research Data Alliance, erweitern die FAIR-Datenrichtlinien explizit auf Software. Fachzeitschriften verlangen zunehmend Code-Verfügbarkeitserklärungen, und einige fordern Code-Reviews als Teil der Publikation.

So entscheiden Sie, ob Sie einen RSE benötigen

Nicht jede Gruppe benötigt einen dedizierten RSE. Nutzen Sie diese Kriterien als groben Filter:

Leserfavorit: Dataquest — Projektbasierte Data-Science-Pfade mit geführtem Terminal und realen Datensätzen.

Sie benötigen wahrscheinlich einen, wenn:

• Software zentral für Ihre Forschungsergebnisse ist und von Personen außerhalb Ihrer Gruppe verwendet wird.
• Sie Code über mehrere Grants und Jahre hinweg pflegen und er bricht ständig zusammen.
• Sie immer wieder dieselbe Infrastruktur (I/O, Parallelität, Packaging) neu aufbauen, die andere bereits gelöst haben.
• Reviewer, Kollaborateure oder Geldgeber nach der Software-Nachhaltigkeit fragen und Sie keine gute Antwort haben.
• Ihre Gruppe viel Zeit mit Softwarewartung verbringt, die in Publikationen unsichtbar bleibt.

Sie benötigen möglicherweise (noch) keinen, wenn:

• Ihr Code wirklich Wegwerf-Code ist – eine einmalige Analyse für eine einzige Abbildung.
• Ihre Bedürfnisse durch gut gepflegte Community-Tools gedeckt sind und Sie nur Glue-Skripte schreiben.
• Sie ein Gruppenmitglied haben, das wirklich Spaß daran hat, gut darin ist und Zeit hat.

Ein Mittelweg: Stellen Sie einen Teilzeit-RSE ein, nehmen Sie an einer Core-Gruppe teil oder investieren Sie in Schulungen, um bestehende Forscher bei der Einführung von Best Practices zu unterstützen. Das schlechteste Ergebnis wäre, einen RSE einzustellen und ihn dann als Ad-hoc-IT-Support zu nutzen.

Karrierewege und wie man ein RSE wird

RSE-Karrieren sind sehr vielfältig. Einstiegspunkte sind unter anderem:

• PhD in einem computergestützten Bereich (Physik, Chemie, Bioinformatik), der sich zur Softwareseite hin entwickelt hat.
• Software-Engineer aus der Industrie, der an wissenschaftlichen Problemen arbeiten möchte.
• Forschungspersonal, das seine Softwarerolle formalisiert.

Die wichtigsten Fähigkeiten, grob in der Reihenfolge ihrer Häufigkeit:

1. Kenntnisse in Python (und oft C++, Fortran oder Julia für performance-kritischen Code).
2. Versionskontrolle mit Git, einschließlich Branching- und Code-Review-Workflows.
3. Test-Frameworks (Pytest, GoogleTest) und CI (GitHub Actions, GitLab CI).
4. Packaging und Environment-Management (Conda, Pip, Container).
5. HPC und parallele Programmierung (MPI, OpenMP, CUDA, Job-Scheduler wie Slurm).
6. Wissenschaftliche Kompetenz im Fachbereich: ausreichend, um mit Forschern auf Augenhöhe zu sprechen.
7. Kommunikations- und Lehrfähigkeiten.

Die Karriereleiter ist weniger standardisiert als in der Wissenschaft oder Industrie. Einige RSEs werden permanente Staff Scientists; einige wechseln in die Leitung des Research Computing; einige kehren in die Lehre/Forschung zurück; einige gehen in die Industrie. Das Fehlen einer klaren Leiter ist ein reales, häufig diskutiertes Problem in der Community und ein Grund, warum Berufsverbände und zentrale Gruppen wichtig sind.

Häufige Missverständnisse

• „RSE ist nur IT-Support für Wissenschaftler.“ Nein – RSEs prägen Forschungsfragen und besitzen Softwareprodukte. Der IT-Support wartet die Infrastruktur.
• „Jeder gute Programmierer kann RSE machen.“ Der Domänenkontext ist enorm wichtig. Ein brillanter Webentwickler weiß möglicherweise nicht, warum die Reihenfolge einer Gleitkomma-Summierung ein Ergebnis verändert.
• „RSEs schreiben nur Code.“ Ein großer Teil des Jobs besteht aus Beratung, Schulung und Design-Diskussionen.
• „RSE ist ein Sprungbrett zu einem ‚echten‘ akademischen Job.“ Für einige ist es das; für viele ist es eine legitime, dauerhafte Karriere.
• „Man braucht einen Informatik-Abschluss.“ Die meisten RSEs kommen aus wissenschaftlichen Domänen, nicht aus der Informatik.

Wichtige Erkenntnisse

• Research Software Engineering wendet professionelle Software-Praktiken auf Forschungscode an und behandelt Software als erstklassiges, langlebiges Forschungsergebnis.
• Ein RSE wird durch die Kombination von Software-Engineering-Skills, aktiver Forschungsbeteiligung und Domänenexpertise definiert – nicht durch eine spezifische Berufsbezeichnung oder Zertifizierung.
• RSE unterscheidet sich von IT-Support, Data Science und „Forschern, die codieren“ primär durch die Verantwortung für die Software als Produkt und deren mehrjährige Lebensdauer.
• Kernaktivitäten sind der Aufbau und die Wartung von Code, die Ermöglichung von Reproduzierbarkeit, Performance-Tuning, Beratung, Schulung sowie Beiträge zu Grants und Publikationen.
• RSEs können zentralisiert, eingebettet oder hybrid organisiert sein; jedes Modell hat reale Vor- und Nachteile in Bezug auf Kontext, Karriereweg und Priorisierung.
• Die Entscheidung, ob man einen RSE benötigt, hängt davon ab, ob Software zentral, wiederverwendet und langlebig ist – nicht allein von der Gruppengröße.

Quellen & weiterführende Literatur

• Research software engineering — Wikipedia: Research software engineering is the application of software engineering practices, methods and techniques for research software, i.e. software that was made for…
• Software engineering — Wikipedia: Software engineering is a branch of both computer science and engineering focused on designing, developing, testing, and maintaining software applications. It involves…

Häufig gestellte Fragen

Was ist Research Software Engineering in einfachen Worten?

Research Software Engineering ist die Praxis, die Software zu bauen und zu warten, auf die sich Wissenschaftler verlassen, wobei dieselben professionellen Standards – Tests, Versionskontrolle, Dokumentation, Wartung – angewendet werden, die auch kommerzielle Softwareteams nutzen. Ein Research Software Engineer arbeitet an der Schnittstelle zwischen Softwareentwicklung und einem wissenschaftlichen Fachbereich, sodass er sowohl den Code als auch die Wissenschaft versteht, der er dient. Das Ziel ist Software, die korrekt, wiederverwendbar ist und auch Jahre später noch funktioniert.

Wie unterscheidet sich ein Research Software Engineer von einem Software-Engineer?

Ein traditioneller Softwareentwickler erstellt normalerweise Produkte für Benutzer oder Kunden, und die Anforderungen werden häufig von einem Produktteam festgelegt. Ein Entwickler von Forschungssoftware arbeitet an Software, deren Zweck darin besteht, wissenschaftliche Erkenntnisse zu generieren oder zu unterstützen, wobei die Anforderungen oft explorativer Natur sind und das „richtige“ Ergebnis im Voraus unbekannt sein kann. RSEs erfordern in der Regel auch tatsächliche Domänenkenntnisse, die ausreichen, um zu beurteilen, ob ein numerisches Ergebnis physikalisch plausibel ist, und nicht nur, ob der Code ausgeführt werden kann.

Benötige ich einen Doktortitel, um Forschungssoftware-Ingenieur zu werden?

Nein, aber Domänenkenntnisse sind unerlässlich und ein Doktortitel ist eine gängige Möglichkeit, diese zu erwerben. Viele RSEs haben einen Doktortitel in Physik, Chemie, Bioinformatik oder verwandten Bereichen und sind in ihrer Arbeit auf die Softwareseite umgestiegen. Andere kommen aus der Softwareentwicklungsbranche und erlernen das Fachgebiet bei der Arbeit. Was zählt, ist die Möglichkeit, sich mit Forschern als Peer über die Wissenschaft auszutauschen, nicht die Qualifikation selbst.

Welche Programmiersprachen verwenden Forschungssoftware-Ingenieure?

Python dominiert, insbesondere bei Analyse, Skripterstellung und Glue-Code, oft neben NumPy, Pandas und HDF5-basierter I/O. Leistungskritische Komponenten werden häufig in C++, Fortran oder C geschrieben, wobei Julia und Rust auf dem Vormarsch sind. R bleibt in der Statistik und Bioinformatik wichtig, und Shell-Scripting, Make und Workflow-Sprachen wie Snakemake und Nextflow sind allgegenwärtig. Die Sprache ist weniger wichtig als die Praktiken, die sie umgeben.

Ist Forschungssoftware-Engineering eine gute Karriere?

Für Menschen, die sowohl Spaß an Wissenschaft als auch an Software haben, kann es eine hervorragende Karriere mit großer Nachfrage, abwechslungsreichen Problemen und sichtbaren Auswirkungen sein. Der größte Vorbehalt besteht darin, dass die Karrierestrukturen weniger standardisiert sind als in der Wissenschaft oder der Industrie, sodass der Aufstieg stark von der Institution und davon abhängt, ob eine zentrale RSE-Gruppe existiert. Viele RSE finden die Arbeit stabiler und besser bezahlt als Postdoc-Stellen, obwohl das Fehlen einer universellen Karriereleiter ein anerkanntes Problem ist.

Wie unterstützt Forschungssoftware-Engineering die Reproduzierbarkeit?

RSE-Praktiken machen Ergebnisse reproduzierbar, indem sie genaue Softwareversionen festlegen, Builds und Tests automatisieren, Abhängigkeiten dokumentieren und Code mit einem DOI archivieren, damit er zitiert und abgerufen werden kann. Ohne diese Praktiken hängen Analysen oft von undokumentierten Schritten und spezifischen Bibliotheksversionen ab, die später nicht rekonstruiert werden können. RSEs führen außerdem Container und Workflow-Manager ein, die eine gesamte Rechenumgebung erfassen, nicht nur den Code.

Weiterführende Literatur und maßgebliche Quellen

• Der Wikipedia-Artikel zum Thema Research Software Engineering bietet einen umfassenden Überblick und die Geschichte des Begriffs.
• Das Software Sustainability Institute (software.ac.uk) veröffentlicht ausführlich zu RSE-Definitionen, Karrieren und Community-Umfragen.
• Die Society of Research Software Engineering (society-rse.org) ist der britische Berufsverband für diesen Bereich.
• Die FAIR-Prinzipien für Forschungssoftware der Research Data Alliance erweitern die FAIR-Datenrichtlinien speziell auf Software.
• Das Journal of Open Source Software (joss.theoj.org) und das Journal of Open Research Software veröffentlichen peer-reviewte Forschungssoftware.