Die Wahrheit über Hochschul-IT: Viele Systeme, wenig Zusammenhang

Wer eine Hochschule von innen kennt, kennt das Bild: Ein Campus-Management-System, das Immatrikulationen verwaltet. Ein Learning-Management-System für die Lehre. Ein CMS für den Webauftritt. Ein ERP für die Verwaltung. Dazu Forschungsinformationssysteme, E-Prüfungsplattformen, Bibliothekssoftware, Identity-Management. Und jedes dieser Systeme wurde zu einem anderen Zeitpunkt, von einem anderen Anbieter, für eine andere Abteilung eingeführt.

Das Ergebnis ist kein Ökosystem. Es ist ein Flickenteppich.

Die zweite Schwerpunktstudie des HIS-Instituts für Hochschulentwicklung (HIS-HE), die im Frühjahr 2025 an 175 Hochschulen aus Deutschland, Österreich und der Schweiz durchgeführt wurde, bestätigt das strukturell: Viele Hochschulen betreiben nach wie vor eine Vielzahl nicht integrierter Anwendungen. Fortschritte bei der Infrastruktur sind messbar – aber die interne Systemkohärenz bleibt das zentrale ungelöste Problem.

Für den Hochschulalltag bedeutet das: Daten, die in einem System existieren, müssen manuell in das nächste übertragen werden. Änderungen an Studiengangsstrukturen müssen an mehreren Stellen gleichzeitig gepflegt werden. Schnittstellen, die eigentlich Brücken sein sollten, sind oft Sackgassen.

Das ist kein technisches Nischenproblem. Es kostet täglich Arbeitszeit, verhindert Datenqualität – und blockiert jeden Versuch, die Hochschule nach außen hin kohärent darzustellen.

Warum die Website das letzte Glied in einer langen Kette ist

An keinem Punkt wird die Fragmentierung der Hochschul-IT sichtbarer als bei einem Website-Relaunch. Hochschulen investieren erhebliche Mittel in neue Designs, neue CMS-Installationen, neue Navigationsstrukturen. Und stellen dann fest, dass die Kerninhalte – Studiengangsseiten, Personenverzeichnisse, Veranstaltungskalender, Publikationslisten – aus Systemen kommen, die nicht mit dem neuen CMS sprechen.

Campus-Management-System und CMS kommunizieren nicht. Forschungsdatenbank und Webauftritt sind voneinander entkoppelt. Personalverzeichnisse werden doppelt gepflegt. Was dann entsteht, ist ein aufwendig gestaltetes Frontend, das inhaltlich auf veralteten, manuell gewarteten Daten basiert.

Das Problem liegt nicht am CMS. Das Problem liegt an der fehlenden Integrationsstrategie darunter.

Die HRK hat diesen Punkt bereits früh benannt: Campus-Management-Systeme sind zwar an fast 90 Prozent der deutschen Hochschulen implementiert. Vollständige digitale Workflows – vom Eintritt bis zum Austritt eines Studierenden – sind jedoch kaum vorhanden. Was formal vorhanden ist, und was tatsächlich zusammenarbeitet, sind zwei verschiedene Dinge.

Wer die Website seiner Hochschule modernisieren will, muss daher eine Frage stellen, die nichts mit Design zu tun hat: Welche Daten sollen auf der Website erscheinen – und aus welchem System kommen sie? Wenn diese Frage nicht beantwortet ist, bevor das erste Webdesign-Briefing geschrieben wird, wird die Modernisierung halbfertig bleiben.

Barrierefreiheit ist keine Kür – sie ist seit Juni 2025 Pflicht

Zu den systemischen Herausforderungen der digitalen Transformation kommt seit dem 28. Juni 2025 eine regulatorische hinzu: Das Barrierefreiheitsstärkungsgesetz (BFSG) ist in Kraft getreten. Öffentliche Einrichtungen und damit auch Hochschulen sind schon länger über die BITV 2.0 zur digitalen Barrierefreiheit verpflichtet. Mit dem BFSG weitet der Gesetzgeber diese Anforderungen weiter aus und schafft ein verbindliches Sanktionssystem: Bei Verstößen drohen Bußgelder von bis zu 100.000 Euro.

