Anbieterbindung
Anbieterbindung beschreibt die Abhängigkeit von einem Hersteller oder Dienstleister, die einen Wechsel nur mit erheblichem Aufwand zulässt.
Bei der Wahl einer Plattform und beim Zuschnitt eigener Erweiterungen entscheidet sich, wie frei ein Betrieb später über Software und Dienstleister verfügen kann.
In einfachen Worten
Anbieterbindung entsteht auf mehreren Ebenen. Auf der Ebene der Software binden geschlossener Quellcode, proprietäre Datenformate und Verträge mit fester Laufzeit. Auf der Ebene des Dienstleisters bindet fehlende Dokumentation, ein Zugang, der nur einer Partei vorliegt, und Programmcode, den außer dem Ersteller niemand einordnen kann. Offener Quellcode nimmt die erste Ebene weg: Er lässt sich weitergeben, prüfen und von einem anderen Team fortführen. Die zweite Ebene bleibt davon unberührt. Sie hängt an der Bauweise und an dem, was übergeben wird.
Wozu brauche ich das?
Die Frage stellt sich vor jeder Systementscheidung und vor jeder größeren Erweiterung. Zu klären ist, wem der Quellcode gehört, wo er liegt, wer Zugang zu Server und Konten hat, welche Dokumentation entsteht und in welchem Format Daten exportiert werden können. Die Antworten gehören in den Vertrag, nicht in ein späteres Gespräch.
Beispiel aus der Praxis
Zwei Betriebe setzen dieselbe quelloffene Plattform ein. Der eine hat seine Erweiterungen als getrennte Bestandteile neben der Plattform, mit eigener Versionsverwaltung und einer Beschreibung der Schnittstellen. Der andere hat Anpassungen in den Kern der Plattform geschrieben. Beim Wechsel des Dienstleisters übernimmt im ersten Fall ein neues Team die Arbeit innerhalb weniger Tage. Im zweiten beginnt die Übergabe mit der Frage, welche Änderung wofür gedacht war.
Wirtschaftlicher Nutzen
Geringe Anbieterbindung erhält die Verhandlungsposition und hängt unmittelbar an der Systemarchitektur des Vorhabens. Sie wirkt außerdem auf den laufenden Aufwand: Wer Aktualisierungen einspielen kann, ohne eigene Anpassungen zu verlieren, bleibt auf einem aktuellen Stand, ohne jedes Mal ein Projekt aufzusetzen.
Typische Fehler
- Anpassungen in den Kern der Plattform geschrieben – jede Aktualisierung der Standardsoftware wird dadurch zu einem Vorhaben mit ungewissem Ausgang.
- Zugänge zu Server, Domain und Konten nur beim Dienstleister – im Streitfall fehlt der Zugriff auf die eigene Anwendung.
- Keine Dokumentation vereinbart – die Übergabe beginnt mit der Rekonstruktion von Entscheidungen.
- Daten nur in einem systemeigenen Format vorgehalten – ein Export in ein offenes Format ist später nur mit Aufwand möglich.
- Offenen Quellcode mit Unabhängigkeit gleichgesetzt – die Bindung an den Dienstleister bleibt davon unberührt.
Worauf achten?
- Eigentum am Quellcode, Ablageort und Zugänge vertraglich klären, bevor die Entwicklung beginnt.
- Eigene Erweiterungen getrennt von der Plattform halten, damit Aktualisierungen sie unberührt lassen.
- Zugänge zu Server, Domain und Konten im eigenen Haus führen und Zugriffe gezielt vergeben.
- Eine übergabefähige Dokumentation als Teil der Leistung vereinbaren, nicht als Zugabe.
- Einen Export der eigenen Daten in ein offenes Format vorsehen und ihn einmal tatsächlich ausführen.
Häufig gestellte Fragen
Schützt offener Quellcode vor Anbieterbindung?
Er nimmt die Bindung an den Hersteller weg, weil der Quellcode weitergegeben und von einem anderen Team fortgeführt werden kann. Die Bindung an den Dienstleister bleibt bestehen; sie hängt an Dokumentation, Zugängen und der Bauweise.
Was gehört vor Projektbeginn geklärt?
Wem der Quellcode gehört, wo er abgelegt ist, wer Zugang zu Server und Konten hat, welche Dokumentation entsteht und in welchem Format die eigenen Daten exportiert werden können.
Woran erkenne ich eine hohe Bindung?
Daran, dass Aktualisierungen der Plattform regelmäßig zu Vorhaben werden, dass Zugänge nur beim Dienstleister vorliegen und dass niemand im Haus benennen kann, welche Anpassung wofür gebaut wurde.