Bloß kein Vendor Lock-In! Oder doch?
Vendor Lock-In wird besonders im Cloud-Kontext häufig als unbedingt zu vermeidendes Risiko behandelt. Dabei gehen wir regelmäßig Abhängigkeiten ein und müssen dies auch tun, um konkurrenzfähig zu bleiben. Zum Risiko wird es nur, wenn man es nicht sinnvoll managt.
Beginnen wir mit einer kurzen Betrachtung der Potentiale der Cloud, weil man diesem Thema in der Lock-In-Debatte sehr häufig begegnet. Das große Potential der Hyperscaler ist die Auswahl an Angeboten, die helfen, die eigene vertikale Fertigungstiefe gezielt zu reduzieren. Indem ich mich beispielsweise gezielt in Richtung Serverless bewege, muss meine eigene IT ganz viele nicht differenzierende Dinge nicht mehr selbst tun. Stattdessen kann ich die freigewordenen Kapazitäten nutzen, um schneller an innovativen, hochgradig differenzierenden Angeboten für meine Kundschaft zu arbeiten und so meine Wettbewerbsfähigkeit zu stärken.
Auch Open Source Software ist letztlich ein Lock-In.
Dazu kommen noch viele Möglichkeiten, die sich nur mit sehr hohen Investitionen und Betriebskosten im eigenen Rechenzentrum abbilden lassen: KI-Modelle in allen Größen und Varianten. Verwaltung von IoT-Devices und zugehörigen Datenströmen mit Digital Twins. Dynamische Ressourcenbereitstellung für sehr volatile Use Cases. SaaS in allen Spielarten. Lease statt Buy. Damit ergeben sich ganz andere strategische Optionen – nicht nur für die IT, sondern auch für die Fachseite in Form ansonsten nicht umsetzbarer bzw. unrentabler Geschäftsmodelle.
Die Angst vor dem Vendor Lock-In
Diese Potentiale lassen sich aber nicht heben, wenn man sich zur Vermeidung eines Vendor Lock-Ins auf den kleinsten gemeinsamen Nenner, sprich Container und Kubernetes, beschränkt, womöglich sogar mit darin selbst betriebenen Datenbanken, Message Busses, Load Balancern und so weiter. Damit hat man letztlich nur ein weiteres On-Premises-Rechenzentrum mit den zugehörigen Einschränkungen aufgebaut, nur eben auf der Hyperscaler-Hardware statt beim Colocation Provider oder im eigenen Gebäude.
Aber woher kommt die verbreitete Angst vor dem Lock-In? Es ist die Angst, dass ein Anbieter die resultierende Abhängigkeit von seinem Produkt oder Service z. B. durch willkürliche Preiserhöhungen ausnutzen könnte. Das hat es in der Vergangenheit gegeben. So wird z.B. Oracle, aber auch anderen Anbietern, eine recht willkürliche Preispolitik gegenüber treuen Bestandskunden vorgeworfen. Deshalb möchte man Lock-In unbedingt vermeiden, häufig begleitet von Scheinargumenten und sehr emotional geführten Debatten.
Nur ist das zu kurz gedacht. Denn eigentlich wollen wir Lock-In! Wir begeben uns dauernd in Lock-In-Situationen. Warum? Weil es uns ökonomische Vorteile bringt. Indem wir bestimmte Leistungen nicht selber erbringen, sondern von anderen Parteien beziehen, können wir zum einen Kostenvorteile erzielen und zum anderen unsere eigene Wertschöpfung optimieren.
Lieber alles selbst entwickeln?
Wollten wir überhaupt keinen Lock-In in der IT, müssten wir unsere Hardware selbst herstellen, Firmware und Betriebssysteme selber schreiben, ebenso Middleware, Datenbanken, Message Busses, Compiler, Runtimes und noch viel mehr. Unsere IT würde ohne signifikanten ökonomischen Mehrwert mehr als 90 % unseres Unternehmens in Personal und Kosten einnehmen, was einem ökonomischen Selbstmord gleichkäme. Ergo: Wir brauchen Lock-In!
Lock-In ist ein normaler Teil einer jeden IT-Strategie, und das ist gut und richtig so.
Auch die in diesem Kontext gerne hochgehaltene Open Source Software (OSS) ist letztlich ein Lock-In. Stellen Sie sich einfach einmal vor, eine unternehmensweit genutzte OSS-Komponente könnte plötzlich nicht mehr genutzt werden, z. B. weil die Maintainer die Komponente nicht mehr pflegen können oder die hinter der Komponente stehenden Rechteinhaber auf eine sehr teure kommerzielle Lizenz wechseln – beides mehrfach im OSS-Umfeld geschehen. Die resultierenden Ausstiegskosten und -risiken wären eklatant. Ein klarer Fall von Lock-In.
Auch das gerne genutzte Argument, dass man dann ja den Source Code „forken“ und selber pflegen könne, ist letztlich unhaltbar, wenn man kurz darüber nachdenkt. Das würde eine signifikante Erhöhung der Fertigungstiefe ohne geschäftlichen Mehrwert bedeuten, wäre ökonomisch also nicht vertretbar. Man kann den Ausstieg damit etwas hinauszögern, aber man muss ihn trotzdem durchführen. Entsprechend bedeutet auch OSS immer Lock-In.
Lock-In aktiv managen
Lock-In ist ein normaler Teil einer jeden IT-Strategie, und das ist gut und richtig so. Zum Risiko wird er nur, wenn er nicht sauber gemanagt wird. Aber wie managt man Abhängigkeiten?
Wir wählen Lock-In, weil wir uns einen ökonomischen Wettbewerbsvorteil davon versprechen. Ohne diese Grundvoraussetzung ergibt Lock-In keinen Sinn. Ist die Grundvoraussetzung erfüllt, entscheiden wir uns basierend auf einer Kosten-Nutzen-Risiko-Betrachtung für oder gegen den Lock-In:
- Wir bewerten den Wettbewerbsvorteil in Einsparungen und Nutzen, den wir vom Lock-In im Vergleich zum Selbermachen über die erwartete Nutzungsdauer erwarten.
- Dagegen stellen wir die erwarteten Ausstiegskosten und -dauer sowie das daraus resultierende Risiko.
- Stellt man fest, dass die Kostenvorteile über die erwartete Nutzungsdauer niedriger sind als die erwarteten Ausstiegskosten, entscheidet man sich gegen den Lock-In.
- Sind die erwarteten Einsparungen (klar) positiv, bewertet man das Ausstiegsrisiko im Verhältnis zu den erwarteten nicht-monetären Vorteilen (Nutzen).
- Überwiegen die Vorteile die Risiken, wählt man den Lock-In, sonst nicht.
Einen Lock-In sollte man nur eingehen, wenn er einen konkreten Vorteil bringt.
Auf diese Weise kann man effektiv seine Lock-In-Risiken managen und bewusste Entscheidungen für oder gegen einen Lock-In treffen. Zusätzlich führt man damit die häufig emotional und mit diffusen Argumenten geführte Lock-In-Debatte auf eine rationale unternehmerische Betrachtung zurück.
Lock-In mit Augenmaß
Sollten wir jetzt also mit fliegenden Fahnen in Richtung Hyperscaler rennen? Nicht unbedingt. Die Hyperscaler bieten uns eine Menge attraktiver Potentiale, die wir anderenorts nicht finden. Deshalb stellen sie eine Option dar, die man auf jeden Fall ökonomisch bewerten sollte.
Dennoch sollte man einen Lock-In nur eingehen, wenn er dem Unternehmen einen konkreten Vorteil bringt. Das Geschäftsmodell, die Rahmenbedingungen (Stichwort: Regulierung) und all das muss auch passen. Dazu kommen übergreifende Risikoabwägungen, angefangen beim erforderlichen Nachschulen der Belegschaft, bis hin zum derzeit schwer einschätzbaren Gebaren der amerikanischen Regierung und den sich daraus möglicherweise ergebenden Risiken für die Nutzung der Hyperscaler.
Fazit
Lock-Ins sind eine strategische Notwendigkeit. Die Entscheidung für und wider Lock-In sollte man bewusst und faktenbasiert treffen und nicht basierend auf diffusen Ängsten und (Schein-)Argumenten. Wie bei allem gilt aber auch beim Thema Lock-In: Man sollte es mit Augenmaß tun. Nicht alles, was man tun kann, sollte man auch tun. Denn wie Michael Porter so treffend sagte: „The essence of strategy is choosing what not to do“; zu Deutsch in etwa „Die Essenz von Strategie ist sich zu entscheiden, was man *nicht* tun sollte.“
