Warum bekommen es die Kultusministerien es einfach nicht hin mit den Schulclouds?
Mebis ist vor den Weihnachtsferien unter der Last der Nutzeranfragen zusammengebrochen. Das hat viele Nachfragen ausgelöst und Wasser auf die Mühlen derjenigen laufen lassen, die proprietäre Lösungen wie MS-Teams bevorzugen: „Siehste, die Kultusministerien bekommen es nicht auf die Reihe!“ Ich möchte in diesem Artikel einmal eine Lanze brechen für die Situation, in denen sich Fachreferate in Kultusministerien befinden und vor welchen Aufgaben sie stehen, wenn man wirklich eine Plattform landesweit zur Verfügung stellen möchte.
Shortread
- Fachpersonal mit IT-Kompetenz ist im öffentlichen Bereich rar. Wer hier etwas erreichen und kreativ oder pragmatisch sein möchte, muss oft Entscheidungen treffen und Menschen blind vertrauen, die er/sie zunächst nicht versteht. Man braucht Mut zum Handeln. Der wird aber nicht belohnt – schon gar nicht von der Öffentlichkeit (s.u.).
- Handelt man einfach und setzt um, kommen mit Sicherheit kritische Nachfragen zum Ausschreibungsrecht. Das ist momentan kaum einzuhalten. Bei den Summen, von denen wir reden, kommen wir zumindest mit dem Anspruch „landesweit“ immer in die europaweite Ausschreibung. Wenn man es ganz eng am Auschreibungsrecht macht, muss man offen ausschreiben und kann das spätere Produkt nur in Grenzen vorherbestimmen.
- Beachtet man das Ausschreibungsrecht, kommen mit Sicherheit kritische Nachfragen zum Thema Datenschutz. Der technisierte Schulbetrieb auf Distanz stellt ohne transparent und demokratisch verabschiedete gesetzliche Regelungen für manche Kritiker per se „einen schweren Grundrechtseingriff“ dar. Dass Schule, die gar nicht stattfindet, auch Grundrechte berühren könnte, ist bei den Nachfragenden oft nicht so entscheidend – auch nicht, dass beim Betrieb durch die öffentliche Hand Daten in der öffentlichen Hand verbleiben und Formalia im Prinzip nachgeholt werden könnten.
- Beachtet man das Ausschreibungsrecht und Datenschutzrecht kommen kritische Nachfragen zur Einbindung der Betroffenen in den Entscheidungsprozess. Die Berücksichtigung von Datenschutzaspekten schränkt technische Möglichkeiten erheblich ein. Die Lösungen, die dabei herauskommen müssen, werden fast zwangsläufig pädagogisch unbefriedigend sein.
Das kann man alles berücksichtigen und machen. Es dauert aber Jahre. Die Ministerien können also handeln und dafür öffentlich „auf die Fresse“ bekommen oder sie können die notwendigen Schritte für eine transparente und rechtsfeste Umsetzung gehen und für ihre Langsamkeit „auf die Fresse“ bekommen.
Ja, das hätte man ggf. weit früher in Angriff nehmen müssen. Hat man aber nicht. Dafür gibt es ja auch berechtigt „auf die Fresse“. Aber helfen tut das auch nicht gerade.
Der Ausweg: Man handelt jetzt systemlogisch m.E. oft gerade so, dass man sich nicht dem Untätigkeitsvorwurf aussetzen muss, aber auch nicht zu viel Geld versenkt, was man dann später verantworten muss. Das diese oftmals „Verlegenheitslösungen“ im Betrieb mit allen Schüler:innen nicht standhält, ist langfristig besser verantwortbar, als wenn man gleich sehr viel Geld investiert hätte. „Es waren halt die Umstände!“
Longread
Schauen wir uns mal Moodle an und tun wir so, als wollten für das landesweit ausrollen. Daran lässt sich ganz hübsch die gesamte Bandbreite an Herausforderungen zeigen:
Moodle ist erstmal so eine Art Programm. Eigentlich noch viel weniger. Es ist viel mehr ein Text mit vielen Anweisungen. Dieser Text muss von einem Übersetzer („Interpreter“) in etwas übersetzt werden, was ein Browser wie Firefox oder Chrome anzeigen kann. Das nennt man „Seitenquelltext“ und den kann man sich anzeigen lassen, wenn man auf einer Internetseite die rechte Maustaste drückt und „Seitenquelltext anzeigen“ auswählt. Dieser Seitenquelltext wird von einem weiteren, diesmal echten Programm („Webserver“) an den Browser bzw. Anwender ausgeliefert. Für das Prozedere braucht man primär einen schnellen Prozessor (CPU). Etwas Hauptspeicher (RAM) gehört auch dazu.
Damit Moodle Daten speichern und ausgeben kann, wird ein Datenbanksystem (DBMS) verwendet. Das ist ein Programm, welchen Daten sehr effizient speichern und i.d.R. noch viel effizienter wieder ausgeben kann. Das klappt besonders gut, wenn die Daten möglichst vollständig im Hauptspeicher (RAM) liegen. Selbst eine SSD ist deutlich langsamer beim Zugriff.
Große Dateien lassen sich nicht sinnvoll in einem Datenbanksystem ablegen. Moodle legt nur Verweise (Links) in seine Datenbank, die dem Moodlecode sagen, wo ein Bild oder eine PDF-Datei zu finden ist. Dateien werden in Storages gelagert. Für den RAM wären sie schlicht zu groß. Storages können SSDs (teuer) oder normale Festplatten (günstig) sein. Moodle verschlüsselt aber seine Dateien. Zum Ver- und Entschlüsseln braucht man wiederum CPU-Leistung. RAM zum Ausliefern braucht man verhältnismäßig wenig, da Dateien in kleinen Portionen und nicht vollständig verschickt werden.
Wenn man Moodle selbst aufsetzt, wird man i.d.R. sowas bauen:
Alle drei Komponenten laufen auf dem gleichen Server und konkurrieren dann um CPU, RAM und Storage. Man kann für 50,- Euro Server mieten, die für 800‑1000 Schüler:innen ausreichen. Allerdings kommt es sehr stark auf die Nutzung an: Wenn man vorwiegend Kurse baut, in denen lediglich Aufgaben und PDFs koexistieren, klappt das spielend. Die dazu nötigen Abfragen sind harmlos. Wenn aber z.B. das Testmodul oder der Chat exzessiver genutzt werden, kann es schnell aus sein mit der Freude an der tollen Funktion. Dann muss man den nächstgrößeren Server kaufen oder herumoptimieren (mehr als 15–20% holt man damit aber nach meiner Erfahrung nicht raus).
Ich bin davon überzeugt, dass alle Installationen von Moodle auch auf Landesebene genau so angefangen haben: Erst mal einen Testserver aufsetzen und schauen, wie der Betrieb so läuft.
Das Spiel „Hardware upgraden“ ist aber irgendwann zu Ende: Wenn viele Anfragen hereinkommen, startet der Webserver mehr Interpreter. Diese produzieren dann mehr Anfragen an das Datenbanksystem. Und sie belegen mehr RAM.
Der Moodleserver fängt an zu sterben, wenn die Daten aus der Datenbank nicht mehr in den Hauptspeicher passen. Dann kommen diese Daten auf die langsame Festplatte. Dadurch stauen sich Anfragen, die das DBMS unter normalen Umständen spielend bewältigt hätte und immer mehr Interpreter müssen warten und werden nicht beendet. Wenn RAM und Auslagerungsspeicher voll sind, werden die Überlebensinstinkte des Betriebssystems geweckt. Dieses beginnt nun damit, Interpreter zu beenden, um wieder RAM frei zu bekommen. Die Anfragen an diese Interpreter laufen nun ins Nirwana und es geht für den Nutzer entweder ins Nirwana (Connection timed out) oder mit einem letzten Lebenszeichen in den Kurort (500 – Bad Gateway). Ein Absturz ist das technisch gesehen nicht. Das System selbst funktioniert ja noch, tut aber nicht das, was es soll.
Was tun?
Eine simple Möglichkeit besteht darin, die Arbeit einfach auf mehrere Server zu verteilen. Das geht mit diesem einfachen Verfahren, wenn Schulen jeweils eigene Moodlesysteme erhalten sollen,
Wenn man merkt, dass ein Server überlastet ist, schiebt man die entsprechende Schule einfach auf einen neuen. Man kann auch Schulen, die nicht viel Last erzeugen, mit mehreren anderen auf einen Server packen. Kommen neue Schulen, kauft man neue Server dazu.
Ich baue davor gerne noch einen Proxy. Ein Proxy speichert Seiten, die schon einmal von Moodle gebaut worden sind in seinem Speicher als Kopie. Wenn ein Anwender wieder genau diese Seite anfordern, muss man nicht den Moodleserver selbst damit behelligen. Die einzelnen Moodleserver machen dabei immer noch alles gleichzeitig: Moodlecode + DBMS + Storage.
Für so ein Setup muss man erheblich mehr können als beim ersten. Vor allem beim Überwachen der Server. Und man sollte z.B. das Verschieben einer Schule auf einen anderen Server tunlichst automatisieren. Sich einen Rootserver mieten und mit einem Verwaltungstool Moodle zu installieren reichen dann nicht mehr. Trotzdem ist das Setup sehr simpel, da die Moodlesserver für sich selbstständig arbeiten. Den Proxy kann man z.B. durch Failover-IPs im Notfall als „single point of failure“ automatisch eliminieren.
Ich wette, dass auch auf Landesebene das oft die erste Eskalationsstufe ist, weil man solche Setups selbst als Laie noch mit eigenen Mitteln hinbekommt.
Mebis hat noch mehr Probleme
Mebis ist eine zentrale Installation. Es gibt keine Segmentierung in Einzelmoodlesysteme für Schulen. Wildes Herumgeschiebe der Schulen ist nicht möglich. Also muss man noch eine Schippe Komplexität drauflegen und jetzt wirklich skalieren.
Man trennt jetzt keine Moodlessysteme – das geht ja auch gar nicht. Man trennt die einzelnen Komponenten wie Moodlecode, DBMS und Storage auf. Man kann dadurch die einzelnen Server auf ihre Aufgabe hin optimieren. Für den Moodlecode viel CPU-Wumps, für die Datenbank viel Speicher. Und man kann Read-Only-Datenbanken vorhalten, aus den nur gelesen wird. Schreiboperationen bei Moodle sind vergleichsweise gering. Ein diesmal richtiger Loadbalancer entscheidet je nach Auslastung der CPU-Nodes, wohin die Anfrage geht. Wenn es nicht reicht, stellt man neue Server dazu. Wenn man es gut macht, beliebig viele. Für ein ganzes Bundesland wird man das über Rechenzentrumsgrenzen hinaus machen müssen. Und die Server müssen untereinander durch schnelle Verbindungen vernetzt sein. Die Daten müssen ja unter den DBMS- und Storage-Servern schnell aktualisiert werden Monitoring bleibt Pflicht. Und Backups. Und Desaster-Recovery.
Durch Automatisierung kann man schnell reagieren. Große Anbieter wie itslearning dürften vergleichbare Setups fahren und selbst die haben sich bezüglich der Anfragemenge beim Wechsel ins Schulszenario C offenbar stellenweise verkalkuliert.
Microsoft und Google stellen aller Wahrscheinlichkeit nach nicht mal mehr eigene Server für solche Aufgaben hin. Das wird so ziemlich alles in wirklich großen Rechenzentrum mit abertausenden von Maschinen virtualisiert sein. Bei einer drohenden Überlastung „bläst“ sich das System dann automatisiert auf.
Das Problem der Ausschreibung
Das letzte Setup kann man nicht durch eine beschränkte Ausschreibung (drei Vergleichsangebote) bekommen. Da geht es um mehr Taler. Das Teure ist weniger die später Skalierung (der Zubau an Servern). Das Teure ist der Gehirnschmalz, der in die Konzeption fließen muss. Schon für die Ausschreibung braucht man für das Lastenheft immense technische Kenntnisse. Wer bei der Konzeption einer Ausschreibung mitwirkt (und so jemanden wird man brauchen), darf übrigens später nicht mehr mitbieten.
Schon ein kleines Setup wird dadurch immens teuer. Rechnen tut sich eine solche Vorbereitung nur bei späteren Wachsen in die Breite. Daher wird man erst schlicht das Geld dafür nicht bekommen. Und wenn man es krisenbedingt dann doch bekommt, sind die Anbieter und IT-Spezialisten, die so etwas hochziehen könnten, auf wunderbare Weise mit Aufträgen ausgelastet.
Das ist Menschen mit begrenztem technischen Know-How nicht vermittelbar. Oder – wäre Corona nicht gekommen – wäre man in der Presse bitterböse verprügelt worden, dass man so viel Geld für ein so kleines Setup verballert hat.
Was wesentlich leichter daherkommt, ist die Ausschreibung eines spezifischen Produkts wie z.B. Microsoft Teams. Dafür dürften sogar extra Berater / Lobbyisten von Microsoft oder Apple oder … ins Haus kommen, die die Ministerien bei der Erstellung einer sachgerechten Ausschreibung „unterstützen“. Um das Ausschreibungsrecht einzuhalten, müssen das strenggenommen Mitarbeiter:innen einer „Tochter“ des Großunternehmens sein (s.u.).
Und natürlich ist diese Variante für die Fachreferate der Kultusministerien attraktiv!
Das Datenschutzproblem
Das einzige mir bekannte System, das in Zusammenarbeit mit einem Landesdatenschutzinstitut entwickelt worden ist, ist die niedersächsische Bildungscloud (NBC). Über die dadurch verbleibende Funktionalität mag sich jeder selbst ein Bild machen. Die NBC bzw. die darunterliegende HPI-Schulcloud ist unter starkem Beschuss hinsichtlich der Finanzierung – Ausschreibungsrecht halt.
Bei großen us-amerikanischen Anbietern ist die Datenschutzproblematik oft noch nicht geklärt. Schlägt ein Kultusministerium hier zu, gibt es öffentlichen Unmut. Deswegen ist der Datenschutz der erklärte Feind derjenigen, die schnell handeln und ebenso schnell zu einem funktionsfähigem System kommen wollen. Auf deren Seite stehen zurzeit viele Anwender, deren Anforderungen man eigentlich oft so zusammenfassen kann: „Wenn eine öffentlich finanzierte Cloud mir nicht das bieten kann, was mir MS-Teams bietet, dann ist sie nichts!“ Spoiler: Systeme, die den Datenschutz berücksichtigen, können das rein formal schon nicht.
Die „Gefahr“, die von großen Anbietern ausgeht, ist eine noch sehr abstrakte – wie etwa die Aussicht auf die zweite Coronawelle im August für die meisten Kultusministerien. Es ist absolut nicht abzuschätzen, was uns da bei der Verwendung von Schüler:innendaten durch das Silicon-Valley noch bevorstehen könnte. Das Vertrauen in reine Lernplattformanbieter ist da noch gefühlt größer – die werden ja auch niemals an Investoren verkauft werden, oder? Bei komplett offenen Systemen wie z.B. Moodle hat man als öffentliche Hand die volle Kontrolle und alle Probleme und Herausforderungen gegen sich.
Das Beteiligungsproblem
Gegen Anwender:innen, die eine Lösung mit ihren Features gewohnt sind, lässt sich schwer etwas durchsetzen, was technisch einen Rückschritt darstellt. Lehrmanagementsysteme sind hier viel besser geworden, aber eben immer noch nicht richtig gut. Außerdem gibt dann noch Leute wie mich, die große Schwierigkeiten mit Lehrmanagementsystemen haben. Apple, Microsoft, itslearning, die NBC und Moodle sind deshalb so erfolgreich, weil sie Schule so abbilden, wie Schule ist: Die Lehrkraft gibt die Strukturen bis hin zu „Laufwegen“ (Lernpfade) vor, die die Schüler:innen dann entlanglaufen. Man kann Lehrmanagementsysteme anders nutzen – nur braucht man sie dann eigentlich nicht mehr.
Onenote kann das gute, alte Schulheft technisch am allerbesten imitieren und zudem alle Hefte immer für die Lehrkraft verfügbar machen. Ob letzteres ein Vorteil ist, müsste man noch diskutieren. Für mich gibt nicht viel Übergriffigeres als ein Blick auf alle Bildschirme z.B. via Apple Classroom. Aber das entspricht den Anforderungen, die an Apple herangetragen werden.
Anwender:innen sind oft in Verbänden organisiert. Ein Verband ist immer das Gegenüber des Kultusministeriums bei Benehmensprozessen. Die Mitglieder werden gerade im Bereich der Anwendung digitaler Technologie extrem heterogen sein. Herzlichen Glückwunsch bei der Konsensfindung.
Das Qualifizierungsproblem
Um eine Schulcloud sinnvoll nutzen zu können, muss man in der Anwendung digitaler Werkzeuge kompetent sein. Lassen wir diesen Punkt lieber. Der Artikel ist eh schon zu lang.
Fazit
Schulclouds in der öffentlichen Hand zu entwickeln war auch schon vor Corona nicht so einfach. Die Kompromisslösungen können dem jetzigen Ansturm nicht gewachsen sein und auch nicht problemlos und unbürokratisch aufgepustet werden. Wenn ich ein Kultusministerium mit der Aufgabe einer schnellen Umsetzung beraten müsste, würde ich zu einem Fertigprodukt raten.
Formal sind viele Fachreferate in den MKs fit. Der Weg zu einem Lehrmanagementsystem in der öffentlichen Hand ist mehr als steinig: Technische Expertise, Ausschreibungsrecht, Beteiligungsverfahren – alles viel einfacher mit Lock-in-Lösungen, wie es Teams, itunes oder auch Webweaver oder itslearning oder <beliebiges Lehrmanagementsystem> nunmal so sind.
Moodle ist eine echte Ausnahme, weswegen ich den bayrischen Weg mit Mebis persönlich absolut klasse finde. Muss jetzt halt technisch nur noch laufen. Wenn es die Bayern nicht schaffen, ist die Weltordnung nicht nur in der Bundesliga außer Kraft gesetzt.
