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?

Low-Code- beziehungsweise No-Code-Plattformen

Unter anderem durch eine Veröffentlichung der Forrester Group ist der Begriff Low-Code publik geworden. Im Prinzip geht es darum, möglichst viele Konzepte unter einen Hut zu bekommen, die das Schreiben von Code erübrigen oder zumindest deutlich reduzieren. So enthalten die Low-Code-Plattformen die Vorgehensweisen von RAD und MDSD und berücksichtigen ALM (Application Life Cycle Management) sowie Continuous Integration (CI) beziehungsweise Continuous Deployment (CD) für Entwicklungs-, Test- und Produktionsumgebungen – kurzum den Makro- und Mikro-Entwicklungsprozess.

Um eine "One-Click"-Erstellung der gesamten Umgebung zu ermöglichen, muss eine entsprechende PaaS (Platform as a Service) zur Verfügung stehen. Dazu existieren On-premise-Angebote wie die Container-Plattform OpenShift, in der Regel jedoch entsprechende Cloud-Services. Diese aPaaS (Application Platform as a Service) bieten alles an, was eine Anwendung für ihren gesamten Lebenszyklus benötigt – von der ersten Planungsphase über die Entwicklung, Abnahme bis in den Betrieb. Abbildung 1 zeigt die Architektur einer Low-Code-Plattform.

Wer Interesse an der Geschichte der Softwareentwicklung hat, sei an der Stelle auf die Ähnlichkeiten der Low-Code-Plattformen zu den CASE-Tools (Computer Aided Software Engineering) hingewiesen. Hier gilt wohl der Spruch "Wer zu früh ist, den bestraft das Leben", CASE-Werkzeuge stammen aus einer Zeit weit vor Cloud & Co. und damals gab es viele der Möglichkeiten von heute noch nicht.

Eine umfassende Low-Code-Plattform sollte sämtliche in Abbildung 1 dargestellten Aspekte der Softwareentwicklung abdecken. Entwicklungswerkzeug(e), Entwicklungs-, Test und Produktionsumgebung sowie der Entwicklungsprozess sind in einer Plattform zusammengefasst. Die Möglichkeit, sämtliche Funktionen als Cloud-Service (aPaaS) zu verwenden, vereinfacht den Einstieg in solche Low-Code-Plattformen. Eigene Server und Installationen sind nicht erforderlich.

Aus Sicht der Anwendungsentwickler haben sich die Elemente einer Anwendung und der Prozess der Entwicklung seit den 90er-Jahren bis heute konzeptionell nicht verändert (siehe folgenden Kasten zur Struktur einer Anwendung und des Entwicklungsprozesses).

Mehr Infos

Präsentationsschicht:

• <Desktop-, Web- und Mobilen-Benutzeroberfläche>: Visuelle Editoren für Benutzeroberfläche
• <Präsentationslogik>: Textueller Code
  

Geschäftslogikschicht:

• <Geschäftsprozesse>: Visuelle Editoren für BPMN und/oder UML-Aktivitätsmodelle
• <Geschäftsprozesslogik>: Textueller Code
• <Geschäftsentitäten>: Visuelle Editoren für UML-Klassenmodelle
• <Geschäftsentitätenlogik>: Textueller Code

Datenschicht:

• <Datenbank>

Basis:

• <Security>
• <Benutzermanagement>
• <Authentifizierung: Login (Single Sign On)>
• <Autorisierung: Zugriffsmanagement>
• <Token-Generierung für API-Zugriffe>

Makro- und Mikro-Entwicklungsprozess:

• User Stories, Aufgaben-, Version-Tracking und Dokumentation
• Integrierte Entwicklungsumgebung
• Metriken-Plattform für den Code-Analyse
• Continuous Deployment für Entwicklungs-, Test- und Produktionsumgebung: Quellcode-Versionierungssystem, Build-Server, Artefakt-Management, Server- und Container-Management

Die aktuellen Low-Code-Plattformen bieten folgende Unterstützung bei der Anwendungsentwicklung:

