„Demokratisierung“ der Programmierung: No-Code- und Low-Code-Plattformen im Fokus

No-Code- und Low-Code-Plattformen demokratisieren bereits jetzt die Softwareentwicklung. Diese Plattformen ermöglichen es Endnutzern, sogenannten Citizen Developers, eigene Workflows und Lösungen ohne tiefgehende Programmierkenntnisse zu erstellen. Doch trotz ihrer Vorteile bringen sie auch Herausforderungen mit sich. Beides sollte sorgfältig gegeneinander abgewogen werden.

Die Welt von morgen schon heute?

Auf dem World Government Summit 2024 in Dubai stellte der CEO von Nvidia, Jensen Huang, eine gewagte Prognose auf: In 10 bis 15 Jahren werde niemand mehr programmieren lernen müssen, da künstliche Intelligenz (KI) diese Aufgaben übernehmen werde. Im Gegensatz dazu argumentierte der CEO von Google, Sundar Pichai, dass KI als Werkzeug dienen werde, das sogar mehr Menschen zum Programmieren anregen werde. Wer von beiden recht behält, wird die Zeit zeigen. Was jedoch bereits die Landschaft verändert, sind No-Code- und Low-Code-Plattformen, die darauf abzielen, die Softwareentwicklung zu demokratisieren.

Diese Plattformen sind darauf ausgelegt, Endnutzer, sogenannte Citizen Developers, zu befähigen, ihre eigenen Workflows und Lösungen zu erstellen, fast oder ganz ohne einen formalen Code schreiben zu müssen.

Ein Beispiel aus dem Arbeitsalltag 

Ein Beispiel aus dem Arbeitsalltag von Rechtsanwälten oder Steuerberatern: Per E-Mail geht eine Nachricht eines wichtigen Mandanten ein. Ein Workflow erkennt mittels Stimmungsanalyse, dass die Nachricht sehr wichtig und dringend ist, und benachrichtigt sofort mittels Chatfunktion den mandatierten Anwalt und seine Vertretung. Die E-Mail-Anhänge konnten einem Mandat zugeordnet werden und werden mit einer kurzen Zusammenfassung in der Dokumentenverwaltung abgelegt. Der Mandant wird automatisch über den Eingang seiner E-Mail informiert und es wird ihm schnellstmöglich ein Rückruf zugesagt. Dieser erfolgt über die Internettelefonie-Applikation, die die Teilnehmer, die Gesprächsdauer und den Zweck speichert. Diese Daten werden über einen Workflow ins Billing-System übermittelt.

Für diesen komplexen Workflow wäre früher ggf. eine maßgeschneiderte Softwarelösung erforderlich gewesen, die heute aber mit wenigen Klicks selbst erstellt und wieder an neue Bedürfnisse angepasst werden kann. Die mögliche Komplexität hängt davon ab, auf welche Art von Plattform man setzt.

Ein Überblick über bekannte Plattformen

No-Code-Plattformen verwenden ausschließlich grafische Elemente, um Programmabläufe wie Eingaben, Ausgaben und Bedingungen darzustellen und gleichzeitig ausführbar zu machen. Low-Code-Plattformen bieten etwas mehr Flexibilität, indem sie die begrenzte Nutzung von Code ermöglichen, um die Funktionalität zu erweitern. Im Gegensatz zur No-Code-Variante ist man hier also nicht völlig auf die Programmbausteine angewiesen, die der Anbieter zur Verfügung stellt. 

Platzhirsch bei den Low-Code-Plattformen ist sicherlich Microsoft mit seinem Produkt Power Automate. Kein Wunder, denn aufgrund seiner Stellung im Betriebssystemmarkt und bei Office-Produkten fällt es Microsoft leicht, eine Automatisierungslösung für die breite Palette von Produkten aus dem eigenen Haus anzubieten. Teilweise in Konkurrenz zu Power Automate steht UIPath, eine Automatisierungsplattform, die nicht so stark ins Microsoft-Ökosystem integriert ist, allerdings auch eine Steuerung von Programmen als Teil von Workflows zulässt, die dies eigentlich nicht vorsehen. UIPath simuliert hier menschliche Eingaben über die Tastatur oder die Maus. Schon nicht mehr den Endanwender als Entwickler im Blick hat dagegen die Low-Code-Plattform ServiceNow. Gleiches gilt für die Produkte von Onit, wie z.B. OnitX Enterprise Legal Management oder OnitX Matter Management.

No-Code- und Low-Code-Lösungen anderer Anbieter sind häufiger in speziellere Anwendungen eingebettet: im Bereich des Legal-Business-Managements z. B. etwa HighQ von Thomson Reuters, das über No-Code-Workflows etwa Tasks generieren oder Daten für die eingebaute Dokumentenautomation erfassen lässt. Obwohl ebenfalls eine No-Code-Lösung, erlaubt Bryter durch zahlreiche Verbindungen zu Applikationen von Drittanbietern den „Blick über den eigenen Tellerrand“. Lawlift ist eine weitere No-Code-Dokumentenautomation, die ins Microsoft-Ökosystem integriert ist und die Erstellung von Vorlagen mit komplexen Regeln erlaubt. Konkurrent ContractExpress (Thomson Reuters) setzt dagegen auf eine eigene Programmiersprache, die in einer Microsoft Word Vorlage verwendet wird.

