Um die Abhängigkeit von IT-Anbietern - Stichwort Lock-In - zu reduzieren, sollten Unternehmen eine strategische Analyse ihrer Lösungen durchführen. [...]
Viele IT-Verantwortliche wollen nicht von einem einzelnen Hardware-, Software- oder Cloud-Anbieter abhängig sein. Sie nehmen große Anstrengungen in Kauf, um solche Lock-In-Effekte zu verhindern und unabhängig zu bleiben. Dabei kann es oft passieren, dass Prioritäten falsch gesetzt werden. Im schlimmsten Fall entstehen neue, größere Abhängigkeiten oder die Vorteile, die neue Technologien eigentlich bringen sollten, verschwinden.
Lock-In ist nicht gleich Lock-In
Wenn Unternehmen von einem Lock-In sprechen, ist in vielen Fällen der sogenannte Vendor Lock-In gemeint. Das bedeutet, von einem einzelnen Anbieter, wie etwa eines CRM- oder Datenbanksystems, abhängig zu sein. Dabei fürchten die Verantwortlichen, durch langfristige Verträge rund um Lizenzen, Wartung und Support mit hohen, unkontrollierbaren Kosten gebunden zu sein.
Bei näherer Betrachtung zeigt sich jedoch, dass es eine Vielzahl unterschiedlicher Lock-In-Arten gibt. Ein Lock-In bedeutet im Grunde, nicht mehr von einer technischen Lösung auf eine andere wechseln zu können. Langfristige Verträge können ein Grund dafür sein. Zusätzlich sind aber auch technische Abhängigkeiten denkbar, oder die eigene Organisation ist nicht auf einen technischen Wechsel vorbereitet.
Wer von einer Lösung auf eine andere wechselt, muss dafür Anpassungen vornehmen, Daten migrieren oder die Architektur umstellen. Das gilt sowohl für kommerzielle Angebote als auch für Open-Source-Produkte. Der technische und finanzielle Aufwand, um zu einem neuen Produkt zu wechseln und es zu integrieren sowie die damit verbundenen Risiken bilden eine starke Barriere. Auch nach einem erfolgreichen Umstieg sind häufig Serviceverträge mit weiteren Dienstleistern nötig, um die neue Lösung zu betreiben, so dass ein neuer Vendor-Lock-In entsteht.
Wenn Unternehmen Standardlösungen umfangreich modifizieren, manövrieren sich viele von ihnen in einen Versions-Lock-In. Upgrades sind in diesem Fall ausgesprochen kostspielig. Noch größer sind die Probleme, wenn der Support einer älteren Version ausläuft. Zudem können Sicherheitslücken auftauchen, für die es keine Patches mehr gibt, wodurch ein Upgrade zur Pflicht wird. Die damit verbundene Dringlichkeit kann die Upgrade-Kosten in die Höhe treiben und die eigene Verhandlungsposition schwächen.
Es gibt eine Reihe weiterer Abhängigkeiten, die Unternehmen häufig erst spät bemerken: Konzentriert sich das eigene Personal auf eine spezielle Lösung, entsteht ein Skill-Lock-In: Das Unternehmen hat jahrelang in den Aufbau von speziellem Know-How investiert, das auch genutzt werden soll. Das führt oft dazu, dass neuere Technologien zugunsten etablierter, wenn auch veralteter Lösungen vermieden werden. Die Fähigkeit zum Wechsel sinkt. Das ist das Gegenteil von Agilität.
Gerade mit Blick auf die Cloud haben Unternehmen oft Angst vor einem neuen Technologie- und Plattform-Lock-In. Einige Unternehmen versuchen dem durch eine „Hybrid-Multi-Cloud-Strategie“ entgegenzutreten. Dabei wollen sie mithilfe von Open-Source-Abstraktionsschichten die individuellen Unterschiede der Cloud-Anbieter „wegabstrahieren“. Dieser Ansatz kann jedoch die verfügbaren Services und Features auf das Minimum reduzieren, das dem kleinsten gemeinsamen Nenner der Cloud-Anbieter entspricht. Darüber hinaus können Kosten, ein hoher Personalaufwand und zusätzliche Risiken durch Aufbau und Betrieb einer neuen Abstraktionsschicht entstehen. Es droht ein Lock-In mit der eigenen IT-Abteilung. Besitzt das IT-Team in diesem Fall wenig Erfahrung und knappe Ressourcen, kann die Innovationskraft, Auswahl und Betriebskompetenz leiden.
Lock-In-Effekte sinnvoll evaluieren
Das Thema Lock-In lässt sich daher nicht einfach auf eine einzige Strategie reduzieren. Hier bietet es sich an zu analysieren, in welcher Form Lock-Ins akzeptabel und für die Innovationskraft des eigenen Unternehmens unkritisch sind. Zudem sollte bewertet werden, in welchen Bereichen mit wenig Aufwand mehr Flexibilität erreicht werden kann.
Zuerst gilt das Prinzip „Teile und herrsche“. Statt eine große Strategie für alle Lock-In-Probleme auf einmal zu suchen, ist es besser, für jeden Anwendungsfall die richtige Herangehensweise zu wählen. IT-Architekturberater Gregor Hohpe schlägt dafür eine Vier-Felder-Matrix vor. In diesem Modell gilt es, am Anfang zwei Fragen zu beantworten:
- Was kostet ein Wechsel?
- Welchen besonderen Nutzen bietet eine bestimmte Lösung?
Die Antworten dazu können in vier Quadranten eingetragen werden:
Die einfachsten Fälle sind die beiden Quadranten im Bereich „niedrige Wechselkosten“: Hier ist das Lock-In-Risiko aufgrund der niedrigen Wechselkosten gering. Was günstig migriert werden kann, lässt sich nicht lange einsperren. Open-Source-Anwendungen, Container-Applikationen und andere Standard-Software fallen hierunter. Die Fälle, bei denen hohe Wechselkosten zu erwarten sind, sollten genauer betrachtet werden. Hier gilt es zu fragen, warum die Wechselkosten so hoch eingeschätzt werden. Lässt sich die Anwendung so aufteilen, dass sie flexibler, einfacher beherrschbar und dadurch auch günstiger zu migrieren ist? In diesem Fall kann eine Microservices-Architektur oder die Kapselung traditioneller Komponenten in Containern helfen. Häufig führt so eine Aufteilung dazu, dass viele Teile der Anwendung in den „niedrige Wechselkosten“-Quadranten rutschen und sich dadurch das Problem größtenteils von allein löst. Darüber hinaus führen kleinere, unabhängig voneinander arbeitende Teile oft zu höherer Agilität und Innovations-Geschwindigkeit in der Entwicklung.
Übrig bleiben die harten Fälle, die nur schwer aufzuteilen sind und bei denen hohe Wechselkosten drohen. Oft gehören dazu große Datenbanken oder monolithische Kernanwendungen mit langen Änderungszyklen. Dabei kann eine bewusste Entscheidung für eine bestimmten Anbieter durchaus sinnvoll sein, wenn im Gegenzug ein starker und langfristiger Nutzen entsteht. Vorsicht ist geboten, wenn die Wechselkosten hoch sind, aber kein besonderer Nutzen erwartet wird. Solche Fälle sollten Unternehmen unbedingt vermeiden, indem sie gezielt nach besseren Alternativen suchen.
Wechselwahrscheinlichkeit bei IT-Abhängigkeiten
Des Weiteren ist es nützlich zu definieren, wie wahrscheinlich es ist, dass ein Wechsel nötig wird. Die Antworten pro Anwendung können erneut auf einer Kosten-Wahrscheinlichkeits-Matrix festgehalten werden. Auch hier ist der Quadrant mit niedrigen Kosten bei gleichzeitig niedriger Wechsel-Wahrscheinlichkeit unkritisch. Eine hohe Wechselwahrscheinlichkeit ist dagegen vertretbar, wenn die Wechsel-Kosten niedrig bleiben. Das ist ein wichtiger Aspekt von „Agilität“, denn viele Wechsel bei niedrigen Wechselkosten helfen Unternehmen über häufige Iterationen hinweg, schnell bessere Lösungen zu finden.
Besondere Vorsicht sollten IT-Entscheider den Fällen mit hohen Wechselkosten widmen, bei denen häufig Wechsel erwartet werden: Woran liegt das? Gibt es Alternativen, die den nächsten Umstieg weniger wahrscheinlich oder kostengünstiger machen? Auch hier lohnt es sich, darüber nachzudenken, wie starre und veraltete Systeme, so genannte technische Schulden, abgebaut werden können.
Der erste Wechsel kann in diesem Fall zwar aufwändiger sein. Ein Beispiel wäre etwa die Migration von einer kommerziellen Datenbank auf eine Open-Source-Alternative samt Schema-Transformierung und Neu-Implementierung von Spezialfunktionen. Dafür können Unternehmen so langfristig auch einen Quadranten-Wechsel erreichen hin zu einer Situation, die zukünftige Umstiege kostengünstiger oder weniger wahrscheinlich macht. Der „Lotterie“-Quadrant mit hohen Wechselkosten bei niedriger Wechselgeschwindigkeit stellt ein latentes Risiko dar: Entweder das Unternehmen hat Glück und spart sich in Zukunft einen teuren Wechsel oder es tritt doch noch der Fall ein, dass ein ungeplanter Wechsel das Budget durcheinanderbringt. Um solchen Risiken zu begegnen, bietet es sich an, etwa über längere Zeit ein Wechsel-Budget anzusparen oder den Einfluss der betroffenen Anwendung möglichst stark von anderen Anwendungen zu entkoppeln. Das Unternehmen kann teure Wechselrisiken auch akzeptieren, wenn die Wechsel-Wahrscheinlichkeit sehr gering erscheint.
Mit diesen Fragen und den darauf aufbauenden Quadranten-Analysen können Unternehmen ihre Lock-In-Bedenken besser greifbar machen. Sie können die Vor- und Nachteile verschiedener Lösungen evaluieren. Das gilt sowohl für Technologie- als auch für Architektur-Wechsel oder für den Umstieg auf ein anderes Preismodell. Dabei spielen die Auswahl an Services, Varianten und Features pro Service, regionale Abdeckung und Preismodelle eine Rolle, da sie den Kunden die Möglichkeit bieten, innerhalb einer Plattform die richtige Lösung zu finden.
*Constantin Gonzalez arbeitet als Principal Solutions Architect bei Amazon Web Services (AWS) in München. Seit mehr als 20 Jahren beschäftigt er sich mit verschiedenen Technologien wie CPU- und Systemarchitektur, Storage, Betriebssystemen, High Performance Computing, Webtechnologien, Cloud Computing, Microservices-Architekturen, IoT und maschinellem Lernen.
Be the first to comment