Low Code im Selbstversuch - Wir haben es ausprobiert!

Wie soll man den Überblick behalten im rasant wachsenden Dschungel der Low Code Plattformen? Mit einem eintägigen Selbstversuch haben wir etwas Licht ins Dunkel gebracht und sind dabei zu einer Einschätzung gelangt, wann der Einsatz von Low Code sinnvoll ist.

Warum Low Code interessant ist

In den letzten Jahren sind am Markt zahlreiche Low Code Plattformen erschienen. Anders als klassische Softwareentwicklungswerkzeuge, ermöglichen sie es, Anwendungen mit wenig Programmcode zu erstellen. Dies wird erreicht mit grafischen Editoren, die es erlauben Formulare zu entwerfen, Prozessabläufe zu definieren oder auf einfache Art und Weise Entscheidungslogik festzulegen. Es gibt sogar Unterstützung für den Aufruf externer Web Services. Vor allem richtet sich Low Code an diejenigen, die bisher bloß als Anforderer an der Softwareentwicklung beteiligt waren. Sie können nun mit Hilfe der Low Code Plattformen eigenständig Anwendungen erstellen, als sogenannte “Citizen Developer”. Angesichts des Fachkräftemangels in der IT weckt das für manches Unternehmen Hoffnungen auf einen Weg aus dem Entwicklungsstillstand . Gleichzeitigen wächst häufig das IT-Know-How in den Fachabteilungen. Statt eine Schatten-IT mit Exceltabellen etc. zu schaffen, könnten sie aktiv die Anwendungslandschaft erweitern. Und warum der IT erst alles erklären, wenn man es gleich selbst bauen kann? In dieser schönen neuen Welt mit Citizen Developern ändern sich sicherlich auch die Zusammenarbeitsmodelle, wie etwa im Anforderungsprozess, im Fachtest und im Produktionssupport. Zum anderen kann Low Code auch interessant sein für “Pro Coder”, also Menschen, die bereits als Softwareentwickler:in tätig sind. Die Idee ist, dass sie so schneller ans Ziel kommen als mit komplett manuell geschriebenem Code.

Aber funktioniert das wirklich? Was können die heutigen Low Code Plattformen schon? Lassen sich damit tatsächlich ganze Anwendungen schaffen? Welche IT-Kenntnisse benötigt man? Welches Tool ist das Richtige? Dazu wollten wir uns gerne ein Bild machen und Erfahrungen sammeln.

Versuchsaufbau - Sechs Plattformen und eine Referenzaufgabe

Bei der viadee veranstalten wir einmal im Jahr den ShipIt Day, eine interne Veranstaltung mit vielen kleinen Miniprojekten, die alle eine Gemeinsamkeit haben: sie sollen abends fertig sein. Kurz: die perfekte Gelegenheit für unseren Feldversuch. Als gemischte Gruppe von 16 Personen haben wir uns eingefunden in unserem Projektraum im Schloss Krickenbeck im Nettetal. Gemischt deshalb, weil wir sehr unterschiedlichen Vorkenntnisse mitgebracht haben, sowohl was Programmierung betrifft, als auch, was Low Code angeht.

Die Auswahl der getesteten Tools beruhte einer Marktanalyse und aktuellen Kundenprojekten:

• Appian

• Comidor

• Pega

• Process Maker

• UIPath kombiniert mit camunda 8 (beides keine klassischen Low Code Tools, aber mit beiden zusammen war die Aufgabe lösbar)

Um eine Vergleichbarkeit herzustellen, wurde mit jeder Plattform derselbe Anwendungsfall probiert. Dabei ging es um die Beantragung einer Reiseversicherung. Uns war es wichtig, folgende Aspekte in der Aufgabenstellung unterzubringen, um die Stärken und Schwächen der höchst unterschiedlichen Tools sauber herauszuarbeiten:

