Warum Enterprise Low Code nicht das Ende des Programmierers bedeutet. Ein Blick aus technischer Sicht

Low Code: Die Zukunft der Softwareentwicklung? Ein Blick hinter die Kulissen zeigt, warum Enterprise Low Code nicht das Ende des Programmierers bedeutet. Erfahren Sie, wie Fachexperten und Entwickler zusammenarbeiten, um maßgeschneiderte Lösungen zu entwickeln und welche Vorteile die Trennung von Fachlichkeit und Technologie bietet. Wir tauchen in die Welt der mgm A12-Plattform ein.

Das Low-Code-Prinzip ist die treibende Kraft hinter der kooperativen Arbeit von Modellierern und Entwicklern. Es besagt, dass Fachexperten, die über ein tiefes Verständnis ihres spezifischen Fachgebiets verfügen, die fachlichen Anforderungen einer Anwendung in Modellen definieren. Diese Experten sind mit der so genannten Fachlichkeit, wie Gesetzestexten oder branchenspezifischen Fachdokumenten, vertraut und können diese präzise definieren. Sie erstellen Modelle, die die Fachlichkeit abbilden. Die erstellten Modelle umfassen verschiedene Typen wie Daten- und Oberflächenmodelle, die die Fachlichkeit widerspiegeln und in der Laufzeitumgebung der Anwendung verwendet werden. Die Modelle können durch Individualentwicklung ergänzt werden. Zusammen wird im Anschluss eine Anwendung bereitgestellt (siehe Abbildung 1).

Abbildung 1: Das Low-Code-Prinzip ermöglicht es Fachexperten, die fachlichen Anforderungen einer Anwendung ohne tiefere Programmierkenntnisse durch die Erstellung von Modellen zu definieren (© mgm technology partners)

Vorteile der Trennung von Fachlichkeit und Technik

Die Trennung von Fachlichkeit und Technologie ermöglicht, wiederkehrende Funktionen wie Formulare über Modelle abzudecken. Lässt sich die geforderte Fachlichkeit nicht modellieren, so kann die Plattform auch erweitert werden. Bei der Erweiterung der Plattform durch Individualentwicklung, muss die Softwareentwicklung nicht die gesamte Fachlichkeit verstehen – ein Vorteil insbesondere bei komplexen Unternehmensanwendungen.

Viele Eigenschaften der Anwendung werden sowieso von den Fachanwendern definiert: Felder mit Datentyp, Validierung- bzw. Formatregeln, Beschriftung und Abhängigkeiten zwischen Feldern.

In solchen Szenarien braucht es häufig Individualentwicklungen, um spezielle Funktionen oder Geschäftsprozesse umzusetzen, die in vorhandenen Modellen nicht abgedeckt werden. Die fertige Anwendung kombiniert Modelle und Individualentwicklung und wird als Gesamtlösung ausgeliefert. Genau diese Szenarien unterstützt die mgm A12 Enterprise Low-Code Plattform.

Modellierung sollte auch für Fachkräfte ohne technischen Hintergrund zugänglich bleiben. Das bedeutet: Für das Erstellen von Modellen braucht es keine Programmierkenntnisse oder Kenntnisse von Programmiersprachen. Wichtig sind vielmehr ein gewisses technisches Verständnis sowie die Fähigkeit, Geschäftsregeln präzise zu formulieren. So können Fachbereiche eigenständig Modelle pflegen und erweitern – unabhängig von der Softwareentwicklung.

Ein weiterer Vorteil beim Einsatz von Modellen ist die Technologieunabhängigkeit. Komponenten, die die Modelle ausführen, können in einer anderen (neueren) Technologie umgesetzt werden. Die Modelle sind dann weiterhin nutzbar.

Ziel bei A12: Low Code mit so viel Individualentwicklung wie nötig

Das Ziel der A12-Plattform besteht darin, Anwendungen vollständig über Modellierung umzusetzen. Viele Geschäftsprozesse – etwa das Lesen, Schreiben und Aktualisieren von Daten – lassen sich so abbilden. Ein typisches Beispiel wäre eine Anwendung zur Abwicklung von Reisekosten: Mitarbeitende erfassen ihre Ausgaben, die anschließend durch das Backoffice geprüft und an die Buchhaltung weitergeleitet werden. Solche Anwendungen entstehen in einer Low Code Plattform rein modellbasiert – ohne individuell geschriebenen Code. Damit entspricht die Umsetzung dem Prinzip von No-Code.

