Lock-In Effekte in Organisationen
Get out – Lock-In strategisch minimieren
Welche Arten von Lock-In in aktuellen oder zukünftigen in Organisationen auftreten und wie diese zu minimieren sind
Mit zunehmender Auslagerung von IT-Ressourcen und IT-Prozessen zu Drittanbietern gewinnt das Thema des bewussten Managements von Lock-In immer mehr an Relevanz. Das Problem des Lock-In beschreibt, dass ein genutzter Service oder ein verwendetes Produkt nicht ohne Aufwand durch eine gleichwertige Lösung eines anderen Anbieters ausgetauscht werden kann. Was zuerst nur nach Technik klingt, kann sich aber auch andere Formen annehmen. Eine gute Übersicht über die einzelnen Lock-In Varianten wurde bereits von Martin Fowler und Gregor Hohpe veröffentlicht, die im Folgenden als Basis dient.
Erstgespräch anfragen
Tristan
Pötzsch
André
Rentschler
Niklas
Fischer
Adam
Zgraja
Lock-In Arten im Detail
- Bei dieser Art des Lock-In handelt es sich um die Schwierigkeit, von einem Anbieter zu einem anderen zu wechseln. Im Falle eines Vendor Lock-In besteht die Problematik darin, dass ein Anbieterwechsel nur durch sehr hohe Kosten und Aufwände, oder durch weitreichende strukturelle Änderungen zu bewerkstelligen ist. Diese Problematik kann zum Beispiel durch Preiserhöhungen oder ein verändertes Produktangebot seitens des Anbieters zu zusätzlichen Problemen führen.
- Beispiel: Verwendung von cloud-nativen Produkten eines Cloud-Anbieters wie Data Factory auf MS Azure.
- Im Rahmen des Produkt Lock-In steht die starke Bindung an ein Produkt oder einen Service im Vordergrund. Diese Produktbindung kann durch maßgeschneiderte und stark personalisierte Produkte, sowie durch die Integration eines Produktes in die firmeneigene Architektur entstehen. Durch die Nutzung von Open-Source Produkten lässt sich zwar die Anbieterbindung verringern, eine gewisse Produktbindung bleibt jedoch durch bestimmte APIs, Funktionalitäten und Konfigurationen immer bestehen.
- Beispiel: Ein starker Produkt Lock-In ist zum Beispiel die SAP-Welt, die extra für einen Kunden oder Bereich individualisiert wurde. Aber auch die Nutzung der Programmiersprache Java für eigene Applikation ist ein Produkt Lock-In.
- In vielen großen Unternehmen gibt es interne Richtlinien, welche die Verwendung bestimmter Technologien und deren Versionen vorgibt oder beschränkt. Darüber hinaus können umfangreiche Modifizierungen einer Standardlösung im Falle von Versions-Upgrades dazu führen, dass die Anpassungen unbrauchbar gemacht oder zunehmend kostspielig werden. Die Probleme, welche durch einen Versions Lock-In entstehen, verstärken sich über die Zeit. So kann der IT-Support für veraltete Versionen seitens des Anbieters eingestellt werden, Sicherheitslücken auftreten, für die keine Patches bereitgestellt werden, oder aber die Nutzung eins bestimmten Betriebssystems zwingend erforderlich sein.
- Beispiel: Verwendung von Java JDK 11, auch wenn der aktuelle Stand Java JDK 18 ist.
- Die Verwendung oder Wahl einer IT-Architektur ist eine weitreichende und strategisch wichtige Frage. Lock-In ist dabei vorprogrammiert, da eine schnelle und unkomplizierte Änderung der Architektur nie möglich ist. Die enormen Kosten und Aufwände, die bei einem Architektur Wechsel auftreten, können eine Festlegung auf eine altbewährte Architektur zur Folge haben. So müsste bei dem Wechsel einer monolithischen Architektur zu einer serverlosen Architektur die Granularität der Dienste komplett anders geschnitten werden.
- Beispiel: Umstellung von einer Host-Architektur in eine dezentrale oder Microservice Architektur; Umstellung einer containerbasierten Microservice zu einer serverlosen Architektur.
- Konzentrieren sich Unternehmen und deren Personal auf spezielle Lösungen, entsteht ein Fähigkeiten Lock-In. Wenn Personal sich zum Beispiel mit Python und den entsprechenden Libraries vertraut machen, brauchen sie Zeit, um auf andere Dienste oder Technologien umzuschulen. Unternehmen haben über lange Zeit in ihr Personal und den Aufbau von speziellem Know-How investiert, welches dann auch genutzt werden soll. Das kann dazu führen, dass neuere Technologien oder Produkte zugunsten etablierter, wenn auch älterer Lösungen vermieden werden und die Bereitschaft und Fähigkeit zu einem Wechsel sinkt.
- Beispiel: Sichtbar bei Produkten, die benutzerdefinierte Sprachen verwenden oder bei „config only“ / no-code Frameworks
- Hierbei handelt es sich um eine spezielle Form der Produktbindung. Plattformen führen Anwendungen aus und können auch Benutzerkonten und verschiedenste Zugriffsrechte und Infrastruktursegmentierungen enthalten. Cloud Plattformen bieten zusätzlich Dienste wie Speicher- oder Machine Learning Dienste, die in der Regel nicht frei zugänglich sind. Man kann den Grad des Lock-In bei Plattformen reduzieren, indem man diese proprietären Dienste nicht nutzt, jedoch macht dies ein wesentliches Motiv einer Plattformnutzung zunichte.
- Beispiel: Nutzung der GCP Plattform und Plattform-nativer managed services.
- Verträge und rechtliche Rahmenbedingungen führen oftmals dazu, dass Unternehmen an bestimmte Lösungen gebunden sind. So können europäische Unternehmen zum Beispiel ihre Daten nicht in Rechenzentrum im Nicht-EU-Ausland oder anderer Cloud-Anbieter migrieren. Lizenzvereinbarungen mit Softwareanbietern können darüber hinaus verbieten, Systeme in die Cloud zu verlagern, obwohl diese dort wesentlich performanter laufen würden.
- Beispiel: Oracle Datenbanken dürfen nicht auf VM-Instanzen bei den gängigen Hyperscalern betrieben werden, sondern dürfen wenn dann nur als Bare Metal Solution zum Einsatz kommen.
- Eine unterschwellige gleichwohl ernste Art ist der mentale Lock-In. Bei dieser Art handelt es sich darum, dass Entscheidungsträger aufgrund gemachter Erfahrungen mit Produkten oder Dienstleistern eine gewissen Voreingenommenheit in den Entscheidungsprozess einfließen lassen. Diese Voreingenommenheit kann vor allem im Falle schlechter Erfahrungen dazu führen, dass gewisse Optionen verworfen werden.
- Beispielsweise: Entscheidungsträger A hat in einem vergangenen Projekt Probleme mit dem Support Team für Sybase Produkte erlebt und ist seither gegen jegliche Produkte dieser Reihe.
Regulatorische Rahmenbedingungen und Trade-Offs
Der Gesetzgeber hat das Thema Lock-In ebenfalls im Rahmen der Leitlinien zur Auslagerung an Cloud-Anbieter berücksichtigt. In diesen definiert die ESMA Verhaltensweisen für Fonds, CCPs, Transaktionsregister, Kreditinstitute und CSDs, die sicherstellen müssen, dass sie trotz Auslagerungen an Externe stets die Risiken und Kundendaten in der eigenen Hand haben müssen.
Insbesondere nach Leitlinie Nr. 5 (Ausstiegsstrategie) muss beim Eingehen einer wesentlichen Auslagerung mit einem Cloud-Anbieter ein Exit-Plan definiert werden. Auf Basis dessen soll das auslagernde Unternehmen rechtliche und strategische Planungssicherheit in Bezug auf das Cloud-Engagement erlangen. Grundsätzlich muss ein Kreditinstitut/Finanzdienstleister bei wesentlichen Auslagerungen perspektivisch (Trigger-)Events definieren, die zukünftig eine Störung oder Beendigung der Nutzung des Cloud-Services auslösen könnte.
In einem solchen Fall muss sichergestellt sein, dass eine Auslagerungsvereinbarung mit einem Cloudanbieter beendet werden kann, ohne kritische/wesentliche Funktionen der Bank zu gefährden. Konkret bedeutet dies, dass durch den Ausfall des Cloudangebots weder
- das Kundengeschäft unverhältnismäßig unterbrochen werden darf,
- noch die Einhaltung der anzuwendenden rechtlichen Vorschriften
- noch die Vertraulichkeit und Integrität der Kundendaten gefährdet sein darf.
Die Akteure müssen bei Auslagerungen an einen Cloudanbieter einen Überblick, rechtliche Sicherheit und Flexibilität bewahren. Hierfür sollten die Banken und Finanzdienstleister folgende messbare Maßnahmen vor dem Eingehen einer Cloud-Auslagerung etablieren:
- Ausstiegsplan (Umfassend, überprüft und dokumentiert)
- Alternativen (Übergangspläne und Brückenlösungen)
- Verträge (Kooperation des Cloudanbieters bei Beendigung)
- Messbarkeit (KPIs, Szenario- & Impact-Analysen)
Grundsätzlich kann festgehalten werden, dass der Einsatz von Cloud-Services einer tieferen individuelle Risikoanalyse Bedarf als der klassische Bezug isolierter Hardware oder Software-Lizenzen.
Wer vor der Entscheidung steht, wesentliche (Bank-)Funktionen an Cloud-Anbieter auszulagern, sollte sich anhand einer einfachen 2×2-Matrix klar machen, welcher Nutzen durch die Cloud-Auslagerung generiert wird. Der Einsatz von Cloud zieht grundsätzlich Wechselkosten auf technischer, menschlicher oder rechtlicher Ebene nach sich. Entsprechend hoch muss der entstehende Nutzen sein, um zumindest einen „akzeptierten Lock-In“ zu erreichen. Die ESMA-Leitlinien stellen als Rahmenbedingungen sicher, dass Banken und Finanzinstitute sich dieser Wechselkosten von Beginn an bewusst sind und überhaupt in der Lage sind, Alternativlösungen in Notfällen treffen zu können.
Wie solche Lock-Ins am Beispiel der Nutzung von Serverless-Architekturen möglichst minimiert werden können, wurde von uns in einem Whitepaper „The silence of the Lambda – Portabilität von Serverless / FaaS Implementierungen zwischen Cloud Providern unter Berücksichtigung regulatorischer Anforderungen“ untersucht. Dieses Whitepaper finden Sie hier.
Disclaimer: Bei der Erstellung des Inhalts ist die größtmögliche Sorgfalt verwendet worden, dennoch bleiben Änderungen, Irrtümer und Auslassungen vorbehalten. Die getroffenen Aussagen basieren auf Beurteilungen, historischen Daten und rechtlichen Einschätzungen zum Zeitpunkt der Erstellung des Inhalts. Alle Angaben erfolgen ohne Gewähr für die inhaltliche Richtigkeit und Vollständigkeit. Die Überlassung des Inhalts erfolgt nur für den internen Gebrauch des Empfängers. Die Aufbereitung stellt keine Rechts- oder Anlageberatung dar. Diese muss individuell unter Berücksichtigung der Umstände des Einzelfalls erfolgen.
Für eine bessere Lesbarkeit wird auf dieser Website das generische Maskulinum verwendet, wobei alle Geschlechter gleichermaßen gemeint sind.