• Prozessmodellierung - der Beantragungsprozess war vorgegeben als winziges BPMN-Modell mit zwei menschlichen Akteuren, der Kund:in und der Sachbearbeitung

• Datenerfassung - darin enthalten auch ein Fall geschachtelter Daten, nämlich die Liste der Reisenden

• Konsistenzprüfungen der Eingaben - darin enthalten Prüfungen, die sich auf mehrere Datenfelder im Zusammenhang beziehen

• Aufruf eines Externen Services - in unserem Fall zur Prüfung einer IBAN

• Entscheidungslogik - unter welchen Umständen wird dem Antrag stattgegeben

• Mailversand

Anwendungsfall für alle Low Code Plattformen im Vergleich

Während der Umsetzung haben wir unsere Eindrücke zu obigen Aspekten festgehalten, also ob die Aufgabe erfolgreich gelöst werden konnte. Darüber hinaus hatten wir ein Auge auf Usability, Zuverlässigkeit, Flexibilität, Kollaboration und Interoperabilität mit anderen Plattformen.

Im Zuge unseres Selbstversuchs haben wir insbesondere drei Erkenntnisse mitgenommen, welche wir im folgenden erläutern werden:

1. Low Code Plattformen sind nicht selbsterklärend

Obwohl Low Code Plattformen oft als einfach zu bedienen beworben werden, sind die Anwendungen ohne IT-Grundlagen und spezielle plattformbezogene Kenntnisse nicht selbsterklärend nutzbar. Auf den Plattformen werden unzählige IT Begriffe verwendet, mit denen man ohne Vorwissen und eine gewissen IT-Affinität wenig anfangen könnte. Was ist eine Prozessinstanz, was sind Datentypen wie funktionieren Bedingungen und Schleifen? Als IT Beratungsunternehmen verfügen wir über sehr gut ausgebildete und kompetente Mitarbeitende, die genau dieses Vorwissen mitbringen. Dennoch haben wir gemerkt, dass jede Plattform ihre ganz eigene Sprache und Konzepte hat, weshalb man ohne das Studium von Tutorials und Dokumentationen nicht weit gekommen wäre. Beispielsweise wird der Begriff “Business Rule” in mehreren Plattformen verwendet, aber meint nicht dasselbe. Wir sind in unseren Gruppen mit der Umsetzung der Referenzaufgabe sehr unterschiedlich weit gekommen. Dies mag zum einen an der individuellen Gruppenzusammensetzung liegen, wobei wir annehmen dass dies bei den vorhandenen Kompetenzen nicht der ausschlaggebende Faktor war, weshalb der Fortschritt wohl im Wesentlichen von der Usability, der vorhandenen Dokumentation und der Community der Low Code Plattform abhängt - insofern die jeweilige Plattform die geforderte Funktionalität überhaupt bietet.

2. Mindshift und Veränderung der Arbeitsweise erforderlich

Der Einsatz von Low Code Plattformen erfordert einen "Mindshift" oder eine Veränderung in der Denkweise und Arbeitsweise, insbesondere im Vergleich zu traditionellen Entwicklungsumgebungen. Viele der Teilnehmenden des Selbstversuchs sind “Pro Coder”, d.h. sie sind es gewohnt eine traditionelle Entwicklungsumgebung wie Eclipse oder IntelliJ und die damit einhergehenden Freiheiten zu verwenden. Hierzu zählen bspw. Versionsverwaltung über Git, Auto-Completion, Syntax-Highlighting und Debuggingunterstützung. Zudem werden benötigte Klassen und Funktionen für den spezifischen Anwendungsfall maßgeschneidert oder es wird sich einem Repository bedient. Das Feedback dieser Nutzergruppen zu den erprobten Tools fiel daher gemischt aus. Man fühlte sich wie in ein enges “Korsett” bzw. einen Entwicklungsrahmen gedrückt, dem man sich anpassen muss. Es fiel auf, dass jede der Low Code Plattformen sein ganz eigenes Entwicklungserlebnis mitbringt, welches abhängig von der Entwickler:innen-Gruppe ganz unterschiedlich bewertet wird. Abhängig vom Background der Zielgruppe sollte daher abgewogen werden, welcher Entwicklungsansatz (Low Code vs. Pro Code) der richtige ist.

