Was ist Vendor Lock-In und wie lässt es sich ver­hin­dern?

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 Ab­hän­gig­keit 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 nach­fol­gen­den Ab­schnit­ten.

Generell versteht man unter dem „Lock-in“-Effekt die Ab­hän­gig­keit eines Kunden von einem Produkt bzw. einer Tech­no­lo­gie. Dabei ist die Ab­hän­gig­keit dem Umstand ge­schul­det, dass ein Wechsel mit hohem Aufwand verbunden und damit un­at­trak­tiv ist. Steht die Tech­no­lo­gie 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 Tech­no­lo­gien und Leis­tun­gen, aus denen ein Kunde wählen kann. Angeboten werden diese zu un­ter­schied­li­chen Preisen und Be­din­gun­gen. Jede ge­schäft­li­che Beziehung zwischen Kunde und Anbieter hat eigene Vor- und Nachteile. Aus der Ent­schei­dungs­fin­dung, mit mehreren oder nur wenigen Anbietern zu arbeiten, ergibt sich ein Span­nungs­feld.

Aus ad­mi­nis­tra­ti­ver Sicht ist es wün­schens­wert, mit nur wenigen Anbietern zu arbeiten. Dies führt zu einer homogenen Umgebung, die mit ge­rin­ge­rer Kom­ple­xi­tät ein­her­geht. Im Ex­trem­fall werden sämtliche Produkte und Leis­tun­gen von einem einzigen Anbieter bezogen. Jedoch stellt sich damit auch die komplette Ab­hän­gig­keit von diesem Anbieter ein. Der Kunde sitzt am kürzeren Hebel und hat gegenüber dem Anbieter eine schlechte Ver­hand­lungs­po­si­ti­on.

Das klas­si­sche Beispiel für Vendor Lock-In im Software-Bereich ist die Bindung an den Anbieter Microsoft. In vielen Wirt­schafts­zwei­gen stammen sämtliche Kern­kom­po­nen­ten von dem Groß­kon­zern: Be­triebs­sys­tem (Windows), An­wen­dungs­soft­ware (Office), Datenbank (Access), etc. Damit stehen alle wichtigen Software-Kom­po­nen­ten von den Pro­gram­men über Lizenzen und Preis­ge­stal­tung bis hin zum Support unter der Kontrolle eines einzelnen Anbieters. Der Vendor Lock-In ist komplett.

Die Ab­hän­gig­keit von einem Anbieter ergibt sich aus dem Un­ver­mö­gen, den Anbieter zu wechseln. Auch wenn ein Wechsel theo­re­tisch möglich sein sollte, ist dieser ggf. nur mit enorm hohem Aufwand um­zu­set­zen. Der Kunde ist faktisch an den Anbieter gebunden. Ver­deut­li­chen wir uns das Prinzip an einem einfachen Beispiel:

Oft handelt es sich bei Tech­no­lo­gie-Kom­po­nen­ten um so­ge­nann­te „Kom­ple­men­tär­gü­ter“. Dabei besteht eine Ab­hän­gig­keit der einzelnen Kom­po­nen­ten un­ter­ein­an­der. Ein Beispiel: Besitzt man eine Xbox oder eine Play­sta­ti­on mit einer ent­spre­chen­den Spie­le­samm­lung, wechselt man wahr­schein­lich nicht das System, denn dann müsste man auch alle Spiele neu kaufen, weil sie auf dem jeweils anderen System nicht laufen.

Neben der be­schrie­be­nen In­kom­pa­ti­bi­li­tät kon­kur­rie­ren­der Tech­no­lo­gien, er­schwe­ren re­gu­la­to­ri­sche und or­ga­ni­sa­to­ri­sche Hürden den An­bie­ter­wech­sel. Zum einen binden ggf. Li­zenz­be­din­gun­gen und sonstige ver­trag­li­che Ver­ein­ba­run­gen den Kunden an einen Anbieter. Zum anderen wurde ggf. bereits in Wissen und Training der Mit­ar­bei­ter in­ves­tiert. Ist dieses Tech­no­lo­gie-spe­zi­fisch und lässt sich nicht über­tra­gen, wird der Status quo ze­men­tiert.

Im Kern der Über­le­gun­gen liegt die Er­kennt­nis, dass das Ganze mehr ist als die Summe der Teile. In der Tat umfasst das Ganze (ein System):

• die Teile (Kom­po­nen­ten)
• die In­ter­ak­tio­nen und sonstige explizite oder implizite Ver­bin­dun­gen zwischen den Teilen
• sich daraus ergebende (emergente) Ei­gen­schaf­ten des Ge­samt­sys­tems.

