Was bedeutet Low-Code überhaupt?
Low-Code an sich bedeutet zunächst einmal “wenig Code” bzw. “wenig Programmieren”. Gemeint ist dabei eigentlich immer ein Stück Software – welches sonst aufwändig programmiert werden musste – in irgendeiner Art und Weise zu vereinfachen. Das kann zum Beispiel bedeuten, Funktionen konfigurierbar zu machen, also durch eine grafische Benutzeroberfläche (GUI).
Foto: Sentavio - shutterstock.com
Blickt man auf Google Trends so lässt sich sofort erkennen, dass der Begriff in Deutschland kaum verwendet wird. In Amerika sieht die Sache schon wieder anders aus. Die schlechte Bekanntheit lässt sich vielleicht auch darauf zurückführen, dass der Begriff erst 2014 vom Branchenanalysten „Forrester Research“ für diese spezielle Art der Anwendungsentwicklung vergeben wurde.
Best Practice: WordPress
Um den Begriff Low-Code noch etwas griffiger zu gestalten, schauen wir uns den Sachverhalt an einem Beispiel an. WordPress ist das wohl beliebteste Content-Management-System für Websites: es unterstützt über 70 Prozent der Top-1-Million Webseiten im Web. Mit WordPress hat man eine (relativ) einfache Möglichkeit, sich selbst eine Website zu erstellen, inklusive aller wichtigen Funktionen wie die Erstellung eines Blogs oder das Hinzufügen von Bildern oder das Verändern des Erscheinungsbildes der eigenen Website.
WordPress ist bereits im Jahr 2003 erschienen und hat durch den Open-Source-Ansatz ein riesiges Ökosystem aufgebaut. So ist es heutzutage immer einfacher für Anwender, verschiedenste Medien auf der eigenen Website einzubauen, wunderschöne, vorgefertigte Designs zu erwerben oder spezielle Funktionen durch Plugins einzubinden. Bereitgestellt werden diese Erweiterungen durch Entwickler, die damit ihr tägliches Brot verdienen können, statt durch die indviduelle Entwicklung von Webseiten. Dafür haben sich wiederum eine Vielzahl von Freelancern auf dem freien Markt gefunden, die teilweise ohne oder mit wenig Programmierkenntnissen die Wünsche des Anwenders erfüllen.
Zusammengefasst bietet WordPress also ein System, das einerseits Anwendern die Konfiguration von Websites ermöglicht und auf der anderen Seite Entwicklern den Freiraum zur Programmierung spezieller Features bietet. Das ist eines der Grundprinzipien von Low-Code.
Woher kommt die Low-Code Bewegung?
Wie angesprochen, strebt man mit dem Low-Code Ansatz danach, die Bedienung von einem komplexen System zu vereinfachen. Im Beispiel WordPress ist das die Erstellung von Websites und die Marschrichtung vom Entwickler zum Anwender bzw. Power-User. Aber eigentlich hat die Low-Code-Bewegung schon viel früher angefangen. Mit sogenannten 4GL begann der Trend bereits in den 1980er Jahren.
4GL sind “Fourth-Generation-Languages”, ein Begriff aus der Softwareentwicklung. Er beschreibt Programmiersprachen, welche auf einem höheren Abstraktionslevel als die der dritten, zweiten und ersten Generation sind. Während 1GL die Maschinensprache ist, also am nähesten “an-der-Hardware-dran”, ist 4GL bereits weit weg davon. Vereinfacht lassen sich die Generationen folgendermaßen ausdrücken:
1GL: Maschinensprache
2GL: Assemblersprache
3GL: Prozedurale Programmierung
4GL: Deklarative Programmierung
5GL: Künstliche Intelligenz
Die Assemblersprache (2GL) ist ebenfalls als hardwarenah zu bezeichnen. Der Quelltext, auch Assemblercode genannt, wird durch den sogenannten Assembler direkt in ausführbare Maschinensprache (1GL) umgewandelt.
Und auch in den nachfolgenden Generationen ging es eigentlich immer darum, eine Sprache in die nächst Niedere zu übersetzen. Die gängigste Generation ist auch heute noch 3GL: die prozedurale Sprache. Selbst wenn man kein Programmierer ist, hat man meistens schon einmal von den Sprachen wie C oder C# gehört, vielleicht sogar schon einmal mit objektorientierten Sprachen wie C++, Java oder JavaScript gearbeitet.
Was macht nun 4GL anders als 3GL? Während 3GL vor allem die Einführung von standardisierten Kontrollstrukturen geprägt hat, haben Programmierumgebungen der vierten Generation das Ziel, möglichst schnell und mit möglichst wenig Codezeilen für einen bestimmten Anwendungsfall Funktionen oder aber auch komplette Anwendungen bereitstellen zu können.
Das klingt erst einmal spannend, ist aber insgesamt ein schwammiger Begriff und wurde in den 1980er Jahren vor allem für Marketingzwecke eingesetzt. Später wurde das Gebiet etwas eingegrenzt, um zum Beispiel auf Skriptsprachen eines geschlossenen Systems zu verweisen.
Wie man es auch nimmt, haben solch moderne Entwicklungsumgebungen immer die folgenden Ziele:
einfachere, anwenderorientierte Darstellung und Unterstützung des Entwicklungsprozesses
bessere Wartbarkeit und Erweiterbarkeit durch den Anwender
und die sich daraus ergebende kürzere und kostengünstigere Entwicklung
Dann bleibt noch 5GL übrig. Darauf wollen wir in diesem Beitrag nicht näher eingehen. Man stelle sich einfach 4GL im Quadrat vor, und man kommt bei 5GL heraus. Es wird nur noch schwammiger. Aber es hat was mit künstlicher Intelligenz zu tun.
Abgrenzung Low-Code zum heutigen Gebrauch mit Low-Code Development Platforms
Low-Code ist also aus den unterschiedlichen Paradigmen der Softwareentwicklung heraus entstanden. Der Begriff hat in den letzten Jahren insbesondere in den USA eine echte Renaissance erfahren, nämlich durch das Aufkommen von sogenannten “Low-Code Development Platforms”. Kurz gesagt handelt es sich dabei um Plattformen, welche die Erstellung von Software bzw. Anwendungen durch möglichst wenig Programmierung anbieten und damit auch Anwendern ohne großes Programmierwissen ermöglichen sollen, Applikationen zu erstellen.
LCP, MADP, RMAD, RAD, RADP, WTF?
Man braucht sich keine fünf Minuten durch Google hangeln, um zu bemerken, dass sich Hersteller allerlei unterschiedliche Bezeichnungen für ihre Plattform geben. Dort liest man von “Mobile Application Development Platforms” (MADP), von “Rapid Mobile App Development” sowie von “Mobile back-end services” (MBS) und “Rapid Application Development Platforms” (RADP). Ja was denn nun?
Alle diese Begriffe haben ihre Daseinsberechtigung, sind aber eher nützlich zur Klassifizierung von Plattformen als zum Verständnis. Um sich selbst ein klares Bild zu verschaffen ist es wichtig, den Fokus der Plattform zu erfassen und mit den eigenen Bedürfnissen abzugleichen. Die wichtigsten Fragen vorab:
Was will ich mit der Plattform erreichen?
Wer soll die Plattform bedienen (innerhalb, außerhalb meiner Organisation)?
Welche Business Values verspreche ich mir davon (Höhere Kundenbindung, kürzere Entwicklungszeit, Zugang zu Informationen) und wie bemesse ich diese?
Wo liegen heute die Probleme in meiner Organisation, die ich ohne eine solche Plattform nicht gelöst bekomme?
Wie sieht es in der Praxis aus?
Zurück zum Blick auf unser Schaubild des Anwenders und des Full-Stack-Developers: mit einer Low-Code Plattform kann beiden geholfen sein. Wie? Als Anwender kann ich Teile meiner Anwendung vielleicht selbst anpassen und entlaste damit meine Entwickler oder spare mir sogar Kosten ein. Auf der anderen Seite kann ich in der Kommunikation mit dem Entwickler schneller auf den Punkt kommen – denn er hat die Möglichkeit mir viel schneller einen ersten Prototypen zu zeigen und mit mir abzusprechen.
Aus der Brille des Entwicklers sieht es genau anders herum aus: ich mache mir Kapazitäten frei für komplexere Aufgaben und muss mich nicht mit immer wiederkehrenden Aufgaben beschäftigen, indem ich einfachere Aufgaben in die Richtung des Anwenders geben kann.
Wenn es Low-Code gibt, dann geht doch auch No-Code?
No Code ist zunächst einmal ein Album von Pearl Jam, wenn man in Google danach sucht. Auf der anderen Seite ist es eine Weiterentwicklung des Low-Code-Ansatzes. Der Name ist Programm: Hier wird nicht programmiert. Aber auch bewusst, denn die meisten Plattformen und Angebote richten sich strikt an den Endanwender innerhalb einer Organisation oder sogar an Privatanwender. Das kann ein Vorteil sein – so finden sich Excel-Profis und Makro-Jongleure schnell zurecht – allerdings werden hier auch ganz schnell Grenzen aufgezeigt. Das Andocken komplexerer Systeme oder das Hinzufügen von individualisierten Plugins oder Skriptbausteinen ist kaum möglich.
Dadurch bleibt der Entwickler vor der Tür – und muss sich dann zu späterer Stelle doch wieder im nächsten Projekt einschalten.
Was heißt das für Business Anwendungen und für Prozessoptimierung im industriellen Umfeld? Mit No-Code beißt man sich wahrscheinlich die Zähne aus. Aus unserer Erfahrung können wir nur sagen, dass sich nahezu jede Anfrage und jedes Projekt ein bisschen gestaltet. Das heißt im Umkehrschluss, dass Flexibilität der wichtigere Faktor für unsere Kunden ist.