Abschlussbericht des Projektes - Switch

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
UHU-Abschlussbericht:
Version 1
20.09.2010
Niklaus Lang, Sebastian Linxen,
Rolf Brugger

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
1. Management Summary
An den Betrieb von Lernplattformen (LMS) an Schweizer Hochschulen werden zunehmend
hohe Anforderungen gestellt. Ein LMS-Dienst soll kosteneffizient, sicher und stabil sein, ein
ausreichendes Trainings- und Supportangebot bieten und zeitgemässe technische und didaktische
Funktionen bieten. Zudem werden LMS-Dienste immer stärker organisationsintern
integriert sowie mit anderen Hochschulen vernetzt.
Die Informatikdienste, die LMS für ihre Hochschulen betreiben, stehen daher vor grossen
Herausforderungen, bei deren Bewältigung sie weitgehend auf sich selber gestellt sind. In
dieser Studie wird der Frage nachgegangen, ob die Zusammenlegung von Ressourcen der
Hochschulen für einen gemeinsamen Betrieb von LMS realisierbar ist und ob sie qualitative
und ökonomische Vorteile bietet.
Um die Möglichkeiten eines von Hochschulen gemeinsam getragenen LMS-Dienstes abzuklären,
wurde im Rahmen eines AAA-Projektes die Machbarkeitsstudie UHU durchgeführt.
Dabei wurden in einer Umfrage die grundsätzliche Bereitschaft der Hochschulen zu einem
LMS Outsourcing sowie die detaillierten Anforderungen an einen LMS-Dienst erhoben.
Gleichzeitig wurden potenzielle Schweizer Anbieter von Hosting-Diensten für ILIAS, Moodle
und OLAT gebeten, ein Angebot für Schweizer Hochschulen zu skizzieren. Das Projektteam
stellte anschliessend die Nachfrage und das Angebot einander gegenüber und analysierte
sie.
Der Fragebogen für die Bedürfniserhebung wurde an die Informatikdienste einer Eidgenössisch-Technischen
Hochschule (ETH), der Universitäten und der Fachhochschulen sowie an
die E-Learning-Verantwortlichen der Fachhochschulen und pädagogischen Hochschulen
sowie an den Bereich Lehrentwicklung und -technologie einer weiteren ETH gesandt.
Zwölf Institutionen beantworteten die Anfrage, sieben davon bekundeten ihr Interesse an einem
Outsourcing und füllten den Fragebogen aus.
Die Bedürfnisanalyse hat ergeben, dass die Nachfrage nach ILIAS- und OLAT-Hosting-
Diensten vergleichsweise gering ausfällt, und dass somit ein gemeinsamer Betrieb ökonomisch
kaum sinnvoll ist. Dennoch steht es den interessierten Hochschulen frei, individuelle
Verträge mit den Anbietern für ILIAS- und OLAT-Hosting-Dienste abzuschliessen. Dies ist
zum Teil schon heute der Fall.
Bei Moodle zeigen sich sechs Hochschulen mit einem Potenzial von insgesamt ca. 50'000
Benutzern an einem Dienst interessiert. Bei den Anforderungen an die Funktionalität stellte
sich heraus, dass die Grundfunktionen von Moodle ausreichend sind und nur in gewissen
Fällen durch Plug-ins erweitert werden müssen. Deutlich grössere Unterschiede zeigen sich
hingegen bei den Anforderungen an die Konfigurierbarkeit, die Verfügbarkeit und die Integration
in die bestehende Hochschulinfrastruktur. Zurzeit gibt es drei Anbieter für Moodle, die
alle eine flexible Offerte unterbreiten. Aufgrund der vorliegenden Informationen passen Angebot
und Nachfrage weitgehend zueinander. Es wird hingegen unumgänglich sein, die Ver-
2/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
fügbarkeit, Skalierbarkeit und Integration für jede Hochschule individuell auszuhandeln. Da
die Hochschulen keine Aussagen über ihre Preisvorstellungen gemacht haben, lassen sich
eventuelle ökonomische Vorteile gegenwärtig nicht beurteilen.
Die weitere Entwicklung eines skalierbaren nationalen Moodle-Diensteangebots für die
Hochschulen wäre bei Bedarf in einem Folgeprojekt zu realisieren.
3/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
2. Einleitung
2.1. Ausgangslage
An den Fachhochschulen der Schweiz haben sich bis heute drei Learning-Management-
Systeme (LMS) etabliert: Moodle, OLAT und ILIAS. Die FID (Fachkommission Informatikdienste
der KFH) und ihre Subkommission SBA (Subkommission Business Applications)
rechnen damit, dass die Anforderungen an die zentralen Dienste (Informatik und Businessapplikationen)
für den Betrieb von LMS kontinuierlich wachsen werden. Dies ist unter anderem
auf folgende Gründe zurückzuführen:
• Einführung von Masterstudiengängen
• steigende Anforderungen an die Performance der diversen LMS und der relevanten
technischen Infrastruktur
• Anbindung der E-Learning-Plattformen an die Schuladministrations- und Identity -
Management-Systeme der Hochschulen
• Verfügbarkeit und Support
• der Wunsch nach mehr Kooperation zwischen den Schweizer Hochschulen
2.2. Nutzen eines gemeinsamen Hostings
Eine gemeinsam betriebene Hosting-Lösung würde den verschiedenen Institutionen der
Schweizer Hochschullandschaft eine Vielzahl an Vorteilen bringen:
• Durch eine Auslagerung des LMS-Hostings würden die Hochschulen eine höhere
Leistungsqualität bei gleichzeitig verbesserter Kooperation auf nationaler Ebene erreichen.
Dies würde sich besonders auf kooperativ betriebene Masterstudiengänge
(z.B. FTAL) positiv auswirken.
• Den Endbenutzern wie Dozierenden und Studierenden würde eine hohe Verfügbarkeit
der Services gewährleistet werden.
• Das Outsourcing bzw. der gemeinsame Betrieb von geschäftskritischen Webapplikationen
wurde an Hochschulen bisher kaum praktiziert. Das durchgeführte Projekt
würde sich daher durch einen starken Innovationscharakter auszeichnen.
• Die Informatik- und Businessapplikationsdienste der FHs wären gemeinsam mit
SWITCH in der Lage, einen qualitativ hochwertigen Service anzubieten.
2.3. Projektziele
Das Projekt verfolgte das Ziel, eine Machbarkeitsstudie zum gemeinsamen Betrieb eines o-
der mehrerer LMS durchzuführen. Im Rahmen dieser Abklärungen wurden die Produkte
Moodle, OLAT und ILIAS in Betracht gezogen, da dies in erster Linie die LMS sind, die in der
Schweizer Hochschullandschaft zum Einsatz kommen. Folgende Aspekte wurden bei der
Konzeption und Durchführung der Studie berücksichtigt:
4/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
• Erfassung der Bedürfnisse und Anforderungen der Businessapplikationsdienste
(SBA) sowie der Informatikdienste (FID) an Hochschulen.
• Klärung der Mandantenfähigkeit der derzeit verfügbaren Lösungen sowie der Anbindungsmöglichkeiten
an die gängigen Schuladministrationssysteme (z.B. Evento, eAcademia,
SAP etc.) und das Identity-Management-System der Hochschulen (zwingend
AAI-fähig)
• Evaluation der LMS
• Auswahl der zu unterstützenden Plattformen
• Abschätzung des Total Cost of Ownership (TCO) einer zentralisierten Lösung
• Organisatorische und rechtliche Aspekte einer zentralen Lösung
• Technische Aspekte einer zentralen Lösung (Skalierbarkeit, Sicherheit)
• Konzept für die Erbringung der geforderten Leistungen, entweder durch den kooperativen
und nachhaltigen Betrieb einer E-Learning-Plattform an einer Hochschule (intern)
oder alternativ durch einen externen Dienstleistungsanbieter.
• Erstellung eines Modells für bedarfsgerechte Supportleistungen
2.4. Vorgehen
Um ein umfassendes Bild der aktuellen Situation zu erhalten, wurde die zu untersuchende
Zielgruppe auf alle Schweizer Hochschulen ausgedehnt. Aus ressourcentechnischen Gründen
beschränkte sich der Untersuchungsschwerpunkt auf die drei gängigsten Learning-
Management-Systeme (Moodle, OLAT, ILIAS) in der Schweizer Hochschullandschaft.
In einem ersten Schritt wurde ein Fragebogen erstellt, der zum einem den Bedarf einer gemeinsam
betriebenen Hosting-Lösung erheben und zum anderen über eine Ist-/Soll-Analyse
den aktuellen Stand und die Bedürfnisse an ein eingesetztes LMS identifizieren sollte.
In einem zweiten Schritt diskutierten E-Learning- und IT-Verantwortliche der Schweizer
Hochschulen die generelle Thematik, die Ziele und das Vorgehen der Studie. Des Weiteren
wurde auf die Expertise der Beteiligten zurückgegriffen und Anpassungen sowie Verbesserungen
am Fragebogen wurden vorgenommen.
Der Fragebogen deckte folgende Themenbereiche ab:
Organisation und Management des LMS
Integration des LMS in bestehende Abläufe
Erweiterungsfähigkeit des LMS
Sicherheit des LMS
Funktionalitäten des LMS
Benutzerfreundlichkeit des LMS
Support
Verfügbarkeit des LMS
5/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
Skalierbarkeit des LMS
Jährliche Kosten des LMS
In der Erhebungsphase wurde den IT- und E-Learning-Verantwortlichen von 21 Schweizer
Hochschulen ein Fragebogen gesandt. Gleichzeitig erhielten Hosting-Anbieter von Learning-
Management-Systemen eine angepasste Version des Fragebogens, um einen Eindruck der
Leistungsfähigkeit und des Funktionsumfangs der Dienste zu erhalten.
In der anschliessenden Analysephase wurden die erhaltenen Antworten ausgewertet und
anhand der gewonnen Daten wurde ein Einsatzszenario für die LMS entwickelt. Dieses wurde
an diverse Hosting-Anbieter gesandt, damit diese anhand dieses Szenarios und der damit
verknüpften Systemanforderungen ein passendes Angebot erstellen konnten.
In der Konklusionsphase wurden die Angebote ausgewertet und Empfehlungen für das weitere
Vorgehen definiert.
Fragebogen
Hochschulen
Szenario 1
Fragebogen
Anbieter
Analysephase
Erstellung des Fragebogens
+ Erhebungsphase
Konklusionsphase
Schaubild 1: Schematischer Ablaufplan der Machbarkeitsstudie
6/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
3. Bedarfserhebung und Ergebnisse
Der Fragebogen wurde an 21 Hochschulen gesandt. Die angepasste Version für Hosting-
Anbieter wurde ebenfalls an alle Hochschulen und zusätzlich an zwei Unternehmen verteilt.
Vier Hochschulen kommunizierten, dass aktuell kein Bedarf an einem möglichen gemeinsamen
Hosting besteht und nahmen somit nicht an der Umfrage teil. Die positive Rücklaufquote
der Fragebogen, die versandt wurden, belief sich auf sieben. Zusätzlich gingen sechs
Antworten potenzieller Hosting-Anbieter ein.
3.1. LMS-Verteilung
Tabelle 2 zeigt die LMS, die an den befragten Schweizer Hochschulen eingesetzt werden.
Einige Einrichtungen bieten ihren Dozierenden und Studierenden mehrere LMS zur Auswahl
an.
Moodle ILIAS OLAT
6 1 3
Tabelle 2: Übersicht der eingesetzten LMS an den Schweizer Hochschulen. Mehrfachnennungen möglich.
3.2. Anforderungen an ein LMS
Der Anforderungskatalog wurde anhand der eingegangenen Antworten der diversen Hochschulen
erstellt. Da die produktspezifischen Ansprüche in der Regel allgemein formuliert und
auf alle einbezogenen Produkte (Moodle, OLAT, ILIAS) übertragbar waren, setzt sich der
folgende Anforderungskatalog aus den kumulierten Bedürfnissen der Hochschulen an ein
LMS zusammen.
3.2.1. Organisation und Management
Abbildung der hochschulspezifischen Organisationsstrukturen auf das LMS-
Strukturverzeichnis
Das eingesetzte System muss eine individuelle Konfiguration und Abbildung aller gewünschten
hochschulspezifischen Organisationsstrukturen ermöglichen.
Anpassung des "Look and Feel" an Kundenwünsche
Das eingesetzte System muss eine Anpassung des Layouts (Themes, Blocks) auf verschiedenen
Organisationsebenen erlauben. Dabei müssen die Corporate-Identity-Vorgaben der
jeweiligen Hochschule integrierbar sein.
7/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
Anpassung des Standard-Toolsets
Das eingesetzte System soll eine einfache Anpassung des Standard-Toolsets (Hinzufügen/Entfernen)
auf unterschiedlichen Organisationsstrukturen ermöglichen, ohne dass sich
dies auf die Gesamtstruktur auswirkt.
Struktur der Rollen und Rollenmodelle
Das eingesetzte System soll neben Standardrollen auch die Adaption der Rechte vorhandener
Rollen und die Generierung neuer Rollen unterstützen.
3.2.2. Integration
Integration des LMS in bestehende Arbeitsprozesse
Das genutzte System soll eine Automatisierung diverser Verwaltungsprozesse ermöglichen.
Neben einer Erstellung von Nutzer-Accounts, Kursen und Einschreibungen aus der jeweiligen
hochschulspezifischen Verwaltungssoftware müssen auch Rückmeldungen aus dem
LMS (z.B. Noten, Kursabschluss etc.) an die Verwaltungssoftware möglich sein.
Anforderungen an Schnittstellen bezüglich der Integration externe Systeme
Die Hochschulen spezifizierten keine Anforderungen bezüglich der Integration externer Systeme.
3.2.3. Erweiterungsmöglichkeiten
Vorgehensweise für die Entwicklung und Installation von Erweiterungen
Ein standardisiertes und umsichtiges Vorgehen für die Entwicklung und Installation von Erweiterungen
ist gefordert. Das genutzte System soll bei Bedarf auch die Installation von Erweiterungen
bei einzelnen Organisationsstrukturen ermöglichen.
Upgrade-Verfahren für Erweiterungen
Bezüglich der Implementierung von Erweiterungen wird eine standardisierte Kommunikationspolitik
mit den Endnutzern vorausgesetzt. Das genutzte System soll eine Deinstallation
oder Deaktivierung von Erweiterungen bei einzelnen Organisationsstrukturen ermöglichen.
Anforderungen an Schnittstellen (APIs) in Bezug auf Erweiterungen
Es wurden keine speziellen Anforderungen spezifiziert. Die Anforderungen an Schnittstellen
ergeben sich aus den Ansprüchen, die diverse Erweiterungen mit sich bringen werden.
8/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
3.2.4. Sicherheit
Eingesetztes Authentifikationsverfahren
Das genutzte System soll neben den gängigen Authentifikationsverfahren auch eine Authentifizierung
über die von SWITCH zur Verfügung gestellte Authentication and Authorization
Infrastructure (AAI) unterstützen.
Sicherheit von Kursdaten
Die Zugriffsrechte auf Kursdaten sollen über Rollen, AAI-Attribute, Gruppenzugehörigkeit
und Verfügbarkeitszeiträume gesteuert werden.
Sicherheit von Userdaten
Das genutzte System sollte die Anonymisierung von Nutzerdaten erlauben sowie eine Deaktivierung
der Erfassung von Userdaten auch auf den verschiedenen Organisationsebenen
ermöglichen.
Sichere E-Assessments
Diese Funktionalität wird aktuell nur vereinzelt verwendet. Lediglich eine Institution fordert
die Möglichkeit, sichere E-Assessments durchzuführen, und erwartet eine Exportfunktion der
Ergebnisse.
3.2.5. Funktionalitäten
Verwendetes LMS
Tabelle 3 zeigt die LMS, die an den befragten Schweizer Hochschulen eingesetzt werden.
Einige Einrichtungen bieten ihren Dozierenden und Studierenden mehrere LMS zur Auswahl
an.
Nur eine der Einrichtungen zieht eine Migration auf eine andere LMS-Lösung in Betracht. Die
meisten Hochschulen streben eine Aktualisierung bzw. ein Upgrade des verwendeten LMS
in absehbarer Zeit an.
Moodle ILIAS OLAT
6 1 3
Tabelle 3: Übersicht der eingesetzten LMS an den Schweizer Hochschulen. Mehrfachnennungen möglich.
Integrierte Autorentools
Das genutzte System muss eine breite Palette an integrierten Autorentools bieten. Ebenso
muss die Einbindung externer Lernpakete (z.B. SCORM) unterstützt werden.
9/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
Unterstützte Importformate
Gängige Importformate, wie SCORM, IMS, AICC, GIFT, XML, IMS-CP etc., müssen durch
das eingesetzte LMS unterstützt werden.
Unterstütze Exportformate
Neben dem Export- und Import von Anwendungsdaten innerhalb eines LM-Systems müssen
die gängigsten Exportformate, wie XML, HTML, TXT etc., unterstützt werden.
Unterstützung kollaborativer Arbeit
Das LMS soll nach Möglichkeit Schnittstellen zu diversen Kollaborationstools unterstützen.
Unterstützung von Mobile Learning
Das LMS muss in naher Zukunft grundlegende Mobile-Learning-Funktionen unterstützen.
Unterstützung von Web 2.0 Funktionalitäten
Neben der Unterstützung von Web-2.0-Funktionalitäten durch Bordmittel wie Blog- und Wiki-
Funktionen muss das LMS aktuelle Standards unterstützen und Schnittstellen zu externen
Applikationen ermöglichen.
Unterstützung von E-Portfolios
Das genutzte System soll die Integration von E-Portfolio-Modulen und die Verbindung zu externen
Lösungen (z.B. Mahara) unterstützen.
Unterstützung von Assessment- und Test-Applikationen
Neben den gängigen Bordmitteln zur Test- und Assessment-Erstellung muss die Integration
von Tests und Assessments unterstützt werden, die mit externen Applikationen erstellt wurden.
Unterstützung von Anti-Plagiat-Software
Diese Thematik wird aktuell zwar aktiv an den befragten Hochschulen diskutiert, allerdings
wird Anti-Plagiat-Software momentan kaum eingesetzt. Ein zukünftiger Einsatz von Anti-
Plagiat-Software ist an einigen Hochschulen jedoch wahrscheinlich.
10/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
Umfrage und Evaluationsfunktionalitäten
Das eingesetzte LMS soll durch eine ausgewogene integrierte Batterie an Funktionen Umfragen
und Evaluationen ermöglichen. Auch die Einbindung (Import) extern erstellter Umfragen
soll unterstützt werden.
Weitere Tools
Aktuell bieten die Hochschulen ihren Kunden eine Sammlung diverser Tools an. Neben generellen
externen Tools, die der Optimierung der Lehre dienen, stehen auch administrative
Tools zu Verfügung. Spezielle Wünsche (must-haves) richten sich zum einen an eine erweiterte
Suchfunktion des ILIAS-LMS (Lucene-Suche), die im Idealfall auch das CMS der entsprechenden
Hochschule durchsucht (1 Nennung). Wünsche an das LMS (Moodle) bezogen
sich auf das Dokumenten-Management (Versionierung, Datenaustausch).
Generelle Anforderungen an die Funktionalitäten
Ein gutes Dateimanagement wurde mehrfach gefordert (Versionierung, Sharing). Auch der
Einsatz von Metadaten wird teilweise eingesetzt und gefordert (Switch-Cast).
3.2.6. Benutzerfreundlichkeit (Usability)
Benutzeroberfläche
Das genutzte System muss ein gutes und einfaches Dateimanagement unterstützen. Massenoperationen
wie das Hochladen mehrerer Dateien und "Drag & Drop"-Funktionalitäten
sollen unterstützt werden. Theme-Anpassungen für Personen mit körperlichen Einschränkungen
sollen ermöglicht werden.
Hilfefunktionen
Die Hochschulen sind mit der vorhandenen integrierten Hilfe der jeweiligen LMS zufrieden.
Diese Angebote werden zusätzlich noch durch selbst erstellte oder externe Schulungs- und
Hilfematerialien erweitert. Viele Hochschulen sehen jedoch Bedarf an verbesserten Hilfsmaterialien,
die sich an diversen Tasks und den unterschiedlichen Zielgruppen orientieren, die
im Rahmen der LMS-Nutzung auftreten. In diesem Rahmen werden nicht nur text- und bildbasierte
Hilfen, sondern auch videobasierte Tutorials gewünscht.
3.2.7. Support
1st-Level-Support
Alle Hochschulen bieten den 1st-Level-Support vor Ort an. Es besteht ein sehr geringes Interesse
daran, den 1st-Level-Support an ein externes Dienstleistungsunternehmen auszulagern.
11/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
2nd-Level-Support
Alle Hochschulen bieten den 2nd-Level-Support vor Ort durch feste Einrichtungen an. Eine
Hochschule will den 2nd-Level-Support auslagern. Eine andere Hochschule erwartet ein E-
Mail-Helpdesk, sowie eine klare Kommunikations- und Erreichbarkeitspolitik für diesen Supportlevel.
3rd-Level-Support
Ungefähr die Hälfte der Hochschulen ist bereit, diesen Dienst an externe Anbieter auszulagern
– entweder an kommerzielle Anbieter oder die entsprechenden hochschultechnischen
Pendants. Für zukünftig geforderte Entwicklungen zeichnet sich eine Tendenz zur Auslagerung
des 3rd-Level-Supports vor.
Didaktische Unterstützung
Alle Hochschulen decken den Bedarf an didaktischen Schulungen über interne Einrichtungen
ab. Komplexe und spezielle Themen könnten durch externe Anbieter übernommen werden
(Anforderung einer Hochschule).
Training und Tutorials
Das Angebot an Schulungen und Tutorials wird an allen Einrichtungen durch interne Ressourcen
abgedeckt. Nur eine Institution will Trainingsaufgaben an externe Anbieter auslagern.
3.2.8. Verfügbarkeit
Wartungsfenster und Uptime
Die Anforderungen der Hochschulen sind sehr unterschiedlich. Einzelne Einrichtungen verlangen
Wartungen zu Abend- und Randzeiten, andere nehmen auf Prüfungsphasen keine
Rücksicht. Es ist wahrscheinlich, dass sich für die Hochschulen keine gemeinsamen Wartungsfenster
finden lassen würden.
Eine hohe Verfügbarkeit wird von allen Institutionen gefordert, unter anderem weil auch Studierende
in anderen Zeitzonen auf die Plattform zugreifen. Konkret soll keine Downtime länger
als acht Stunden (in den Semesterferien) dauern. Eine maximale Downtime von zwei
Stunden innerhalb der Bürozeiten bei vier bis acht Wartungsfenstern pro Jahr wird gefordert.
Downtimes müssen einen Monat vorher angekündigt werden.
Daten- und Kurs-Management, Backup, Archivierung
Erwünscht sind tägliche System-Backups und regelmässige Kurs-Level-Backups sowie die
Archivierung nicht mehr benötigter Kurse nach ca. einem Jahr. Backup und Archivierung sind
wichtige Themen, aber die Vorstellungen darüber sind nicht immer genau spezifiziert.
12/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
3.2.9. Skalierbarkeit
Mengengerüst und Erweiterungsfähigkeit
ILIAS – Anzahl Accounts und weitere Entwicklung
Insgesamt eine Institution interessiert sich für ein ausgelagertes ILIAS-Hosting.
Aktuelle Anzahl Accounts: ~9'000
Durchschnittliches tägliches Maximum: ~170. Maximale Spitzenlast: ~500
Storage: ~0.7T
Erwartete Nutzeranzahl bis 2015: ~ + 20%
Erwartete Storage-Kapazität bis 2015: vierfaches Wachstum
Moodle – Anzahl Accounts und weitere Entwicklung
Insgesamt sieben Institutionen interessieren sich für ein ausgelagertes Moodle-Hosting.
Aktuelle Anzahl Accounts: ~50'000
Maximale Anzahl gleichzeitiger Nutzer: ~1500
Storage: ~2TB
Erwartete Nutzeranzahl bis 2015: ~ + 20% (maximal +100%)
Erwartete Storage-Kapazität bis 1015: zwei- bis vierfaches Wachstum
OLAT – Anzahl Accounts und weitere Entwicklung
Insgesamt drei Institutionen nutzen bereits ein ausgelagertes OLAT-Hosting.
Aktuelle Anzahl Accounts: ~10'000
Maximale Anzahl gleichzeitiger Nutzer: aufgrund der Datenlage ist keine Aussage möglich
Storage: aufgrund der Datenlage ist keine Aussage möglich
13/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
4. Entwickelte Szenarien der LMS-Hostinganbieter
4.1. ILIAS
Zwei Institutionen traten im Rahmen der UHU-Befragung als potenzielle ILIAS-Hosting-
Anbieter in der Schweiz in Erscheinung. Die angebotenen Dienstleistungen werden nachfolgend
in komprimierter Form präsentiert. Alle Funktionen, die im ILIAS-Core-System enthalten
sind, werden dem Kunden obligatorisch angeboten und daher in der Zusammenfassung
nicht weiter ausgeführt. Eine genaue Auflistung der ILIAS-Standardfunktionen findet sich unter
http://www.ilias.de/docu/.
4.1.1. ETH 1
Das ILIAS-Hosting-Angebot der ETH 1 entspricht weitgehend dem Angebot für Moodle (siehe
4.2.2). Der Kunde erhält eine eigene ILIAS-Installation zu einem jährlichen Fixpreis.
4.1.2. HS 1
Organisation und Management
Kunden erhalten eine komplette ILIAS-Installation (independent ILIAS installation). Mit Hilfe
von Mandanten (getrennten Datenbankbereichen) können diverse unabhängige Instanzen
der abgebildeten Institutionen umgesetzt werden.
Integration
Zur Übernahme der Personen und Kursdaten wurden Schnittstellen aus der Evento-
Verwaltungssoftware geschaffen: Personendatensätze können auf der Lernplattform angelegt
und Studierende in bereits angelegte Kurs- und Gruppen-Objekte eingetragen werden.
Strukturen der Studienangebote Kurs-Objekte und Gruppen-Objekte können partiell kopiert
werden, müssen aber anschliessend manuell angepasst werden. Studierende haben nach
Beendigung des Studienganges ein Jahr Zugriff auf alle belegten Studienangebote.
Erweiterungsmöglichkeiten
Anpassungswünsche und Wünsche für zusätzliche Funktionalitäten werden von der Fachstelle
geprüft und bei einer ausreichenden Trägerschaft realisiert.
Sicherheit
Die Authentifizierung erfolgt mit AAI, lokalen Accounts oder via WebDAV-Schnittstelle.
14/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
Funktionalitäten
Es gelten zum einem die Standardfunktionen von ILIAS mit den oben erwähnten Erweiterungen,
zum anderen besteht Zugriff auf eine Media-Wiki-Farm.
Benutzerfreundlichkeit (Usability)
Neben der offiziellen Dokumentation werden zielgruppen- und aufgabenspezifische Tutorials
zur Verfügung gestellt.
Support
Es werden 1st-, 2nd- und 3rd-Level-Support, didaktischer Support sowie Schulungen und
Tutorials angeboten. Anfragen an den 3rd-Level-Support werden von den internen IT-
Services mit Unterstützung der ILIAS-Entwickler-Community beantwortet.
Verfügbarkeit
Im Rahmen eines täglichen Wartungsfensters von 2:00 Uhr bis 5:00 Uhr werden ein Backup
und notwendige Wartungsarbeiten durchgeführt.
Skalierbarkeit
Die Storage capacity kann ab 2011 nach Bedarf erweitert und ohne systemtechnische Veränderung
auf ~1.0 Petabyte erhöht werden.
Kosten
• Gebühr pro Kurs pro Jahr
• Gebühr pro Student pro Jahr
• In den Kosten ist der Support (1st-, 2nd- uns 3rd-Level) über eine Hotline (montags
bis freitags von 8:00–17:00 Uhr) enthalten. Nicht inbegriffen sind Aufwände, die für
die inhaltliche Unterstützung entstehen.
Integrationskosten hängen von den vorhandenen Systemen an der jeweiligen Hochschule ab
und können von Fall zu Fall variieren.
4.2. Moodle
Für einen Moodle-Hosting-Dienst konnten drei Anbieter in der Schweiz gefunden werden.
Ihre Angebote werden nachfolgend kurz zusammengefasst. Alle Funktionen, die im Moodle-
Core System enthalten sind, werden dem Kunden grundsätzlich angeboten und sind daher in
der Zusammenfassung nicht aufgelistet. Eine genaue Auflistung der Moodle-
Standardfunktionen findet sich unter http://www.moodle.org.
15/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
4.2.1. HS 2
Organisation und Management
Kunden erhalten eine komplette Moodle-Installation (independent Moodle installation).
Integration
Gemäss der Standard-Policy werden Nutzer nach 90 Tagen Inaktivität in einem Kurs aus
diesem ausgetragen. Kundenspezifische Policies können ausgehandelt werden, um z.B.
Alumni dauerhaften Zugang zu den Kursen zu ermöglichen.
Erweiterungsmöglichkeiten
Es werden einige von der HS 2 entwickelte Extensionen angeboten. Zusätzlich stehen den
Kunden die Erweiterungen Turnitin (Anti-Plagiat-Service) und LAMS (Visualisierung von Studierendeaktivitäten)
zur Verfügung.
Sicherheit
Die Authentifizierung erfolgt via AAI oder über lokale Accounts.
Funktionalitäten
Es gelten die Standardfunktionen von Moodle mit den oben erwähnten Erweiterungen.
Benutzerfreundlichkeit (Usability)
Neben der offiziellen Dokumentation bietet die HS 2 einige angepasste Tutorials und Handbücher
an.
Support
Die HS 2 bietet folgende Support-Dienste an: 1st-, 2nd- und 3rd-Level-Support, didaktischen
Support sowie Schulungen und Tutorials.
Verfügbarkeit
Maximal ein Wartungsfenster von zwei Stunden pro Monat. Keine Wartung in Prüfungsperioden.
Maximal ein Tag Serviceunterbruch pro Jahr in den Semesterferien für grössere Systemupgrades.
Jeder Kurs wird täglich mit einer Vorhaltezeit von einem Tag gesichert. Tägliches Systembackup,
wobei von jeder Datei die fünf letzten Versionen verfügbar sind. Pro Monat bleibt ein
Systembackup für ein Jahr verfügbar.
16/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
Skalierbarkeit
Aufgrund der Datenlage ist keine Aussage möglich.
Kosten
Grobe Schätzungen:
• Einmalige Setup-Gebühr
• Kosten für Hardware
• Gebühr pro Kurs pro Jahr
• Gebühr pro Student pro Jahr
• Optional:
o Gebühr für Support
o Gebühren für Schulungen
o Gebühren für kostenpflichtige Software
(Siehe Auswertung in Kapitel 5.)
4.2.2. ETH 1
Organisation und Management
Kunden erhalten eine komplette Moodle-Installation (independent Moodle installation).
Integration
Kundenspezifische Integrationen werden angeboten.
Erweiterungsmöglichkeiten
Grundsätzlich werden nur Kernfunktionen sowie gut unterstützte und gewartete Erweiterungen
angeboten. Der Kunde entscheidet, welche Erweiterungen installiert oder entwickelt
werden sollen und zu welchem Zeitpunkt sie installiert werden. Die Erweiterungen müssen
den Qualitätsanforderungen der ETH 1 genügen.
Sicherheit
Die Authentifizierung erfolgt mit AAI (empfohlen) oder lokalen Accounts.
Funktionalitäten
Es gelten die Standardfunktionen von Moodle.
17/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
Benutzerfreundlichkeit (Usability)
Eine Dokumentation wird angeboten.
Support
Die ETH 1 bietet 1st-, 2nd- und 3rd-Level-Support (keine Softwareentwicklung), didaktischen
Support sowie Schulungen und Tutorials an.
Verfügbarkeit
Die Verfügbarkeit wird mit dem Kunden vereinbart.
Skalierbarkeit
Die Skalierbarkeit wird mit dem Kunden vereinbart.
Kosten
Grobe Schätzungen:
• Jährlicher Fixpreis
• Optional:
o Stundentarif für kundenspezifische Integrationen oder Anpassungen
(Siehe Auswertung in Kaptitel 5.)
4.2.3. Kommerzieller Anbieter 1
Organisation und Management
Kunden erhalten bei Bedarf eine komplette Moodle-Installation (independent Moodle installation).
Integration
Kundenspezifische Integrationen werden angeboten.
Erweiterungsmöglichkeiten
Innerhalb der jeweiligen Instanzen können individuelle Installationen von Erweiterungen eingesetzt
werden. Der kommerzielle Anbieter 1 bietet unter anderem das E-Portfolio Mahara
als Erweiterung an. Entwicklung und Integration von Erweiterungen und Anbindung externer
Applikationen können in Auftrag gegeben werden.
18/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
Sicherheit
Identifikation über LDAP, Active Directory, lokale Accounts und AAI.
Funktionalitäten
Es werden die Standardfunktionen von Moodle unterstützt. Kundenwünsche können berücksichtigt
werden.
Benutzerfreundlichkeit (Usability)
Aufgrund der Datenlage ist keine Aussage möglich.
Support
Der kommerzielle Anbieter 1 ist für die Applikationswartung zuständig, ein Hosting-Partner
für den Betrieb der Infrastruktur. Es wird 2nd- sowie 3rd-Level-Support geleistet. Das SLA
kann an die Anforderungen der Hochschule angepasst werden. Didaktischer Support kann
über Partnerfirmen erfolgen.
Verfügbarkeit
Die garantierte Verfügbarkeit und der Preis hängen von dem gewählten Hosting-Anbieter
und dem vereinbarten SLA ab.
Skalierbarkeit
Die Skalierbarkeit wird mit dem Kunden vereinbart.
Kosten
Zusammensetzung der Kostenpakete:
Einmalig für die Gesamt-Plattform
o Detailanalyse und Konzeption
o Installation und Konfiguration der Initial-Infrastruktur
Einmalig pro Hochschule
o Analyse des aktuellen Moodle Source Codes
o Sicherheitsanalyse aller eingesetzten Moodle-Module
o Datenmigration aus bestehender Moodle-Installation
o Testing und Deployment
Jährliche/monatliche Kosten
o für die Gesamt-Plattform oder Hochschule (nach Vereinbarung)
19/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
o
o
4.3. OLAT
Kosten für Hosting
Supportkosten gemäss SLA
Im Rahmen der Befragungsphase traten eine kommerzielle und eine universitäre Einrichtung
als OLAT-Hosting-Anbieter auf dem Schweizer Markt auf. Die angebotenen Dienstleistungen
werden nachfolgend in komprimierter Form präsentiert. Alle Funktionen, die im OLAT-Core-
System enthalten sind, werden obligatorisch angeboten und daher in der Zusammenfassung
nicht weiter ausgeführt. Eine genaue Auflistung der OLAT-Standardfunktionen findet sich unter
http://www.olat.org.
4.3.1. HS 3
Organisation und Management
Kunden nutzen die OLAT-Instanz der HS 3.
Integration
Aktuell können Daten wie Noten oder Kreditpunkte mit Hilfe einer Excel-Tabelle in das Campus-Management-System
übertragen werden. Die OLAT-Instanz der HS 3 muss von den
Kunden genutzt werden.
Erweiterungsmöglichkeiten
Es werden in erster Linie die Standardfunktionen angeboten.
Sicherheit
AAI/Shibboleth, AAI-VHO für externe Nutzer. Der Kunde muss Mitglied der AAI-Föderation
sein und einen eigenen Identity Provider betreiben.
Funktionalitäten
Es gelten die Standardfunktionen von OLAT. Zusätzlich besteht Zugriff auf ein externes Anti-
Plagiat-Tool. Der Zugriff auf Kurselemente kann unter anderem durch die Nutzerkompetenz
gesteuert werden, die an der erreichten Punktzahl gemessen wird.
Benutzerfreundlichkeit (Usability)
Es besteht Zugriff auf eine mehrsprachige offizielle Dokumentation. Des Weiteren stehen
eine kontextspezifische Hilfe, aufgaben- und anwenderorientierte Quick-Guides sowie Video-
Tutorials zur Verfügung.
20/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
Support
Es wird kein 1st-Level-Support angeboten. Pro Monat erhalten Kunden zwei Stunden 2nd-
Level-Support und einmalig einen 3rd-Level- und didaktischen Support sowie eine Schulung
und den Zugriff auf Tutorials.
Verfügbarkeit
Jedes Jahr werden zwei grössere sowie bis zu sechs kleinere Releases gefahren. Für jedes
Release bestehen zwei Stunden Downtime. Jede Nacht wird ein automatisches Backup
durchgeführt.
Nutzerprofile und Lernressourcen werden gesichert und nach zwei Jahren Inaktivität mit
Vorankündigung gelöscht.
Skalierbarkeit
Die Kapazität kann bei steigenden Nutzerzahlen und den damit verbundenen Begleiterscheinungen
entsprechend angepasst werden.
Kosten
Fixer Preis pro Jahr und Institution bei bis zu 10'000 Nutzern.
4.3.2. Kommerzieller Anbieter 2
Organisation und Management
Kunden erhalten eine komplette OLAT-Installation (independent OLAT installation).
Integration
Aktuell können Daten mit Hilfe einer Excel-Tabelle exportiert und User importiert werden.
Zusätzlich werden kundenspezifische Integrationen angeboten. Eine Webservice Schnittstelle
(REST API) bietet die Möglichkeit externe Systeme anzubinden.
Erweiterungsmöglichkeiten
Bei Bedarf können zusätzliche Erweiterungen entwickelt und implementiert werden. Erweiterungen,
die von einem Zusammenschluss mehrerer Hochschulen entwickelt wurden, können
vom kommerziellen Anbieter 2 implementiert werden. Erweiterungen werden je nach Eignung
in das Standard-Release übernommen. Erweiterungen, die nicht in das Standard-
Release übernommen werden, werden gegen einen geringen Aufpreis ebenfalls gewartet.
21/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
Sicherheit
Die Authentifizierung erfolgt mit AAI/Shibboleth, LDAP-Authentifizierung oder lokalen Accounts.
Funktionalitäten
Es gelten die Standardfunktionen von OLAT mit den oben erwähnten Erweiterungen. Zusätzlich
besteht Zugriff auf ein externes Anti-Plagiat-Tool. Es existieren weitere Funktionalitäten,
die nur im Release des kommerziellen Anbieters 2 enthalten sind.
Benutzerfreundlichkeit (Usability)
Neben der offiziellen, als OLAT-Kurs integrierten Dokumentation, wird zusätzlich eine kontextabhängige
Hilfe zur Verfügung gestellt.
Support
Es wird kein 1st-Level-Support angeboten. 2nd- und 3rd-Level-Support werden für SLA
Standard montags bis freitags von 08:00–18:00 Uhr mit einer Reaktionszeit von acht Stunden
angeboten. SLA Premium wird montags bis sonntags von 06:00–22:00 Uhr an 365 Tagen
im Jahr mit drei Stunden Reaktionszeit angeboten.
Ein didaktischer Support wird bereitgestellt und zielgruppenorientierte Trainings werden angeboten.
Verfügbarkeit
Die Verfügbarkeit von OLAT hängt vom SLA ab und kann in Zusammenarbeit mit den Kunden
spezifiziert werden.
Skalierbarkeit
Die Kapazität kann bei steigenden Nutzerzahlen und den damit verbundenen Begleiterscheinungen
entsprechend angepasst werden.
Kosten
Die entstehenden Kosten hängen vom Setup und der Anzahl der Nutzer ab. Die Summe
setzt sich aus einem Anschaffungs- und einem monatlichen Grundpreis zusammen, der von
der Anzahl der User abhängt.
22/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
5. Ergebnisse und Diskussion der Szenarien
Wie aus den Umfrageergebnissen hervorgeht, gibt es für alle in der Studie berücksichtigten
Lernplattformen potenzielle Anbieter und Bezüger von Hosting-Diensten. Die nachfolgende
Tabelle 4 zeigt eine Übersicht darüber, wie viele Institutionen aktuell die analysierten LMS
nutzen, wie viele an einem Outsourcing interessiert sind und wie viele Dienstanbieter es gibt.
Die Tabelle zeigt kein vollständiges Bild für die Situation in der Schweiz, weil als Basis ausschliesslich
die Antworten auf die Umfrage dienen. Dies betrifft insbesondere die Anzahl der
aktuellen Installationen an den Institutionen, die für alle drei LMS tatsächlich höher ist.
ILIAS Moodle OLAT
Von Institutionen aktuell verwendet 2 8 3
Institutionen, die daran interessiert
sind, LMS als Hosting-Dienst zu beziehen
1 6
(+1)
3
Anbieter von Hosting-Diensten 2 3 2
Tabelle 4: Anzahl der Institutionen, die bestimmte LMS verwenden, Anzahl der an Outsourcing interessierten Institutionen
sowie Anzahl potenzieller Hosting-Anbieter
Grundsätzlich zeigt sich, dass Institutionen, die aktuell ein LMS nutzen, mit deren Leistung
und Funktionsumfang weitgehend zufrieden sind. Ein Umstieg auf ein alternatives LMS wird
praktisch nie in Erwägung gezogen.
Ein Teil der Hochschulen, die gegenwärtig ein eigenes LMS betreiben, erwägt kein Outsourcing.
Begründet wird dies in den meisten Fällen mit der Befürchtung, dass durch das
Outsourcing der Einfluss auf die Konfigurier- und Erweiterbarkeit des LMS beeinträchtigt
würde. Ausserdem seien die kurzen Kommunikationswege zwischen E-Learning-Support
und technischen Betreibern von Vorteil. Darüber hinaus ist an jenen Institutionen kein ökonomischer
Vorteil durch Outsourcing zu erwarten, an denen die Betreiber der LMS keine
Vollkostenrechnungen anstellen müssen.
5.1. ILIAS
Zwei der an der Umfrage beteiligten Institutionen haben angegeben, ILIAS zu nutzen, und
eine davon ist prinzipiell bereit, ILIAS mit ca. 9'000 Usern als Hosting-Dienst zu beziehen.
Zurzeit gibt es zwei Diensteanbieter.
Aufgrund der niedrigen Zahl an potenziellen Dienstebezügern ist die weitere Entwicklung eines
skalierbaren nationalen Diensteangebots wenig sinnvoll. Dennoch steht es den interessierten
Hochschulen frei, individuelle Verträge mit den Anbietern für ILIAS-Hosting-Dienste
abzuschliessen.
23/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
5.2. Moodle
Acht der an der Umfrage beteiligten Institutionen nutzen aktuell Moodle. Nur ein Teil davon
ist an einem Outsourcing interessiert. Dazu kommen einige wenige Institutionen, die zu einer
Migration auf Moodle bereit wären, oder die gegenwärtig noch kein LMS verwenden. Daraus
ergeben sich sechs Interessenten für ein Outsourcing. Eine Institution sieht sich mit zahlreichen
ungeklärten Fragen konfrontiert, die ein Outsourcing zur Folge hätte. Sie möchte sich
aber dennoch die Option offenhalten, Moodle demnächst als Dienst zu beziehen. Alle Interessenten
eingeschlossen ergäbe sich eine potenzielle Nutzerbasis von ca. 50'000 Usern.
Selbst wenn sich nur ein Teil der Interessenten zu einem Outsourcing von Moodle-Diensten
entschlösse, dürften sich dank der Bündelung von Know-how und aufgrund von Skaleneffekten
ökonomisch und organisatorisch interessante Perspektiven eröffnen. Mit drei ernsthaften
Anbietern wäre auch gewährleistet, dass sich ein gesunder Markt für Moodle-Dienste bilden
könnte.
Vergleich von Angebot und Nachfrage
Alle Institutionen, die an einem Moodle-Dienst interessiert sind, fordern eine hohe Flexibilität
bezüglich Konfigurierbarkeit, Integrierbarkeit, Erweiterbarkeit und Verwaltung der Lernplattform.
Da Moodle die Mandantenfähigkeit fehlt, ist dies praktisch nur dadurch zu erreichen,
dass jeder Institution eine eigene Instanz bereitgestellt wird. Alle Diensteanbieter offerieren
separate Moodle-Instanzen, unterscheiden sich aber bezüglich Virtualisierungsgrad und Skalierungsmöglichkeiten
auf der System- und Hardwareebene. Der kommerzielle Anbieter 1
bietet separate Instanzen auf virtualisierter Hardware gemäss Architekturmodell 8.1.2 basierend
auf deren eigener virtueller Server-Infrastruktur. Der kommerzielle Anbieter 1 bietet
ebenfalls separate Instanzen auf einer virtuellen Serverinfrastruktur an, die bei einem Hosting-Partner
eingekauft werden kann. Der kommerzielle Anbieter 1 kann die Architekturmodelle
8.1.1, 8.1.2, 8.1.3, 8.1.4 realisieren, betont jedoch dass das Modell 8.1.3. die Hardware
besonders effizient nutzt und gleichzeitig sehr weitreichende Skalierungsmöglichkeiten bietet.
Alle Anbieter offerieren sämtliche Supportlevels. Allerdings möchten die Dienstebezüger den
1st- und 2nd-Level-Support inhouse behalten, und nur die Hälfte von ihnen kann sich vorstellen,
den 3rd-Level-Support auszulagern. Ähnlich sieht es aus mit Schulungen und Tutorials.
Während die Anbieter weitreichende Schulungsofferten machen, planen die Institutionen,
diese selber anzubieten. Lediglich bei sehr spezifischen oder komplexen Schulungsaufgaben
ist ein Outsourcing punktuell denkbar.
Bezüglich Verfügbarkeit scheinen die Anbieter die teilweise recht hohen Anforderungen zu
erfüllen. Da die Anbieter flexibel sind, kann bzw. muss die Verfügbarkeit von Fall zu Fall
ausgehandelt werden, was sich gegebenenfalls auf die Kosten auswirkt. Das gleiche gilt für
die Skalierbarkeit.
Es ist schwierig, Aussagen darüber zu machen, ob die Preis- und Kostenvorstellungen von
Anbietern und Nachfragern zueinander passen. Zum einen haben die Hochschulen, die Interesse
an einer gemeinsam betriebenen Lösung bekundet haben, ihre derzeitigen Vollkosten
nicht offengelegt und somit keinen Rahmen für die Orientierung geliefert, zum anderen
machen auch die Hochschulen, die Moodle-Dienste anbieten, keine öffentlichen Aussagen
über ihre Preise. Lediglich der kommerzielle Anbieter 1 wagt eine (wie vom Projektteam erbetene)
sehr grob geschätzte und unverbindliche Preisvorstellung. Die Preise liegen für die
24/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
Gesamtplattform in der Grössenordnung von 50’000-150'000 Franken einmalig und 3’000-
6'000 Franken monatlich. Diese Kosten sind durch die Anzahl beteiligter Hochschulen zu teilen.
Einmalig sind pro Hochschule für das Setup und die Datenmigration zusätzlich 20’000-
30'000 Franken zu veranschlagen. Nicht inbegriffen sind hier Support und Training.
5.3. OLAT
Gegenwärtig verwenden drei an der Umfrage beteiligte Institutionen OLAT. Eine Besonderheit
im Vergleich zu Moodle und ILIAS ist, dass alle drei Institutionen bereits OLAT als
Dienst beziehen und damit auch weitgehend zufrieden sind. Bei einer Institution hängt die
künftige Nutzung von OLAT vom Ergebnis der Evaluation ab, die zurzeit durchgeführt wird.
Einer weiteren Institution ist die Zusammenarbeit mit Partnerschulen wichtig. Falls sich an
den Partnerschulen ein anderes LMS als OLAT etablieren sollte, würde daher ein Umstieg
erwogen. Die Benutzerbasis dieser Einrichtung beträgt ca. 5'000 Nutzer.
Die Schweizweite Benutzerbasis von OLAT an Hochschulen umfasst aktuell ca. 50'000 Nutzer.
Den drei Dienstebezügern stehen zwei Anbieter gegenüber. Aufgrund der niedrigen Anzahl
von potenziellen Dienstebezügern und der relativ kleinen Benutzerbasis der an der Umfrage
beteiligten Hochschulen erscheint die weitere Entwicklung eines skalierbaren nationalen
Diensteangebots wenig sinnvoll. Dennoch steht es den interessierten Hochschulen frei, individuelle
Verträge mit den Anbietern für OLAT-Hosting-Dienste abzuschliessen.
25/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
6. Konklusion und weiteres Vorgehen
Anhand der gewonnenen Ergebnisse zeigte sich, dass die Anzahl an potenziellen Dienstbezügern
für das Learning Management System Moodle am stärksten ausgeprägt ist. Eine weitere
Entwicklung eines skalierbaren nationalen Dienstangebots an den (Fach-)Hochschulen,
die einen Hosting-Dienst für Moodle beziehen wollen, ist in einem Folgeprojekt zu prüfen.
Die Ergebnisse der Umfrage zeigten, dass bei den teilnehmenden Institutionen das Interesse
und die Anzahl potenzieller Dienstbezüger für die Plattformen OLAT und ILIAS für die weitere
Entwicklung eines skalierbaren nationalen Dienstangebots nicht stark genug ausgeprägt
sind (siehe Tabelle 5).
ILIAS Moodle OLAT
Von Institutionen aktuell verwendet 2 8 3
Institutionen, die daran interessiert
sind, LMS als Hosting-Dienst zu beziehen
1 6
(+1)
3
Anbieter von Hosting-Diensten 2 3 2
Tabelle 5: Anzahl der Institutionen, die bestimmte LMS verwenden, Anzahl der an Outsourcing interessierten Institutionen
sowie Anzahl potenzieller Hosting-Anbieter
6.1. Zielerreichung
Die Beteiligung der angeschriebenen Hochschulen war sehr unterschiedlich. Daher dürfen
die Ergebnisse einzig und allein auf die beteiligten Hochschulen bezogen werden und dürfen
nicht verallgemeinert werden.
Im Rahmen der Machbarkeitsstudie sollten die Möglichkeiten eines gemeinsamen Betriebes
eines oder mehrerer LMS geprüft werden. Die folgende Tabelle zeigt eine Übersicht der Ziele,
die im Rahmen der Machbarkeitsstudie erreicht werden sollten, sowie die damit verknüpften
Ergebnisse.
Ziel
Ergebnisse
Erfassung der Bedürfnisse und Anforderungen
der Businessapplikationsdienste (SBA)
und der Informatikdienste (FID) an den
Hochschulen
Ziel erreicht.
26/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
Klärung der Mandantenfähigkeit der derzeit
verfügbaren Lösungen sowie der Anbindungsmöglichkeiten
an die gängigen Schuladministrationssysteme
(z.B. Evento, eAcademia,
SAP etc.) und dem Identity-
Management-System der Hochschulen
(zwingend AAI-fähig)
Evaluation und Vorschlag zu unterstützender
Plattformen
Abschätzung der Total Cost of Ownership
(TCO) einer zentralisierten Lösung
Organisatorische und rechtliche Aspekte einer
zentralen Lösung
Technische Aspekte einer zentralen Lösung
(Skalierbarkeit, Sicherheit)
Konzept für die Erbringung der geforderten
Leistungen, entweder durch den kooperativen
und nachhaltigen Betrieb einer eLearning-Plattform
an einer Hochschule (intern)
oder alternativ durch einen externen Dienstleistungsanbieter
Erstellung eines Modells für bedarfsgerechte
Supportleistungen
Ziel teilweise erreicht. Mandantenspezifische
Anpassungen müssen in der Regel durch
spezialisierte Unternehmen realisiert werden.
Die Anbindungsmöglichkeiten an die gängigen
Schuladministrationssysteme sind nicht
restlos geklärt. Dies müsste in einem möglichen
Folgeprojekt geklärt werden.
Ziel erreicht.
Ziel teilweise erreicht.
Die internen Kosten der jeweiligen Hochschulen
konnten teilweise nicht oder nicht
ausreichend detailliert erhoben werden. Die
TCO müssen von den beteiligten Institutionen
intern selber erstellt werden.
Dies müsste in einem möglichen Folgeprojekt
geklärt werden.
Ziel nicht erreicht.
Aufgrund der kantonalen Unterschiede und
der damit verbundenen zeit- und ressourcenintensiven
Arbeiten konnte dieser Aspekt
nicht bearbeitet werden.
Dies müsste in einem möglichen Folgeprojekt
zu klären sein.
Ziel teilweise erreicht.
Dies müsste in Form eines SLAs im möglichen
Folgeprojekt mit dem designierten Anbieter
ausgearbeitet werden.
Ziel erreicht.
Ziel teilweise erreicht.
Dies müsste in Form eines SLAs im möglichen
Folgeprojekt mit dem designierten Anbieter
ausgearbeitet werden.
27/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
Tabelle 6: Ziele und Ergebnisse der Machbarkeitsstudie
6.2. Weiteres Vorgehen
Der vorliegende Bericht wird von der Fachkommission Informatikdienste (FID) verabschiedet
und den verantwortlichen Stellen der Konferenz der Fachhochschulen der Schweiz (KFH)
vorgestellt.
6.3. Ausblick auf ein mögliches Folgeprojekt
Die Entwicklung des Learning-Management-Systems Moodle steht bis Ende 2010 vor einem
wichtigen Evolutionsschritt (Wechsel der Releases von 1.9.x auf 2.0). Dies bedeutet einen
erhöhten Migrationsaufwand für alle Hochschulen, die Moodle aktuell einsetzen. Es bietet
sich also an, mit den interessierten Hochschulen ein Folgeprojekt für Moodle-Hosting zu starten,
das folgende Ziele verfolgt:
Ziel:
Evaluation eines geeigneten Hosting-
Anbieters
Bemerkung
Eventuell ist eine Ausschreibung notwendig.
Dies könnte unter der Leitung von SWITCH
für alle interessierten Hochschulen geschehen.
Anbindungsmöglichkeiten an die gängigen
Schuladministrationssysteme (z.B. Evento,
eAcademia, SAP etc.) bewerkstelligen
Abschätzung der Total Cost of Ownership
(TCO) einer zentralisierten Lösung
Die internen Kosten der jeweiligen Hochschulen
können aufgrund der aktuellen Datenlage
nicht angegeben werden und müssen
von den beteiligten Hochschulen intern
zur Abschätzung selber erstellt werden.
Organisatorische und rechtliche Aspekte einer
zentralen Lösung
Technische Aspekte einer zentralen Lösung
(Skalierbarkeit, Sicherheit)
Erstellung eines Modells für bedarfsgerechte
Supportleistungen
Dies ist in Form eines SLAs mit dem designierten
Anbieter auszuarbeiten.
Dies ist in Form eines SLAs mit dem designierten
Anbieter auszuarbeiten.
Tabelle 7: Ziele des möglichen Folgeprojektes
28/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
6.4. Kostenrahmen für eine Gesamtplattform
Die möglichen Kosten für eine Gesamtplattform hängen von diversen Aspekten ab. So beeinflussen
unter anderem die vorhandene Infrastruktur, hochschulspezifische Systemanpassungen
und Service-Level-Agreements die entstehenden Kosten.
Tabelle 8 zeigt einen möglichen Kostenrahmen für eine gemeinsam betriebene Moodle-
Lernplattform. Dieser Kostenrahmen basiert auf den geschätzten Preisvorstellungen, die der
kommerzielle Anbieter 1 auf Bitten der Projektgruppe erstellt hat. Die Kostenmodelle der als
Hosting-Anbieter auftretenden Hochschulen sind nicht öffentlich einsehbar und können daher
nicht in der unten stehenden Kalkulation berücksichtigt werden. In dieser Tabelle fehlen jedoch
die internen Kosten der beteiligten Hochschulen. Um die Total Cost of Ownership zu
erhalten, müssen die internen Kosten von jeder interessierten Institution geschätzt und auf
das unten stehende Kostenmodell addiert werden.
Einmalige Kosten Gesamtplattform
(durch Anzahl
beteiligter Hochschulen
zu teilen)
Einmalige Kosten pro
Hochschule
Monatliche Kosten
pro Hochschule
Weitere Kosten
50'000 - 150'000 CHF 20'000 - 30'000 CHF 3'000 - 6'000 CHF 1st-, 2nd-, 3rd-Level-
Support, didaktischer
Support, Trainings
Tabelle 8: Möglicher Kostenrahmen für eine gemeinsam betriebene Moodle-Lernplattform
Die Kosten sind in einem Folgeprojekt mit den aktuellen Betriebskosten der jeweiligen teilnehmenden
Hochschule zu vergleichen.
29/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
7. Anhang: Lastenheft – Anfrage an Hosting-Anbieter
7.1. Situation
Im Rahmen der Machbarkeitsstudie UHU - Universities Hosting United wurden im März 2010
Fragebogen an alle Schweizer Hochschulen (ETHs, kantonale Universitäten, Fachhochschulen,
pädagogische Hochschulen) gesandt. Die Umfrage hatte zum Ziel, die Bereitschaft
und Anforderungen der Hochschulen für das Outsourcing des Betriebs von Lernplattformen
zu erheben.
Insgesamt meldeten zehn Institutionen ein grundsätzliches Interesse an LMS-Outsourcing.
Gewünscht wurden Hosting Services für Moodle (7x), OLAT (3x) und ILIAS (1x). OLAT stellt
einen Sonderfall dar, weil alle drei Institutionen, die OLAT fordern, diese Plattform bereits
heute als ausgelagerten Dienst nutzen.
Die in diesem Dokument aufgeführten Anforderungen stellen die zusammengefassten Antworten
der an einem LMS Outsourcing interessierten Institutionen dar. Das Ziel ist nun, Hosting-Modelle
für LMS zu entwickeln, die den Anforderungen so weit wie möglich Genüge
leisten.
Dabei ist es wichtig anzumerken, dass UHU keine formelle Ausschreibung mit Evaluation ist,
sondern lediglich eine Machbarkeitsstudie. Die von den Institutionen gelieferten Anforderungen
sind uneinheitlich und oft unterschiedlich genau formuliert. Ebenso sind sie nicht verbindlich,
und es besteht seitens der Institutionen keine Verpflichtung, auf ein passendes Angebot
einzugehen.
Daher wird von potenziellen Diensteanbietern auch keine Offerte im eigentlichen Sinne erbeten.
Vielmehr soll den Diensteanbietern die Möglichkeit gegeben werden, ein oder mehrere
passende Hosting-Angebote zu entwickeln und grob geschätzte Preisvorstellungen zu formulieren.
Die Anforderungen und Angebote werden im UHU-Schlussbericht zusammengefasst und
diskutiert. Falls für die potenziellen Dienstnutzer und -anbieter die Aussicht auf eine erfolgversprechende
Kooperation besteht, wird deren Realisierung in einem Folgeprojekt gesondert
angegangen werden.
7.2. Vorgehen
Potenzielle Diensteanbieter werden gebeten, ein oder mehrere generelle Hosting-Szenarien
zu entwickeln. Als Basis dienen die unten aufgelisteten Anforderungen mit dem im vorliegenden
Lastenheft zu Grunde gelegten Mengengerüst. Dort, wo für die Szenarienentwick-
30/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
lung oder Preiskalkulation nötige Angaben fehlen, kann der Diensteanbieter entweder vernünftige
Annahmen machen (und deklarieren!) oder mit der Projektleitung Rücksprache halten.
Die in Kapitel 7.3.1 und 7.3.7 genannten Anforderungen sind entweder sehr individuell oder
besonders unscharf deklariert. Hier werden die Diensteanbieter gebeten, einige typische
Szenarien zu entwickeln, die als Optionen bezogen werden könnten. Das Ziel soll sein, den
Institutionen einige plastische Beispiele für optionale Dienstleistungspakete und deren Preis
zu geben.
Praktisch ausnahmslos ist für die Institutionen die Migration auf ein alternatives LMS ausgeschlossen.
Auf die in Kapitel 7.3.4, 7.3.5. und 7.3.6 genannten Anforderungen muss daher
nicht speziell eingegangen werden, da diese LMS-Basisfunktionalitäten betreffen, die den
aktuellen Erfordernissen der Institutionen genügen.
Die in Kapitel 8 skizzierten Hosting-Architekturen bilden keine abschliessende Aufzählung.
Sie dienen der Definition von Begriffen, auf die sich ein Diensteangebot beziehen kann.
7.3. Umfrage: Fragebogen
7.3.1. Organisation und Management
Abbildung der hochschulspezifischen Organisationsstrukturen auf das LMS-
Strukturverzeichnis
Das eingesetzte System muss eine individuelle Konfiguration und Abbildung aller gewünschten
hochschulspezifischen Organisationsstrukturen ermöglichen.
Anpassung des "Look and Feel" an Kundenwünsche
Das eingesetzte System muss eine Anpassung des Layouts (Themes, Blocks) auf
verschiedenen Organisationsebenen erlauben. Dabei müssen die Corporate-Identity-
Vorgaben der jeweiligen Hochschule integrierbar sein.
Anpassung des Standard-Toolsets
Das eingesetzte System soll eine einfache Anpassung des Standard-Toolsets (Hinzufügen/Entfernen)
bei unterschiedlichen Organisationsstrukturen ermöglichen, ohne
dass sich dies auf die Gesamtstruktur auswirkt.
Struktur der Rollen und Rollenmodelle
Das eingesetzte System soll neben Standardrollen auch die Adaption der Rechte
vorhandener Rollen und die Generierung neuer Rollen unterstützen.
31/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
7.3.2. Integration
Integration des LMS in bestehende Arbeitsprozesse
Das genutzte System soll eine Automatisierung diverser Verwaltungsprozesse ermöglichen.
Neben der Erstellung von Nutzer-Accounts, Kursen und Einschreibungen
aus der jeweiligen, hochschulspezifischen Verwaltungssoftware müssen auch Rückmeldungen
aus dem LMS (z.B. Noten, Kursabschluss etc.) an die Verwaltungssoftware
möglich sein.
Anforderungen an Schnittstellen bezüglich der Integration externer Systeme
Die Hochschulen spezifizierten keine Anforderungen bezüglich der Integration externer
Systeme.
7.3.3. Erweiterungsmöglichkeiten
Vorgehensweise für die Entwicklung und Installation von Erweiterungen
Ein standardisiertes und umsichtiges Vorgehen für die Entwicklung und Installation
von Erweiterungen ist gefordert. Das genutzte System soll bei Bedarf auch die Installation
von Erweiterungen bei einzelnen Organisationsstrukturen ermöglichen.
Bezüglich der Implementierung von Erweiterungen wird eine standardisierte Kommunikationspolitik
mit den Endnutzern vorausgesetzt. Das genutzte System soll eine
Deinstallation oder Deaktivierung von Erweiterungen bei einzelnen Organisationsstrukturen
ermöglichen.
Anforderungen an Schnittstellen (APIs) in Bezug auf Erweiterungen
Es wurden keine speziellen Anforderungen spezifiziert. Die Anforderungen an
Schnittstellen ergeben sich aus den Ansprüchen, die diverse Erweiterungen mit sich
bringen werden.
7.3.4. Sicherheit
Eingesetztes Authentifikationsverfahren
Das genutzte System soll neben den gängigen Authentifikationsverfahren auch eine
Authentifizierung über die von SWITCH zur Verfügung gestellte Authentication and
Authorization Infrastructure (AAI) unterstützen.
32/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
Sicherheit von Kursdaten
Die Zugriffsrechte auf Kursdaten sollen über Rollen, AAI-Attribute, Gruppenzugehörigkeit
und Verfügbarkeitszeiträume gesteuert werden.
Sicherheit von Userdaten
Das genutzte System sollte die Anonymisierung von Nutzerdaten erlauben sowie eine
Deaktivierung der Erfassung von Userdaten auch auf den verschiedenen Organisationsebenen
ermöglichen.
Sichere E-Assessments
Diese Funktionalität wird aktuell nur vereinzelt verwendet. Nur eine Institution fordert
die Möglichkeit, sichere E-Assessments durchzuführen, und erwartet eine Exportfunktion
der Ergebnisse.
7.3.5. Funktionalitäten
• Verwendetes LMS
Moodle ILIAS OLAT
6 1 3
Nur eine der Einrichtungen zieht eine Migration auf eine andere LMS-Lösung in Betracht.
Die meisten Hochschulen streben eine Aktualisierung bzw. ein Upgrade des
verwendeten LMS in absehbarer Zeit an.
Integrierte Autorentools
Das genutzte System muss eine breite Palette an integrierten Autorentools bereitstellen.
Ebenso muss die Einbindung externer Lernpakete (SCORM) unterstützt werden.
Unterstützte Importformate
Gängige Importformate, wie SCORM, IMS, AICC, GIFT, XML, IMS-CP etc., müssen
durch das eingesetzte LMS unterstützt werden.
33/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
Unterstütze Exportformate
Neben Export- und Import von Anwendungsdaten innerhalb eines LM-Systems müssen
die gängigsten Exportformate, wie XML, HTML, TXT etc., unterstützt werden.
Unterstützung kollaborativer Arbeit
Das LMS soll nach Möglichkeit Schnittstellen zu diversen Kollaborationstools unterstützen.
Unterstützung von Mobile Learning
Das LMS sollte in naher Zukunft grundlegende Mobile-Learning-Funktionen unterstützen.
Unterstützung von Web-2.0-Funktionalitäten
Neben der Unterstützung von Web-2.0-Funktionalitäten durch Bordmittel wie Blogund
Wiki-Funktionen muss das LMS aktuelle Standards unterstützen und Schnittstellen
zu externen Applikationen ermöglichen.
Unterstützung von E-Portfolios
Das genutzte System soll die Integration von E-Portfolio-Modulen und die Verbindung
zu externen Lösungen (z.B. Mahara) unterstützen.
Unterstützung von Assessment- und Test-Applikationen
Neben den gängigen Bordmitteln zur Test- und Assessmenterstellung muss die Integration
von Tests und Assessments unterstützt werden, die mit externen Applikationen
erstellt wurden.
Unterstützung von Anti-Plagiat-Software
Die Integration von Anti-Plagiat-Software in ein bestehendes LMS wird aktuell nicht
von den Hochschulen gefordert. Die Thematik wird aktuell jedoch von den Hochschulen
aufgegriffen. Eine zukünftige Unterstützung von Anti-Plagiat-Software durch das
eingesetzte LMS ist jedoch wahrscheinlich und soll unterstützt werden.
Umfrage und Evaluationsfunktionalitäten
Das eingesetzte LMS soll durch eine ausgewogene integrierte Batterie an Funktionen
Umfragen und Evaluationen ermöglichen. Auch die Einbindung (Import) extern erstellter
Umfragen soll unterstützt werden.
34/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
Weitere Tools
Aktuell bieten die Hochschulen ihren Kunden eine Sammlung diverser Tools an. Neben
generellen externen Tools, die der Optimierung der Lehre dienen, stehen auch
administrative Tools zu Verfügung. Wünsche an das LMS (Moodle) bezogen sich auf
das Dokumenten-Management (Versionierung, Datenaustausch).
Generelle Anforderungen an die Funktionalitäten
Ein gutes Datei-Management wurde mehrfach gefordert (Versionierung, Sharing).
7.3.6. Benutzerfreundlichkeit (Usability)
Benutzeroberfläche
Das genutzte System muss ein gutes und einfaches Datei-Management unterstützen.
Massenoperationen wie das Hochladen mehrerer Dateien und "Drag & Drop"-
Funktionalitäten sollen unterstützt werden. Theme-Anpassungen für Personen mit
körperlichen Einschränkungen sollen ermöglicht werden.
Hilfefunktionen
Die Hochschulen sind mit der vorhandenen On-Board-Hilfe der jeweiligen LMS zufrieden.
Diese Angebote werden zusätzlich noch durch selbst erstellte oder externe
Schulungs- und Hilfsmaterialien erweitert. Jedoch sehen viele Hochschulen Bedarf an
verbesserten Hilfsmaterialien, die sich an diversen Tasks und den unterschiedlichen
Zielgruppen orientieren, die im Rahmen der LMS-Nutzung auftreten. Im diesen Rahmen
werden nicht nur text- und bildbasierte Hilfen, sondern auch videobasierte Tutorials
gewünscht.
7.3.7. Support
1st-Level-Support
Alle Hochschulen bieten den 1st-Level-Support inhouse an. Es besteht ein geringes
Interesse daran, den 1st-Level-Support an einen externen Dienstleister auszulagern.
2nd-Level-Support
Alle Hochschulen bieten den 2nd-Level-Support inhouse durch feste Einrichtungen
an. Eine Hochschule will den 2nd-Level-Support auslagern. Eine Hochschule macht
ein E-Mail-Helpdesk sowie eine klare Kommunikations- und Erreichbarkeitspolitik zur
Bedingung.
35/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
3rd-Level-Support
Hier zeichnet sich ein gemischtes Bild ab: Ungefähr die Hälfte der Hochschulen nutzt
auch hier internen Support, während die andere Hälfte diesen Dienst an externe Anbieter
ausgelagert hat. (Entweder kommerzielle Anbieter oder die entsprechenden
hochschultechnischen Pendants). Die Tendenz für zukünftige geforderte Entwicklungen
sieht eine Auslagerung des 3rd-Level-Supports vor. Auch eine Erhöhung der finanziellen
Mittel wird gefordert (1 HS).
Didaktischer Support
Alle Hochschulen decken den Bedarf an didaktischen Schulungen über interne Einrichtungen
ab. Komplexe und spezielle Themen könnten durch externe Anbieter
übernommen werden (Anforderung einer HS).
Training und Tutorials
Auch der Training Support wird durch interne Ressourcen abgedeckt. Es werden
überwiegend regelmässige Workshops angeboten. Für spezielle Themen oder bei
Anfrage werden extra Kurse/Schulungen generiert und angeboten. Das Angebot an
Tutorials spielt ebenfalls eine wichtige Rolle – wie auch die Workshops sollen sie aktuelle
Entwicklungen und Trends abbilden. Auch wurde hier einmal die Erstellung videobasierter
Daten als Soll-Zustand genannt.
Nur eine Institution will Trainingsaufgaben an externe Einrichtungen abgeben.
7.3.8. Verfügbarkeit
Wartungsfenster und Uptime
Aktuell stehen vielerorts wöchentliche oder gar tägliche Wartungsfenster offen. Bei
zwei Institutionen wird im Quartalsrhythmus gewartet. Wartungen finden oft zu
Abend- und Randzeiten statt. Nur vereinzelt wird auf Prüfungsphasen Rücksicht genommen.
Gewünscht wird eine hohe Verfügbarkeit, unter anderem weil auch Studierende in
anderen Zeitzonen auf die Plattform zugreifen. Must-have: keine Downtime länger als
acht Stunden (in den Semesterferien), maximal eine Downtime von zwei Stunden innerhalb
der Bürozeiten bei vier bis acht Wartungsfenstern pro Jahr. Downtimes müssen
im Vorfeld einen Monat vorher angekündigt werden.
Daten- und Kurs-Management, Backup, Archivierung
Aktuell täglich ein Systembackup. An einzelnen Schulen auch Kursbackup. Vorhaltezeit
drei Monate bis unbegrenzt. Unbenutzte Kurse und Accounts werden entweder
gar nicht, nach Rücksprache oder nach ca. einem Jahr gelöscht.
36/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
Erwünscht sind Kurs-Level-Backups und die Archivierung nicht mehr benötigter Kurse
nach ca. einem Jahr. Backup und Archivierung sind wichtige Themen, aber die Vorstellungen
darüber sind nicht immer genau.
7.3.9. Erweiterungsfähigkeit
ILIAS
• Anzahl Accounts und weitere Entwicklung
Insgesamt eine Institution interessiert sich für ein ausgelagertes ILIAS-Hosting.
Aktuelle Anzahl Accounts: ~9'000
Durchschnittliches tägliches Maximum: ~170. Maximale Spitzenlast: ~500
Storage: ~0.7T
Erwartete Anzahl User bis 2015: ~ + 20%
Erwartete Storage-Kapazität bis 2015: vierfaches Wachstum
Moodle
• Anzahl Accounts und weitere Entwicklung
Insgesamt sieben Institutionen interessieren sich für ein ausgelagertes Moodle-
Hosting.
Aktuelle Anzahl Accounts: ~50'000
Maximale Anzahl gleichzeitiger Nutzer: ~1500
Storage: ~2TB
Erwartete Anzahl User bis 2015: ~ + 20% (maximal +100%)
Erwartete Storage-Kapazität bis 1015: vierfaches Wachstum
OLAT
• Anzahl Accounts und weitere Entwicklung
Insgesamt drei Institutionen nutzen bereits ein ausgelagertes OLAT-Hosting.
Aktuelle Anzahl Accounts: ~5'000
37/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
Maximale Anzahl gleichzeitiger Nutzer: Aufgrund der Datenlage ist keine Aussage
möglich.
Storage: Aufgrund der Datenlage ist keine Aussage möglich.
8. Anhang: Hosting-Architekturen
Nachfolgend werden einige mögliche Architekturmodelle skizziert, die für das Hosting von
LMS für mehrere Hochschulen in Frage kommen könnten. Die Liste ist nicht vollständig,
sondern dient dazu, allgemeine Begriffe einzuführen, auf die in Offerten verwiesen werden
kann.
8.1.1. Independent LMS Installations
Each LMS installation is operated on its own hardware infrastructure.
8.1.2. Multiple LMS Copies
Independent LMS installations are operated on a dedicated or virtualized hardware infrastructure
(i.e. on a cluster of web servers behind a load balancer).
Options: The different LMS installations may be copies of the same code base, or alternatively
copies of different LMS versions.
38/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
8.1.3. Virtualized LMS
Multiple LMS instances (and Apache) are operated on a cluster of web servers behind a load
balancer. The LMS instances are instantiated from the same common code base. Each LMS
instance has its own URL/domain.
Options: The different LMS instances may alternatively be copies of different LMS versions.
8.1.4. Behemoth LMS
One single LMS instance is operated on a dedicated, virtualized or clustered hardware infrastructure.
The LMS is virtualized on the application level by creating separate categories/groups
for each university.
39/40

SWITCH, Werdstrasse 2, P.O. Box, CH-8021 Zürich
www.switch.ch
40/40