Abhängigkeiten zwischen Modellen oder komplizierten Regeln werden bereits im fachlichen Teil definiert und nicht erst in der Entwicklung. Das vereinfacht den Prozess von Anfang an, reduziert die Komplexität und minimiert das Risiko, dass Softwareentwickler komplexe Regeln über viele „if“ Statements abbilden müssen. In der Entwicklung sind Felder oft in mehreren Ebenen definiert: Oberfläche, Oberflächenobjekt, Transferobjekt, Backendobjekt und Persistenz. Durch die Modellierung muss das Feld nur einmal definiert werden. Das erleichtert Änderungen an den Datenstrukturen enorm.

Das Prinzip Low Code: wie alles begann

Um die Entwicklung von Low Code besser zu verstehen, lohnt ein Blick auf den Ursprung. Früher sprach man von 4GL-Anwendungen, zu denen Werkzeuge wie Power Builder oder VBA gehörten.

Programmierer erstellten dabei Anwendungen meist mit einem Designer und definierten Ereignisse, um Code einzubinden – etwa für einen OK-Button (siehe Abbildung 2). Diese Herangehensweise hat jedoch erhebliche Nachteile, insbesondere die mangelnde Strukturierungsmöglichkeit des Codes für den Entwickler.

Dies führt oft dazu, dass in der Anwendung, insbesondere bei wichtigen Funktionen wie dem OK-Button, über die Zeit Tausende von Codezeilen entstehen. Änderungen erfordern häufig Duplikationen, was zu unübersichtlichen und schwer wartbaren Anwendungen führt.

Abbildung 2: So sah Low Code früher aus. (© Copyright mgm technology partners)

A12 verfolgt das Ziel, mit einem Modellierungsansatz den Entwicklungsprozess grundlegend anders zu gestalten. Der Schlüssel liegt darin, dass kein Code generiert wird, sondern Modelle – mit wenigen Ausnahmen – direkt zur Laufzeit interpretiert werden.

Individuelle Entwicklungen erfolgen ergänzend und bleiben als eigenständige Codestruktur klar von der Modellierung getrennt. Für Softwareentwickler, Modellierer und Citizen Developer kombiniert A12 damit No-Code- und Low-Code-Ansätze mit einer sauberen Erweiterungsmöglichkeit über individuellen Code.

Die Architektur der Low-Code-Plattform A12

A12 baut auf einem einheitlichen Technologie-Stack auf (siehe Abbildung 3). Im Frontend kommen TypeScript mit React und Redux als Haupttechnologien zum Einsatz, während das Backend auf Java mit Spring Boot setzt.

Im No-Code-Teil der Plattform übernimmt der Client eine zentrale Rolle. Er bildet die Laufzeitumgebung, stellt Funktionen wie Navigation, Menüführung und ein grundlegendes Rollenrechte-System bereit und integriert typische Web-Elemente wie Header, Footer, Notification-Bar sowie Statusinformationen.

Der Client integriert hochwertige UI-Komponenten, die als „Engines“ bezeichnet werden. Diese interpretieren Modelle zur Laufzeit und decken Funktionen wie Listendarstellungen über die Overview-Engine oder Formulare über die Form-Engine ab.

Die Daten werden in JSON-Dokumente im Server generisch gespeichert. Es können einzelne Datensätze (Dokumente) abgefragt oder über eine API nach Dokumenten gesucht werden. Der Client lässt sich sowohl für modellgetriebene Oberflächen als auch für eigene Screens verwenden. Eigene Screens basieren wie die Engines auf den A12 Widgets. Sie können aber auch Engines enthalten, da das A12 Ökosystem modular aufgebaut ist. Zusätzlich können neben dem Standard Persistenz-Service eigene Backend-Services integriert werden (siehe Abbildung 3).

Sowohl der Low-Code- als auch der No-Code-Ansatz arbeiten im selben Client- Framework im Browser und nutzen die generische Persistierung der Dokumente im Backend.

Abbildung 3: Die Low-Code-Plattform A12 basiert auf einem einheitlichen Technologie-Stack. (© mgm technologie parterns)

Low Code – die Anforderungen

Wie bereits beschrieben, verfolgt A12 das Ziel, Anwendungen vollständig durch Low-Code-Modellierung umzusetzen. Dabei entfällt die Notwendigkeit, eigenen Code zu schreiben oder Build- und Deployment-Skripte zu pflegen. Konfiguration und Entwicklung erfolgen direkt über Modellierung, wobei das einfache Speichern der Modelle über entsprechende Schaltflächen genügt. Änderungen lassen sich per Preview-Funktion überprüfen, bevor sie auf einem Server bereitgestellt werden.

Low Code und Individualentwicklung harmonieren perfekt im A12 Framework

