Fallstudie für eine internationale Forschungsorganisation

Wie ein zentraler Content Hub internationale Websites, gemeinsame Inhalte und lokale redaktionelle Verantwortung verbindet

Dutzende Länder-, Fach- und Themenangebote müssen Inhalte in mehreren Sprachen veröffentlichen. Viele Redakteurinnen und Redakteure arbeiten mit unterschiedlichen Zuständigkeiten. Zentrale Kommunikation, regionale Vertretungen und wissenschaftliche Fachbereiche benötigen gemeinsame Inhalte – aber auch eigene redaktionelle Hoheiten.

Die technische Aufgabe besteht deshalb nicht darin, möglichst viele Websites zu bauen. Sie besteht darin, die Komplexität an einer Stelle beherrschbar zu machen.

Ein Content Hub statt vieler isolierter Systeme

Eine klassische Multisite-Landschaft würde für jedes Angebot ein eigenes System bereitstellen. Inhalte, Funktionen und Aktualisierungen würden sich zwangsläufig vervielfachen. Mit jeder weiteren Website stiegen Wartungsaufwand und Abstimmungsbedarf.

Das sinnvollere Zielbild ist ein zentraler Drupal Content Hub. Er verwaltet strukturierte Inhalte, Übersetzungen, Medien, Metadaten und Beziehungen an einer gemeinsamen Stelle. Websites, Portale und weitere Anwendungen greifen auf diesen Bestand zu und spielen ihn entsprechend ihrer Aufgabe aus.

Ein wissenschaftlicher Beitrag kann dadurch auf der zentralen Website erscheinen, von einem Länderangebot übernommen und in einem thematischen Portal ergänzt werden. Der gemeinsame Ursprung bleibt nachvollziehbar. Inhalte müssen nicht kopiert und anschließend an mehreren Stellen gepflegt werden.

Gemeinsame Grundlage, lokale Hoheiten

Zentralisierung darf nicht bedeuten, dass jede redaktionelle Entscheidung durch eine zentrale Stelle laufen muss.

Das Berechtigungskonzept unterscheidet deshalb zwischen gemeinsamen und lokalen Verantwortlichkeiten. Die zentrale Redaktion kann verbindliche Inhalte, Inhaltsmodelle und Publikationsregeln bereitstellen. Regionale oder fachliche Redaktionen entscheiden innerhalb ihres Zuständigkeitsbereichs über Übersetzungen, Ergänzungen und eigene Veröffentlichungen.

Drupal bildet diese Hoheiten über Rollen, Rechte, redaktionelle Bereiche und definierte Workflows ab. Freigaben können je nach Inhalt unterschiedlich verlaufen. Ein Veranstaltungshinweis benötigt einen anderen Prozess als eine wissenschaftliche Publikation oder eine institutionelle Stellungnahme.

Eine gemeinsame Authentifizierung schafft einen einheitlichen Zugang. Die eigentlichen Rechte bleiben dennoch präzise auf Fachbereich, Sprache, Region und Inhaltstyp begrenzt.

Headless, wo die Trennung einen Vorteil schafft

Drupal übernimmt in diesem Modell die redaktionelle und strukturelle Verantwortung. Die Frontends können davon technisch entkoppelt arbeiten.

Diese Headless-Architektur ist kein Selbstzweck. Sie ist sinnvoll, wenn unterschiedliche Websites, Anwendungen oder Ausgabekanäle auf dieselben Inhalte zugreifen sollen. Sie ermöglicht eigenständige Frontends, ohne redaktionelle Strukturen mehrfach aufzubauen.

Wo eine vollständige Trennung keinen Vorteil bietet, können klassische Drupal-Komponenten oder Progressive Decoupling eingesetzt werden. Die Architektur folgt der Aufgabe – nicht einem technischen Dogma.

Eine Änderung – gezielt überall aktualisiert

Ändert eine Redaktion beispielsweise den Titel eines Forschungsprojekts, eine Kontaktperson oder einen Veranstaltungstermin, soll diese Änderung automatisch in allen betroffenen Angeboten erscheinen.

Die Redakteurin oder der Redakteur bearbeitet den Inhalt einmal im zentralen Content Hub. Nach der Freigabe erkennt das System, welche Länder-, Fach- oder Themenangebote diesen Inhalt verwenden. Nur diese Angebote werden aktualisiert. Andere Websites und Inhalte bleiben unberührt.

Die Redaktion veröffentlicht wie gewohnt. Das System verteilt die freigegebene Änderung an die betroffenen Länder-, Fach- und Themenangebote und zeigt, wo sie erfolgreich übernommen wurde. Ist ein Ziel vorübergehend nicht erreichbar, wird die Übertragung automatisch wiederholt.

Für die Organisation bedeutet das: Inhalte werden nur einmal gepflegt, Änderungen bleiben nachvollziehbar und die einzelnen Angebote behalten dennoch ihre klar definierten Zuständigkeiten.

Suche über Sprachen und Fachgebiete hinweg

Eine internationale Forschungsorganisation veröffentlicht nicht nur Seiten, sondern auch Publikationen, Projekte, Veranstaltungen, Personen und Messdaten.

Eine zentrale Suche muss diese unterschiedlichen Inhalte verstehen. Apache Solr ermöglicht sprachabhängige Indizes, Fachfilter, Synonyme und gewichtete Suchergebnisse. Nutzerinnen und Nutzer können den Gesamtbestand durchsuchen oder die Ergebnisse gezielt auf Sprache, Region, Forschungsgebiet oder Inhaltstyp begrenzen.

