Was genau bedeutet "Low Code"?

Wikipedia definiert "Low Code" bzw. "Low-Code-Plattform" als

Der Begriff Low-Code-Plattform (auch Low-Code-Entwicklungsplattform) bezeichnet eine Entwicklungsumgebung für Software, die die Entwicklung mit visuellen Applikationsdesign-Werkzeugen und anderen grafischen Modellierungsverfahren ermöglicht, anstatt klassische textbasierte Programmiersprachen zu verwenden. Dadurch soll die Entwicklungs- und Bereitstellungszeit für Software verringert werden. Low-Code-Plattformen sollen außerdem die Kosten für Projektplanung, Mitarbeitertraining und die eigentliche Entwicklung senken.

Dem stimme ich generell zu und nehme für mich daraus die folgenden Stichworte mit:

Grafische Modellierung statt textbasierter Programmiersprachen
Minimierung von Entwicklungszeit
Minimierung von Bereitstellungszeit

Anhand dieser Stichworte versuche ich im Folgenden in Applikationen in 4 generelle "Low Code" Kategorien einzuteilen.

Ich denke, dass das wichtig ist, da viele Leute teilweise nur von einer der Kategorien sprechen, wenn sie "Low Code" sagen. Falls in dieser Kategorie dann "Low Code" nur oberflächlich eingesetzt wird, kann das bei manchen ein verzerrtes Bild von der "Low Code" Idee hinterlassen.

1) Grafische Entwicklertools

Das sind häufig Frameworks, die ich in mein eigenes Projekt integrieren kann und mit dem ich dann grafisch Workflows in meiner Applikation modellieren kann. Der Rest meiner Applikation ist aber klassisch entwickelt und wird damit auch klassisch bereitgestellt. Das bedeutet, dass der Workflow zwar von mir als Entwickler mit Low-Code Mitteln erstellt, er danach aber gebündelt zusammen mit Code Änderungen in einem klassischen Deployment verteilt wird. Die Bereitstellungszeit zwischen zwei Deployments ändert sich hier nicht (Abgesehen von einer vielleicht kleineren Entwicklungszeit).

Die beiden Vorteile von diesem Vorgehen sind klar. Das Workflow-Framework nimmt mir als Entwickler in dem Workflow-Umfeld viele wiederkehrende Schritte ab, die ich einfach grafisch modellieren kann. Damit spare ich Zeit. Der Workflow ist aber auch gleichzeitig übersichtlicher und ich kann mir mit meinem Kunden zusammen den Workflow grafisch ansehen und schnell ändern.

2) Grafisch konfigurierbare Systeme

Auf der anderen Seite gibt es viele Applikationen, die ich in einem festgelegten Rahmen fast von Grund auf neu konfigurieren kann. Ein gutes Beispiel dafür aus dem Microsoft Umfeld ist SharePoint. Ich kann leicht über die Oberfläche meine eigenen Listen, Datenstrukturen und Ansichten auf diesen konfigurieren. Es gibt teilweise sogar Automatismen, mit denen ich bestimmte Prozesse und Freigaben zwischen den Elementen definieren kann. Neben SharePoint sprießen aber auch schon seit ein paar Jahren mehrere andere Lösungen dieser Art aus dem Boden. Häufig stehen hier Projektmanagement- und Abrechnungsprozesse im Vordergrund.

Ich als Entwickler installiere hier nicht die Plattform und entwickele darauf meine Applikation, sondern benutze eine schon bestehende Plattform, die ich dann so anpasse, wie mein Anwendungsfall es verlangt. Ich mir daher viel Zeit und Aufwand, den ich vorher in Dinge wie Datenspeicherung, Berechtigungssysteme oder Oberflächengestaltung hätte stecken müssen.

Ein Nachteil bei diesen Systemen ist häufig die Transportierbarkeit. Ich kann zwar mir zwar "eben mal kurz" eine Applikation "zusammenklicken" aber was passiert, wenn die Applikation schon genutzt wird? Muss ich dann Anpassungen direkt im Produktivsystem machen oder kann ich ein Testsystem erstellen, dort zuerst Änderungen testen und dann gezielt diese Änderungen deployen? Kann ich meine Anpassungen überhaupt automatisch in eine andere Applikation kopieren?

Bei vielen dieser Systeme gibt es zu diesen Fragen keine Antworten. Häufig stand bei der Entwicklung und dem Design dieser Plattformen nämlich etwas anderes im Vordergrund und die Idee von Konfigurierbarkeit und Low-Code war eher ein Nachgedanke.

