Vom Maschinencode zu No-Code: Den Hunger nach Software stillen

Die Idee war genial: Maschinen zu bauen, bei denen nicht von vorneherein festgelegt war, was sie zu tun hatten. Ein Staubsauger saugt Staub und ein Scheibenwischer wischt Scheiben, aber ein Computer? Er rechnet, klar, aber was er berechnet, ist in der Bauphase noch offen: Finite Elemente, Mehrwertsteuer oder Katzenvideos.

Was der Rechner schließlich ausführt, entscheidet die Software – und damit beginnt das Problem. Gute Software ist immer knapp. Schon seit den Anfängen der IT gab es immer viel zu viele (mögliche) Aufgaben für immer viel zu wenige Programme. Früher nannte man es “Software-Krise”, mittlerweile ist der Begriff verschwunden, weil man sich daran gewöhnt hat.

Mit der breiten Durchsetzung der IT, der Etablierung von Computern in jedem Unternehmen, in jeder Behörde und in jeder Studierstube, hat sich das Problem keineswegs erledigt, im Gegenteil. Nicht nur die komplexen, sich stets verändernden Prozesse in Wirtschaft und Gesellschaft erzeugen immer neuen Software-Bedarf, die IT selbst legt noch was drauf: Schließlich war sie es, die die Digitalisierung vom Zaun gebrochen hat und damit den Hunger nach Software auf eine neue Stufenleiter gehoben hat. Jeder Schritt auf dem Weg in die digitalisierte Welt ist mit einem Mehr an Software verbunden.

Natürlich hat sich die Entwicklung von Software seit “Plankalkül” und den ersten Computer-Ungetümen bis zur Unkenntlichkeit verändert. Aber aufwändig und kompliziert ist sie geblieben. Selbstverständlich muss man heute nicht mehr tagelang codieren, um eine simple Rechenoperation zustande zu bringen, aber heute erwartet man von einem Programm auch deutlich mehr als simple Rechenoperationen. Die Abbildung von Anforderungen der realen Welt auf die technischen Systeme der IT war eben noch nie trivial, sie erforderte viel Know-how, viel Erfahrung und weil auch das nicht immer ausreichte, oft auch Glück, Sitzfleisch und gute Laune, beispielsweise bei der nächtlichen Suche nach einem Fehler im Code. Softwareentwicklung muss im Grund stets vier Probleme lösen:

• Abstraktion von den Aufgaben: Die Softwareentwicklung muss Anforderungen, die nicht ihre eigenen sind, sondern von Dritten an sie herangetragen werden, verstehen und in ein Programmstruktur umsetzen; das ist vielleicht der schwierigste Teil ihrer Arbeit.
• Das erstellte Programm muss (definierten) qualitativen Ansprüchen genügen: Es muss seine Aufgaben erfüllen, soll keine Fehler oder Überraschungen enthalten und muss hinreichend performant laufen.
• Die Programmerstellung muss in einem vorgegeben Zeitrahmen erfolgreich abgeschlossen werden; diese Anforderung hat sich mit der Digitalisierung und den mobilen Systemen mit ihren extrem kurzen Release-Zyklen enorm verschärft.
• Insgesamt muss die Entwicklung von Software trotz hoher Anforderungen und großem Aufwand wirtschaftlich vertretbar bleiben.

An diesen Anforderungen beißt sich die Softwareentwicklung seit Anbeginn die Zähne aus.

Problemlösung in mehreren Schritten

In den Anfängen musste Software maschinennah codiert werden. Der (Maschinen-)Code war rein binär und musste auf jeden Prozessortyp abgestimmt werden; Massenanwendungen ließen sich so natürlich nicht auf den Markt bringen, und nur wenige Experten waren in der Lage, auf diese Weise Software zu entwickeln.

Dennoch waren diese Systeme so erfolgreich, dass der Bedarf an zusätzlichen Anwendungen rasch wuchs. Mit Assembler war man einen Schritt weiter: Das System übertrug den Code selbst in Maschinensprache, die Codierung erfolgte zwar weiter hardwarenah, war aber zumindest in Ansätzen verständlicher; dennoch blieb Softwareentwicklung Fachleuten vorbehalten.

