Wenn ein Unternehmen in zunehmendem Maße No-Code-Software-Tools einsetzt, kann man davon ausgehen, dass es sich auf mehreren Ebenen unverhältnismäßig stark auf sein praktisches, aber abstraktes Software-Toolset verlässt - und damit die Gefahr des Lock-in erhöht. [...]
Technologieunternehmen sprechen immer von Freiheit. Sie sagen gerne, dass ihr zentrales Marktangebot auf der Wahlfreiheit des Kunden beruht, auf der Freiheit, eine beliebige Auswahl an eigenen (oder fremden) Tools, Diensten und Funktionen zu nutzen, auf einer Laissez-faire-Haltung gegenüber dem Implementierungspartner, den ein Unternehmen auswählen möchte, und auf dem Glauben an plattformunabhängige Open-Source-Technologien, die ein Maximum an Auswahl, Flexibilität und Kontrolle bieten.
In Wahrheit ist das oft nur Angeberei.
Auch wenn sie versprechen, den offenen Weg zur Interoperabilität zu beschreiten, und in der Tat den Großteil ihrer Plattform-DNA so entwickeln und ausrichten, dass sie klar und transparent ist, geht von den meisten Technologieunternehmen immer ein gewisses „Wir können es besser“ aus, denn sie würden es lieber sehen, wenn die Kunden möglichst alles einzeln kaufen.
Im besten Fall handelt es sich dabei um ein natürliches Gewinnstreben, das nicht unbedingt zu beanstanden ist. Im schlimmsten Fall kommt es zu einer Art „Vendor Lock-in„, bei dem die Kunden aufgrund von Verträgen, Klauseln und Gepflogenheiten, die mit einer bestimmten Anbieter-Kunden-Beziehung verbunden sind, auf die Verwendung einer begrenzten Anzahl von IT-Tools festgelegt werden.
Fragen Sie einen auch nur halbwegs erfahrenen Software- oder Datenentwickler nach dieser Art von Problemen, und er wird höchstwahrscheinlich schon einmal dabei gewesen sein, es getan haben und dafür ein T-Shirt bekommen haben. Wir alle wissen, dass es solche Szenarien gibt, aber der Aufstieg von Low-Code– und jetzt auch No-Code-Softwareplattformen wird von einigen als ein beschleunigender Verschlimmerer angesehen, der dieses Dilemma noch verstärken könnte.
Die Vermutung ist, dass ein Unternehmen, das zunehmend No-Code-Tools einsetzt, auf mehreren Ebenen unverhältnismäßig abhängig von diesem abstrahierten Software-Toolset wird, was die Gefahr eines Lock-in erhöht.
Die vier No-Code Lock-ins
Wenn wir uns einig sind, dass wir diesem Konzept einen angemessenen Wahrheitsgehalt zugestehen können, was sind dann die vier Eckpfeiler des No-Code–Lock-Ins und wie können wir auf ihr Vorhandensein achten und sie vermeiden? Sie äußern sich wie folgt:
- Lock-in durch die professionellen Dienstleistungen eines No-Code-Anbieters.
- Lock-in durch der kundenspezifischen Funktionalität des Anbieters.
- Lock-in auf kommerzieller Ebene.
- Lock-in in Bezug auf Daten und Code-Eigentum.
Der Aufbau eines starken internen Kompetenzzentrums könnte eine Lösung sein, um einige dieser Risiken auf breiterer Ebene abzumildern, aber lassen Sie uns die vier (oben) aufgezählten Eckpfeiler der Reihe nach betrachten und untersuchen, wie man sie umgehen kann.
Lock-in der professionelle Dienstleistungen
Ein Lock-in, der sich aus den professionellen Dienstleistungen eines Anbieters ergibt, tritt auf, wenn ein Unternehmen nur eine begrenzte Auswahl an Vertragspartnern für die anfängliche Systemintegration und die laufende Implementierung von Dienstleistungen hat.
So kann es beispielsweise sein, dass es in einer bestimmten Region nur einen oder eine Handvoll Integratoren gibt, die mit der Lösung eines bestimmten Anbieters arbeiten. In diesem Fall sind diese Dienstleistungen auf Anfrage nicht ohne weiteres verfügbar und werden möglicherweise nicht zu einem wettbewerbsfähigen Preis angeboten.
Katherine Kostereva ist Gründerin und CEO des in Boston, Massachusetts, ansässigen Unternehmens für Low-Code/No-Code-Prozessmanagement und CRM Creatio. Sie erklärt, wie sie die Technologie ihres Unternehmens mit einer angeborenen und realistischen Einschätzung der Risiken in diesem Bereich aufgebaut hat. Kostereva empfiehlt, Anbieter auszuwählen, die über umfangreiche Partnernetzwerke (von globalen Systemintegratoren bis hin zu kleineren Beratungsunternehmen) in der ganzen Welt verfügen.
Lock-in durch kundenspezifische Funktionen
Eine durch die kundenspezifische Funktionalität des Anbieters verursachte Abhängigkeit liegt vor, wenn eine bestimmte kundenspezifische Funktionalität, die der Anbieter für einen Kunden entwickelt hat, nur schwer unterstützt, erweitert oder angepasst werden kann. In diesem Fall könnte das Unternehmen in der Lage sein, sich weiterzuentwickeln, ohne ständig auf die Dienste des Anbieters und sein einzigartiges Fachwissen angewiesen zu sein.
„Um dies zu vermeiden, raten wir, darauf zu achten, dass eine Low-Code/No-Code-Plattform eine moderne, flexible Architektur mit maximaler Kompositionsfähigkeit bietet (wie unsere eigene paketbasierte Architektur), die es den Entwicklern ermöglicht, lose gekoppelte Funktionsblöcke zu erstellen und diese in kleinen Teilen und fast unabhängig voneinander anzupassen“, erklärt Kostereva.
Ein umfangreiches Ökosystem solcher kompatiblen Anwendungen ist ein echter Schutz vor einer funktionsbezogenen Anbieterbindung.
Lock-in auf kommerzieller Ebene
Das Schreckgespenst des kommerziellen Lock-in entsteht oft durch komplexe oder intransparente Verträge, Nutzungsbedingungen und versteckte Kosten. Dies ist dann der Fall, wenn die anfänglichen Gesamtbetriebskosten im Laufe der Zeit ansteigen, weil es nicht möglich ist, ohne kostenpflichtige Zusatzmodule und Integrationen zu arbeiten, wenn die Gebühren für die Datennutzung schrittweise ansteigen und wenn andere schleichende Kosten im Vertrag versteckt sind.
Um dem entgegenzuwirken, ist es laut Kostereva und Team wichtig, von Anfang an zu prüfen, wie transparent die Vertragsklauseln sind. Dies gilt insbesondere für No-Code-Plattformen, da sie oft Teil eines ausgeklügelten Anbieter-Ökosystems sind.
„Die Lösung für dieses Problem ist Transparenz, sorgfältiges Studium des Vertrags und echte Sorgfalt. ‚Echte Fürsorge‘ ist für uns ein Teil der DNA unseres Unternehmens. Mit diesem Begriff meinen wir den Aufbau aufrichtiger und langfristiger Beziehungen, die Bereitstellung einer helfenden Hand zuerst (und das Nachdenken über das Geschäft und die Kosten danach), die offene und transparente Kommunikation und die Schaffung von Mehrwert“, so Kostereva von Creatio.
Lock-in in Bezug auf Daten- und Code-Eigentum
Abschließend (für den Moment) sollten wir uns mit dem Einschluss von Daten- und Codebesitz befassen. Dies ist der Fall, wenn es für den Benutzer (damit meinen wir zunächst die Entwickler, jetzt aber auch die Low-Code-/No-Code-Business-Community) keine einfache Möglichkeit gibt, nach Beendigung der Beziehung zum Anbieter auf seinen benutzerdefinierten Code und seine Daten zuzugreifen, sie zu ändern oder zu übertragen.
„All diese Optionen sind ein Muss für moderne No-Code-Plattformen und sollten ausdrücklich im Vertrag aufgeführt werden. Von der technischen Seite her haben wir diese Fähigkeit mit unserer flexiblen, paketbasierten Architektur und dem Einsatz moderner Technologie bereitgestellt. Die Benutzeranpassungen werden in separaten Paketen gespeichert, auf die der Benutzer leicht zugreifen, sie ändern und herunterladen kann. Die Benutzerdaten sind vollständig geschützt und können vom Eigentümer jederzeit in beliebiger Weise abgerufen werden“, so Kostereva.
Kostereva empfiehlt No-Code-Lösungen, die gängige Technologien und Programmiersprachen (C#, JavaScript, Angular) verwenden. Im Fall von Creatio macht dies die Wiederverwendung des von den No-Code-Tools von Creatio generierten Quellcodes für professionelle Entwickler recht einfach, falls dies erforderlich sein sollte.
Zunehmende Popularisierung
Da das Universum der gebrauchsfertigen Anwendungen nun wie Pilze aus dem Boden schießt und die Popularisierung von Low-Code/No-Code unvermindert weitergeht, sollten wir vielleicht einen neuen mentalen technologischen Prüfmechanismus entwickeln, um diese Lock-in-Fallen zu erkennen.
Ohne die Vorteile von Low-Code-Plattformen und -Tools ausbremsen, vereiteln oder abschwächen zu wollen, könnten sie die Freiheit einschränken, wenn wir nicht auf einige der hier aufgeführten Vorbehalte und Vorsichtsmaßnahmen achten.
Denken wir daran, dass Low-Code-Tools weniger, aber vor allem No-Code-Tools Unternehmen die Möglichkeit bieten, Unternehmensabläufe ohne besondere Kenntnisse zu automatisieren. Wenn ein Unternehmen dieses Maß an Selbstständigkeit erreichen will, muss es diese Plattformen mit der gebotenen Sorgfalt und Überlegung angehen, um die Vorteile zu nutzen, die sich daraus ergeben.
*Adrian ist ein Technologiejournalist mit über zwei Jahrzehnten Erfahrung in der Presse. Sein Hauptaugenmerk liegt auf der Untersuchung von Fragen der Software-Anwendungsentwicklung. Sein besonderes Interesse gilt außerdem Open Source, Datenanalyse und Datenintelligenz, Cloud Computing, mobilen Geräten und Datenmanagement. Er hat für verschiedene Printmedien, Zeitungen und das Fernsehen gearbeitet.
Be the first to comment