Low-Code == Low Quality?

Inhaltsverzeichnis

Im Zeitalter von Digitalisierung, IT 4.0 und ähnlichen omnipräsenten Themen lässt sich festhalten: Die Geschwindigkeit in der IT nimmt fortlaufend zu. Vorbei sind die Zeiten beispielsweise von langen Architekturphasen oder Prototypen. Agile Softwareentwicklung ist schon deshalb kaum vermeidbar, weil es nicht mehr möglich ist, auf die Fertigstellung eines klassischen Softwareprojekts zu warten und erst dann in Produktion zu gehen. Seien es die Anpassung des Auftragsmanagements oder die Erweiterungen zur genaueren Datenanalyse, am liebsten möchte der Fachbereich das Ergebnis bereits gestern sehen.

Im vorliegenden Artikel schauen die Autoren auf die Geschichte der Low-Code-Ansätze, betrachten die aktuellen Angebote und bewerten, welchen (Zeit-)Gewinn sie bringen können sowie die dabei in Kauf zu nehmenden Kosten und Einschränkungen.

RAD als Vorläufer Nummer eins

Bereits in den 90er-Jahren entstanden erste Versionen von RAD-Produkten (Rapid Application Development), etwa Visual Basic, Delphi oder auch Oracle Forms. Mit diesen Programmierumgebungen können Entwickler ihre Desktop-Anwendung visuell "zusammensetzen". Sowohl die Elemente der Benutzeroberfläche als auch die Logik lassen sich als Komponenten in einer Komponentenpalette ablegen. Die grafische Oberfläche steht im Mittelpunkt und wird Schritt für Schritt um die Geschäftslogik angereichert. So zeichnen sich RAD-Tools als einfach zu erlernende Umgebungen aus. Die Oberfläche als zentrales Element ist anschaulich und ermöglicht frühe Vorstellungen von der Anwendung.

Darüber hinaus wurden andere wichtige Aspekte für Geschäftsanwendungen bedacht. Zur Anwendungsverteilung auf dem Desktop lässt sich eine einzige integrierte "fat" EXE-Datei zum Verteilen oder eine schlankere EXE mit separaten DLL-Bibliotheken generieren.

Allerdings hatten und haben RAD-Tools auch Einschränkungen. Sie sind in der Regel proprietär. Das heißt, ein Verlassen der Umgebung des Tools ist nicht oder nur eingeschränkt möglich. Die Zielumgebung ist häufig festgelegt, beispielsweise Microsoft Windows für Visual Basic und Delphi, ein Oracle-Applikationsserver nebst Datenbank für Oracle Forms. Embarcadero hat allerdings angefangen, Delphi von einer reinen Windows- in Richtung einer Cross-Plattform-Software zu erweitern. So lassen sich neben Windows heute auch macOS, Linux und insbesondere mobile Apps generieren. Die gemeinsame Arbeit an einer Anwendung ist kaum oder zumindest nur mit Einschränkungen möglich, da sie meist nur geringfügig modular aufgebaut sind. Eine Trennung ist somit höchstens anhand verschiedener Masken realisierbar.

RAD-Tools wie Visual Cafe und Borlands JBuilder hatten zudem mit der Geschwindigkeit beziehungsweise dem Ressourcenbedarf zu kämpfen. Getreu dem Motto "eat your own dog food" waren sie selbst in Java geschrieben, was zur damaligen Zeit einen enormen Ressourcenhunger bedeutete.

Im 21. Jahrhundert verschwanden die meisten genannten RAD-Umgebungen vom Radar. Java ist heute die meistgenutzte Programmiersprache und Eclipse immer noch die wohl verbreitetste Entwicklungsumgebung. "Klassische" UI-Toolkits wie Swing und SWT werden jedoch zunehmend bedeutungslos und Anwendungen praktisch ausnahmslos für das Web geschrieben. Der in Eclipse enthaltene WYSIWYG-Designer (What You See Is What You Get) WindowBuilder fristet somit ein Schattendasein.

Für den Webbereich gibt es einige kommerzielle visuelle Editoren wie MyEclipse oder
Open-Source-Produkte wie die JBoss Tools sowie NetBeans. Oracles Application Express (APEX) bietet ebenfalls eine Weboberfläche an, allerdings befinden sich Benutzer dann in Abhängigkeit zur Oracle-Datenbank.

