Was ist Vendor Lock-In und wie lässt es sich verhindern?

Vendor Lock-In tritt dann ein, wenn ein Kunde sich so eng an einen Anbieter bindet, dass ein Wechsel faktisch unmöglich wird. Es ergibt sich also eine Abhängigkeit des Kunden vom Anbieter. Auch bei der Nutzung von Cloud-Angeboten sollte man die Gefahr des „Lock-In“-Effekts im Auge behalten. Was genau hinter Vendor Lock-In steckt und wie er sich vermeiden lässt, verraten wir in den nachfolgenden Abschnitten.

Generell versteht man unter dem „Lock-in“-Effekt die Abhängigkeit eines Kunden von einem Produkt bzw. einer Technologie. Dabei ist die Abhängigkeit dem Umstand geschuldet, dass ein Wechsel mit hohem Aufwand verbunden und damit unattraktiv ist. Steht die Technologie unter der Kontrolle eines einzigen Anbieters (auf Englisch „Vendor“), ist der Kunde faktisch an den Anbieter gebunden und es kommt zum „Vendor Lock-In“.

Auf dem Markt existiert eine Vielzahl von Technologien und Leistungen, aus denen ein Kunde wählen kann. Angeboten werden diese zu unterschiedlichen Preisen und Bedingungen. Jede geschäftliche Beziehung zwischen Kunde und Anbieter hat eigene Vor- und Nachteile. Aus der Entscheidungsfindung, mit mehreren oder nur wenigen Anbietern zu arbeiten, ergibt sich ein Spannungsfeld.

Aus administrativer Sicht ist es wünschenswert, mit nur wenigen Anbietern zu arbeiten. Dies führt zu einer homogenen Umgebung, die mit geringerer Komplexität einhergeht. Im Extremfall werden sämtliche Produkte und Leistungen von einem einzigen Anbieter bezogen. Jedoch stellt sich damit auch die komplette Abhängigkeit von diesem Anbieter ein. Der Kunde sitzt am kürzeren Hebel und hat gegenüber dem Anbieter eine schlechte Verhandlungsposition.

Das klassische Beispiel für Vendor Lock-In im Software-Bereich ist die Bindung an den Anbieter Microsoft. In vielen Wirtschaftszweigen stammen sämtliche Kernkomponenten von dem Großkonzern: Betriebssystem (Windows), Anwendungssoftware (Office), Datenbank (Access), etc. Damit stehen alle wichtigen Software-Komponenten von den Programmen über Lizenzen und Preisgestaltung bis hin zum Support unter der Kontrolle eines einzelnen Anbieters. Der Vendor Lock-In ist komplett.

Die Abhängigkeit von einem Anbieter ergibt sich aus dem Unvermögen, den Anbieter zu wechseln. Auch wenn ein Wechsel theoretisch möglich sein sollte, ist dieser ggf. nur mit enorm hohem Aufwand umzusetzen. Der Kunde ist faktisch an den Anbieter gebunden. Verdeutlichen wir uns das Prinzip an einem einfachen Beispiel:

Oft handelt es sich bei Technologie-Komponenten um sogenannte „Komplementärgüter“. Dabei besteht eine Abhängigkeit der einzelnen Komponenten untereinander. Ein Beispiel: Besitzt man eine Xbox oder eine Playstation mit einer entsprechenden Spielesammlung, wechselt man wahrscheinlich nicht das System, denn dann müsste man auch alle Spiele neu kaufen, weil sie auf dem jeweils anderen System nicht laufen.

Neben der beschriebenen Inkompatibilität konkurrierender Technologien, erschweren regulatorische und organisatorische Hürden den Anbieterwechsel. Zum einen binden ggf. Lizenzbedingungen und sonstige vertragliche Vereinbarungen den Kunden an einen Anbieter. Zum anderen wurde ggf. bereits in Wissen und Training der Mitarbeiter investiert. Ist dieses Technologie-spezifisch und lässt sich nicht übertragen, wird der Status quo zementiert.

Im Kern der Überlegungen liegt die Erkenntnis, dass das Ganze mehr ist als die Summe der Teile. In der Tat umfasst das Ganze (ein System):

