Für wen ist Low Code was? Low Code in der Automatisierung

Ein Gastbeitrag von Jakob Freund*

Anbieter zum Thema

Was ist Low Code eigentlich genau? Ursprünglich stand der Begriff dafür, Software-Anwendungen mit geringen bis gar keinen Programmierkenntnissen zu erstellen, doch heute sind damit unter anderem Entwickler-Shortcuts gemeint.

Entwickler und Anwender nutzen den Begriff „Low Code“ für die Software-Erstellung ohne jegliche Entwicklungserfahrung. Allerdings ist das nur eine Intepretation, so der Autor Jakob Freund.
Entwickler und Anwender nutzen den Begriff „Low Code“ für die Software-Erstellung ohne jegliche Entwicklungserfahrung. Allerdings ist das nur eine Intepretation, so der Autor Jakob Freund.
(Bild: gemeinfrei: Bernd Hildebrandt / Pixabay )

Tatsächlich können einige Low-Code-Ansätze zur Automatisierung bei Entwicklern aber mehr Kopfzerbrechen verursachen als Systeme, die von Grund auf neu erstellt wurden. Meistens können Low-Code- und Pro-Code-Ansätze gut nebeneinander bestehen und tun dies auch. Die Developer Experience ist bei den meisten Automatisierungs-Deployments weitaus nuancierter, deshalb soll die Thematik im folgenden Artikel genauer betrachtet werden.

Die Geschichte von Low Code

Zunächst ist es wichtig, zu verstehen, wie der Begriff „Low Code“ entstanden ist. Er basiert auf der wachsenden Popularität von Low-Code-Plattformen, die aus den Bereichen Rapid Application Development (RAD), Mobile App Development und Cloud App Development (PaaS oder aPaaS) hervorgegangen sind.

Der Begriff wurde vor etwa sechs Jahren erstmals von den Forrester-Analysten John Rymer und Clay Richardson erwähnt. Sie versuchten, Angebote von Unternehmen wie Mendix, Outsystems oder Salesforce zu kategorisieren.

Je nachdem, wen Sie fragen, unterscheiden sich die Definitionen von Low Code heute ziemlich stark. Zunächst war eine Plattform zur Entwicklung von Software-Anwendungen durch Anwender mit minimalem Fachwissen gemeint. Später jedoch wurde Low Code nicht nur von Anwendern ohne jegliche Entwicklungserfahrung immer stärker genutzt, sondern auch von erfahrenen Entwicklern. Die Beziehung zwischen Developer Personas und Low Code ist daher eine komplexe.

Was Low Code für Entwickler bedeutet

Für manche Entwickler ist Low Code ein Synonym für „entwicklerunfreundlich.“ Denn bei der Erstellung einer deklarativen Plattform geht die Transparenz verloren, die eigentlich mit dem Schreiben des eigenen Codes einhergeht.

Das stellt Entwickler vor die schwierige Aufgabe, Probleme in Anwendungen zu beheben, die sie nicht von Grund auf selbst geschrieben haben. Dadurch wird auch die Aktualisierung dieser Anwendungen schwierig, insbesondere wenn sie in Legacy-Systeme oder komplexe Umgebungen eingebunden sind.

Low Code in der Automatisierung

In der Automatisierung ist Robotic Process Automation (RPA) einer der am schnellsten wachsenden Anwendungsfälle für Low Code. In einigen Fällen kann ein leichtgewichtiger RPA-Bot verwendet werden, um einen einfachen Prozess zu automatisieren, zum Beispiel für die Ausführung einer Bonitätsprüfung im Namen eines neuen Benutzers oder Annahme/Ablehnung einer Anfrage basierend auf einem bestimmten Schwellenwert.

Da ereignisgesteuerte Prozesse jedoch komplexer werden, können RPA-Deployments zu unnötigen Engpässen werden oder aufgrund von Legacy-Anwendungen oder -Systemen sogar ganz ausfallen. Hier kommt der Entwickler ins Spiel, der die Low Code-Implementierung auflösen und durch echte Programmierung ersetzen muss.

Außerdem ist es wichtig, dass Business Stakeholder von Anfang an in das Prozessdesign einbezogen werden, um sicherzustellen, dass das Endprodukt dessen Anforderungen an die Automatisierung erfüllt. Es gibt Standards wie BPMN (Business Process Model and Notation), die Stakeholder einbeziehen, da komplexe Prozesse in leicht verständlichen Ablaufdiagrammen dargestellt werden. Dieser Teil wird als „Low Code“ oder „No Code“ bezeichnet.

Der Schlüssel für erfolgreiche Automatisierungsprojekte

Daher müssen in Entwickler-Tools einerseits Akronyme wie BPMN zur Definition eines Orchestrierungs-Workflows und andererseits Funktionen eingesetzt werden, mit denen bei Bedarf individuelle Änderungen am Code selbst vorgenommen werden können. Entwicklerfreundlichkeit sollte bei einer offenen und flexiblen Architektur ansetzen.

Automatisierungsprojekte sind jedoch selten einfach und sie sind am effektivsten, wenn sie schrittweise umgesetzt werden. Sie bestehen oft aus einer Patchwork-Lösung, die sowohl moderne, auf Microservices basierende Anwendungen (oder selbst entwickelte/eingekaufte), die gut mit APIs funktionieren, als auch ältere Anwendungen umfasst, die das nicht tun. Die Flexibilität, Software in bestehende Technik-Stacks und Entwicklungsumgebungen zu integrieren, ist der Schlüssel zum Erfolg eines Automatisierungsprojekts.

Es mag zwar eine gute Idee sein, alle Legacy-Technologien komplett aus Ihrem Stack zu entfernen und zu ersetzen und Microservices-basierte Anwendungen von Grund auf neu zu schreiben, aber für größere Unternehmen ist ein schrittweiser Ansatz weit weniger disruptiv. Eine Orchestrierungslösung kann dabei helfen, mit vorhandenen Technologien zu arbeiten und gleichzeitig neue zu integrieren.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Cloud Computing

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Deshalb: Shortcuts

Zusammenfassend lässt sich sagen, dass Entwickler bei Automatisierungs-Deployments immer noch Shortcuts benötigen, jedoch nur, wenn sie auch die Möglichkeit erhalten, die Komplexität der zugrunde liegenden Systeme und des Codes genauer unter die Lupe zu nehmen. Für den Fall, dass etwas schief geht oder angepasst werden muss, kann eine quelloffene Architektur die Produktivität der Entwickler steigern - unter Umständen die Passende Option zu einer Black-Box-Plattform, deren Nutzung eigentlich einfach sein sollte. In der Designphase sollten Entwickler in der Lage sein, Stakeholdern zu helfen, die grundlegende Architektur eines Prozesses mit minimalem Aufwand zu visualisieren und zu ändern.

Die Entscheidung für Low Code oder Pro Code erfolgt nicht immer nach dem Prinzip „Entweder-Oder“. Ihre Tools sollten Entwicklern bei der Navigation durch eine komplexe Infrastruktur helfen – selbst wenn das bedeutet, dass individuelle Änderungen am Code vorgenommen werden.

Jakob Freund, CEO von Camunda.
Jakob Freund, CEO von Camunda.
(Bild: Camunda )

* Der Autor Jakob Freund ist als CEO von Camunda, einem Anbieter von Software zur Prozessorchestrierung, iverantwortlich für die Vision und Strategie des Unternehmens. Neben einem MSc in Informatik ist er Co-Autor des Buches „Real-Life BPMN“ und ein gefragter Referent auf Technologie- und Branchenveranstaltungen.

(ID:48397443)