Die Vorteile

Ein Vorteil von No-Code- und Low-Code-Plattformen ist, dass der Endanwender selbst wiederkehrende Aufgaben automatisieren kann, ohne zuerst eine der bekannten formalen Programmiersprachen (z. B. C, Python oder Clojure) lernen zu müssen. Entmachtet wird damit – zumindest scheinbar – die IT-Elite aus professionellen Programmierern und Systemadministratoren. Der Endnutzer kann nun seine Lösung nicht nur selbst, sondern auch unmittelbar in die Tat umsetzen. Der umständliche und zeitintensive Prozess, Dritte erst noch davon zu überzeugen, dass das Problem überhaupt einer Lösung bedarf, entfällt. 

Dies gewährleistet auch, dass die eigene Lösung auch wirklich das eigene Problem löst. Wenn Dritte mit der Lösung betraut werden, ist dies nicht zwingend der Fall, da sie die Auswirkungen des Problems nicht spüren und die Folgen der Lösung nicht selbst tragen werden.

No-Code- oder Low-Code-Anwendungen bieten auch mehr Flexibilität, wenn Problem und Lösung nicht mehr überlappen und Änderungen des Workflows erforderlich sind. Der Endanwender nimmt erneut das Zepter selbst in die Hand, statt wieder die Rolle des Bittstellers einzunehmen.

Ein positiver Nebeneffekt der Plattformen kann auch sein, dass sich der Endanwender erstmals mit dem bisherigen Workflow auseinandersetzen muss und so erkennt, was optimiert werden kann.

Die Herausforderungen 

Ein Nachteil von Low-Code- und No-Code-Plattformen sind die erheblichen technischen Einschränkungen. Während traditionelle Programmiersprachen theoretisch jedes Problem innerhalb der Grenzen von Speicher und Rechenleistung lösen können, kann der Endanwender der Plattformen nur mit den Bausteinen arbeiten, die ihm der Anbieter zur Verfügung stellt. Dies gilt umso mehr, je spezieller der Anwendungsbereich der Plattform ist, weil die Bausteine genau darauf zugeschnitten sind.

Um im Beispiel von Power Automate zu bleiben: Hier stellt Microsoft nicht nur Hunderte Workflowbausteine für seine eigenen Produkte zur Verfügung, sondern erlaubt es auch Drittanbietern, solche Bausteine zur Verfügung zu stellen. Speziellere Plattformen wie HighQ erlauben eine solche Erweiterung oft nur in Form von sogenannten APIs (Application Programming Interfaces), die sich aber nicht an Endanwender richten.

Ein wesentlicher Teil des Programmierens mit formalen Sprachen besteht aus rigorosen Tests, um Fehler im Ablauf frühzeitig zu finden. Dabei versucht der Programmierer, sein Programm selbst zu überlisten und Fehler zu provozieren. Werden sie entdeckt, wird das Programm überarbeitet und wieder getestet, bis es sicher genug erscheint, um es dem Endnutzer zur Verfügung zu stellen. Nicht nur dürfte ein solches Vorgehen den typischen Endanwender überfordern, sondern die jeweiligen Plattformen stellen ihm häufig auch die hierzu erforderlichen Bausteine nicht zur Verfügung. Je komplexer der Workflow, der mit der Plattform realisiert werden soll, desto problematischer ist dieses Manko.

Komplexere Workflows erfordern auch eine Möglichkeit, sie mit ihren jeweiligen Abläufen so zu dokumentieren, dass sie von anderen Personen als dem Ersteller nachvollzogen werden können. Zielgruppe dieser Dokumentation sind aber nicht nur andere Anwender, sondern auch etwa Datenschutz- oder Cybersecurity-Beauftragte im Unternehmen, die wissen müssen, welche Daten verarbeitet und an wen sie ggf. weitergeleitet werden. Erstaunlicherweise muss oft mit Screenshots oder Textbeschreibungen der Workflows gearbeitet werden, da die Plattformen selbst kaum Unterstützung bieten. Die Folge: Jede Änderung des Workflows erfordert neuen Dokumentationsaufwand. Klassische Programmiersprachen bieten hierfür eigene Tools, die diesen Aufwand drastisch reduzieren helfen. 

Augenmerk sollte auch darauf gelegt werden, ob die Workflows in irgendeiner Form exportiert und wieder importiert werden können, um z. B. lokale Sicherheitskopien anfertigen oder bei Änderungen wieder zu einer Vorversion zurückspringen zu können, wenn sich in der aktuellen Version Fehler eingeschlichen haben. Der Workflow sollte als wertvolles Asset betrachtet werden, den es zu schützen und zu sichern gilt. Dies sollte nicht allein dem Anbieter überlassen werden.

Beachtet werden muss schließlich auch die Gefahr des Vendor Lock-in: Mit jedem Workflow, der auf der Plattform erstellt wird, festigt sich die Position des Anbieters, weil die bereits erstellten, getesteten und dokumentierten Workflows nicht auf Plattformen anderer Anbieter eingesetzt werden können. Ein Wechsel zu einer anderen (besseren oder billigeren) Plattform scheitert dann ggf. an den Kosten des Wechsels, die durch Neuerstellung, Testung und Dokumentation der Workflows auf der Konkurrenzplattform erneut anfallen.