Die Oberflächengestaltung erfolgt zunehmend mit HTML, CSS und JavaScript, womit gleichzeitig der zusätzliche Berufszweig des Webdesigners entstanden ist. Unterschiedliche Webbrowser, Betriebssysteme wie Linux und macOS und Devices vom PC über das Smartphone bis zu Wearables kommen als Zielsysteme in Frage. Schließlich sind Neuentwicklungen nur noch in den seltensten Fällen wirklich autark, in aller Regel sind andere Systeme und/oder Datenquellen anzubinden.

An dieser Stelle ist es spannend, dass Desktop-Anwendungen auf mobilen Geräten eine gewisse Renaissance erleben. Mobile Anwendungen, "Apps" unter Android und iOS, laufen komplett lokal. Die Entwicklungsumgebungen bieten entsprechend einen guten visuellen Editor mit Android Studio und Xcode an. Allerdings sind auch sie durch Webanwendungen bedroht, sei es durch responsive Webapps oder Techniken wie Progressive Web Apps (PWA).

MDSD als Vorläufer Nummer zwei

Die Idee der modellgetriebenen Softwareentwicklung (MDSD, Model Driven Software Development) ist, den Abstand zwischen Fachbereich und Entwicklung mit einer oder mehreren Modellierungssprachen zu verkleinern. Modelle sollen einen ganzheitlichen und gemeinsamen Blick auf die Domäne ermöglichen, die sowohl den technischen als insbesondere auch den fachlichen Anforderungen Rechnung trägt. UML (Unified Modeling Language) und BPMN (Business Process Modeling Notation) haben sich in Geschäftsanwendungen durchgesetzt. In Anwendungen, in denen Prozesse (BPMN), Struktur (UML-Klassenmodell) und Zustände (UML-Zustandsmodell) nicht trivial sind, ist man froh, aktuelle und ausführliche Modelle zu besitzen. Als Nebenprodukt des zu generierenden Modells erhält man so eine jederzeit aktuelle Dokumentation.

Generatoren und Interpreter sowohl zur Entwicklungs- als auch zur Laufzeit werden anschließend verwendet, um den Code soweit wie möglich aus dem Modell zu generieren beziehungsweise zu interpretieren. Der restliche Anteil, der nicht (sinnvoll) als Modell darstellbar ist, wird zusätzlich manuell und oft textuell kodiert.

MDA war über Jahre, wenn nicht gar Jahrzehnte, eines der Themen, die die Softwareentwicklung revolutionieren sollten. Allerdings ist das immer wieder erneute Generieren, insbesondere bei kleinen Änderungen wie dem Hinzufügen eines neuen Attributs mühselig und verlangt in einem Projekt mit mehr als einem Entwickler schnell nach einem größeren Koordinationseinsatz. Auch die Nahtstelle zwischen generiertem und eigenem Code bleibt problematisch. So gab es lange Zeit größeres Interesse an UML-Produkten wie AndroMDA. Heute spielen sie jedoch nur noch eine untergeordnete Rolle. BPMN erfreut sich nach wie vor großen Interesses, da Fachbereiche gut mit der Darstellungsweise zurechtkommen. Als populäres Beispiel sei das Open-Source-Produkt Camunda genannt. BPMN bildet jedoch nur einen relativ schmalen Ausschnitt aus einer Software ab und lässt sich somit kaum als vollständiger Ansatz verstehen.

Neben den genannten (und vielen weiteren ähnlichen) Plattformen dürfte so ziemlich jeder Entwickler mit ein paar Berufsjahren auf dem Buckel ambitionierte Versuche einer eierlegenden Wollmilchsau kennengelernt haben. Also den Versuch, ein Framework, eine Plattform zu implementieren, die im Rahmen des eigenen Geschäftskontexts einen Großteil der Softwareentwicklung erübrigt, standardisiert oder in irgendeiner Form vereinfacht. Dazu gehören dann Design- und Architekturvorgaben für den Entwicklungsprozess und die IT-Landschaft.

Wie so häufig steckt der Teufel dabei im Detail. Trotz aller guten Ansätze, die zur Entscheidung für eine eigenentwickelte Plattform geführt haben, werden über kurz oder lang Dinge auftauchen, die so gar nicht zu dem überlegten Modell passen. Das können, müssen aber keine eigenen Fehlentscheidungen sein. Wer hat 2007 oder sogar noch eher daran gedacht, das eine Software auch in der eingeschränkten Umgebung eines Smartphones laufen muss?