To lowcode or to code für Tools eurer Geschäftsprozesse?

Bei uns in der Hochschule überlegen wir aktuell, wie wir Formulare, Workflows, … für all die kleinen Anfragen, Aufträge und Abläufe digital erstellen und verknüpfen können, welche bisher durch einfache PDF-Formulare umgesetzt wurden. Nimmt man da nocode, lowcode oder doch etwas ganz anderes? Hier ein paar Überlegungen …

Bestimmt kennt ihr das auch von eurer Arbeit oder Organisation. Es gibt interne Abläufe, die auch bisher noch über analoge oder digitale Formulare und jeder Menge eMails abgebildet werden, ab eirgentlich wegen ihrer übergreifenden Natur und den vielen Schritten mit unterschiedlichen Akteuren in eine zentralere Stelle und automatisiert gehören. Natürlich sollte dies schon längst durch Fachanwendungen der jeweilgen Abteilungen wie Personal (Stellenbesetzung, onboarding, offboarding, Dienstreise, Krankmeldung, Urlaub, …), Haushalt / Beschaffung, Presse abgebildet sein. Aber wer nicht gerade ein XXL Monolithen wie SAP einsetzt, der muss sich mit dem begnügen was sein Ökosystem / toolset bisher so bietet. Bei uns sind das viele Module der verschiedenen HIS (Hochschulinformationsystem) Generationen. Das mit weiteren Tools wie Projektmanagement (PM), Customer-Releationship Management (CRM), Enterprise Content Management (ECM) oder Dokument Management (DMS) anrufeichern ist natürlich möglich, aber auch mit viel customizing verbunden und wahrscheinlich nutzt man dann doch wieder nur einen Bruchteil dieser jeweiligen Schwergewichte, oder zwingt sich in gedankliche Korsetts wie der Idee von klassischen Dokumenten in Workflows.

Dann also doch wieder eine Eigenentwicklung die man selber konzipieren, programmieren und umsetzen muss? Hmm…

Lowcode oder nocode

In den letzten Jahren kamen immer mehr Produkte auf den Markt, welche es durch rein grafische Gestaltung und Konfiguration es ermöglichen teilweise oder sogar ganz ohne klassische Programmierung auszukommen. So ganz neu ist der Ansatz mit Baukästen und Widgets ja nicht, man denke nur an das Rapid Application Development von Delphi, oder der Idee, dass mit SQL und Reportdesignern die Business Intelligence auch für Nicht-Informatiker erschlossen wird. Oder denken wir an Drupal oder Eclipse Codegenerierung aus UML Notation und die ganzen Ansätze zur Modellgetriebenen Entwicklung nach der Jahrtausendwende …

Einige der Low Code Development Platforms (LCDPs) sind noch nicht wirklich lange veröffentlicht und haben auch eine übersichtliche Versionshistorie und vielleicht noch einen längeren Weg zu gehen, ehe sie feature-complete und mit einer stabilen Architektur aufwarten können. Was ich mir bisher angeschaut habe, sind explizit Open Source Lösungen, weil ich der Meinung bin, dass man sich sonst sehr schnell in eine harte Abhängigkeit zum Hersteller gibt (vendor lockin), wenn man nicht nur hosting, sondern auch Entwicklungsumgebung aus der Hand gibt.

Nextcloud Tables

Ok, das Addon ist sicherlich eine der einfachsten Lösungen. Es ermöglicht mit verschiedenen Nutzern gemeinsam per Forms an Datensätzen zu arbeiten. Das können natürlich auch Vorgänge sein, aber man ist schon sehr eingeschränkt, da man keine Beziehungen formulieren kann. Mit Nextcloud Funktionen wie Historie oder Flows könnte man vielleicht auch workflows nachempfinden, aber eigentlich eignet sich das wahrscheinlich eher zur Erfassung von einfachen Sachen.

Baserow

Baserow.io ist ein Tabellen getriebener Ansatz und eher ein Frontend für eine normale Datenbank, was mit Formularen und Zuständen einen unterstützen kann. Aber man kann hier deutlich mehr machen, wie etwa auch Beziehungen zwischen Tabellen.

Lowdefy

Einen anderen Ansatz verfolgt lowdefy.com wo man Formulare, Zustände und Abläufe per YAML Datei in einem Struktur-Schema definiert. Das ermöglicht aus meiner Sicht nicht nur ein schnelles Vorranschreiten und späteres Verfeinern des Designs, sondern lässt sich auch mit legacy DBs und APIs offenbar recht gut verbinden. Man kann sich schneller „einlesen“ und muss bei der Plattform nicht lernen wo welcher Button gedrückt werden muss und in welcher Menü-Ebene man wegen jeder kleinen Änderung abtauchen muss.