Der Siegeszug der IT begann ab den 60er-Jahren mit den höheren Programmiersprachen. Sie machten es möglich, Aufgaben der realen Welt so für die Computersysteme zu formulieren, dass sie auch für Nicht-Ingenieure einigermaßen nachvollziehbar blieben. Sprachen wie FORTRAN oder COBOL starteten damals ihre Karriere; wie groß der Fortschritt war, den sie brachten, zeigt die Tatsache, dass sie in ihren jeweiligen Nischen tatsächlich bis heute überlebt haben.

Diese Hochsprachen waren mit dem Versprechen angetreten, verständlichen Code zu ermöglichen und auf diese Weise die Kollegen aus den Fachabteilungen in die Softwareentwicklung einzubeziehen. Und natürlich sollte die Programmierung damit insgesamt schneller und effizienter werden. Letzteres wurde zwar erfüllt, denn schneller und effizienter als mit Assembler kam man nun schon voran, doch mit ihrer komplexen Syntax und den zahllosen kryptischen Statements blieben auch die Hochsprachen den Spezialisten vorbehalten. Nicht die Fachabteilungen machten die Software, vielmehr wurde mit wachsender Nachfrage nach dieser Software Programmierer endgültig zum Beruf. Die Übersetzung von Anforderungen in die Zeilen eines Programms blieb eine große Herausforderung – bei größeren Software-Projekten musste man demzufolge in Monaten, wenn nicht Jahren rechnen.

Trotzdem nahm der Bedarf an Anwendungen weiter zu, was zunächst zu einer Vermehrung der Programmiersprachen führte. Gegen Ende der 70er-Jahre hatte jedes Anwendungsthema seine eigene (höhere) Programmiersprache – Experten beherrschten schon mal ein Dutzend davon. Die Kollegen aus den Fachabteilungen mit ihrem Wissen über die Anwendungsszenarien? Blieben erst recht außen vor. Die so genannte Software-Krise erreichte einen ersten Höhepunkt.

So konnte es natürlich nicht weitergehen. Als ab den frühen 80er-Jahren vor dem Hintergrund der Erschaffung des PC und damit einer umfassenden Computerisierung der Wirtschaft der Softwarebedarf geradezu explodierte, wurden auch in der Softwareentwicklung neue Wege beschritten. Zum einen veränderten sich die Programmiersprachen selbst, indem neue Paradigmen eingeführt wurden.

Als wichtigste Neuerung ist hier die Objektorientierung zu nennen, die mit Sprachen wie C++ populär wurde und blieb. Sie ermöglichte durch das Konzept der Vererbung beispielsweise eine technisch saubere, dynamische Wiederverwendbarkeit von einzelnen Elementen, sodass auch aufwändige Neuerungen wie graphische Oberflächen für “normale” Programmierer halbwegs effizient zu meistern waren. Speziell auf die Web-Bedingungen abgestimmt sind Java und Java Script, die mittlerweile zu den populärsten Sprachen gehören. Die Zahl der Programmiersprachen ist aber weiterhin kaum überschaubar: Zu den bekannteren gehören aktuell neben der Java- und der C-Familie zum Beispiel PHP, Python, Swift, R, Haskell, Kotlin, Groovy, Ruby – und nicht zu vergessen Rust.

Aus technischer Sicht haben alle ihre Berechtigung, aber für den betrieblichen Alltag hilft das wenig: jede dieser Sprachen ist ein Spezialisten-Thema und für eine schnelle und fachnahe Softwareentwicklung wenig geeignet. Diese Sprachen lösen einzelne Software-Probleme, aber nicht das generelle Problem des Software-Hungers.

