Lock-in ist nicht nur technisch
Vendor Lock-in bezeichnet eine Abhängigkeit, die einen Wechsel des Anbieters so teuer oder riskant macht, dass er praktisch nicht mehr in Frage kommt. Bei Cloud-Diensten entsteht diese Abhängigkeit selten nur durch Technik. Lizenzbündel, proprietäre Datenformate, eingespielte Prozesse, Integrationen und das Wissen der Mitarbeitenden wirken ebenso stark.
Eine vollständige Unabhängigkeit ist bei integrierten Plattformen wie Microsoft 365 weder realistisch noch immer wünschenswert. Ziel ist eine bewusste Abhängigkeit: Die Organisation kennt ihre Bindungen, hat sie bewertet und verfügt über einen gangbaren Plan für den Ernstfall.
Die Ebenen der Abhängigkeit
- Daten: Formate, Exportmöglichkeiten, Metadaten und Berechtigungen
- Anwendungen: Integrationen, Automatisierungen und Erweiterungen
- Identität: zentrale Anmeldung und Abhängigkeiten weiterer Dienste
- Verträge: Laufzeiten, Mindestmengen, Preisanpassungen und Kündigungsrechte
- Kompetenzen: internes Wissen und verfügbare Partner am Markt
Exit in die Ausschreibung schreiben
Der beste Zeitpunkt, um einen späteren Wechsel abzusichern, ist die Beschaffung. Anforderungen an Datenrückgabe, Exportformate, Unterstützung bei der Überführung, Fristen und Kosten gehören in die Unterlagen und in den Vertrag. Anbieter können aufgefordert werden, ihr Exit-Konzept darzulegen, das dann in die Bewertung einfliesst.
Der Bund hat mit dem Vorhaben Public Clouds Bund Rahmenverträge mit mehreren Hyperscalern abgeschlossen. Das zeigt einen Weg, Einzelabhängigkeiten zu begrenzen. Kleinere Organisationen werden kaum mehrere Plattformen parallel betreiben, können aber Verträge, Daten und Architektur so gestalten, dass ein Wechsel möglich bleibt.
Architektur mit Wechseloptionen
Offene Schnittstellen, dokumentierte Integrationen und eine saubere Trennung zwischen Daten und Anwendungslogik erhöhen die Wechselbarkeit. Bei KI-Lösungen gilt dies besonders: Wer Modelle über eine eigene Schicht anbindet, kann sie später austauschen, ohne alle Anwendungsfälle neu zu bauen.
Einen Exit regelmässig üben
Ein Exit-Plan, der nie überprüft wurde, ist eine Annahme. Sinnvoll sind stichprobenweise Exporttests, eine aktuelle Liste kritischer Integrationen und eine jährliche Überprüfung der Vertragsbedingungen. Für regulierte Organisationen ist ein dokumentiertes Exit-Szenario häufig auch aufsichtsrechtlich relevant.
Einordnung durch techtask
techtask bewertet Abhängigkeiten in Microsoft Cloud Umgebungen nüchtern und ohne Anbieterinteresse. Wir helfen, Exit-Anforderungen beschaffungstauglich zu formulieren und Architekturentscheide so zu treffen, dass die Organisation handlungsfähig bleibt.
Quellen
Primärquellen und offizielle Dokumentation.
Passende Beratung
Vom Wissen zur belastbaren Entscheidung.
Wir unterstützen Sie bei der Einordnung, Konzeption und Umsetzung im konkreten Organisationskontext.
Leistung ansehen