Vendor Lock-in ist kein technisches Problem. Es ist das Ergebnis von Entscheidungen, die nie als solche behandelt wurden.
Im Alltag wirken diese Entscheidungen harmlos. Ein Tool wird eingeführt, weil es schnell hilft. Eine Integration wird gebaut, weil sie gerade sinnvoll ist. Ein Vertrag wird verlängert, weil ein Wechsel Aufwand bedeutet.
Das ist nicht falsch. Es ist nur unvollständig.
Denn jede dieser Entscheidungen verschiebt Kontrolle. Und wenn niemand diese Verschiebung bewusst verantwortet, entsteht Abhängigkeit.
Wie Lock-in tatsächlich entsteht
Lock-in entsteht nicht durch ein einzelnes Produkt. Er entsteht durch die Struktur, in der Entscheidungen getroffen werden.
Typisches Muster in gewachsenen Organisationen:
Ein Team führt ein System ein, um ein konkretes Problem zu lösen. Andere Teams integrieren sich, weil es naheliegend ist. Mit jeder Integration steigt der Nutzen. Gleichzeitig sinkt die Austauschbarkeit.
Irgendwann ist das System nicht mehr nur ein Werkzeug. Es ist Teil des Betriebs.
Spätestens an diesem Punkt ist die Entscheidung nicht mehr technisch. Sie ist wirtschaftlich und organisatorisch. Nur wird sie selten so behandelt.
Das bekannte Beispiel: Microsoft 365.
Nicht die Einführung ist kritisch. Sondern das, was danach passiert. Identity wird zentralisiert. Kommunikation läuft darüber. Dokumente werden dort abgelegt. Geräte werden darüber verwaltet.
Jede Entscheidung für sich ist nachvollziehbar. In Summe entsteht eine Struktur, in der ein Wechsel nicht mehr realistisch ist, ohne den Betrieb zu gefährden.
Diese Situation ist nicht das Ergebnis von Vendor-Strategie. Sie ist das Ergebnis fehlender Steuerung auf Organisationsseite.
Die drei Ebenen der Abhängigkeit
Abhängigkeit entsteht gleichzeitig auf mehreren Ebenen. Wer nur eine betrachtet, unterschätzt das Risiko.
Lizenzabhängigkeit
Ein System wird so zentral, dass es nicht mehr ersetzt werden kann, ohne den Betrieb zu unterbrechen. Verträge werden verlängert, weil Alternativen kurzfristig nicht tragfähig sind.
Datenabhängigkeit
Daten sind formal exportierbar. Praktisch fehlt die Struktur, um sie sinnvoll zu migrieren. Historie, Referenzen und gewachsene Nutzung lassen sich nicht ohne Weiteres übertragen.
Betriebsabhängigkeit
Die kritischste Ebene bleibt oft unsichtbar. Betriebsentscheidungen liegen beim Anbieter. Recovery-Zeiten, Netzwerkkonfiguration, Failover-Verhalten.
Ein System kann sich wie eigene Infrastruktur anfühlen und ist es nicht.
Diese Ebenen verstärken sich gegenseitig. Wer sie getrennt betrachtet, erkennt das Problem zu spät.
Exit-Strategie ist eine Führungsentscheidung
Viele Organisationen behaupten, sie könnten jederzeit wechseln.
Gemeint ist meist: Daten lassen sich exportieren.
Das greift zu kurz.
Eine belastbare Exit-Strategie beantwortet andere Fragen:
Wer trägt die Verantwortung für einen Wechsel?
Welche Prozesse müssen im Zielsystem wiederhergestellt werden?
Wie lange darf der Betrieb eingeschränkt sein?
Welche Risiken werden akzeptiert und welche nicht?
Diese Fragen sind nicht technisch. Sie sind Führungsarbeit.
Solange sie nicht beantwortet sind, existiert keine Exit-Strategie. Nur eine Annahme.
Der richtige Zeitpunkt ist vor der Entscheidung
Lock-in wird nicht beim Wechsel sichtbar. Dort wird er nur spürbar.
Entstanden ist er vorher.
Jede Entscheidung für ein System verändert die eigene Handlungsfähigkeit. Wer diese Wirkung nicht bewertet, trifft unvollständige Entscheidungen.
Das bedeutet konkret:
Vor einer Integration muss klar sein, welche Abhängigkeit entsteht.
Vor einer Plattformentscheidung muss klar sein, wer sie später verantwortet.
Vor einer Vertragsbindung muss klar sein, unter welchen Bedingungen sie aufgelöst werden kann.
Diese Klärung verlangsamt Entscheidungen. Kurzfristig.
Langfristig verhindert sie Situationen, in denen Entscheidungen nicht mehr getroffen werden können.
Woran man fehlende Steuerung erkennt
Einige typische Symptome:
Niemand kann beziffern, was ein Wechsel kosten würde.
Verantwortung für Systeme ist verteilt, aber nicht eindeutig zugeordnet.
Betriebsrisiken werden erst im Störfall sichtbar.
Vertragsverlängerungen erfolgen unter Zeitdruck.
Diese Muster sind kein Zufall. Sie sind das Ergebnis fehlender struktureller Klarheit.
Was sich ändern muss
Organisationen müssen aufhören, Lock-in als technisches Risiko zu behandeln.
Es ist ein Steuerungsproblem.
Das bedeutet:
Abhängigkeiten werden bewusst entschieden, nicht implizit aufgebaut.
Verantwortung für Systeme ist klar zugeordnet.
Betriebsfähigkeit wird als Kriterium in Entscheidungen integriert.
Nicht jedes Risiko lässt sich vermeiden. Aber jedes Risiko lässt sich sichtbar machen und einordnen.
Genau dort entsteht Handlungsfähigkeit.
Platform Engineering für Organisationen mit gewachsener Systemlandschaft setzt an dieser Stelle an. Nicht bei der Auswahl von Tools, sondern bei der Struktur, in der Entscheidungen getroffen werden.