Einen anderen Weg aus der Software-Krise schlugen Lösungen ein, die ohne selbst Programmiersprache zu sein, die Erstellung von Code vereinfachten: Seit den 80er-Jahren wird die Softwareentwicklung begleitet von einer Vielzahl von Programm- und Maskengeneratoren, von Werkzeugen wie Computer Aided Software Engineering (CASE), 4GL-Sprachen oder von Ansätzen wie Rapid Protoyping oder Modellbasierter Entwicklung, wofür es dann auch wieder eigene Sprachen gibt wie etwa UML. Diese Konzepte versuchen auf unterschiedliche Weisen, die Codierung zu automatisieren und damit von technischem Ballast zu befreien, sodass die Entwicklung sich auf fachliche Aspekte konzentrieren kann und so schneller und einfacher wird. Der Entwickler arbeitet dabei primär mit dem jeweiligen Werkzeug, den eigentlichen Code erstellt mehr oder weniger das System. Auch wenn die steile Karriere der IT in den 90er-Jahren ohne solche Tools kaum denkbar wäre, ein Durchbruch im Sinne der oben genannten Punkte steht weiterhin aus. Auch die diversen Programmierwerkzeuge sind komplex und aufwändig, sodass Software-Projekte aufwändig und langwierig geblieben sind. Sie können nach wie vor die Fach-Experten nur unzureichend einbinden, und immer wieder machen spektakulär gescheiterte Projekte unangenehm auf sich aufmerksam.

Abkehr vom Code

Generell gilt: Mit der herkömmlichen Art und Weise des Programmierens, also wesentlich mit dem Erstellen von Code, lassen sich die aktuellen Anforderungen der Digitalisierung – ob mobil oder nicht – nicht mehr erfüllen. Es dauert zu lang und oft fehlen dafür auch geeignete Mitarbeiter.

Einen neuen Paradigmenwechsel – nicht hinsichtlich der Codierung, sondern der Entwicklungsmethodik – brachte erst in jüngster Zeit das Konzept der agilen Entwicklung, das nicht zuletzt durch den stark wachsenden Bedarf an mobilen Applikationen gepusht wurde. Gerade agiles Entwickeln macht eine sehr enge Verzahnung von Business und Softwareentwicklung unerlässlich.

Der 2014 von Forrester eingeführte Begriff “Low Code” beschreibt einen alternativen Ansatz der Softwareentwicklung: Anwendungssoftware wird – anders als Systemsoftware – künftig grundsätzlich nicht mehr codiert, sondern aus fertigen Komponenten zusammengebaut. Der Schwerpunkt liegt dabei auf dem Design der Oberfläche und den Prozessen, alles Weitere erledigt die Plattform automatisch im Hintergrund.

Die Entwickler kommen nicht mehr aus der IT, sondern explizit aus der Fachabteilung: Die sogenannten Citizen Developer sind technisch affine Mitarbeiter, die vor allem über fachliche Kompetenz verfügen. Sie sind nach entsprechendem Training in der Lage, ohne Hilfe der IT selbst Modelle erstellen und in lauffähige Anwendungen zu überführen. Es liegt auf der Hand, dass diese Art der Softwareentwicklung deutlich schneller und damit effizienter ist, als herkömmliches Programmieren. Die Projektdauer liegt hier nicht mehr bei einem Jahr, sondern vielleicht bei zwei Monaten.

Das Verfahren ist im Prinzip nicht ganz neu, denn zum Beispiel 4GL-Sprachen sind ähnlich vorgegangen. Doch hier lag der Fokus auf den Daten und der Datenbank, die Lösungen waren statisch und konnten komplexe Workflows kaum abbilden. Low-Code- und No-Code-Plattformen orientieren sich dagegen an den Workflows von Business-Prozessen und eigenen sich damit besonders für Lösungen im Case Management oder für CRM-Anwendungen.

Typische Vertreter des Low-Code-Ansatzes sind OutSystems oder Appian. Noch einen Schritt weiter geht die Pega-7-Plattform, die sich das Konzept des “No Code” auf die Fahnen geschrieben hat. Hier wird gar nicht mehr programmiert, sondern nur noch modelliert und konfiguriert. Den eigentlichen Code generiert die Plattform automatisch – in diesem Fall Java, Java Script HTML5 oder XML. Der Citizen Developer bekommt ihn gar nicht mehr zu Gesicht. Hinreichend verbreitet könnten Low-Code und No-Code den Bedarf an guter Software endlich zeitnah stillen. Nicht zuletzt weil der Citizen Developer die herkömmliche Lücke zwischen IT und Fachabteilung gar nicht erst entstehen lässt.