Die einzelnen Teile lassen sich bei einem Wechsel oft relativ einfach bewegen. Dem­ge­gen­über müssen die Ver­bin­dun­gen ggf. aufwendig neu erzeugt werden. Bei einem organisch ge­wach­se­nen System sind die Ver­bin­dun­gen zwischen den Kom­po­nen­ten meist implizit. Dann fehlt die zum Wie­der­auf­bau des Ge­samt­sys­tems not­wen­di­ge Be­schrei­bung; ein Wechsel wird schwierig bis unmöglich.

Ein konkretes Beispiel:

Stellen wir uns ein Da­ten­bank­sys­tem vor, das innerhalb der In­fra­struk­tur eines Anbieters existiert. Die darin ge­spei­cher­ten Daten lassen sich beim Wechsel zu einem anderen Anbieter relativ einfach migrieren. Doch wie sieht es mit den weiteren Kom­po­nen­ten und den Ver­bin­dun­gen da­zwi­schen aus? Ein­stel­lun­gen, Zu­griffs­rech­te, Ver­tei­lung der Datenbank über mehrere Server (Sharding), etc. Kennen wir die Kom­ple­xi­tät des Ge­samt­sys­tems, bzw. können wir diese erfassen? Wenn ja, lässt sich das Ge­samt­sys­tem unter ver­tret­ba­rem Aufwand auf der In­fra­struk­tur des neuen Anbieters re­pro­du­zie­ren? In vielen Fällen dürfte die Antwort auf zumindest eine dieser Fragen „nein“ lauten.

Am Beispiel der Re­vi­si­ons­si­cher­heit lässt sich ver­deut­li­chen, wie emergente Sys­tem­ei­gen­schaf­ten den An­bie­ter­wech­sel er­schwe­ren. Die Re­vi­si­ons­si­cher­heit als Kriterium umfasst tech­ni­sche, or­ga­ni­sa­to­ri­sche und re­gu­la­to­ri­sche An­for­de­run­gen. Damit handelt es sich um eine über­ge­ord­ne­te Sys­tem­ei­gen­schaft. Nach­ge­wie­sen wird die Re­vi­si­ons­si­cher­heit eines Systems durch eine Zer­ti­fi­zie­rung. Die Zer­ti­fi­zie­rung ist auf einen konkreten Fall bezogen; beim An­bie­ter­wech­sel wird das System neu aufgebaut und muss dem­entspre­chend neu zer­ti­fi­ziert werden. Der damit ein­her­ge­hen­de Mehr­auf­wand erhöht die Wech­sel­kos­ten 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 ge­spei­chert. Möchten wir einen anderen Anbieter zur Ver­ar­bei­tung der Daten einsetzen, müssen diese über das Netzwerk über­tra­gen werden. Dabei fallen Trans­fer­kos­ten an. Also ist es attraktiv, auch die Ver­ar­bei­tung dem ersten Anbieter zu über­tra­gen. Es ergibt sich ein schlei­chen­der Lock-In-Effekt.

Je mehr Daten man speichert und je länger die Ge­schäfts­be­zie­hung anhält, desto stärker ist der Lock-In-Effekt. Baut die eigene Ge­schäfts­lo­gik auf Anbieter-spe­zi­fi­schen Features, APIs und Kon­fi­gu­ra­tio­nen auf, wird es schwer­fal­len, das Geflecht auf­zu­tren­nen. Im Ex­trem­fall stammt alles aus der Hand eines einzelnen Managed Service Providers. Auch bei der Er­stel­lung einer In­di­vi­du­al­lö­sun­gen durch ein Sys­tem­haus ist Vorsicht geboten. Durch ein hohes Maß an An­pas­sun­gen ergibt sich eine starke Bindung des Kunden an den Anbieter.

Schauen wir uns zunächst an, welche tech­no­lo­gi­schen Ka­pa­zi­tä­ten die Cloud ausmachen. Wir iden­ti­fi­zie­ren drei grund­le­gen­de Funk­tio­na­li­tä­ten:

• Software-Defined Net­wor­king (SDN): Anstatt physische Router und Switches ein­zu­set­zen und zu kon­fi­gu­rie­ren, werden virtuelle Netzwerke und Netz­werk­ge­rä­te verwendet.
• Software-Defined Storage (SDS): Anstelle phy­si­scher Mas­sen­spei­cher kommen Object Stores wie „Amazon S3“ und Block Stores wie „Azure Blob Storage“ in einem Software Defined Data Center zum Einsatz.
• Compute- und Ser­ver­less-Lösungen: Mit „In­fra­struc­tu­re-as-a-Service“ (IaaS) und „Container-as-a-Service“ (CaaS) werden Be­triebs­sys­te­me und An­wen­dun­gen vir­tua­li­siert. Mit „Function-as-a-Service“ (FaaS) wie „AWS Lambda“ und „Microsoft Azure Functions“ werden einzelne Funk­tio­nen zum Aufruf be­reit­ge­stellt.