1. Präsentationsschicht: Mit visuellen Editoren werden die UI-Elemente einfach zusammengeklickt und wunschgemäß arrangiert. Eine Abstimmung mit dem Fachbereich anhand der "echten" Maske ist jederzeit möglich.
2. Geschäftslogikschicht: Mit visuellen Editoren für BPMN und UML lassen sich Prozesse und Geschäftsentitäten entwerfen. Diese Editoren können die detaillierte Logik und einzelne Prozessschritte vergleichbar mit Flowcharts umsetzen.
3. Datenschicht: Entweder werden die SQL-Befehle aus den Geschäftsentitäten komplett generiert oder die Datenbankstruktur wird visuell mit einem ERM-Editor (Entity Relationship Model) erstellt.
4. Basisdienste wie Authentifizierung und Autorisierung werden meistens innerhalb einer Menüstruktur angeboten.

In der Theorie sehr sinnvoll, stellen sich in der Praxis jedoch schnell Fragen: So ist es relativ einfach, Elemente übersichtlich zu arrangieren. Wie aber sollen sich diese bei einer Veränderung der Auflösung oder gar einem anderen Anzeigegerät verhalten? So muss es möglich sein, entweder das Verhalten oder mehrere Maskenvarianten für verschiedene Auflösungen und Geräte zu hinterlegen.

Auch bei der Modellierung der Geschäftsprozesse stellen sich schnell einige Fragen. So ist es allein aus Verständnis- und Dokumentationszwecken sicherlich sinnvoll, die Prozesse im Großen abzubilden. Ob dagegen eine schnell zu programmierende if-then-else-Anweisung aufwendig in einem Modell beschrieben werden muss, ist fraglich. Ebenso sind Generatoren beim Erstellen der Datenbankobjekte und -zugriffsschichten beschränkt, zudem sollte auch der Umgang mit bestehenden Strukturen möglich sein.

In der Theorie sollte jedes Unternehmen klare Vorgaben bezüglich des Makro- und Mikro-Entwicklungsprozesses haben und die nötige Infrastruktur idealerweise per Knopfdruck, zumindest aber per Checkliste erzeugen können. In der Praxis zeigt sich jedoch, dass das Rad – oder Teile von selbigem – jedes Mal neu erfunden wird. Macht sich das zwei Tage dauernde Onboarding neuer Entwickler bei einer Projektlaufzeit von sechs Monaten und mehr kaum bemerkbar, sieht die Rechnung bei häufig wechselnden Teams und kurzen Projektlaufzeiten ganz anders aus. Der Vorteil, die gesamte Umgebung von einer Low-Code-Plattform zur Verfügung gestellt zu bekommen, ist daher nicht zu unterschätzen. Dies ist gegebenenfalls mit weniger Flexibilität zu bezahlen.

Tabelle 1 stellt einige Low-Code-Plattformen mit ausgewählten Eigenschaften dar. Vier Eigenschaften wurden hierbei untersucht:

• Besitzt die Plattform visuelle Editoren und lassen sich aus Modellen Code transparent generieren?
• Umfasst die Plattform den kompletten Makro- und Mikro-Entwicklungsprozess?
• Lässt sich das Ergebnis exportieren und in die andere Plattform importieren beziehungsweise einfach in einer Entwicklungsumgebung öffnen?
• Welche Programmiersprachen werden für die detaillierte Anpassung unterstützt?