Joget DX

Einen auf Java basierenden Ansatz ist joget.org. Mit einer UI definiert man Forms, Daten und Workflows in WYSIWYG Manier zusammen und nutzt dazu offenbar verschiedenen Designer.

REI3

Mit rei3.de scheint es ebenfalls eine interessante Plattform aus deutschen Landen. Obwohl das Oberflächen-Design vielleicht etwas altbacken wirkt, scheinen damit recht komplexe Abläufe möglich zu sein, wenn man einmal auf die Beispiele schaut. Wie etabbliert das Ganze ist, kann man aufgrund des überschaubar vielen (öffentlichen) Schulungsmaterial nicht so wirklich einordnen.

Camunda

Tja Camunda ist nun wirklich eine richtig große BPMN-Suite. Man designt also Arbeitsprozesse visuell in Diagrammen und die integrierte Workflow-Engine kann dann entsprechend die Vorgänge durchführen. Natürlich ist die Prozessgestaltung selbst schon eine gewisse Schwelle und auch die vielen Funktionen und Module der Plattform können einen bestimmt erst einmal überfordern. Aber es gibt auch extrem viel öffentliches Material, um sowohl Notation, als auch das Werkzeug kennenzulernen. Es scheint auch viele Consulter und Firmen zu geben, welche das als Werkzeug für die Analyse der Prozesse beim Kunden nutzen.

Soll es das gewesen sein?

Tja nun müsste man sich überlegen, ob man mit einem dieser Tools nicht mal durchstarten will. Allerdings sitzt mir da meine bisherigen Erfahrungen aus der IT-Welt wie ein kleiner Teufel auf der Schulter und säen Zweifel. Konkret befürchte ich, dass die Tools teilweise noch nicht alt genug sind, um sich schon ausreichend mit den Problemstellungen eines kompletten Lifecycles auseinandergesetzt und wissen was sie umsetzen können und was sie bewußt nicht implementieren.
Die Videoturorials zeigen (verständlicherweise) für den Einstieg nur sehr kleine Spielzenarien: lies etwas aus DB und stelle es hübsch da, Erstelle einen neuen Datensatz . Das wars.

Meine Erfahrung zeigt aber, dass der Aufwand oft im Detail steckt und das Problem nicht unbedingt ist schicke Tabellen, Diagramme in Reports zu erhalten. Ich vermisse bei den Tools oft mal komplexe Realwelt-Beispiele und „Kriegsgeschichten“ der Anwender. Für mich konkret wäre es etwa interessant, ob man es schafft effizient und schlau einen digital Urlaubsantrag zu stellen. Also kann ich Nutzer aus dem AD, Exchange-Kalender, die bahn.de API und OpenStreetMap-Routing zu etwas mit wirklichem Mehrwert kombinieren? Etwas das ein mehrstufige Bearbeitung und speichern von Zwischenständen des Wizzards ermöglicht und sich bei der Validierung auch nicht nur auf dumme Pflicht / Optionales Feld Eigenschaften stützt?
Aber ich vermute, dass die lowcode / nocode Werkzeuge für solche Anforderungen wahrscheinlich oft nicht weitgenug gedacht worden sind. In den Videos zeigte sich eine eher überischtliche Auswahl von (komplexen) Datentypen und Aktionen und wenig zu konkurierenden Beabreitung an Daten. Natürlich ist auch eine gute Usability wichtig und die ist komplex, wenn man sie auf (mobile) Devices und Multi-User Umgebungen umsetzen will. Erst recht, wenn es dabei dann auch noch Rollen mit unterschiedlichsten Anforderungen gibt.

Sein wir ehrlich, IT ist einfach auch komplex und Anwendungen haben auch sehr vielfältigen Anforderungen. Angefangen von Geschäftslogik über Berechtigungen, der Integration von legacy Systemen, Aktualsierungen als Reaktionen auf veränderte Bedingungen der Außenwelt, Historie von Konfiguration / Einstellungen, ….