• die Teile (Komponenten)
• die Interaktionen und sonstige explizite oder implizite Verbindungen zwischen den Teilen
• sich daraus ergebende (emergente) Eigenschaften des Gesamtsystems.

Die einzelnen Teile lassen sich bei einem Wechsel oft relativ einfach bewegen. Demgegenüber müssen die Verbindungen ggf. aufwendig neu erzeugt werden. Bei einem organisch gewachsenen System sind die Verbindungen zwischen den Komponenten meist implizit. Dann fehlt die zum Wiederaufbau des Gesamtsystems notwendige Beschreibung; ein Wechsel wird schwierig bis unmöglich.

Ein konkretes Beispiel:

Stellen wir uns ein Datenbanksystem vor, das innerhalb der Infrastruktur eines Anbieters existiert. Die darin gespeicherten Daten lassen sich beim Wechsel zu einem anderen Anbieter relativ einfach migrieren. Doch wie sieht es mit den weiteren Komponenten und den Verbindungen dazwischen aus? Einstellungen, Zugriffsrechte, Verteilung der Datenbank über mehrere Server (Sharding), etc. Kennen wir die Komplexität des Gesamtsystems, bzw. können wir diese erfassen? Wenn ja, lässt sich das Gesamtsystem unter vertretbarem Aufwand auf der Infrastruktur des neuen Anbieters reproduzieren? In vielen Fällen dürfte die Antwort auf zumindest eine dieser Fragen „nein“ lauten.

Am Beispiel der Revisionssicherheit lässt sich verdeutlichen, wie emergente Systemeigenschaften den Anbieterwechsel erschweren. Die Revisionssicherheit als Kriterium umfasst technische, organisatorische und regulatorische Anforderungen. Damit handelt es sich um eine übergeordnete Systemeigenschaft. Nachgewiesen wird die Revisionssicherheit eines Systems durch eine Zertifizierung. Die Zertifizierung ist auf einen konkreten Fall bezogen; beim Anbieterwechsel wird das System neu aufgebaut und muss dementsprechend neu zertifiziert werden. Der damit einhergehende Mehraufwand erhöht die Wechselkosten und trägt zum Lock-In Effekt bei.

Die Nutzung des Cloud Computing bietet viele Vorteile. Jedoch droht auch hier des Vendor Lock-In. Ein typisches Beispiel: Wichtige Daten sind bei einem Cloud-Anbieter gespeichert. Möchten wir einen anderen Anbieter zur Verarbeitung der Daten einsetzen, müssen diese über das Netzwerk übertragen werden. Dabei fallen Transferkosten an. Also ist es attraktiv, auch die Verarbeitung dem ersten Anbieter zu übertragen. Es ergibt sich ein schleichender Lock-In-Effekt.

Je mehr Daten man speichert und je länger die Geschäftsbeziehung anhält, desto stärker ist der Lock-In-Effekt. Baut die eigene Geschäftslogik auf Anbieter-spezifischen Features, APIs und Konfigurationen auf, wird es schwerfallen, das Geflecht aufzutrennen. Im Extremfall stammt alles aus der Hand eines einzelnen Managed Service Providers. Auch bei der Erstellung einer Individuallösungen durch ein Systemhaus ist Vorsicht geboten. Durch ein hohes Maß an Anpassungen ergibt sich eine starke Bindung des Kunden an den Anbieter.

Schauen wir uns zunächst an, welche technologischen Kapazitäten die Cloud ausmachen. Wir identifizieren drei grundlegende Funktionalitäten:

• Software-Defined Networking (SDN): Anstatt physische Router und Switches einzusetzen und zu konfigurieren, werden virtuelle Netzwerke und Netzwerkgeräte verwendet.
• Software-Defined Storage (SDS): Anstelle physischer Massenspeicher kommen Object Stores wie „Amazon S3“ und Block Stores wie „Azure Blob Storage“ in einem Software Defined Data Center zum Einsatz.
• Compute- und Serverless-Lösungen: Mit „Infrastructure-as-a-Service“ (IaaS) und „Container-as-a-Service“ (CaaS) werden Betriebssysteme und Anwendungen virtualisiert. Mit „Function-as-a-Service“ (FaaS) wie „AWS Lambda“ und „Microsoft Azure Functions“ werden einzelne Funktionen zum Aufruf bereitgestellt.