Eine Cloud-Computing-Umgebung umfasst die tech­ni­schen Aspekte Hosting, Spei­che­rung und An­wen­dun­gen. Ferner finden sich die or­ga­ni­sa­to­ri­schen Aspekte Kon­fi­gu­ra­ti­on, Support und Re­gu­la­to­ri­en. Eine spe­zi­fi­sche Cloud-Umgebung setzt sich aus un­ter­schied­li­chen Aus­prä­gun­gen dieser Aspekte zusammen. Anhand der Fülle der un­ter­schied­li­chen Aus­prä­gun­gen lässt sich ab­schät­zen, wie komplex die Migration zwischen Anbietern für ge­wöhn­lich 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 be­reit­ge­stellt, gehören jedoch zu keinem Zeitpunkt dem Kunden. Daher obliegt es – im Rahmen der ab­ge­schlos­se­nen Verträge – dem Anbieter, zu ent­schei­den, ob und zu welchen Be­din­gun­gen die Dienste angeboten werden.

Was nun, wenn sich die Parameter eines in Anspruch ge­nom­me­nen Dienstes ändern? Im schlimms­ten 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 Be­din­gun­gen zu Ungunsten des Kunden. Dabei sitzt der Anbieter prin­zi­pi­ell am längeren Hebel, da der Kunde auf den Anbieter an­ge­wie­sen ist.

Gründe für die Ab­hän­gig­keit von einem Anbieter ergeben sich auch auf Kun­den­sei­te. So sind die Mit­ar­bei­ter des Un­ter­neh­mens daran gewöhnt, mit der vom Anbieter zur Verfügung ge­stell­ten Tech­no­lo­gie zu arbeiten. Tech­ni­sche Experten sind für ge­wöhn­lich auf bestimmte Tech­no­lo­gien spe­zia­li­siert. Beim Wechsel zu einem anderen Anbieter muss ggf. das Personal neu geschult werden; evtl. erfordert ein Wechsel sogar die An­stel­lung neuen Personals.

Um aus dem Vendor Lock-In aus­zu­bre­chen, 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 Wohl­erge­hen der Or­ga­ni­sa­ti­on vom Erfolg der Migration abhängt, muss diese vorher geplant und getestet werden. Auch bei Auf­wen­dung großer Sorgfalt ist es möglich, dass sich Fehler erst im Nach­hin­ein 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 tat­säch­lich lohnt.

Der beste Ansatz zur Ver­mei­dung von Vendor Lock-In besteht darin, diesem auf stra­te­gi­scher Ebene von Anfang an ent­ge­gen­zu­wir­ken. Anstatt auf einen Anbieter zu setzen und diesem damit Macht zu über­tra­gen, wird auf mehrere Standfüße gesetzt. Die internen Systeme werden explizit mit dem Ziel aufgebaut, Teil­kom­po­nen­ten später aus­tau­schen zu können.

Im Folgenden haben wir spe­zi­fi­sche stra­te­gi­sche, or­ga­ni­sa­to­ri­sche und tech­ni­sche Maßnahmen zu­sam­men­ge­fasst, die Ihnen dabei helfen, Vendor Lock-In zu vermeiden.

Wird bei der Wahl von Partnern und Tech­no­lo­gien die Gefahr von Vendor Lock-In von Vorn­her­ein in die Über­le­gun­gen mit­ein­be­zo­gen, lassen sich bessere Ent­schei­dun­gen treffen. Be­trach­tet man bei­spiels­wei­se ver­gleich­ba­re Tech­no­lo­gien zweier Anbieter zu leicht un­ter­schied­li­chen Preisen, kann es durchaus Sinn machen, sich für das Angebot mit dem höheren Preis zu ent­schei­den. Zumindest, wenn davon aus­ge­gan­gen wird, dass dies die Gefahr für Vendor Lock-In mindert.

Generell ist eine rigorose Be­stands­auf­nah­me er­for­der­lich: Die eigenen An­for­de­run­gen in Bezug auf Tech­no­lo­gie zu verstehen und bereits exis­tie­ren­de IT-Struk­tu­ren zu erfassen, ist das A und O. Aufbauend auf der Kenntnis der eigenen Systeme und An­for­de­run­gen wird die IT-Land­schaft ana­ly­siert. Dabei ist es wichtig, emergente Trends mit­ein­zu­be­zie­hen und das „End of Life“ von Tech­no­lo­gien im Auge zu behalten. Werden z.B. noch Legacy-Systeme ein­ge­setzt, empfiehlt sich eine Um­stel­lung.