Die Anforderungen sind konkret: Websites müssen dem WCAG-2.1-Standard auf Stufe AA entsprechen. Das bedeutet unter anderem ausreichende Farbkontraste, vollständige Tastaturbedienbarkeit, Alt-Texte für Bilder und untertitelte Videos. Für Hochschulen, deren Webangebote oft historisch gewachsen und mit tausenden Seiten, PDFs und eingebetteten Medien befüllt sind, ist das eine erhebliche Aufgabe.

Der entscheidende Punkt: Barrierefreiheit lässt sich nicht nachträglich auf eine Website aufsetzen. Sie muss in der Architektur verankert sein – im Template-System, in den Redaktionsworkflows, in der Art, wie Inhalte eingepflegt werden. Ein CMS, das Redakteurinnen und Redakteure nicht aktiv dabei unterstützt, barrierefreie Inhalte zu erstellen, wird zwangsläufig barrierefreie Ergebnisse verfehlen.

Das ist zugleich eine Chance: Hochschulen, die ihr CMS ohnehin modernisieren, sollten Barrierefreiheit nicht als Add-on behandeln, sondern als strukturellen Bestandteil der neuen Architektur. Ein System, das von Anfang an barrierefrei gedacht ist, spart langfristig erheblich mehr Aufwand als eines, das im Nachgang angepasst werden muss.

Was zukunftssichere IT-Infrastruktur konkret bedeutet

Der Begriff „zukunftssichere IT-Infrastruktur" klingt groß. In der Praxis lässt er sich auf drei konkrete Prinzipien herunterbrechen, die den Unterschied zwischen nachhaltigem Fortschritt und weiterer Komplexitätsakkumulation ausmachen.

Modular statt monolithisch. Systeme, die alles können wollen, können am Ende meist nichts richtig. Die zukunftsfähige Hochschul-IT besteht aus spezialisierten Systemen, die über klar definierte Schnittstellen miteinander kommunizieren. Das Campus-Management-System verwaltet Studierendendaten. Das CMS stellt diese Daten für die Website bereit. Das Forschungsinformationssystem liefert Publikationsdaten. Kein System übernimmt die Aufgaben des anderen – aber alle sprechen die gleiche Sprache.

Das setzt API-first-Architekturen voraus: Systeme, die von Anfang an so gebaut sind, dass andere Systeme auf ihre Daten zugreifen können. TYPO3 – das meistgenutzte CMS an deutschen Hochschulen – geht diesen Weg mit dem Headless-Ansatz konsequent: Das Backend verwaltet Inhalte, das Frontend rendert sie, und die Verbindung ist eine standardisierte Schnittstelle. Andere Systeme können dieselbe Schnittstelle nutzen.

Open Source statt Abhängigkeit. Proprietäre Systeme schaffen Vendor-Lock-in. Hochschulen, die ihre Kerninfrastruktur auf proprietären Plattformen aufgebaut haben, zahlen nicht nur Lizenzkosten – sie verlieren langfristig die Kontrolle über ihre eigenen Daten und Prozesse. Open-Source-Systeme geben diese Kontrolle zurück. Sie erlauben eigene Weiterentwicklungen, sind community-geprüft und unabhängig von Unternehmensentscheidungen Dritter. Für öffentlich finanzierte Institutionen ist das nicht nur ein wirtschaftliches Argument, sondern eines der digitalen Souveränität.

Iterativ statt revolutionär. Der häufigste Fehler bei IT-Transformationsprojekten: Der Versuch, alles auf einmal zu lösen. Ein vollständiger Big-Bang-Relaunch, der alle Systeme gleichzeitig ablöst, überfordert Budgets, Kapazitäten und Nutzerakzeptanz gleichermaßen. Die Alternative ist ein modularer Transformationspfad: Zuerst eine solide technische Basis schaffen. Dann System für System integrieren. Den Betrieb sicherstellen, während die Weiterentwicklung läuft.

Das ist keine Kompromisslösung. Es ist die nachweislich erfolgreichere Strategie.

Was das in der Praxis bedeutet: Universität Hohenheim