Eine Cloud-Computing-Umgebung umfasst die technischen Aspekte Hosting, Speicherung und Anwendungen. Ferner finden sich die organisatorischen Aspekte Konfiguration, Support und Regulatorien. Eine spezifische Cloud-Umgebung setzt sich aus unterschiedlichen Ausprägungen dieser Aspekte zusammen. Anhand der Fülle der unterschiedlichen Ausprägungen lässt sich abschätzen, wie komplex die Migration zwischen Anbietern für gewöhnlich ausfällt:

Bei den genannten Cloud-Produkten wie IaaS, PaaS, SaaS und CaaS handelt es sich allesamt um Dienste. Diese werden vom Anbieter gegen eine Gebühr bereitgestellt, gehören jedoch zu keinem Zeitpunkt dem Kunden. Daher obliegt es – im Rahmen der abgeschlossenen Verträge – dem Anbieter, zu entscheiden, ob und zu welchen Bedingungen die Dienste angeboten werden.

Was nun, wenn sich die Parameter eines in Anspruch genommenen Dienstes ändern? Im schlimmsten Fall kommt es zu Einbußen bei der Qualität oder dem Umfang des Dienstes, oder der Anbieter erhöht den Preis oder ändert die Bedingungen zu Ungunsten des Kunden. Dabei sitzt der Anbieter prinzipiell am längeren Hebel, da der Kunde auf den Anbieter angewiesen ist.

Gründe für die Abhängigkeit von einem Anbieter ergeben sich auch auf Kundenseite. So sind die Mitarbeiter des Unternehmens daran gewöhnt, mit der vom Anbieter zur Verfügung gestellten Technologie zu arbeiten. Technische Experten sind für gewöhnlich auf bestimmte Technologien spezialisiert. Beim Wechsel zu einem anderen Anbieter muss ggf. das Personal neu geschult werden; evtl. erfordert ein Wechsel sogar die Anstellung neuen Personals.

Um aus dem Vendor Lock-In auszubrechen, müssen Daten und Prozesse zu einem neuen Anbieter migriert werden. Bei einer solchen Migration handelt es sich oftmals um einen komplexen Prozess. Da das Wohlergehen der Organisation vom Erfolg der Migration abhängt, muss diese vorher geplant und getestet werden. Auch bei Aufwendung großer Sorgfalt ist es möglich, dass sich Fehler erst im Nachhinein zeigen. Eine komplexe Migration birgt also immer ein hohes Risiko und so stellt sich schnell die Frage, ob sich der Aufwand für einen Wechsel auch tatsächlich lohnt.

Der beste Ansatz zur Vermeidung von Vendor Lock-In besteht darin, diesem auf strategischer Ebene von Anfang an entgegenzuwirken. Anstatt auf einen Anbieter zu setzen und diesem damit Macht zu übertragen, wird auf mehrere Standfüße gesetzt. Die internen Systeme werden explizit mit dem Ziel aufgebaut, Teilkomponenten später austauschen zu können.

Im Folgenden haben wir spezifische strategische, organisatorische und technische Maßnahmen zusammengefasst, die Ihnen dabei helfen, Vendor Lock-In zu vermeiden.

Wird bei der Wahl von Partnern und Technologien die Gefahr von Vendor Lock-In von Vornherein in die Überlegungen miteinbezogen, lassen sich bessere Entscheidungen treffen. Betrachtet man beispielsweise vergleichbare Technologien zweier Anbieter zu leicht unterschiedlichen Preisen, kann es durchaus Sinn machen, sich für das Angebot mit dem höheren Preis zu entscheiden. Zumindest, wenn davon ausgegangen wird, dass dies die Gefahr für Vendor Lock-In mindert.

Generell ist eine rigorose Bestandsaufnahme erforderlich: Die eigenen Anforderungen in Bezug auf Technologie zu verstehen und bereits existierende IT-Strukturen zu erfassen, ist das A und O. Aufbauend auf der Kenntnis der eigenen Systeme und Anforderungen wird die IT-Landschaft analysiert. Dabei ist es wichtig, emergente Trends miteinzubeziehen und das „End of Life“ von Technologien im Auge zu behalten. Werden z.B. noch Legacy-Systeme eingesetzt, empfiehlt sich eine Umstellung.