Trotz der vielen Erleichterungen, sehe ich bei hinreichend komplexen Geschäftsprozesessen nicht, dass es ohne IT-Erfahrung (langfristig) gut geht. Sei es, dass man an etwas wie Backups berücksichtigt, oder sich überlegt wie Daten später in ein neues System migriert werden. Oder hat man an Nachvollziehbarkeit von Änderungen gedacht, oder was passiert, wenn der Cloud-Anbieter gerade streikt und die Organisation eigentlich von all den netten kleinen Tools abhängt die man mal eben so entwickelt hat? Das man die (leidvolle) Erfahrung gemacht hat, sich all diese Fragen zu stellen, erfordert aus meiner Sicht einfach einen Werdegang in der IT und kann von niemand erwartet werden, der eigentlich weder in der Entwicklung, noch im Betrieb solcher Systeme schon länger unterwegs ist. Denn nur dann weiß man auch, dass kleine Anwendungen oft dazu tendieren groß zu werden. Und nicht umsonst gibt es ja den Begriff technische Schulden, die leider auch trotz bester Vorbereitung eben oft immernoch anfallen. Und wer ist denn verantwortlich, wenn es zu Problemen im laufenden Betrieb kommt, oder die Entwicklung ein totes Ende erreicht hat?

Wie macht man es nun?

Mich erinnert das Ganze etwas an die Ansätze Playmobil vs. Lego vs. klassischem Modellbau. Wenn man in einem vorgegeben Szenario wirklich spielen will, für den ist Playmobil. Wer eher sich ausprobieren will und vielleicht in seinem Cowboy+Alien Universum mal einen verrückten Weltraum-Cyber-Kutschen-Raumgleiter mit Holzbeplankung haben will, der findet sich mit Legos Klemmbausteinen natürlich super zurecht. Er muss aber auch die Fantasie und Zeit mitbringen. Wer von letzterem mehr als genug hat und dazu noch etwas Frustrationstolleranz hat und handwerkliche Fähigkeiten mitbringt, für den wäre sicherlich auch Modellbau etwas. Aber ganz ehrlich? Da geht es dann wirklich nur noch um das Bauen und nicht mehr um das spielen mit den aufwendig gestalteten Modellen 😉

Das beschreibt vielleicht ganz gut das Spektrum was ich für die Realisierung von Plattformen für eigene Workflows sehe. Und um ehrlich zu sein tendiere ich fast wirklich zur Nutzung einer etabblierten Programmiersprache, aber mit Nutzung von (gut abgehangenen) High-level Frameworks, welche einen mit fertigen Architekturen und Konzepten die Routineaufgaben abnehmen.
Das erfordert bei dem mehr an Arbeit sicherlich einen externen Partner, zwingt einen dabei aber auch bereits zu einer klaren (groben) Problembeschreibung. Durch iterative Ansätze kann man hier nacharbeiten und durch die offene Technologien hätte man die Möglichkeit (fast) alle Details anzupassen, sich einzuklinken und zu erweitern. Und mit inhouse-Kompetenz hätte man auch ohne externe Dienstleister die Möglichkeit, zeitnah Anpassungen umzusetzen. Oder falls mal ein anderer Partner die Wartung übernehmen sollte, wäre es auch möglich. Dazu klare Software-Tests, Versionsverwaltung von Code / Assets und Konfigurationen in Kombination mit Continuus Integration / Delivery klare Aussagen zu der Funktionsweise der Software, Verhalten nach Updates usw.

Vielleicht sind no/lowcode Werkzeuge ja wirklich hilfreich, wenn Nutzer aus einer Problemdomäne befähigt werden sollen, sich kleine Tools aus ihrer Insiderperspektive zu schreiben. Aber schon wenn man ans Prototyping denkt, frage ich mich, was der Vorteil gegenüber etabblierten Lösungen wäre?

Wie macht man es nun?

Wie würdet ihr denn die folgenden Anwendungsfälle umsetzen?

• on- / offboarding von Personal
• Dienstreise planen + freigeben
• Urlaub planen + freigeben
• öffentliche Veranstaltung planen

Ich glaube ich wäre mit Python + Django webframework und vielleicht django-viewflow recht gut aufgestellt? Es gibt bestimmt auch beliebig viele Alternativen in anderen Programmiersprachen und schöne andere Frameworks, aber diese Werkzeugsammlung hat mich gefühlt schon über 10 Jahre begleitet und ich habe glaube ich ein ganz okes Gefühl zu den Möglichkeiten und Grenzen des Gespannes.
Wenn ihr da vielleicht schon mal eins der oberen Tools für solche Sachen genutzt habt, oder einen ganz anderen Vorschlag hättet, würde ich mich sehr über euer Feedback freuen 🙂