3. Jeder kann alles, hat aber seine ganz individuellen Stärken und Schwächen

Viele der aktuellen Low Code Plattformen werden als universelle Lösungen für alle Arten von Einsatzzwecken beworben. Sie versprechen, die Entwicklung zu beschleunigen, die Komplexität zu reduzieren und die Zusammenarbeit zu verbessern, unabhängig von der Art des Systems, das entwickelt wird. Jedoch hat jede Plattform ihre ganz eigenen Stärken und Schwächen, die oft von ihrem ursprünglichen Einsatzzweck abhängen. Beispielsweise können Plattformen, die ursprünglich für die Prozessautomatisierung entwickelt wurden, besonders stark in der Modellierung und Automatisierung von Geschäftsprozessen sein, aber weniger geeignet für die Entwicklung von komplexen, datenintensiven Anwendungen. Ähnlich kann eine Plattform, die ursprünglich für den Bau von Formularen entwickelt wurde, hervorragende Tools für die Formulargestaltung und Datenvalidierung bieten, aber weniger Möglichkeiten für die Integration mit anderen Systemen. Im Selbstversuch haben wir schnell gemerkt, wo die Grenzen der Plattform liegen und wo sie am besten eingesetzt werden kann. Dies kann dazu führen, dass es sinnvoll wäre mehrere Plattformen für unterschiedliche Einsatzzwecke einzusetzen. Doch leider bieten die meisten Hersteller keine maßgeschneiderten Lizenzen. In jedem Fall ist es wichtig, die Stärken und Schwächen der verschiedenen Plattformen zu verstehen und sie entsprechend ihren jeweiligen Stärken und Schwächen einzusetzen.

Wo sehen wir die größten Potenziale von Low Code Plattformen?

Wir sehen den größten Nutzen von Low Code Plattformen im Bereich der Support-Prozesse von Unternehmen, die nicht das Kerngeschäft betreffen. Hierzu zählen bspw. administrative Prozesse in HR, Marketing, IT und vielen weiteren Bereichen. Durch den Einsatz von Low Code Plattformen können hier ineffiziente Arbeitsabläufe optimiert, Schatten-IT-Lösungen beseitigt oder Prozesse erstmalig digitalisiert und teilweise automatisiert werden. Durch Low Code können Anwendungen in diesem Bereichen schnell und effizient umgesetzt und skaliert werden. Im Kerngeschäft der Unternehmen bringt der Einsatz von Low Code Risiken mit sich. Man ist abhängig vom Anbieter der Plattform. Der technische Unterbau der Plattform ist meist eine Blackbox und man hat weniger Freiheiten in der Gestaltung der Anwendung. Zu einer ähnlichen Einschätzung gelangte auch Gero Zimmer in seinem Artikel Low-Code BPM-Suites vs. BPM-Frameworks - welche Lösung wann nutzen?

Was sind Ihre Erfahrungen mit Low Code Plattformen?

Wir freuen uns auf den gemeinsamen Austausch und beraten Sie gerne bei weiteren Fragen oder Anliegen. Sprechen Sie uns jetzt an:

Die Autoren

Traugott Dittmann

Traugott Dittmann ist Unternehmensberater bei der viadee und hat sechs Jahre lang Erfahrungen in der Einführung, Weiterentwicklung und dem operativen Betrieb eines Business-Rules-Management-Systems gesammelt. Sein Branchenschwerpunkt ist die Telekommunikation.

Bastian Engelking

Bastian Engelking ist seit 2019 Berater bei der viadee Unternehmensberatung AG. Seine Themenschwerpunkte liegen in den Bereichen Prozess- und Testautomatisierung.