Dieser Artikel ist Teil der Reihe Informationsarchitekturen für Netzwerke von Sites und beschäftigt sich mit den Herausforderungen beim Aufbau der Multisite-Architektur der Heinrich-Böll-Stiftung.
Den Relaunch der Heinrich-Böll-Stiftung haben wir schon im September 2013 gemacht. Höchste Zeit, mal ein paar Worte dazu zu verlieren, denn „die Bölls“ – wie sie bei uns liebevoll genannt werden – sind eines der anspruchsvollsten und interessantesten Setups im ganzen Palasthotel. Das wir schnell deutlich wenn man sich die Ausmaße der Heinrich-Böll-Stiftung bewusst macht: 1 Bundestiftung, 19 Landesstiftungen über 30 internationale Büros sowie fast ein Dutzend themenzentrierte Sites. Alles in allem betreuen wir fast 60 Sites, mit fast 300 RedakteurInnen – ein sehr großes Netzwerk an Sites, mit sehr unterschiedlichen Ausrichtungen und Anforderungen.
Wie im Eingangs-Artikel zur Serie Informationsarchitekturen für Netzwerke von Sites beschrieben, stand auch dieses Projekt im Spannungsverhältnis zwischen Gemeinsamkeit und Eigenständigkeit. Auf den ersten Blick überwiegen die Gemeinsamkeiten: Für viele Aussenstehende sind die einzelnen Büros, Landesstiftungen und weiteren Sites gar nicht als eigenständige Institutionen erkennbar, sondern schlicht ein Teil der großen Heinrich-Böll-Stiftung. Das sieht von innen allerdings etwas anders aus: Hinter jeder Site steht eine eigene Redaktion, die – und sei sie noch so klein – eigene Themen und Schwerpunkte hat und diese selbstbestimmt präsentieren und organisieren möchte.
Das Projekt bestand dabei aus zwei Phasen, die das Spannungsfeld gut widerspiegeln: In der ersten Phase ging es um den Relaunch der Webseite der Bundesstiftung. Die Bundesstiftung hat mit 15.000 Inhalten und einer eigenständigen, mehrköpfigen Internetredaktion natürlich die meisten und komplexesten Anforderungen. In der zweiten Phase sollte die frisch gebaute Architektur der Bundesstiftung quasi als Blaupause allen anderen Büros und angeschlossenen Stiftungen zur Verfügung gestellt werden – und zwar so effektiv wie irgend möglich, sowohl bei der Migration als auch im Betrieb. Das bedeutete für uns zwei Dinge: Erstens mussten wir in der ersten Phase ständig die (möglichen) Anforderungen der kommenden Büros mitdenken. Und zweitens mussten wir von Anfang an alle Synergien maximieren. Unsere Lösung, um das hinzubekommen, ist „Das leere Haus“.
„Das leere Haus“
Nachdem wir die Seite der Bundesstiftung vollendet hatten, haben wir das Setup geklont/kopiert und praktisch alle Inhalte gelöscht. Übrig bleiben nur eine beispielhaft aufgebaute Startseite und eine Handvoll Beispiel-Inhalte. Ebenfalls erhalten blieb die gesamte Informationsarchitektur, sprich alle Inhaltstypen, alle Taxonomien. Dabei haben wir bei den zentralen Taxonomien (Themen, Stiftung, Regionen und Formate) auch die Terme beibehalten, bei den Tags aber alle Terme der Bundesstiftung gelöscht.
Ebenfalls Teil des leeren Hauses ist das Base-Theme für alle Stiftungen, in das wir ein paar – zuvor in Workshops definierte – gestalterische (sprich: konfigurierbare) Spielräume eingebaut haben. Diese Spielräume umfassen v.a. die Farbwelt der Site und reichen vom Grün/Orange der Bundesstiftung bis zum Türkis/Pink des Gunda Werner Instituts.
Weitere Inhalte des leeren Hauses sind z.B. der Footer der Sites, der jeweils alle anderen Sites der Heinrich-Böll-Stiftung verlinkt und dessen Hauptbestandteile aus einem zentralen Repository gespeist werden, um Aktualisierungen einheitlich ausspielen zu können. Darüberhinaus kann jeder Site-Footer (trotzdem) zusätzlich individualisiert werden.
Soll eine neue Site aufgesetzt werden, wird von der künftigen Redaktion zunächst ein kleiner Fragebogen ausgefüllt, in dem abgefragt wird, welche Funktionen des leeren Hauses aktiviert sein sollen und welche nicht (Kommentar-Funktion, Adressaten für bestimmte Systembenachrichtigungen, Kontaktformular, Integration des zentralen Kalenders). Dann wird das leere Haus kopiert, entsprechend des Fragebogens konfiguriert und ggf. noch ein Import der Altdaten vorgenommen (aus den unterschiedlichsten Systemen, in denen die jeweilige Seite zuvor steckte). Danach kann die Site auch schon der Redaktion übergeben und für den Launch vorbereitet werden. Auf diese Weise brauchen wir als technische Agentur nur wenige Personentage für das Aufsetzen und Migrieren einer neuer Site. Ohne Migration ist das je nach Individualisierungsbedarf sogar innerhalb eines bis maximal zwei Arbeitstagen zu realisieren.
Die Redaktion erhält dafür eine Site, in der auf der Seite schon viel fertig ist oder nur noch kurz angepasst werden muss. Auf der anderen Seite behält das Setup aber die volle redaktionelle Flexibilität eines ausgewachsenen Drupals: Wenn die vorgegebenen Taxonomien nicht passen, können sie einfach umgebaut werden. Hier greift v.a. der im Eingangsartikel der Serie beschrieben Aspekt der Teilbarkeit „initial geteilt, dann aber vollständig lokalisierbar“.
Gleichzeitig halten wir aber die Code-Basen aller Sites zusammen. Es gibt nur ein einziges Git-Repository, in dem Code verwaltet wird. Gleichzeitig ist aber jede Site eine eigene Installation, auf die wir (zeitlich) getrennt Code ausrollen können. Wir haben extra für dieses Projekt ein individuelles Werkzeug entwickelt, um die zentrale Codebasis automatisiert nacheinander auf alle (in der Summe inzwischen beinahe fünfzig) Sites ausrollen zu können. Das setzt aber im Projekt und im Betrieb die Disziplin voraus, Code weder im Theme, noch in Plugins für einzelne Sites anzupassen. Folgende Freiräume zur Ausgestaltung von Eigenständigkeit haben die einzelnen Redaktionen dabei:
- Individualisierung des Farbschemas
- Redaktionelle Ausgestaltung des inhaltlichen Rahmens (der insbesondere Dank unseres Landingpage-Editors „Grid“ quasi alle denkbaren redaktionellen Freiheiten mitbringt)
- Umbau und Ausbau der mitgelieferten Inhalte
- Aktivierung oder Deaktivierung diverser mitgelieferten Funktionen (z.B. Kommentare)
Entfernte Inhalte
Damit haben sich die Synergien der Gemeinsamkeiten im Netzwerk der Böll-Sites aber noch nicht erschöpft. Es gibt eine Reihe von Komponenten, die zwischen den Sites über das leere Haus und die kontinuierliche gemeinsame Codebasis hinaus geteilt werden. Dazu gehören v.a. die folgenden Aspekte:
- SSO (Single Sign-On) über Open ID
- Content-Sharing
- Content-Proxying
Single Sign-On ist eine der klassischen Anforderungen Site-Netzwerken. Hier ist der zentrale Wunsch, dass sich alle User für die Sites, auf die sie Zugriff haben, nur einen einzigen Usernamen und ein Passwort merken müssen. Wenn man – wie wir in diesem Projekt – mit verteilten Installationen arbeitet, bleibt einem meist nichts anderes übrig als eine zusätzliche zentrale Userverwaltung einzuführen, die die Authentifizierung übernimmt. Großartigerweise gibt es dafür mit OpenID inzwischen einen guten Standard, der von Drupal bereits von Haus ganz ordentlich unterstützt wird.
Content Sharing ist bei Netzwerken von Sites ebenfalls eine regelmäßige Anforderung: Inhalte (meist nur Artikel) aus einer Installation sollen in einer anderen Installation ebenfalls zur Verfügung stehen. Dies ist ein klassisches Beispiel für Teilbarkeit „geteilt und/oder dupliziert bei redaktionellem Bedarf“. Wir haben zu dem Zweck eine zentrale Drupal-Installation aufgesetzt, die sämtliche Inhalte aller angeschlossenen Sites als reine Daten entgegennimmt. Über ein Interface innerhalb der beteiligten Sites können die Redaktionen diesen sog. „Content-Master“ durchsuchen und Inhalte entweder als Kopie oder als Referenz übernehmen. Kopien können verändert und umgeschrieben werden, während sich Referenzen regelmässig mit ihrer ursprünglichen Quelle aktualisieren, also alle lokalen Änderungen überschreiben.
Wichtig für ein erfolgreiches Content-Sharing (und der Grund, warum es in diesem Artikel auftaucht) ist die Tatsache, dass das umso besser funktioniert, je gleichförmiger die Informationsarchitekturen in den beteiligten Sites sind, insbesondere die Strukturen der Inhaltstypen und ihrer direkten Meta-Daten. Es ist natürlich einfach, die Freitext-Felder, wie Titel oder Fließtext von einer Installation zur anderen zu bewegen. Aber schon bei so grundlegenden Eigenschaften wie der Kategorie oder Schlagworten, wird es schwierig, weil bei der Übernahme entweder sichergestellt sein sollte, dass diese Metadaten in der Ziel-Installation ebenfalls vorhanden sind, oder – für den Fall, dass sie es nicht sind – geklärt werden muss, wie mit den fehlenden Daten umgegangen werden soll: Weglassen? Neu anlegen? Anders zuordnen? Noch komplexer wird es, wenn Inhalte wieder auf Inhalte verweisen wie beispielsweise bei sog. „Relateds“ – meist von Hand ausgewählten Referenzen zu einem Artikel. Will man diese auch mitnehmen, könnte man schnell eine Kettenreaktion an zu sharenden Artikeln auslösen.
In einem kommenden Artikel gehen wir noch detaillierter ein auf die Herausforderungen beim Content-Sharing.
Content-Proxying meint das Vortäuschen von Inhalten, die aus Sicht der User aus dem Redaktionssystem kommen, in Wirklichkeit aber an einem zentralen Ort liegen. Bei den Bölls ist die Kalenderfunktion hier das beste Beispiel. Auf den meisten Sites des Böll-Netzwerkes findet sich in der rechten Seitenspalte sehr prominent eine Liste von Terminen. Der Kalender ist ein zentrales Werkzeug der Seite, denn Veranstaltungen auszurichten gehört zum Kerngeschäft fast aller politischen Stiftungen. Aber natürlich werden Veranstaltungen häufiger von mehreren Büros ausgerichtet oder zumindest angekündigt, so dass eine zentralen Kalenderverwaltung praktisch unumgänglich ist.
Hierfür gibt es, ähnlich wie beim Content-Sharing, ebenfalls eine zentrale Drupal-Installation, in der alle beteiligten Redaktionen ihre Termine und Veranstaltungen eintragen sowie festlegen können, welche Veranstaltungen sie auf ihrer Site ausspielen möchten. Da die Termine aber innerhalb der Redaktionssysteme nicht mehr bearbeitet werden können müssen, wird nur der fertige Inhalt der Box von der zentralen Kalender-Installation übernommen. Dafür fragt das Drupal den Kalenderserver regelmässig an, zieht sich das fertig gerenderte HTML und spielt es in der Box der jeweiligen Site wieder aus.
Eine ähnliche Mechanik kommt bei GreenCampus – der Site der Weiterbildungsakademie der Heinrich-Böll-Stiftung – zum Einsatz: Auf ihrer Website sollen die Trainer und Dozenten vorgestellt werden, diese werden jedoch natürlich zuerst im zentralen Kalendertool eingepflegt, weil sie als Daten zu den Veranstaltungen gehören. Selbstverständlich möchte die Redaktion die Trainerprofile nicht mehrfach pflegen, oder immer – wie beim Content-Sharing – von Hand übernehmen. Daher wird dort der Inhalt einer kompletten Seite mit dem gleichen Mechanismus übernommen: Die Seite greencampus.de/de/afar/all-trainers holt sich ihren Inhalt vollautomatisch und nur mit kurzen Zwischenspeicherzeit von der Seite calendar.boell.de/all-trainers.
Wir werden Content-Proxying im Böll-Setup noch in diesem Jahr weiter ausbauen, um eine mächtigere Volltextsuche und einen gemeinsamen Shop zu ermöglichen. Da hier keine echten Daten ausgetauscht werden, sondern nur fertiges HTML, ist das allerdings weniger ein Informations-Architektur-Thema. Damit es aber funktionieren kann, ist es natürlich extrem hilfreich, dass alle Sites mit dem selben Theme laufen, sich HTML also nahtlos von einer in eine andere Site integrieren lässt. Teilbarkeit findet hier also auf Code-Ebene statt.
Fassen wir nochmal kurz zusammen
Im Ausgangs-Artikel zur Serie hatte ich ja davon gesprochen, dass es zwei wichtige Aspekte gibt, nämlich Teilbarkeit und Wiederverwendbarkeit, die jeweils unterschiedliche Ausprägungen haben. Im Folgenden gehe ich diese Aspekte noch einmal durch und zeige einzelne Beispiele im Böll-Projekt. Dabei bezieht sich Teilbarkeit meistens auf Aspekte der Informationsarchitektur und Wiederverwendbarkeit meistens auf Aspekte der Code-Basis.
Teilbarkeit: Global und beständig geteilt
Hierzu gehören bei den Bölls insbesondere die zentralen Content-Typen „Artikel“ und „Landingpage“. Diese sind über alle Installation in ihren Feldern identisch – inklusive ihrer verfügbaren Taxonomien.
Auch das Inventar unseres Landingpage-Editors Grid gehört hierzu: Die einsetzbaren Container- und Box-Typen sind für alle Sites praktisch immer identisch.
Teilbarkeit: Global und beständig geteilt, aber lokalisiert
Herzu gehören die Rollen und User: Alle Beteiligten Sites haben identische Rollen und Rechte. Diese werden auch kontinuierlich gleich gehalten. Welcher User aber welche Rolle hat, wird in jeder Installation aufs neue festgelegt.
Auch das Theme gehört hierzu, das von allen Sites eingesetzt wird. Hier können die Redaktion zwar „ihren Stil“ auswählen, wenn aber Änderungen an den Stilen vorgenommen werden, betreffen die umgehend alle Sites.
Teilbarkeit: Initial geteilt, dann aber vollständig lokalisierbar
Hierzu zählen v.a. die Inhalte der Taxonomien. Hier werden Themen und Regionen initial im leeren Haus mitgeliefert, können dann aber pro Redaktion überschrieben und individuell angepasst werden.
Teilbarkeit: Geteilt und/oder dupliziert bei redaktionellem Bedarf
Das gilt v.a. für das Content-Sharing, hier werden Inhalte erst übernommen, wenn die Redaktion diese aktiv auf ihrer Seite dupliziert/importiert haben möchte.
Es gibt aber auch Module, die selten genutzte Funktionalitäten enthalten und im leeren Haus erstmal deaktiviert sind und nur bei Bedarf aktiviert werden, wie bspw. die gesamte Shop-Funktionalität, die eigene Content-Typen und Taxonomien mitbringt oder bestimmte Mechanismen der E-Mail-Benachrichtigung bei neuen Artikel-Kommentaren.
Teilbarkeit: Gar nicht geteilt
Hierzu gehören bspw. die zentralen Menüs. An dieser Stelle macht das „leere Haus“ zwar einen Vorschlag im Sinne der Menüs der Bundesstiftung, wie man das Menü aufbauen kann. De facto sind die Redaktion aber völlig frei bei der Ausgestaltung. Das gleiche gilt für die grundlegende Struktur der Homepage und anderer zentraler Landingpages.
Wiederverwendbarkeit: Global wiederverwendbare Komponente
Bestes Beispiel hierfür sind wiederum die zentralen Content-Typen und deren Strukturen sowie v.a. der Landingpage-Editor Grid und dessen Bestandteile. Diese sind in allen Installation identisch vorhanden und einsetzbar.
Wiederverwendbarkeit: Spezialisierte Erweiterung für eine global verwendbare Komponente
Ein gutes Beispiel hierfür sind Boxen innerhalb von Landingpages, die initial nicht von allen Sites benötigt oder eingesetzt werden, aber so aufgebaut sind, dass sie von allen Sites wiederverwendet werden können. Grid ist dabei explizit als generisches und erweiterbares Werkzeug konzipiert, so dass die Entwicklung neuer Boxen sehr schnell geht und die Boxen sich nahtlos in die bestehende Installation integrieren lassen. Um zu gewährleisten, dass die Boxen global wiederverwendbar sind, muss man eigentlich nicht viel tun: Es reicht die Vermeidung offensichtlicher Fehler wie z.B. das Hartverdrahten des Site-Titels im Code.
Wiederverwendbarkeit: Spezialisierte, aber global wiederverwendbare Komponente
Ein gutes Beispiel hierfür sind Module, die wir initial nur für eine Site bauen, die aber möglicherweise auch von anderen Sites genutzt werden können, wie bspw. das Afar-Modul, dass die Proxy-Integration der Trainerinnen und Trainer auf GreenCampus ermöglicht. Dieses Modul wird inzwischen auch bei weiteren Sites eingesetzt.
Wiederverwendbarkeit: Spezialisierte, aber nur in einem Kontext benutzbare Komponente
Hier haben wir Rahmen der Heinrich-Böll-Stiftung fast gar keine Beispiele. Möglicherweise kann man das Intranet der Bölls anführen, das ebenfalls eine Site aus der gleichen Code-Basis ist. Hier waren spezielle Anpassungen für die Zugriffsmöglichkeiten auf die Site nötig, da sie nicht öffentlich zugänglich sein soll.
Die dunkelgrüne Seite der Macht
Vieles im Projekt und im Betrieb des Netzwerkes der Heinrich-Böll-Stiftung hat sehr gut funktioniert und funktioniert noch immer sehr gut. Gerade zentrale Herausforderungen beim Aufbau eines so komplexen Netzwerkes haben wir gemeinsam mit den Bölls sehr gut gemeistert. Wir wollen aber auch ein paar Schwächen nicht verheimlichen.
Ungeplante Spielräume in Grid
Grid ist von uns explizit als generisches Werkzeug, als Baukasten-System geplant und gebaut worden. Und die Heinrich-Böll-Stiftung hatte in der Ausschreibung explizit ein generisches Baukasten-System haben wollen. Fast alles in Grid ist so gebaut, dass Redakteuere mit wenigen Handgriffen eine gut aussehende Seite erschaffen können. Das schließt ein, dass es ein paar sehr allgemein gehaltene Werkzeuge gibt, wie eine Media-Box, die es erlaubt, einfach nur ein Bild hochzuladen und zu verlinken, oder eine Text-Box, die es erlaubt, einfach nur etwas Fließtext auf eine Landingpage zu bringen. Womit wir nicht gerechnet haben: Das Redaktionen Text in Grafiken packen und dann die Media-Boxen nutzen, um manuell Teaser zu bauen, obwohl die ja eigentlich anders und visuell einheitlich aus dem System fallen. Oder im Wisiwig-Editor mit Schriftgrössen experimentieren. Hier haben wir gelernt, dass ein Baukasten immer bedeutet, dass man auch etwas sehr Unvorhergesehenes bauen kann. Und manchmal fügt sich Unvorhergesehenes nicht so nahtlos ein, weshalb insbesondere in der Anfangszeit des neuen Website-Netzwerks stets auch eine Auge nötig war, um zumindest besonders heftige gestalterische und technische Ausreißer „geradezuziehen“ oder auffällig kreative Redaktionen wieder etwas „einzufangen“.
Vielen Menschen = Viel Code = Viele Gedanken für’s UI
Auch der Punkt hätte uns eigentlich nicht überraschen dürfen. Hat er aber doch. Die Code-Basis war schon zum Launch der ersten Site größer und komplexer, als das Ziel, mit dem wir normalerweise antreten. Und sie ist im Betrieb nicht schlanker geworden. Wir konnten nicht vermeiden, eine ganze Reihe komplexer Möglichkeiten ins System einzubauen. Um nicht alle Redaktionen mit allen Funktionen zu überlasten, ist die Ausgestaltung der Benutzerführung ein weiteres Werkzeug, um siteübergreifend maximale Gemeinsamkeiten zu bewahren, aber dennoch Eingeständigkeit zu ermöglich. So haben wir eine ganze Reihe von selten genutzten Funktionen im UI des Backends einfach „versteckt“ und entweder auf eigene Seiten ausgelagert, oder in aufklappbare Bereiche verlegt. Die Verbesserung des Backend-UIs ist bei Drupal ohnehin eine kontinuierliche Baustelle, bei den Bölls aber noch umso wichtiger.
Vorläufiges Fazit
Obschon sowohl die Ausgangssituation als auch Umsetzung der Multisite-Architektur völlig anders aussah als bei den Musikexpress-Geschwistern (der vorherige Artikel in dieser Reihe) haben sich ein paar Dinge in beiden Projekten als sehr erfolgreich erwiesen:
- Die Maximierung von Synergien in der Code-Basis lohnt sich praktisch immer. Nicht nur ist der Betrieb effektiver, es lassen sich auch viele Folge-Anforderungen von Netzwerken von Sites effektiver und stabiler umsetzen.
- Grid als Baukastensystem mit seinem Vokabular von Containern und Boxen erlaubt es Redaktionen bei konsequenter Benutzung, sich insbesondere über Inhalte eine große Eigenständigkeit zu erarbeiten bzw. zu bewahren und dennoch die gewünschte visuelle Einheitlichkeit zwischen verschiedenen Sites zu bewahren.
- Wichtigste Herausforderung ist es, so früh wie möglich und so präzise wie möglich die Spielräume und Prioritäten für Eigenständigkeit zu klären.
Alle Beiträge der Serie 'Informationsarchitekturen für Netzwerke von Sites'
- Informationsarchitekturen für Netzwerke von Sites
- Multisite-Architektur der Musikexpress-Geschwister
- Multisite-Architektur der Heinrich-Böll-Stiftung
- Multisite-Architektur der Axel-Springer-Verticals
Die Bilder im Fliesstext sind von …
- maspi / photocase.de
- tobid / photocase.de
- YariK / photocase.de
- und anderen Photocase-PhotographInnen (deren Bilder ich 2004 erworben habe)
