Eine Codebasis, hundert Schulen, eine einzige Quelle der Wahrheit

Das Muster, nicht die Institution

Wenn Sie in einer Drupal-Landschaft im Hochschulbereich mit mehr als fünfzig Websites gearbeitet haben, wird Ihnen die Geschichte, die wir Ihnen erzählen werden, bekannt vorkommen, mit unterschiedlichen Implementierungen an verschiedenen Hochschulen. Zusammengestückelte Funktionalität, die von verschiedenen Teams in verschiedenen Jahren angeflanscht wurde. Erhebliche Abhängigkeiten von individuellem Code, den niemand mehr nachvollziehen kann. Inkonsistente Benutzererlebnisse über Fakultäten und Abteilungen hinweg. Das Onboarding für Redakteur:innen dauert Wochen für jedes neue Programm. Markenrichtlinien in einem PDF, das alle referenzieren und niemand durchsetzt.

Dies ist die häufigste Form einer Drupal-Plattform einer Forschungsuniversität nach einem Jahrzehnt dezentraler Entscheidungen. Es ist nicht das Ergebnis schlechter Ingenieurskunst. Es ist das Ergebnis von Wachstum ohne Governance, und die Lösung ist kein weiteres Framework, kein weiterer Anbieter oder eine komplette Neuplattformierung.

Die Lösung besteht darin, die bereits vorhandene Plattform regierbar zu machen.

Dies ist die Geschichte, wie wir dies für eine solche Institution getan haben.

Der von uns geerbte Bestand

Eine der Top-50 US-Forschungsuniversitäten. Etwa 25.000 Studierende. Mehr als 100 institutionelle Websites, primäre Objekte, Fakultäts- und Schulwebsites, Abteilungswebsites, Microsites und eigenständige Marketingseiten, die ein Jahrzehnt von Entscheidungen umfassen und auf Drupal 7, 8, 9 und 10 laufen. Gehostet auf Acquia Cloud. Gesteuert von einem gemeinsamen Marketing- und IT-Rat. Betreut neben einer langjährig etablierten Kreativagentur, wurden wir hinzugezogen, um zu ergänzen, nicht zu ersetzen.

Die technischen Schulden sahen wie folgt aus:

• Fünf verschiedene Inhaltsmodelle für „Dozentenprofile“ an den verschiedenen Fakultäten.
• Drei verschiedene Methoden zur Erstellung von Veranstaltungen (Paragraphs, Layout Builder und benutzerdefinierte Blöcke).
• Etwa 40 geforkte Varianten des zentralen Design-Frameworks.
• Etwa 70 Contrib-Module mit Versionsdrift, einige Websites sind drei Nebenversionen im Rückstand.
• Individueller Code, der sich über vier frühere Agenturen und zwei Generationen interner Mitarbeiter:innen angesammelt hat.
• Markenrichtlinien in einem PDF von 2021, informell bei der Code-Überprüfung durchgesetzt.
• Onboarding für Redakteur:innen von drei bis sechs Wochen pro neuer Fakultät.

Acquia Site Factory stand zur Debatte. Wir rieten davon ab.

Die Grundursache ist Governance, nicht Technologie:

Die Grundursache für das Patchwork sind nicht „mehr Agenturen“. Es ist das Fehlen von Governance-Gates zum Zeitpunkt der Bereitstellung.

In jedem Hochschulbestand, den wir geprüft haben – und wir haben viele geprüft – gilt dasselbe Muster.

Alles, was die Code-Überprüfung besteht, geht in die Produktion. Prüfer:innen rotieren. Standards weichen ab. Markenrichtlinien, die in PDFs existieren, werden nicht durchgesetzt. Komponentenverträge und Barrierefreiheitsprüfungen, die in CI verankert sind, hingegen schon.

Drupal 10 ist in Ordnung. Acquia Cloud ist in Ordnung. Code-Überprüfung ist in Ordnung. Was in fast jedem Bestand, den wir sehen, fehlt, ist die Durchsetzungsebene zwischen genehmigt und bereitgestellt. Ohne diese Ebene führt jeder wohlmeinende Anbieter, einschließlich des etablierten, letztendlich zu Entropie. Mit ihr wird die Plattform selbstreinigend: Abweichungen werden in dem Moment abgelehnt, in dem sie versuchen, in die Produktion zu gelangen.

Wir mussten den Bestand dieses Kunden nicht neu schreiben. Wir mussten Gates installieren.

Aber die Installation von Gates über mehr als 100 Websites in einem begrenzten Zeitfenster mit einem einzigen Lieferteam ist nicht nur ein technisches Problem. Es ist ein Durchsatzproblem, ein Nachverfolgbarkeitsproblem und ein Problem der Konsistenz unter Druck. Hier kam unser KI-Bereitstellungs-Framework ins Spiel.