Erscheint eine Tech­no­lo­gie oder ein Anbieter in Bezug auf Vendor Lock-In ri­si­ko­be­haf­tet, sollten Sie von Anfang an eine Exit-Strategie de­fi­nie­ren. So kann schnell und ziel­ge­rich­tet auf un­güns­ti­ge Ver­än­de­run­gen seitens des Anbieters reagiert werden. Man weiß schon vorher, was zu tun ist und ist sich der dabei auf­tre­ten­den Kosten und Risiken bewusst.

Der na­he­lie­gends­te Ansatz zur Ver­mei­dung von Vendor Lock-In besteht darin, sich nicht von einem einzelnen Anbieter abhängig zu machen. Statt alle Ge­schäfts­pro­zes­se in die Cloud zu verlagern, wird ein hybrider Ansatz gewählt. Dabei kommt neben den Cloud-Res­sour­cen eines Providers eine private Cloud zum Einsatz. Damit ver­blei­ben Kern­pro­zes­se und die dabei zum Einsatz kommenden Daten unter der eigenen Kontrolle, um die Da­ten­ho­heit zu bewahren.

Demselben Schema folgend kann es vor­teil­haft sein, Cloud-Dienste von mehreren, statt einem einzelnen Anbieter zu beziehen. Aus­schlag­ge­bend ist dabei, dass sämtliche ein­ge­setz­ten Dienste über adäquate Schnitt­stel­len verfügen. Nur so lässt sich aus den einzelnen Kom­po­nen­ten ein schlüs­si­ges Ge­samt­sys­tem zu­sam­men­fü­gen. Zudem sind Dienste von Anbietern vor­zu­zie­hen, die In­ter­ope­ra­bi­li­tät über offene Schnitt­stel­len explizit un­ter­stüt­zen.

Sämtliche Maßnahmen sind nur dann effektiv, wenn sie die tat­säch­lich exis­tie­ren­den Struk­tu­ren innerhalb der Or­ga­ni­sa­ti­on abdecken. Laufen Prozesse quasi unter dem Radar ab, schleicht sich trotz aller An­stren­gun­gen Vendor Lock-In ein. Besonders deutlich wird dies mit Blick auf sog. „Dark Data“: Dabei handelt es sich um Daten, die außerhalb der ei­gent­lich vor­ge­se­he­nen Systeme exis­tie­ren. Es ist ziel­füh­rend, Ab­hän­gig­kei­ten explizit zu machen und Prozesse und Systeme weit­ge­hend zu stan­dar­di­sie­ren.

Die ein­fachs­te tech­ni­sche Maßnahme zur Ver­mei­dung von Vendor Lock-In liegt darin, keine pro­prie­tä­ren Systeme und Formate zu verwenden. Setzt man kon­se­quent auf offene Standards und freie Software, ist man per De­fi­ni­ti­on 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-Res­sour­cen abgegeben hat.

Glück­li­cher­wei­se wurden in den letzten Jahren mächtige Or­ches­trie­rungs-Tools er­schaf­fen, die genau an diesem Punkt ansetzen. Dazu zählen OpenShift und Terraform. Diese Tools dienen als abstrakte Zwi­schen­ebe­ne und ent­kop­peln die eigenen An­for­de­run­gen an eine IT-In­fra­struk­tur von der darunter liegenden, Anbieter-spe­zi­fi­schen Schicht. So wird es möglich, eine gesamte IT-In­fra­struk­tur über mehrere Clouds verteilt auf­zu­bau­en.

Das Stichwort hierbei ist „In­fra­struc­tu­re-as-Code“ (IaC). Wohl­ge­merkt: „Code“, nicht „Service“. Während ein Service gemietet wird, verbleibt Code unter der eigenen Kontrolle. Im Code werden die ge­wünsch­ten Struk­tu­ren definiert. Diese be­inhal­ten einzelne Kom­po­nen­ten, sowie die Ver­bin­dun­gen zwischen ihnen. Neben der damit ein­her­ge­hen­den ex­pli­zi­ten Do­ku­men­ta­ti­on der Systeme im Code, ergeben sich weitere ent­schei­den­de Vorteile.

Aus den im Code abstrakt de­fi­nier­ten Struk­tu­ren pro­vi­sio­niert die Or­ches­trie­rungs-Software kor­re­spon­die­ren­de IT-Systeme. Es ist möglich, die einzelnen Kom­po­nen­ten über mehrere Clouds zu verteilen. Dies funk­tio­niert für Cloud-In­fra­struk­tu­ren ver­schie­de­ner Anbieter, sowie private Clouds im eigenen Un­ter­neh­men. Die damit ein­her­ge­hen­de Reduktion der Wech­sel­kos­ten trägt erheblich zum Schutz vor Vendor Lock-In bei.