Low-Code-Plattformen müssen weitaus mehr bieten als einfache Benutzeroberflächen. Es genügt nicht, Funktionen wie das Einreichen von Reisekostenanträgen bereitzustellen. Entscheidend ist, dass die Plattform in der Lage ist, die dahinterliegenden Geschäftsprozesse vollständig und effizient abzubilden – von der Antragstellung bis zur Bearbeitung und Abrechnung.

A12 verfolgt das Ziel, komplexe Geschäftsprozesse in verschiedenen Branchen wie Versicherungen oder dem öffentlichen Sektor abzubilden. Dabei müssen sowohl verschiedene Benutzergruppen als auch einfache Rechenregeln berücksichtigt werden.

Um dies zu ermöglichen, müssen die Daten von der Benutzeroberfläche entkoppelt werden. Zusätzliche Informationen, die über den reinen Antragsprozess hinausgehen – wie Genehmigungsstatus oder relevante Buchhaltungsinformationen – müssen ebenfalls gespeichert werden. Dies ist einfach abzubilden, in dem diese Daten ebenfalls in dem Geschäftsobjekt „Antrag“ gespeichert werden, für den Antragsteller allerdings unsichtbar sind. Durch diese Strukturierung ist es möglich, verschiedene Ansichten der Daten zu haben – beispielsweise für die Eingabe als Antragsteller oder für die Bearbeitung der Reisekosten in der Sachbearbeitung oder Buchhaltung.

Low Code ergänzt Individualentwicklung – nicht umgekehrt

Ein zentrales Prinzip von A12 lautet: Low-Code-Entwicklung ergänzt die Individualentwicklung und ersetzt sie nicht. Unternehmen erwarten maßgeschneiderte Lösungen, die sich exakt an ihre spezifischen Prozesse anpassen lassen. Daher muss die Plattform so offen gestaltet sein, dass individuelle Erweiterungen jederzeit möglich bleiben.

Gleichzeitig ist es wichtig, dass sich Entwickler in der Plattform zurechtfinden. Sie benötigen die Möglichkeit, den zugrundeliegenden Quellcode einzusehen, um die Funktionsweise der Anwendung zu verstehen und Anpassungen vorzunehmen. Nur so lassen sich individuelle Anforderungen effizient umsetzen und die Wartbarkeit von Anwendungen langfristig sichern. Die Integration von Low Code und Individualentwicklung eröffnet genau diesen Spielraum. Sie ermöglicht eine effiziente Umsetzung fachlicher Prozesse, ohne dabei die Flexibilität und Kontrolle der Individualentwicklung aufzugeben.

Damit wird deutlich: Low-Code-Plattformen dürfen sich nicht nur auf das Bereitstellen einfacher Masken beschränken. Sie müssen die Flexibilität und Leistungsfähigkeit besitzen, komplexe Geschäftsprozesse effektiv abzubilden und gleichzeitig Raum für individuelle Anforderungen zu schaffen. Die Individualentwicklung verwendet APIs um auf Funktionalität der Plattform zuzugreifen (siehe Abbildung 4).

Abbildung 4: Low Code und Individualentwicklung sind gleichberechtigt. (© mgm technology partners)

Client meets Framework: Einheitliches Design trifft Flexibilität

Entwickler fragen häufig, wie das Entwicklungsframework funktioniert. Der Client bildet dabei den zentralen Rahmen für beide Aspekte. Im Applikationsmodell werden Screens und der Screenflow definiert, entweder rein modellbasiert oder durch eigene Implementierungen. Eine wesentliche Voraussetzung für ein konsistentes Nutzererlebnis besteht darin, dass sowohl alle selbst implementierten Screens als auch vorgefertigte Engines auf derselben Widget-Bibliothek basieren. Das sichert ein einheitliches Erscheinungsbild über die gesamte Anwendung hinweg.

Engines werden als UI-Komponenten eingebunden und bleiben für Entwickler transparent. Durch die gemeinsame Widget-Basis lassen sich das Aussehen und Verhalten zentral steuern. Anpassungen wie Schriftarten, Schriftgrößen oder die Positionierung von Schaltflächenerfolgen über Konfigurationen und gelten für Engines und eigenentwickelten Screens gleichermaßen (siehe Abbildung 5).

Zusätzlich gibt es im Front- und Backend Extension-Points, um Komponenten zu erweitern. Dadurch ist es möglich, Funktionalitäten wie einen Barcode-Scanner in die Form-Engine einzubinden. Hier kann z. B. ein spezielles Artikelfeld mit der Barcode Scanner Funktion versehen und in die Form-Engine eingebunden werden.

Abbildung 5: Client meets Framework: Einheitliches Design und Flexibilität (© mgm technology partners)

A12-Modelle flexibel in Eigenentwicklungen nutzen – dank spezieller API