Wie wir geliefert haben: Das KI-Bereitstellungs-Framework

Eine Konsolidierung dieser Größenordnung, die etwa 100 Websites, 70 Module und 40 Theme-Varianten betrifft, ist die Art von Programm, die traditionell achtzehn bis vierundzwanzig Monate dauert und vollständig von der Aufmerksamkeit erfahrener Ingenieur:innen abhängt. Das Risiko liegt nicht in der Ingenieurskunst. Das Risiko liegt in allem, was die Ingenieurskunst umgibt: die richtigen Anforderungen zu ermitteln, die Konsistenz in einem großen Team aufrechtzuerhalten, Fehler zum Zeitpunkt des Commits statt der Veröffentlichung abzufangen und den Fortschritt in einer Sprache zu berichten, auf die ein Governance-Rat reagieren kann.

Wir haben dieses Engagement mit unserem sechs-Engine KI-Bereitstellungs-Framework umgesetzt. Jede Engine ist für eine Phase des SDLC verantwortlich. Die KI bewältigt das Volumen. Menschen treffen jede kritische Entscheidung. Die gesamte Pipeline läuft auf einer persistenten Wissens-Engine, die den Codebasis-Kontext, Architekturentscheidungsaufzeichnungen, Geschäftsregeln und die Plattformkonfiguration speichert und aus jedem Sprint lernt.

1. Discovery Engine, die jedes Gespräch in ein Sprint-bereites Backlog verwandelt: Wir haben alle Stakeholder-Artefakte von Kundenseite erfasst: Interviewprotokolle mit über 30 Fakultäts- und Abteilungsleiter:innen, Marken-Audits, das alte Markenrichtlinien-PDF, Barrierefreiheits-VPATs und die internen Issue-Tickets der letzten drei Jahre. Die KI extrahierte Anforderungen, ordnete Abhängigkeiten zu und generierte ein Sprint-bereites Backlog mit vollständiger Rückverfolgbarkeit zur Quelle, wobei jedes Ticket mit dem Gespräch verknüpft war, das es ausgelöst hatte. Ein Senior PM prüfte jedes Ticket, bevor es in den Sprint aufgenommen wurde. Entdeckungsarbeiten, die sechs Wochen Workshops in Anspruch genommen hätten, dauerten sechs Tage.
2. Build Engine, KI-Pair-Programming mit menschlich gesteuerten Merges: Jede:r Entwickler:in im Team arbeitete mit einem KI-Pair-Programming-Assistenten, der mit dem vollständigen Codebasis-Kontext der Knowledge Engine geladen war. Der Assistent kennzeichnete Anti-Patterns in Echtzeit, schlug Wiederverwendung statt Neuschreibung vor und richtete jede Änderung am Designsystem aus. Jede Pull-Anfrage durchlief eine KI-Erstprüfung (Korrektheit, Standards, Abdeckung, Leistung), bevor sie von einem Senior Engineer manuell freigegeben wurde. +55 % schnellere Aufgabenerledigung. −62 % Produktionsfehler in den ersten 90 Tagen.
3. Security Engine, Shift-Left bei jedem Commit: SAST-Analyse, Scans von Geheimnissen und Anmeldeinformationen, SCA-Abhängigkeitsprüfungen und OWASP Top 10-Checks werden bei jedem Commit durchgeführt. KI-gestützte Filterung hielt die Rate der Fehlalarme unter 3 %, verglichen mit den 20–40 %, die für traditionelles SAST typisch sind. Schwachstellen wurden zum Zeitpunkt des Commits behoben. Es gab keine Sicherheitsüberraschungen bei der Veröffentlichung.
4. Test Engine, Playwright, PHPUnit, KI-generiert, selbstheilend: KI-generierte Playwright E2E-Tests mit selbstheilenden Selektoren deckten browser- und geräteübergreifende User Journeys ab. KI-generierte PHPUnit-Suites erreichten eine Branch-Abdeckung von 85–96 %. Eine Multisite-fähige Regression Suite führte bei jedem Build einen vollständigen Cross-Component-Verifizierungs-Diff durch. QA-Ingenieur:innen hörten auf, Regressionen zu jagen, und führten stattdessen explorative Tests an Edge Cases und UX durch. Der Wartungsaufwand für Tests reduzierte sich um 50–70 %.
5. Delivery Engine, Bereitstellung mit Stakeholder-Transparenz in jedem Sprint: CI/CD wurde nach QA-Freigabe bereitgestellt, keine manuellen Release-Schritte. Die Überwachung nach der Bereitstellung verfolgte Regressionen, Fehler und Leistungsverschlechterungen. Die Delivery Engine generierte leicht verständliche Sprint-Retrospektiven für den gemeinsamen Marketing- und IT-Governance-Rat, Geschwindigkeitsmetriken, Risikoprotokoll, Vorfallszusammenfassung, Empfehlungen für den nächsten Sprint, ohne dass eine technische Übersetzung erforderlich war. Jede Retrospektive floss zurück in die Knowledge Engine, und der nächste Sprint begann intelligenter als der letzte.
6. Knowledge Engine, die persistente Intelligenzschicht: Enthält die Codebasis, Architekturdiagramme, ADRs, Markenstandards, Barrierefreiheitsrichtlinien, Umgebungskonfiguration und Vorfallhistorie. Liefert Kontext an jede andere Engine. Wächst mit jedem Sprint. Im vierten Monat des Engagements kannte die Knowledge Engine den Bestand besser als jede einzelne Person im Team.