Auch hier bleibt die redaktionelle Hoheit erhalten: Nicht jeder intern verfügbare Inhalt darf automatisch in jedem öffentlichen Angebot erscheinen.

Ein Designsystem für unterschiedliche Auftritte

Eine gemeinsame Plattform muss nicht zu identisch aussehenden Websites führen.

Das Designsystem definiert wiederverwendbare Komponenten, Zustände und Gestaltungsregeln. Design Tokens steuern Farben, Typografie und Abstände. In Storybook werden Komponenten unabhängig von einer einzelnen Website entwickelt, geprüft und dokumentiert.

Länder- und Themenangebote können dadurch eine eigene visuelle Ausprägung erhalten, ohne technisch wieder bei null zu beginnen. Barrierefreiheit wird nicht nachträglich auf jeder Website einzeln korrigiert, sondern bereits in den gemeinsamen Komponenten abgesichert.

Fachbereiche behalten die Hoheit über ihre Daten

Forschungs-, Publikations- und Messdaten entstehen häufig in spezialisierten Systemen. Sie vollständig in Drupal nachzubauen, wäre weder wirtschaftlich noch fachlich sinnvoll.

Stattdessen werden die Systeme über klar definierte Schnittstellen angebunden. Drupal übernimmt die redaktionelle Einordnung und Präsentation. Das jeweilige Fachsystem bleibt die maßgebliche Quelle seiner Daten.

Diese Trennung verhindert doppelte Datenpflege und schafft klare Verantwortlichkeiten.

Skalierbarer Betrieb ohne dauerhafte Überdimensionierung

Die Infrastruktur wird nicht nach der durchschnittlichen Nutzung, sondern nach dem möglichen Lastprofil entworfen.

Häufig aufgerufene Inhalte werden schnell ausgeliefert, ohne das zentrale Redaktionssystem bei jedem Seitenaufruf erneut zu belasten. Steigen die Zugriffszahlen, kann die Plattform zusätzliche Kapazität bereitstellen. Datenbank, Suche und Frontend lassen sich dabei unabhängig voneinander skalieren.

So kann dieselbe Architektur kleinere Länderangebote wirtschaftlich betreiben und zugleich starke Lastspitzen auf zentralen Plattformen abfangen.

Web Application Firewall, automatisierte Backups, Monitoring, dokumentierte Wiederherstellungsprozesse und reproduzierbare Deployments gehören dabei zum Betriebskonzept – nicht zu einer späteren Ergänzung.

Komplexität wird nicht beseitigt, sondern geordnet

Eine internationale Plattform bleibt fachlich komplex. Gute Architektur versucht nicht, diese Realität zu verdecken.

Sie schafft klare Zuständigkeiten, gemeinsame Standards und verlässliche technische Grenzen. Inhalte können zentral genutzt werden, ohne lokale Verantwortung aufzugeben. Neue Websites und Kanäle entstehen aus einer vorhandenen Grundlage. Sicherheit, Barrierefreiheit und Betrieb müssen nicht für jedes Angebot neu gelöst werden.

Der zentrale Content Hub wird damit nicht nur zum technischen Backend. Er bildet die organisatorische Struktur der Forschungsorganisation ab – gemeinsam, international und dennoch differenziert. Bei E-Fork beginnt die Konzeption deshalb mit den redaktionellen Hoheiten, Inhaltswegen und Abhängigkeiten. Erst daraus entsteht die technische Architektur. Wer eine bestehende Plattform weiterentwickeln will, sollte diese Verantwortlichkeiten vor der Systemauswahl klären.

• Warum ein zentraler Content Hub statt einer klassischen Multisite?

  Weil gemeinsame Inhalte nur einmal gepflegt werden. Länder-, Fach- und Themenangebote nutzen dieselbe verlässliche Quelle, können Inhalte aber gezielt übernehmen, übersetzen oder ergänzen. So entstehen keine voneinander abweichenden Kopien.

• Wie bleiben lokale redaktionelle Hoheiten erhalten?

  Rollen, Rechte und Freigaben werden pro Land, Sprache, Fachgebiet und Ausgabekanal definiert. Zentrale Standards schaffen den gemeinsamen Rahmen; die zuständigen Redaktionen entscheiden weiterhin, welche Inhalte sie veröffentlichen.

• Wie werden Inhalte zwischen Ländern und Sprachen verteilt?

  Strukturierte Inhalte werden über definierte Schnittstellen bereitgestellt. Redaktionen können sie übernehmen, übersetzen, regional anpassen oder bewusst auslassen. Herkunft, Version und Freigabestatus bleiben nachvollziehbar.

• Wie lässt sich eine bestehende Plattform schrittweise übernehmen?

  Zunächst werden Inhalte, Verantwortlichkeiten, Schnittstellen und technische Abhängigkeiten erfasst. Anschließend erfolgt die Übernahme in klaren Etappen. Bestehende Angebote können während des Übergangs weiterarbeiten, bis Inhalte und Funktionen verlässlich auf die neue Plattform umgestellt sind.

• Kann die Plattform klein starten und international wachsen?

  Ja. Neue Websites, Sprachen, Frontends und Fachsysteme werden schrittweise an die gemeinsame Grundlage angebunden. Betrieb, Suche und Auslieferung lassen sich unabhängig skalieren – vom kleinen Themenangebot bis zur internationalen Plattform.