Produkt	Beschreibung	Visuelle Editoren und modellgetrieben	Kompletter Entwicklungsprozess	Export-Möglichkeit und Plattformunabhängigkeit	Programmiersprache
Zoho Creator	Low-Code-Plattform der bekannten CRM-Plattform. Große Auswahl an Tools wie: – Workflow-Unterstützung mit Zoho Flow – Bugtracker mit Zoho Bugtracker Diese Plattform kommt fast ohne Programmieren aus. Die Programmiersprache Deluge ist eine leicht zu lernende visuelle Programmiersprache.	Ja	Ja	Nein	Deluge
Google App Maker	Low-Code-Plattform von Google, derzeit nur für G-Business-Kunden vorhanden. Für komplexe Logik werden Programmierkenntnisse in JavaScript benötigt. Einfache Anwendungen mit Google-Produkt-Integrationen sind sehr einfach und elegant umgesetzt.	Ja	Nein	Nein	JavaScript
Microsoft PowerApps	Diese Plattform bietet drei unterschiedliche Ansätze an: – Canvas App: Mit Drag & Drop kann eine generelle App erstellt werden. – Modellgesteuerte App: Auf Basis von Prozessen und Daten wird eine App entwickelt. Hierbei spielt das Layouting einer App keine Rolle, da diese fest verankert ist.	Ja	Nein	Nein	Keine Programmiersprache für die Erweiterung
Outsystems	Marktführer bei Low-Code nach Forrester und Gartner. Umfangreiche Plattform, auch in der Cloud. Programmierkenntnisse erforderlich.	Ja	Nein	Ja, mithilfe des Supports	C#, Java
Mendix	Ebenso Marktführer bei Low-Code nach Forrester und Gartner. Mendix bietet komplette Makro- und Mikroentwicklungsprozess aus einer Hand an. Die Plattform nutzt gängige offene Standards wie BPMN, UML, OData, SAML2. Programmierkenntnisse erforderlich.	Ja	Ja	Ja	Java, JavaScript, Scala

Low-Code als Lösung aller Softwareentwicklungsprobleme?

Ansätze der Low-Code-Programmierung sind bereits Jahrzehnte alt und haben die Zielsetzung einer vereinfachten Oberflächenentwicklung (à la RAD) beziehungsweise der ganzheitlichen Softwarearchitektur (à la MDA). Da mit dem technischen Fortschritt die Anforderungen an die Software deutlich gestiegen sind, hat sich jedoch an den Problemstellungen bei diesen beiden Aspekten grundsätzlich wenig verändert. Lässt sich durch Visualisierung vieles vereinfachen, gibt es weiterhin komplexe Sachverhalte, die zu kodieren sind.

An dieser Stelle sei auf das meistens geltende Paretoprinzip in der Softwareentwicklung hingewiesen: Low-Code-Plattformen erreichen 80 Prozent der Ergebnisse eines Softwareprojekts, für die verbleibenden 20 Prozent sind aber leider 80 Prozent des Aufwands zu leisten. Die zeitintensiven komplexesten Teile einer Software lassen sich auf absehbare Zeit nicht generieren.

Einen großen Vorteil können Low-Code-Plattformen dank der heutigen Möglichkeiten der Application Platform as a Service (aPaaS) bieten. Der Aufbau einer kompletten Entwicklungsumgebung ist somit deutlich vereinfacht. Allerdings gibt es in diesem Bereich Tools wie Red Hats OpenShift und in Verbindung mit Docker-Containern Open-Source-Produkte wie Confluence, JIRA, Jenkins, SonarCube und Nexus, die teilweise deutlich vielseitiger sind. Die Investition für den Aufbau der Entwicklungsautobahn auf Basis von Open-Source-Produkten muss vorher getätigt werden, für eine langfristige digitale Strategie ist diese jedoch sinnvoll, da Know-how und Personal aufgebaut werden können. Herstellerunabhängigkeit lässt sich mit diesem Ansatz ebenfalls erreichen.

Insgesamt ist somit eine detaillierte Kosten-Nutzen-Betrachtung nötig, sofern der Einsatz einer Low-Code-Plattform in Erwägung gezogen wird. Dabei sind auch "weiche" Faktoren in Betracht zu ziehen. So stoßen Low-Code-Plattformen häufig auf Ablehnung, was gegebenenfalls auch im eigenen Entwicklerteam für Unruhe sorgen kann.

Dr. Lofi Dewanto
arbeitet als Teamleiter der Softwareentwicklung beim Umweltdienstleister InterserohDienstleistungs GmbH in Köln. Er engagiert sich insbesondere für "javanische" Open-Source-Software sowie MDA.

Manuel Klein
arbeitet als Fachbereichsleiter Enterprise Java Development bei der MT AG in Ratingen. Neben der Programmierung mit Java EE beschäftigt er sich gemeinsam mit seinem Team mit den aktuellen JavaScript-Frameworks sowie hybriden Apps. (ane)