A12-Modelle lassen sich nicht nur während des Entwicklungsprozesses verwenden, sondern auch direkt in Eigenentwicklungen einbinden. Eine dafür bereitgestellte spezifische API ermöglicht es, Modelle zu laden und gezielt Modellinformationen abzufragen. Entwickler können zum Beispiel Annotationen einsetzen, also Key-Value-Paaren, um Felder im UI-Modell zu kennzeichnen. So lässt sich etwa festlegen, dass bestimmte Felder als Artikel-Feld fungieren und automatisch ein spezielles Widget angezeigt wird, das etwa mit einem Barcode-Scanner interagiert.

Auch Daten aus dem A12-Dokumentenmodell stehen in Eigenentwicklungen zur Verfügung. Entwickler können prüfen, ob ein Feld eine Währungsangabe oder Prozentwerte enthalten. Diese Informationen greifen sowohl das Frontend als auch das Backend ab und nutzen sie flexibel für individuelle Erweiterungen oder spezifische Geschäftslogiken. So fließen Modellinformationen nahtlos in eigenentwickelte Anwendungen ein.

Low Code: Was Entwickler oft kritisch sehen

Entwickler bringen bei Low-Code-Plattformen häufig typische Einwände vor:

1. Weniger Flexibilität: Viele Entwickler fürchten, Low Code beschränke sie zu stark und zwinge sie dazu nur Code-Fragmente zu schreiben, ähnlich wie früher bei Visual Basic.

–> Im A12 Framework fühlt sich die Client-Anwendung jedoch wie eine klassische React-Anwendung an – Entwickler arbeiten in einer vertrauten Umgebung.

2. Veralteter Technologie-Stack: Es besteht die Befürchtung, dass der Technologie-Stack der Low-Code-Plattform schnell veraltet sein könnte.

–> A12 setzt auf regelmäßig Updates von Bibliotheken, einschließlich Sicherheitsupdates und größeren Bibliotheks-Updates

3. Künstliche Trennung von Technik und Fachlichkeit: Es besteht die Sorge, dass Entwickler mit Low-Code-Plattformen weniger technisches Verständnis benötigen, was zu einer Trennung zwischen technischer und fachlicher Entwicklung führen könnte.

–> In A12 bleibt die Beteiligung technisch versierter Personen, die auch an der fachlichen Entwicklung beteiligt sind, wichtig. Gerade bei komplexen Anforderungen braucht es ihr Know-how, um optimale Lösungen zu finden, während einfache Anwendungsfälle durch reine Modellierung abgedeckt werden.

4. Weniger Arbeit für Entwickler: Ein oft gehörter Vorbehalt lautet, Low-Code-Plattformen nehme Entwicklern die Arbeit weg.

–> Die Realität sieht anders aus: Komplexe Aufgaben und individuelle Erweiterungen bleiben. Low-Code-Plattformen erleichtert die Umsetzung einfacher Use Cases, schafft aber Raum für Entwickler, sich auf anspruchsvollere Herausforderungen zu konzentrieren. Und der Fachbereich liefert meist reichlich neue Ideen.

Die Zukunft der Softwareentwicklung liegt in der Verbindung von Low Code und Individualentwicklung.

Low Code bedeutet nicht das Ende des Programmierers. Im Gegenteil: Low Code erweitert die Möglichkeiten für Entwickler und Fachexperten gleichermaßen.

Mit Low-Code-Modellen definieren Fachexperten mit tiefgreifendem Fachwissen Anforderungen präzise, ohne selbst zu programmieren. Entwickler greifen diese Modelle auf, ergänzen sie um individuelle Erweiterungen und bringen komplexe Funktionalitäten ins Spiel. So entstehen maßgeschneiderte Anwendungen, die genau zu den Abläufen und spezifischen Anforderungen eines Unternehmens passen.

Diese Trennung von Fachlichkeit und Technologie bringt klare Vorteile: Teams arbeiten effizienter, der Code bleibt besser strukturiert und Wartungsaufgaben lassen sich leichter erledigen. Modellierer und Entwickler können sich auf ihre Stärken konzentrieren, ohne sich gegenseitig auszubremsen. Mit jeder Erweiterung wächst zudem der Fundus an wiederverwendbaren Modellen und Bausteinen – innerhalb einer Anwendung, aber auch anwendungsübergreifend.

Das A12 Framework setzt genau hier an. Es verbindet modellgetriebene Entwicklung und Individualentwicklung in einem konsistenten Technologie-Stack. So lassen sich Low-Code- und No-Code-Ansätze flexibel mit Eigenentwicklungen kombinieren. Unternehmen gewinnen damit maximale Gestaltungsfreiheit – ohne Kompromisse bei Leistung oder Zukunftssicherheit.