Erscheint eine Technologie oder ein Anbieter in Bezug auf Vendor Lock-In risikobehaftet, sollten Sie von Anfang an eine Exit-Strategie definieren. So kann schnell und zielgerichtet auf ungünstige Veränderungen seitens des Anbieters reagiert werden. Man weiß schon vorher, was zu tun ist und ist sich der dabei auftretenden Kosten und Risiken bewusst.

Der naheliegendste Ansatz zur Vermeidung von Vendor Lock-In besteht darin, sich nicht von einem einzelnen Anbieter abhängig zu machen. Statt alle Geschäftsprozesse in die Cloud zu verlagern, wird ein hybrider Ansatz gewählt. Dabei kommt neben den Cloud-Ressourcen eines Providers eine private Cloud zum Einsatz. Damit verbleiben Kernprozesse und die dabei zum Einsatz kommenden Daten unter der eigenen Kontrolle, um die Datenhoheit zu bewahren.

Demselben Schema folgend kann es vorteilhaft sein, Cloud-Dienste von mehreren, statt einem einzelnen Anbieter zu beziehen. Ausschlaggebend ist dabei, dass sämtliche eingesetzten Dienste über adäquate Schnittstellen verfügen. Nur so lässt sich aus den einzelnen Komponenten ein schlüssiges Gesamtsystem zusammenfügen. Zudem sind Dienste von Anbietern vorzuziehen, die Interoperabilität über offene Schnittstellen explizit unterstützen.

Sämtliche Maßnahmen sind nur dann effektiv, wenn sie die tatsächlich existierenden Strukturen innerhalb der Organisation abdecken. Laufen Prozesse quasi unter dem Radar ab, schleicht sich trotz aller Anstrengungen Vendor Lock-In ein. Besonders deutlich wird dies mit Blick auf sog. „Dark Data“: Dabei handelt es sich um Daten, die außerhalb der eigentlich vorgesehenen Systeme existieren. Es ist zielführend, Abhängigkeiten explizit zu machen und Prozesse und Systeme weitgehend zu standardisieren.

Die einfachste technische Maßnahme zur Vermeidung von Vendor Lock-In liegt darin, keine proprietären Systeme und Formate zu verwenden. Setzt man konsequent auf offene Standards und freie Software, ist man per Definition nicht von einem einzelnen Anbieter abhängig. Jedoch führt selbst dieser Ansatz bei Nutzung der Cloud nicht zum Erfolg, wenn man die Kontrolle über die Hardware-Ressourcen abgegeben hat.

Glücklicherweise wurden in den letzten Jahren mächtige Orchestrierungs-Tools erschaffen, die genau an diesem Punkt ansetzen. Dazu zählen OpenShift und Terraform. Diese Tools dienen als abstrakte Zwischenebene und entkoppeln die eigenen Anforderungen an eine IT-Infrastruktur von der darunter liegenden, Anbieter-spezifischen Schicht. So wird es möglich, eine gesamte IT-Infrastruktur über mehrere Clouds verteilt aufzubauen.

Das Stichwort hierbei ist „Infrastructure-as-Code“ (IaC). Wohlgemerkt: „Code“, nicht „Service“. Während ein Service gemietet wird, verbleibt Code unter der eigenen Kontrolle. Im Code werden die gewünschten Strukturen definiert. Diese beinhalten einzelne Komponenten, sowie die Verbindungen zwischen ihnen. Neben der damit einhergehenden expliziten Dokumentation der Systeme im Code, ergeben sich weitere entscheidende Vorteile.

Aus den im Code abstrakt definierten Strukturen provisioniert die Orchestrierungs-Software korrespondierende IT-Systeme. Es ist möglich, die einzelnen Komponenten über mehrere Clouds zu verteilen. Dies funktioniert für Cloud-Infrastrukturen verschiedener Anbieter, sowie private Clouds im eigenen Unternehmen. Die damit einhergehende Reduktion der Wechselkosten trägt erheblich zum Schutz vor Vendor Lock-In bei.