Die Universität Hohenheim steht exemplarisch für eine Herausforderung, die viele Hochschulen kennen: ein breites inhaltliches Spektrum – von Studieninteressierten über Forschende bis hin zu Verwaltung und Kommunikation – kombiniert mit einer gewachsenen Systemlandschaft, die historisch nicht aufeinander abgestimmt wurde.

Im Rahmen des laufenden Website-Relaunches auf TYPO3-Basis haben wir gemeinsam mit der Universität genau dort angesetzt, wo die meisten Relaunches scheitern: nicht beim Design, sondern bei der Datenfrage.

Das zentrale Problem war die Verbindung zwischen dem Campus-Management-System HISinOne und dem CMS. Studiengangs- und Forschungsdaten existierten in HISinOne – aber sie gelangten nicht automatisiert auf die Website. Das Ergebnis: Redakteurinnen und Redakteure pflegten dieselben Inhalte doppelt, Aktualisierungen liefen zeitverzögert ein, und Fehler zwischen System und Website waren unvermeidlich.

Die Lösung war eine API-basierte Middleware, die HISinOne und TYPO3 verbindet. Über optimierte Import- und Synchronisationsprozesse werden Studiengangs- und Forschungsdaten nun zuverlässig aus dem führenden System übernommen und in redaktionell steuerbaren Seitentypen ausgespielt. Die Datenbasis bleibt zentral in HISinOne. Die inhaltliche Qualitätskontrolle und Darstellung bleiben in redaktioneller Hand. Beides schließt sich nicht aus – wenn die Architektur stimmt.

Parallel dazu wurde ein Enterprise-SSO auf SAML-Basis eingeführt, das hochschulkonforme Zugriffssteuerung für interne Bereiche ermöglicht, ohne die öffentlichen Redaktionsworkflows zu belasten. Flankiert wurde das Gesamtprojekt von einer SEO-Migrationsstrategie, die bestehende Sichtbarkeit und Rankings während des Übergangs aktiv absichert – ein oft unterschätztes Risiko bei Relaunches.

Das Ergebnis ist keine fertige Website. Es ist eine zukunftsfähige Plattform: eine technische Basis, auf der Inhalte schneller publiziert, Daten zuverlässiger gehalten und neue Anforderungen – inklusive Barrierefreiheit – strukturiert ergänzt werden können. Hohenheim zeigt, dass der Weg zur datengetriebenen Hochschulwebsite keine Revolution braucht, sondern eine klare Integrationslogik und eine Architektur, die von Anfang an dafür gebaut ist.

Was jetzt zu tun ist

Digitale Transformation ist kein Projekt, das man abschließt. Es ist ein Betriebsmodus. Hochschulen, die das verstehen, hören auf, auf den „richtigen Zeitpunkt" für den großen Wurf zu warten – und beginnen mit dem Schritt, der heute möglich ist.

Drei Maßnahmen, die sofort möglich sind:

Systemlandschaft kartieren. Welche Systeme sind im Einsatz? Wo entstehen manuelle Doppelerfassungen? Welche Schnittstellen existieren – und welche fehlen? Eine ehrliche Bestandsaufnahme dauert Wochen, nicht Monate. Sie ist die Voraussetzung für alle weiteren Entscheidungen.

Barrierefreiheits-Audit durchführen. Das BFSG ist in Kraft. Ein Audit identifiziert, wo der größte Handlungsbedarf besteht. Wer das strukturiert angeht, statt reaktiv, hat die Chance, Barrierefreiheit als Qualitätsmerkmal zu etablieren – nicht als regulatorische Last.

Nächsten Modernisierungsschritt definieren. Nicht das gesamte System auf einmal. Einen konkreten, umsetzbaren Schritt: Eine Schnittstelle, die gebaut wird. Eine Systemkomponente, die ersetzt wird. Ein Prozess, der digitalisiert wird. Wer kleine Schritte konsequent geht, kommt weiter als wer auf die große Lösung wartet.

Die Hochschulen, die in zwei Jahren eine tragfähige digitale Infrastruktur haben werden, haben heute nicht mit dem Masterplan angefangen. Sie haben mit dem ersten umsetzbaren Schritt angefangen.