Fachwissen für digitale Entscheidungen
Was ist Vendor Lock-in und wie vermeidet man ihn?
Kurzantwort
Wo Abhängigkeit wirklich entsteht
Nicht in erster Linie beim Quellcode. Die häufigeren Ursachen:
- Kein Zugang zum Repository. Der Code liegt beim Dienstleister, Sie haben nie hineingesehen.
- Keine Dokumentation der Umgebung. Der Code allein nützt nichts, wenn niemand weiss, wie er ausgeliefert und betrieben wird.
- Zugangsdaten nur beim Dienstleister. Domain, Server, Zertifikate, Dienstkonten.
- Kein Datenexport. Ihre Daten liegen in einer Datenbank, an die Sie nicht herankommen.
- Nur eine Person kennt das System – auf beiden Seiten.
Fünf Massnahmen, die wirken
1. Repository-Zugang von Tag eins
Nicht bei Projektende. Ein Konto mit Lesezugriff kostet nichts und ändert alles.
2. Zugangsdaten in Ihrem Besitz
Domain, Hosting-Konto und Zertifikate sollten auf Ihre Firma laufen, auch wenn der Dienstleister sie verwaltet.
3. Betriebsdokumentation als Liefergegenstand
Wie wird ausgeliefert, welche Abhängigkeiten gibt es, wie sieht ein Backup aus, wie eine Rücksicherung? Das gehört in den Vertrag, nicht in die Hoffnung.
4. Regelmässiger Datenexport
Ein Exportformat, das ohne die Anwendung lesbar ist. Einmal jährlich ausprobieren.
5. Gängige Technik
Eine Anwendung in verbreiteten Technologien kann jeder qualifizierte Dienstleister übernehmen. Ein exotischer Stack macht Sie abhängig von den wenigen Menschen, die ihn beherrschen.
Die ehrliche Einordnung
Eine gewisse Abhängigkeit lässt sich nicht vermeiden – wer ein System gebaut hat, kennt es am besten. Das Ziel ist nicht Unabhängigkeit um jeden Preis, sondern dass ein Wechsel möglich bleibt. Diese Möglichkeit allein verändert das Verhältnis.
Kernfakten
- Häufigste Ursache
- Fehlender Repository-Zugang und fehlende Betriebsdoku
- Wirksamste Massnahme
- Lesezugriff auf den Code ab Tag eins
- Ziel
- Ein Wechsel muss möglich bleiben – nicht wahrscheinlich