Von Low-Code-Anbieterbindung befreien
Lerne, wie du das Vendor-Lock-in bei Low-Code-Plattformen angehst.
Iván Alfonso, Aaron Conrardy, Jordi Cabot
― 10 min Lesedauer
Inhaltsverzeichnis
- Das Problem mit Vendor Lock-In
- Was ist Interoperabilität?
- Aktueller Stand der Low-Code-Plattformen
- Analyse der Interoperabilität
- Unser Ansatz zur Interoperabilität
- Formales Exportverfahren
- Alternatives Exportverfahren
- Importieren von Modellen
- Formales Importverfahren
- Alternatives Importverfahren
- Herausforderungen Vor Uns
- Erstellung eines Standard-Austauschmodells
- Überwindung von Import/Export-Beschränkungen
- Inkrementelle Migration
- KI-gestützte Methoden für Import/Export
- Der Weg Nach Vorn
- Originalquelle
- Referenz Links
Low-Code-Plattformen sind Tools, die es Nutzern ermöglichen, Anwendungen mit minimalem Handcoding zu erstellen. Sie bieten eine visuelle Möglichkeit, Software zu bauen und zu modifizieren, was die Entwicklung beschleunigen und es für Nicht-Programmierer zugänglicher machen kann. Allerdings tun sich diese Plattformen oft schwer, gut miteinander zu arbeiten, was für die Nutzer frustrierend sein kann.
Das Problem mit Vendor Lock-In
Eines der grössten Probleme, mit denen Leute konfrontiert sind, wenn sie Low-Code-Plattformen nutzen, ist der Vendor Lock-In. Das bedeutet, dass man, nachdem man seine Anwendung auf einer bestimmten Plattform erstellt hat, das Gefühl hat, in einer schlechten Beziehung festzusitzen – man muss von vorne anfangen. Nutzer können sich festgefahren fühlen, weil verschiedene Plattformen nicht reibungslos kommunizieren oder Informationen austauschen. Einfach gesagt, sein Projekt auf eine andere Plattform zu bringen, ist wie zu versuchen, seine Frisur in einem Salon zu ändern, der nur weiss, wie man Pony schneidet.
Interoperabilität?
Was istInteroperabilität bezieht sich auf die Fähigkeit verschiedener Plattformen, zusammenzuarbeiten, auch wenn sie verschiedene Sprachen oder Regeln haben. Es ist, als würde man versuchen, Freunde aus verschiedenen Kulturen auf einer Party zu verbinden. Wenn sie nur ihre eigenen Sprachen sprechen, ohne ein gemeinsames Verständnis, wird es schwierig für sie, sich zu verstehen. Ein gutes Mass an Interoperabilität bedeutet, dass verschiedene Plattformen einander verstehen können und es den Nutzern erleichtert wird, ihre Projekte zu migrieren.
Aktueller Stand der Low-Code-Plattformen
Der Low-Code-Markt hat mehrere beliebte Plattformen wie Mendix, OutSystems und Microsoft PowerApps. Diese Plattformen sind bekannt für ihre robusten Fähigkeiten, werden aber oft dafür kritisiert, dass sie nur begrenzte Optionen beim Verschieben von Projekten bieten. Es ist wie ein Foodtruck, der das beste Essen der Stadt hat, aber nur eine Art Taco serviert. Während die Kunden den Taco lieben, möchten sie vielleicht irgendwann einen Burrito von einem anderen Truck, fühlen sich aber am Taco-Stand gefangen.
Diese Plattformen bieten in der Regel nur eingeschränkte Import- und Exportfunktionen, was ein grosses Hindernis darstellen kann. Obwohl sie ähnliche technische Formate verwenden, unterscheiden sich die Schemata und zugrunde liegenden Sprachen so stark, dass sie das Migrieren von Daten erschweren.
Analyse der Interoperabilität
Um die Interoperabilität von Low-Code-Plattformen zu verstehen, können wir uns die verfügbaren Optionen für das Importieren und Exportieren von Modellen ansehen. Man könnte es mit einer Bestandsaufnahme in einer Küche vergleichen, um zu sehen, welche Zutaten für ein neues Gericht vorhanden sind.
Wenn Plattformen nur grundlegende Funktionen anbieten, stehen viele Nutzer mit unvollständigen Rezepten da. Zum Beispiel könnten einige Plattformen das Exportieren einer Datenstruktur erlauben, aber nicht die Beziehungen oder andere wichtige Details, die für eine Anwendung notwendig sind, um reibungslos zu funktionieren. Nutzer werden dann zu Köchen, die mit halbgaren Zutaten arbeiten, und es ist ziemlich herausfordernd, ein vollständiges Gericht zuzubereiten.
Unser Ansatz zur Interoperabilität
Um die Interoperabilität zu verbessern, wird ein modellbasierter Ansatz eingeführt. Das bedeutet, dass Nutzer nicht jedes Mal von vorne anfangen müssen, wenn sie ein Projekt migrieren wollen, sondern an einem Standardpunkt beginnen können. Es ist ein bisschen so, als hätte man eine universelle Fernbedienung für verschiedene TV-Marken: Man braucht nur ein Tool, um sie alle zu steuern.
Dieser modellbasierte Ansatz kann in zwei Hauptszenarien funktionieren:
-
Formales Exportverfahren: Wenn eine Plattform das Exportieren von Modellen in einem lesbaren Format erlaubt, können wir die benötigten Informationen einfach extrahieren, um sie für die Migration vorzubereiten.
-
Alternatives Exportverfahren: Wenn eine Plattform kein formales Exportieren anbietet, können wir visuelle Erkennungsmethoden verwenden, um Screenshots von Modellen zu analysieren und basierend auf diesem Bild ein neues Modell zu erstellen.
Formales Exportverfahren
Wenn eine Plattform eine Möglichkeit bietet, Modelle in einem textlichen Format zu exportieren, wird der Prozess einfacher. Dadurch können wir Informationen wie Klassen und Beziehungen extrahieren und in ein Modell umwandeln, das auf einer neuen Plattform verwendet werden kann. Dieser Ansatz sorgt für einen reibungsloseren Übergang beim Wechsel der Plattform, ähnlich wie das nahtlose Übergehen von einem Lied zum nächsten in einer Playlist.
Hier leiten die Transformationsregeln den Exportprozess. Jede Plattform hat ihre eigene Art, Daten zu strukturieren, aber viele nutzen ähnliche Konzepte, was die Übersetzung erleichtert. Die Idee ist, die Elemente zu identifizieren, die von der Quellplattform in ein Format umgewandelt werden können, das die Zielplattform verstehen kann.
Alternatives Exportverfahren
In Fällen, in denen eine Plattform keine ordnungsgemässe Exportfunktion bietet, können wir visuelle Modelle verwenden. Indem wir ein Bild des Modells analysieren, können wir eine neue Darstellung generieren. Während diese Methode nicht jedes Detail erfassen kann, fungiert sie als Backup-Plan, wenn der ursprüngliche Plan scheitert, ähnlich wie das Finden eines Snacks, wenn das Abendessen verspätet ist.
Ein visuelles Sprachmodell (wie ein schickes KI-Tool) hilft dabei, den Screenshot zu interpretieren und das Modell neu zu erstellen. Dieser Prozess erfordert, einige Kontextinformationen über die spezifische Plattform bereitzustellen, um sicherzustellen, dass die KI versteht, wie das Bild richtig interpretiert wird.
Importieren von Modellen
Sobald wir das Modell bereit haben, ist es Zeit, über das Importieren in die Zielplattform nachzudenken. Dieser Prozess kann ebenfalls in zwei Szenarien unterteilt werden:
-
Formales Importverfahren: Wenn die Zielplattform formale Importe erlaubt, können wir die notwendigen Dateien generieren, die dem erwarteten Format entsprechen.
-
Alternatives Importverfahren: In Fällen, in denen es keine einfache Importoption gibt, erlauben viele Plattformen den Nutzern, Daten aus Quellen wie Excel oder CSV-Dateien hochzuladen, um neue Projekte zu erstellen. Es ist ein bisschen so, als würde man eine Take-out-Box benutzen, um Reste von einem Restaurant zum anderen zu bringen.
Formales Importverfahren
Wenn eine Plattform formale Importe unterstützt, können wir Dateien erstellen, die so strukturiert sind, dass die neue Plattform sie versteht. Dabei wird eine Zuordnung der Elemente vom generierten Modell zur Sprache und Syntax der Zielplattform vorgenommen.
Diese Zuordnung dient als Übersetzungsleitfaden und sorgt dafür, dass alles gut zusammenpasst und einen reibungslosen Übergang ermöglicht. Darüber hinaus ermöglichen Plattformen wie Appian und Oracle Apex das Importieren vollständiger Projekte, einschliesslich Daten, Verhalten und grafischen Modellen, durch vordefinierte Formate.
Alternatives Importverfahren
Für Plattformen, die keine direkten Modellimporte unterstützen, erlauben viele den Import von Daten aus Dateien wie Excel oder CSV. Das ist zwar keine Standardmethode für den Import eines Datenmodells, aber bietet eine Alternative für Nutzer in solchen Situationen. Der Prozess umfasst das Erstellen strukturierter Dateien, die helfen, das benötigte Datenmodell für die Zielplattform abzuleiten.
Wenn man Excel verwendet, generiert jedes Sheet eine neue Klasse, und die Spalten erstellen Attribute. Diese Methode erfasst jedoch möglicherweise die Beziehungen nicht so genau, was zu weniger umfassenden Modellen führen kann. Man könnte sich das vorstellen wie einen Salat ohne das richtige Dressing; es mag gesund sein, aber nicht wirklich zufriedenstellend.
Herausforderungen Vor Uns
Trotz der vorgeschlagenen Methoden zur Verbesserung der Interoperabilität bleiben Herausforderungen bestehen. Nutzer sollten sich bewusst sein, dass Low-Code-Plattformen oft an robuster Dokumentation oder Unterstützung für die Migration von Projekten mangeln, was zu frustrierenden Erfahrungen führen kann. Der Fokus vieler kommerzieller Plattformen liegt darauf, Kunden zu halten, anstatt ihnen zu helfen, woandershin zu migrieren. Die Leute sind oft mit Produkten stuck, die keinen einfachen Ausstieg ermöglichen, was sich anfühlen kann wie in einem endlosen Verkaufsangebot für ein Produkt, das man nicht einmal kaufen wollte.
Erstellung eines Standard-Austauschmodells
Eine wichtige Lösung für das Interoperabilitätsdilemma ist die Schaffung eines standardisierten Austauschmodells für Low-Code-Plattformen. Das Fehlen eines standardisierten Modells bedeutet, dass jede Plattform in ihrer eigenen Blase operiert, was zu Reibungspunkten für Nutzer führt, die wechseln möchten.
Die Erstellung eines solchen Modells würde reibungslose Transfers zwischen den Plattformen ermöglichen, ähnlich wie standardisierte Emojis über Geräte hinweg Menschen helfen, freier zu kommunizieren – egal welche Marke von Telefon sie besitzen. Wenn alle aus demselben Songbuch singen, würde das Bewegen von Modellen zwischen Plattformen zum Kinderspiel, und die Nutzer könnten sich mehr darauf konzentrieren, zu bauen, als sich um die Kompatibilität zu sorgen.
Überwindung von Import/Export-Beschränkungen
Einschränkungen bei Import- und Exportfunktionen können zu unvollständigen Modellen führen, sodass Nutzer mit einem Puzzle dastehen, dem einige wichtige Teile fehlen. Während die manuelle Vervollständigung eine Option ist, wäre es viel effektiver, Techniken zu entwickeln, die den Prozess der Wiederherstellung fehlender Elemente automatisieren. Man könnte es sich wie einen zuverlässigen Rezeptdienst vorstellen, der einem die fehlenden Schritte gibt, wenn man beim Kochen etwas vergessen hat.
Der Einsatz von KI oder einfacheren regelbasierten Methoden kann das Migrationserlebnis verbessern, sodass die Nutzer ihre Bemühungen woanders fokussieren können, anstatt als Detektiv zu spielen. Das Ziel wäre es, den Übergang so einfach wie möglich zu gestalten.
Inkrementelle Migration
Über die Migration vollständiger Modelle hinaus sollten Plattformen die Idee der inkrementellen Migration in Betracht ziehen. Das bedeutet, bestehende Komponenten zu erkennen und neue Elemente hinzuzufügen, ohne die Änderungen des Nutzers zu überschreiben. Man könnte sich das vorstellen wie eine Softwareplattform, die anbietet, frische Toppings auf die Pizza zu streuen, ohne das Ganze zu verändern. Es geht darum, den Nutzern Flexibilität und Kontrolle über ihre Arbeit zu geben.
KI-gestützte Methoden für Import/Export
Die Erforschung fortschrittlicher KI-Techniken für alternative Import- und Exportmethoden könnte ebenfalls den Prozess verbessern. Für das Exportieren könnte die Nutzung von Multi-Bild- oder Videoerkennung das Verständnis der KI für grosse Modelle verbessern, sodass sie jedes Detail genau erfassen kann.
Für den Import wäre es ein echter Game Changer, eine KI zu trainieren, um ein Modell mithilfe der Benutzeroberfläche der Zielplattform zu replizieren. Dieser intelligente Assistent könnte die Nutzer durch die Rekonstruktion ihrer Modelle führen und den Übergang weniger entmutigend machen.
Der Weg Nach Vorn
Obwohl es erhebliche Herausforderungen gibt, verändert sich die Low-Code-Landschaft, und Verbesserungen können geschehen. Das Problem des Vendor Lock-In anzugehen und die Interoperabilität zu verbessern, kann zu besseren Erfahrungen für alle Nutzer führen. Durch die Schaffung eines einheitlicheren Ansatzes würden die Nutzer von schnelleren Übergängen und weniger Kopfschmerzen profitieren.
Es ist entscheidend, bessere Tool-Unterstützung zu entwickeln, insbesondere in Bezug auf UI- und Verhaltensmodelle. Dazu gehören Pläne zur Erstellung benutzerfreundlicher Oberflächen, die den Migrationsprozess vereinfachen. Man könnte sich einen hilfreichen Kumpel in der Softwarewelt vorstellen, der einen Schritt für Schritt durch den Umzugsprozess führt.
Während Entwickler und Innovatoren weiterhin an diesen Lösungen arbeiten, besteht die Hoffnung, dass eine neue Ära der Zusammenarbeit entsteht, die es den Nutzern ermöglicht, die vollen Vorteile von Low-Code-Plattformen zu nutzen, ohne sich in einem einzigen Vendor-Ökosystem gefangen zu fühlen. Die Zukunft sieht vielversprechend aus, und es könnte eine Welt geben, in der Low-Code-Plattformen wirklich gut miteinander auskommen!
Originalquelle
Titel: Towards the interoperability of low-code platforms
Zusammenfassung: With the promise of accelerating software development, low-code platforms (LCPs) are becoming popular across various industries. Nevertheless, there are still barriers hindering their adoption. Among them, vendor lock-in is a major concern, especially considering the lack of interoperability between these platforms. Typically, after modeling an application in one LCP, migrating to another requires starting from scratch remodeling everything (the data model, the graphical user interface, workflows, etc.), in the new platform. To overcome this situation, this work proposes an approach to improve the interoperability of LCPs by (semi)automatically migrating models specified in one platform to another one. The concrete migration path depends on the capabilities of the source and target tools. We first analyze popular LCPs, characterize their import and export alternatives and define transformations between those data formats when available. This is then complemented with an LLM-based solution, where image recognition features of large language models are employed to migrate models based on a simple image export of the model at hand. The full pipelines are implemented on top of the BESSER modeling framework that acts as a pivot representation between the tools.
Autoren: Iván Alfonso, Aaron Conrardy, Jordi Cabot
Letzte Aktualisierung: 2024-12-06 00:00:00
Sprache: English
Quell-URL: https://arxiv.org/abs/2412.05075
Quell-PDF: https://arxiv.org/pdf/2412.05075
Lizenz: https://creativecommons.org/licenses/by/4.0/
Änderungen: Diese Zusammenfassung wurde mit Unterstützung von AI erstellt und kann Ungenauigkeiten enthalten. Genaue Informationen entnehmen Sie bitte den hier verlinkten Originaldokumenten.
Vielen Dank an arxiv für die Nutzung seiner Open-Access-Interoperabilität.
Referenz Links
- https://listlu-my.sharepoint.com/:p:/g/personal/ivan_alfonso_list_lu/EUUIsqZjUkdGtA8S6CMVU7UBssQvnAUFS7iXk7fUgZrUWA?e=COAdEo
- https://www.outsystems.com/forge/component-overview/18855/cool-data-model-info-react-o11
- https://www.outsystems.com/forge/
- https://www.omg.org/spec/UMLDI/1.0/About-UMLDI
- https://docs.anthropic.com/en/docs/build-with-claude/computer-use
- https://github.com/BESSER-PEARL/BESSER-Migration-Hub.git
- https://github.com/BESSER-PEARL/BESSER.git
- https://www.ifml.org/