Diese Art von Plattformen ist auch nichts neues. SharePoint gibt es schon lange und es entstehen im Internet immer mehr Dienste dieser Art. Wenn man die Definition hier etwas weiter fassen möchte, dann kann hierzu durchaus auch durchaus Atlassians Jira und andere zählen.

3) Automatisierungslösungen

Dann gibt es noch Automatisierungslösungen. Diese gibt es zwar schon lange, aber mit dem Aufkommen der Heimautomatisierung ist ihre Anzahl nochmal rasant gestiegen. Hierbei handelt es sich um einfache Logik-Prozesse, die von einem externen System ausgelöst werden und abhängig von definierten Bedingungen in einem anderen System Aktionen auslösen. Ein einfaches Beispiel aus dem Consumer Bereich ist hier IFTT (If-This-Then-That). Ich als Consumer kann hier dem Service meine digitalen Dienste freischalten und diese kann dann für mich dort Aktionen ausführen. Etwa könnte ich mir bei Eingang eines neuen Kalendereintrages automatisch eine Chat-Nachricht schreiben lassen oder ähnliches.

Im Regelfall können diese Plattformen von Haus aus schon mit vielen anderen Systemen Kontakt aufnehmen. Sie geben mir eine einfache grafische Möglichkeit, um Automatisierungen und Prozesse zu erstellen.

Das Problem ist hier aber wie bei den grafisch konfigurierbare Systemen aus dem vorherigen Abschnitt die Transportierbarkeit. Selbst wenn ich auf diesen Plattformen meinen Workflow exportieren und in eine andere Instanz einspielen kann (was nicht immer möglich ist), dann habe ich als Entwickler immer noch das Problem, dass ich Änderungen an den anderen Systemen hiermit nicht transportieren kann.

Wenn ich also eine Änderung an einer "Datenbank" irgendwo habe und zusätzlich eine Änderung an diesem Workflow, dann muss ich als Entwickler beides einzeln im Rahmen eines Changes auf die entsprechenden Produktivsysteme einspielen. Das kann zu mehreren möglichen Fehlerquellen führen und macht eine Entwicklung von komplexen Applikationen hier schwierig.

Bei diesen Lösungen steht die einfache und schnelle Automatisierung von Teil-Prozessen im Vordergrund, nicht die ganzheitliche Entwicklung von Applikationen.

Beispiele für solche Automatisierungsplattformen sind wie schon oben erwähnt IFTT, aber auch Nintex Workflow. Wenn wir die Definition hier etwas ausweiten, dann fallen auch diverse "ETL" Tools in diesem Bereich

4) Komplette Low Code Plattformen

Mit der bisherigen Vorarbeit kommen wir nun zu kompletten Low Code Plattformen. Man kann Sie als Weiterentwicklung der grafisch konfigurierbaren Systeme sehen, die auf der einen Seite schon von Grund auf dafür gedacht und konzipiert sind, um komplette Anwendungsfälle schnell per Low Code grafisch umzusetzen. Auf der anderen Seite sind sie aber auch so erstellt, dass auch das Deployment und das Verteilen der erstellten Applikationen einfach, schnell und zuverlässlich durchgeführt werden kann. Und das im Idealfall auch noch grafisch.

Diese Plattformen bestehen im Regelfall aus wenigstens vier ineinandergreifenden Komponenten:

Einer Komponente zur Datenspeicherung, in der ich einfach Datenstrukturen anlegen kann
Einer Komponente zur Erstellung von Prozessen, mit der ich einfach auf den Daten Prozesse definieren kann
Einer Komponente zur Erstellung von Oberflächen, die es mir möglich machen, mittels Formularen die Daten zu bearbeiten.
Ein Mechanismus, der die Konfiguration der oberen drei Mechanismen portabel in eine Lösung exportieren kann, die ich als Entwickler ohne viel Aufwand einfach auf einem anderen System einspielen kann. Im Idealfall lässt sich dieser Mechanismus sogar noch automatisieren.

Der Unterschied zu den anderen Kategorien besteht hier darin, dass die Idee der schnellen grafische Entwicklung von Applikationen bei der Erstellung der Plattform im Vordergrund gestanden hat, und daher alle Mechanismen ineinander greifen. Damit können mit so einer Plattform komplizierte Applikationen entwickelt werden, die aber auch professionell betrieben und weiterentwickelt werden können.

Als Beispiele für solche Plattformen kann man "Lotus Notes" heranziehen und auch die PowerPlattform von Microsoft. Letztere besteht aus verschiedenen Komponenten, wie etwa