Unser Umgang mit dem Thema Vendor Lock-in erscheint mir oft irrational zu sein. Hier ein Beispiel dazu aus der Praxis:
Ein mittelständisches Unternehmen scheut sich davor eine Datenbank als Software-as-a-Service (SaaS) aus der Amazon Web Services Cloud zu beziehen. Der IT-Leiter hat Angst davor, dass eine Migration zu einem anderen Cloud-Provider nur noch mit sehr hohem Aufwand bewerkstelligt werden kann. Auf der anderen Seite verkauft das Unternehmen ein Software-Produkt, welches nur von einem einzigen Zulieferer bezogen werden kann. Aus Angst um das eigene Geschäftsmodell kauft das Unternehmen den wirtschaftlich angeschlagenen Zulieferer für mehrere Millionen Euro.
Die Datenbank aus der Cloud wird als Vendor Lock-in bezeichnet und man begegnet ihr mit Angst und Misstrauen. Der Kauf des Zulieferers wird als Akquisition bezeichnet und ist alternativlos. Was ist hier wohl der wirkliche Vendor Lock-in? Und welche der beiden Situationen sollte man probieren zu vermeiden?
Oft begeben wir uns hier in ein Schwarz-Weiß-Denkmuster. Der Vendor Lock-in wird dabei nahezu immer als etwas Schlechtes angesehen. Dieses Denkmuster ist meiner Meinung nach nicht differenziert genug. Im möchte euch daher einen kurzen Perspektivwechsel anbieten und die positiven Seiten eines Vendor Lock-in darstellen.
Ich möchte eure Zeit nicht mit Definitionen verschwenden. Davon gibt es genug an anderen Stellen. Für den weiteren Artikel möchte ich den Vendor Lock-in auf einen Satz reduzieren. Wir befinden uns im Vendor Lock-in, wenn auf uns folgende Aussage zutrifft:
Ein Wechsel eines Produkts/Services zu einer gleichwertigen Alternative kann nicht ohne erheblichen Aufwand geschehen.
Um die das Pro und Contra abwägen zu können, müssen wir uns den Deal anschauen. Im Vendor Lock-in bezahlen wir mit Abhängigkeit und bekommen dafür ein Produkt oder einen Service. Die Abhängigkeit bezahlen Organisationen in Form von Geld (zum Beispiel für Lizenzen) oder Aufwand, der bei einem Wechsel betrieben werden muss. Auf der anderen Seite des Deals steht das Produkt oder der Service. Hier bekommen wir die Leistungen, die mit damit verbunden sind. Das können zum Beispiel Funktionalitäten oder nicht-funktionale Aspekte wie Betrieb, Weiterentwicklung oder zum Beispiel ein garantiertes Service Level sein. Es läuft also beim Vendor Lock-in auf folgende Abwägung hinaus:
Abhängigkeit gegen funktionale, nicht-funktionale Aspekte
Woher kommt also die große Angst vor dem Vendor Lock-in. Sie rührt meiner Erfahrung nach von einer Übergewichtung der rechten Seite (Abhängigkeit) her. Dabei wird aber allzu oft vergessen, dass wir auch etwas für diese Abhängigkeit bekommen.
Die Abhängigkeit kann sich in zwei essenziellen Bereichen auswirken. Einerseits sehe ich negative Auswirkungen im finanziellen Bereich. Ein schönes Beispiel dafür sind die Lizenzkosten, die zum Beispiel SAP für seine Module berechnet. Hier wird man zum Update gezwungen und muss gleichzeitig für eine neue Lizenz bezahlen. Der zweite wichtige Bereich betrifft das eigene Geschäftsmodell. Wenn mein Geschäftsmodell auf einer Software beruht, die ich von Dritten beziehe, befinde ich mich in einer großen Abhängigkeit. Hier bindet ein Lock-in mein Geschäftsmodell an die Geschicke des Dritten. Ich befinde mich dann also im Risiko des Verlustes meines kompletten Geschäftsmodells.
Abgesehen von diesen zwei essenziellen Fällen, halte ich das Risiko oft für überbewertet. Ein Wechsel eines SaaS Services oder der Umzug eines Workloads von einem Cloud-Provider zu einem anderen ist mit den entsprechenden Vorkehrungen (siehe weiter unten) nicht mit allzu großem Aufwand verbunden. Schauen wir mal auf die linke Seite des Deals.
Was gewinnen wir also, wenn wir uns in die Abhängigkeit bewegen? Wie oben bereits erwähnt sehe ich hier funktionale und nicht-funktionale Vorteile. In beiden Bereichen unterschätzen wir oft das Potenzial, welches im Beziehen von Software von Dritten liegt.
Die Funktionalitäten, die wir zum Beispiel bei der Nutzung von SaaS-Software oder Cloud Provider Services bekommen, wären viel zu umfangreich als dass ich sie hier aufzählen könnte. Ich möchte daher nur einige Beispiele aufzählen:
Müssten wir diese Dinge selbst programmieren, würden wir sehr viel Aufwand betreiben müssen. Hinzu kommt, dass dieser Aufwand sehr wahrscheinlich auch nicht die gleiche Qualität liefern würde, wie sie die Anbieter dieser Funktionalitäten liefern können.
Neben den funktionalen Vorteilen, haben wir es auch noch mit einer Reihe von nicht-funktionalen Aspekten zu tun. So haben wir beim Vendor Lock-in ja immer einen Vendor. Und dieser Vendor kümmert sich oft um den Betrieb der Software. Er wartet sie und entwickelt sie weiter. Daneben bietet es uns Support und Dokumentation.
Es steht also in Summer ziemlich viel auf der linken Seite unseres Deals. Wenn also diese Argumente noch nicht ausreichen, können wir außerdem darauf schauen, wie wir die Abhängigkeit verkleinern können. Bevor wir dazu übergehen noch ein kleiner Denkanstoß.
In meinem Berufsleben habe ich zwei ziemlich irritierende Ausprägungen der Angst vor dem Vendor Lock-in erlebt. Bei beiden Ausprägungen scheint es mir so, als sei unsere Wahrnehmung etwas entrückt.
Die Angst vor dem Vendor Lock-in scheint sich nur auf den Bezug von Software von großen Organisationen zu beziehen. Oft höre ich Bedenken im Zusammenhang mit Anbietern wie Microsoft, Google, Amazon oder SAP. Auf der anderen Seite schaffen wir Softwareentwickler bereitwillig Abhängigkeiten, wenn wir zum Beispiel Frameworks wie React oder Spring Boot in unseren Projekten verwenden.
Was passiert, wenn Google Angular nicht mehr weiterentwickelt oder wenn Pivotal Software aus Spring Boot aussteigt? Haben wir an der Stelle nicht auch ganz viele Vendor Lock-ins in unserer Software?
Der zweite Aspekt bezieht sich auf den tatsächlichen Wechsel eines Produkts oder Services. Wie oft passiert denn ein Wechsel wirklich? In den Software-Projekten, die ich bisher begleitet habe, haben wir noch nie das Framework oder zum Beispiel den Cloud Provider gewechselt.
Wird hier also der Wechselmöglichkeit zu viel Gewicht beigemessen? Überschätzen wir die Wahrscheinlichkeit für einen tatsächlichen Wechsel?
Wir haben also gelernt, dass ein Vendor Lock-in durchaus auch Vorteile haben kann. Solltet ihr vor einer Entscheidung stehen, bei der es um eine Abhängigkeit geht, kann ich euch noch ein paar Tipps mit auf den Weg geben. Man kann die Abhängigkeit zu Dritten reduzieren.
Wenn es um das Hosting der eigenen Anwendung bei einem der großen Cloud Provider geht, helfen vor allem Docker und die Verwendung von etablierten Technologien. So könnt ihr zum Beispiel eure Anwendung in einem Docker-Image deployen. Docker Runtimes gibt es bei jedem Cloud-Provider. So könnt ihr also mit geringem Aufwand wechseln. Web-Hosting (zum Beispiel für statische Files einer Single Page Application) gibt es als bei jedem Provider. Auch hier ist der Wechsel nicht allzu kompliziert. Schlussendlich könnte ihr bei Datenbanken zum Beispiel auf die etablierten Technologien wie Mongo oder Postgres setzten. Diese gibt es oft auch also Service in der Cloud.
Ein weiteres Mittel, um einen Vendor Lock-in abzuschwächen, findet ihr in der Architektur eurer Software. Ihr solltet euch darüber bewusst sein, welche Komponenten eurer Software eure Kernkompetenz darstellen. Das kann zum Beispiel das Match-Making bei einer Plattform oder die Datentransformation bei einem Data-Warehouse sein. Diese Kernkomponenten solltet ihr nicht in eine Abhängigkeit zu einem Dritten überführen. Um herauszufinden, welches diese Komponenten sind, könnt ihr zum Beispiel auf die Methoden des Domain Driven Design zurückgreifen. Diese erlauben euch, eure Kerndomäne zu erkenne und mit einer entsprechend guten Architektur von Abhängigkeiten zu schützen.
Natürlich sind diese beiden Vorschläge nicht das einzige, was ihr tun könnt. Sie sollen lediglich aufzeigen, dass es Mittel gibt, um den Vendor Lock-in abzuschwächen.
Es ist wie bei allem in der IT: Es kommt darauf an. Der Vendor Lock-in ist nicht pauschal etwas Schlechtes. Wenn man sich in die Abhängigkeit zu einem Dritten begibt, geht man einen Deal ein. Dieser Deal hat auch funktionale und nicht-funktionale Vorteile, die oft zu wenig Beachtung finden. An den richtigen Stellen eingesetzt, kann der Bezug von Software gut funktionieren. Wie sollten aufhören Angst vor dem Vendor zu haben.
Erzähle uns in einem kostenlosen Erstgespräch mehr über dein individuelles Projekt. Wir helfen dir bei den nächsten Schritten und teilen unser Wissen.
Nachricht schreiben