Die Disziplin des Frameworks ist hier wichtiger als die reinen Zahlen. KI schlägt vor; Menschen entscheiden. Jede Engine hat einen menschlichen Überprüfungspunkt. Diese Struktur gab dem Governance-Rat das Vertrauen, ein Programm dieser Größenordnung innerhalb eines festen Zeitrahmens zu genehmigen. Sie wurden nicht gebeten, der KI zu vertrauen. Sie wurden gebeten, einer Pipeline zu vertrauen, in der die KI die Volumenarbeit erledigte und Menschen die wichtigen Entscheidungen genehmigten.

Das Compliance-Gate: Drupalfit

Fünf Engines liefern die Arbeit. Drupalfit ist das Gate, das entscheidet, ob die Arbeit ausgeliefert werden darf.

Drupalfit sitzt in der CI-Pipeline, zwischen dem erfolgreichen Build der Test Engine und dem Deploy der Delivery Engine. Bei jedem Merge in einen Plattform-Branch führt Drupalfit vier erforderliche Prüfungen durch:

1. WCAG 2.1 AA Barrierefreiheit: Automatisierte Axe-Core-Scans gegen einen repräsentativen URL-Satz pro Website. Fehlgeschlagene Scans blockieren den Merge.
2. Design-System-Vertragstests: Jede CSS-Farbe, Schriftfamilie und jedes Marken-Token in jeder kompilierten Komponente wird gegen die Token-Zulassungsliste des Design-Systems geprüft. Tokens außerhalb des Systems blockieren den Merge.
3. Drupal Upgrade Readiness: Jede PR führt upgrade_status und drupal-rector aus, um die Anzahl der Deprecations zu bewerten. Deprecations im benutzerdefinierten Code blockieren den Merge.
4. Drupal-Sicherheitshinweise: drush pm:security wird bei jeder PR ausgeführt. Offene Hinweise blockieren den Merge.

Drupalfit ist die Antwort auf die Frage „Was stoppt das nächste Jahrzehnt der Abweichung?“ und die Antwort ist: ein CI-Job, kein PDF.

Die Richtlinie, die in der Code-Überprüfung existiert, hängt davon ab, welche:r Prüfer:in in dieser Woche im Wechsel ist. Die Richtlinie, die in CI existiert, wird für jeden Merge, jede:n Mitwirkende:n, jede Website, jedes Mal durchgesetzt. Als die Konsolidierung live ging, hatte der Bestand des Kunden Gates. Die Gates laufen immer noch. Die Abweichung wird immer noch abgelehnt.

Das ist das nachhaltige Ergebnis.

Die Zahlen

Wir haben fünf Metriken über das Engagement hinweg gemessen. Alle fünf werden als Bereiche ausgedrückt und konservativ gegenüber veröffentlichten Hochschul-Benchmarks (Princeton WDS, Stanford Sites, Arizona State, NDSU, UCSF, McGill) gehalten.

Wir haben keine Dollarzahl genannt. Wir haben keinen Anstieg der Einschreibungszahlen genannt. Wir haben keinen Lighthouse-Score genannt. Diese Metriken sind nicht nachweisbar, ohne die Institution zu nennen, und wir nennen unsere Hochschulkunden nicht. Was wir behaupten können, ist die operative Veränderung: Der Bestand hörte auf, technische Schulden anzuhäufen. Die nächsten 50 Websites werden das Patchwork nicht neu aufbauen, das die ersten 100 taten.

Was wir NICHT getan haben

Eine kurze Liste, denn sie ist genauso wichtig wie die Arbeit, die wir geleistet haben:

1. Wir haben die Plattform nicht auf Acquia Site Factory umgestellt: Der Kunde nutzt weiterhin Acquia Cloud Multisite, mit einer gemeinsamen Codebasis und pro-Site-Datenbanken. Site Factory ist hervorragend für wirklich vorlagenbasierte Netzwerke geeignet. Es ist die falsche Komplettumstellung für eine föderierte Forschungsuniversitätslandschaft, in der jede Fakultät berechtigterweise Variationen verlangen wird.
2. Wir haben nicht jedes benutzerdefinierte Modul neu geschrieben: Wir haben diejenigen neu geschrieben, die die D11-Bereitschaft blockierten, gemeinsame Funktionalitäten zu drupal.org beigetragen und den Rest durch Core- oder Contrib-Äquivalente ersetzt. 
3. Wir sind nicht zu einer Headless- oder entkoppelten Architektur übergegangen: Drupal rendert das Frontend. Es gab keinen Business Case, dies zu ändern. 
4. Wir haben die etablierte Kreativagentur nicht verdrängt: Sie war weiterhin für Marke und Design verantwortlich. Wir waren für Plattform-Engineering, Governance-as-Code und die KI-Bereitstellungsschicht zuständig. Langjährige Kreativpartner erledigen den Marken- und Designjob in der Regel gut; was oft fehlt, ist die darunterliegende Plattform-Engineering- und Governance-Schicht. Das ist die Lücke, die wir geschlossen haben. 

Komplette Neuplattformierungen haben mehr Marketingbudgets im Hochschulbereich vernichtet als gerettet. Wir haben die Plattform, die der Kunde bereits hatte, regierbar gemacht. Das war der Auftrag.

Warum das jetzt wichtig ist

Zwei Uhren ticken für jeden Drupal-Bestand im Hochschulbereich in den Vereinigten Staaten.

Die erste ist das Ende des Lebenszyklus von Drupal 10 am 9. Dezember 2026. Drupal 11 erfordert PHP 8.3 und Symfony 7, entfernt alles, was bis 10.3 veraltet ist, und macht eine lange Liste von Legacy-Modulen obsolet (Actions UI, Tracker, Book, Forum, Statistics, Tour, Help Topics). Bestände, die bis Q3 2026 warten, um ihre D11-Bereitschaftsarbeiten zu beginnen, werden über die Feiertage Entwicklerstunden zum Notfalltarif bezahlen. Bestände, die upgrade_status und drupal-rector jetzt in ihre CI-Pipeline integrieren und sie als Regressionstest behandeln, werden dies nicht tun.

Die zweite ist die Frist für die Einhaltung der WCAG 2.1 AA gemäß DOJ Title II für öffentliche Einrichtungen. Öffentliche Einrichtungen, die eine Bevölkerung von 50.000 oder mehr bedienen, was jede öffentliche Forschungsuniversität in den Vereinigten Staaten einschließt, müssen bis zum 24. April 2026 konform sein. Kleinere Einrichtungen bis zum 26. April 2027. Der technische Standard ist unverändert. Das Drupalfit Challenge Audit 2025 von 148 Drupal-Websites ergab, dass 84,5 % mindestens ein erkennbares Barrierefreiheitsproblem aufwiesen. Eine bestandsweite Compliance ist nur durch Deploy-Time-Gates erreichbar. Ein Team von Barrierefreiheitsspezialist:innen kann nicht manuell beheben, was über 100 föderierte Content-Redakteur:innen jede Woche neu erstellen.

Beide Uhren sind zwingende Faktoren. Keiner ist der eigentliche Grund, diese Arbeit zu tun. Der eigentliche Grund ist Nachhaltigkeit; die nächsten 50 Websites im Bestand sollten nicht die technischen Schulden neu aufbauen, die die letzten 100 taten. Die zwingenden Faktoren nehmen lediglich die Möglichkeit des Aufschiebens.

Was wir als Nächstes tun

Wir wenden dieses gleiche Vorgehen jetzt für zwei weitere Hochschulinstitutionen, drei Marketingabteilungen von Großunternehmen und als White-Label-Engineering-Partner für zwei Agenturen an, deren kreative Praxis stark ist, deren Engineering-Kapazitäten aber ausgelastet sind. Das Muster ist übertragbar. Das Framework ist übertragbar. Die Gates sind übertragbar.

Wenn Sie diesen Bestand wiedererkennen, wenn Ihnen eines der oben genannten Muster in Ihrer Umgebung bekannt vorkommt, würden wir Ihnen gerne erläutern, wie wir das Audit für Ihre Umgebung strukturieren würden.

Für die technischen Details hinter dieser Geschichte siehe unseren Begleitartikel The Higher-Ed Drupal Modernization Stack for 2026 (in Kürze erscheinend), der tiefer auf SDC-Komponentenverträge, Config Split-Muster im Multisite-Maßstab, das D11-Readiness CI-Muster und die Frage eingeht, wo KI in einem Drupal-Bestand im Hochschulbereich hingehört und wo nicht.

Führen Sie ein kostenloses Drupalfit-Audit für jede einzelne von Ihnen betriebene Website durch, Sicherheit, Leistung, SEO und WCAG 2.1 AA in einem Bericht, unverbindlich, ohne Verkaufsgespräch.

Starten Sie bei DrupalFit