Instant-Entwicklung vs. funktionale Programmierung Grenzen der Low-Code-Entwicklung

Der Low-Code-Ansatz verspricht die Erstellung von Anwendungen nach dem Baukastenprinzip. Ist das noch klassische Programmierung? Nein, soll es auch nicht sein. Funktionale Programmierung wird den Geschäftsanforderungen in der Praxis meist besser gerecht.

Der Low-Code-Ansatz ist quasi die Instant-Wundertüte der Anwendungsentwicklung. Packung auf, ein paar Standardzutaten mixen und fertig ist die Anwendung. Vorgefertigte Komponenten aus dem Baukasten machen aufwändige manuelle Kodierung überflüssig.

Kurzfristig betrachtet mag das Ergebnis durchaus respektabel sein, doch langfristig kann der Aufwand steigen. Geschäftsanwendungen bleiben meist deutlich länger im Einsatz, als bei der Entwicklung vorgesehen. Anforderungen und Prozesse ändern sich mit der Zeit.

Die dann erforderlichen nachträglichen Anpassungen an einer aus Fertigbasteinen bestehenden Anwendung sind jedoch aufwändiger als Eingriffe in einer herkömmlichen Softwarearchitektur. Hier setzt die funktionale Programmierung an, die Effizienzvorteile des Low-Code-Ansatzes aufgreift, aber eingebettet in einer robusten Softwarearchitektur herkömmlicher Machart.

Low-Code-Baukastenprinzip geht zurück auf 4GLs

Low-Code-Plattformen stellen standardisierte Bausteine bereit und leiten den Benutzer, der nicht unbedingt hochqualifizierter Entwickler sein muss, durch alle Schritte bis zur fertigen Anwendung. Das Prinzip basiert auf visueller Modellierung auf einer grafischen Oberfläche, auf der die Anwendung zusammengestellt und konfiguriert wird.

Ebenso wie ein Nichtschwimmer im seichten Bereich eines Gewässers bleibt, begibt sich der Low-Code-Entwickler nicht in die Tiefen der Programmierung, sondern hält sich an Bausteinen fest, die als Schwimmhilfen dienen. Das Low-Code-Prinzip sieht zudem vor, möglichst große Bereiche durch vorgefertigte Komponenten abzudecken und die eigentliche Entwicklung auf individuelle Funktionsmerkmale zu reduzieren.

Dieser Ansatz geht zurück auf 4GLs, Programmiersprachen der vierten Generation, die in den 1980er und 1990er Jahren aufkamen. Ziel war es, den Entwicklern grundlegende Funktionen von Softwareanwendungen zur Verfügung zu stellen und den Programmieraufwand erheblich zu reduzieren. Im Fokus standen Anwendungen für die Dateneingabe, Speicherung in Datenbanken, das erneute Abrufen der Daten und die Verarbeitung zu Reports.

Excel und Access als Programmierhilfe

Ein weiterer Versuch, ohne größeren Programmieraufwand auszukommen, war und ist der Einsatz von Excel oder Access auch für komplexere Aufgaben im Unternehmen. Mehr Möglichkeiten hierfür bot ab 1993 VBA (Visual Basic for Applications), eine Programmiersprache zur Steuerung von Office-Programmen. Mit dem Einzug von VBA-Code in Excel-Sheets konnte nun durchaus von einer Art von Programmierung die Rede sein.

Die Euphorie wurde gedämpft, als klar wurde, dass die Möglichkeiten von Excel ausgereizt waren. Dies gilt insbesondere für die Prozessautomatisierung in größerem Stil, die Bewältigung größerer Datenmengen und die Integration in die übrige Geschäftsumgebung. Geschäftsprozesse, die jahrelang mit Excel bewältigt wurden, auf vollwertige Geschäftsanwendungen zu übertragen, gestaltete sich als aufwändig.

Etwa zur gleichen Zeit, ab 1992, brachte Microsoft mit Access ein Datenbankprogramm heraus, das auch als Programmierhilfe dienen konnte. Auf einer grafischen Oberfläche war es relativ einfach möglich, aus Datenbank-Schemata eine CRUD-Anwendung für die für die grundlegenden Datenmanagementoperationen „Create, Read, Update, Delete“ zusammenzustellen. Wie bei Excel stand jedoch eine aufwändige Migration an, sobald gestiegene Geschäftsanforderungen den Funktionsumfang überforderten.

Der Traum vom „Entwickeln ohne Programmieren“

Die Vision vom „Entwickeln ohne Programmieren“ – oder zumindest ohne viel Programmierarbeit – blieb bis heute bestehen. Er erlebte zuletzt sogar eine Renaissance in Form der heutigen Low-Code-Plattformen. Low-Code-Plattformen ermöglichen es, auf einer grafischen Umgebung Applikationen aus Blöcken zusammenzubauen und zu konfigurieren.

Die meist Web-basierten Anwendungen oder mobile Apps sind für den Betrieb in der Cloud vorgesehen. Sie lassen sich bequem von der Entwicklungsplattform direkt in die Cloud transferieren und in Betrieb nehmen. Dieser Ansatz rationalisiert zweifelsohne viele Standardprozesse, die bei der herkömmlichen Programmierung so anfallen.

Die Gestaltung grafischer Oberflächen oder die Anbindung an Datenbanken erfolgt unkompliziert per Mausklick. Dies macht Low Code zu einer Art Cloud- und Enterprise-fähiger 4GLs, ohne die eingeschränkte Skalierbarkeit von Access und Excel, jedoch nicht völlig ohne Einschränkungen. Geht es über die Eingabe, Wiedergabe und das Reporting von Tabellendaten hinaus, stößt auch Low Code an seine Grenzen.

Object-Relational Mappers (ORMs) wie eine Java-Version von TopLink ab 1996 waren der Versuch, dieses Problem zu lösen. Die für gängige objektorientierte Programmiersprachen verfügbaren ORMs sollten möglichst viele Prozesse bei der Abbildung von Domänenobjekten auf die Datenbank automatisieren.

Dies hatte jedoch zur Folge, dass das Datenbankmodell mit dem Datenmodell fest verbunden ist, so dass mögliche Probleme sich auf beiden Seiten bemerkbar machten. Parallel zum Code-Volumen nahmen mitunter auch die Probleme zu. Schwächen bei der Modellierung, ein kaum zu kontrollierendes Cache-Verhalten, das aufwändige Debugging und Änderungsmanagement führten auch die ORMs letztlich aufs Abstellgleis.

Das Bessere ist des Guten Feind

Der Ansatz, ähnliche Komponenten vieler Anwendungen immer wieder zu nutzen, ist gut, doch nicht zu Ende gedacht. Erstere Einschränkung dürfte bereits zu Beginn eines Entwicklungsprojekts darüber entscheiden, ob es mittels Low Code überhaupt machbar ist. So sind mit Low Code nur Anwendungen innerhalb eines vorgegeben Schemas realisierbar.

Dies kann zu Beginn des Anwendungszyklus den aktuellen Anforderungen durchaus gerecht werden. Viele Unternehmensanwendungen werden jedoch nicht wie vorgesehen in den Ruhestand geschickt, sondern bleiben weitere Jahre im Einsatz und müssen dann fit gemacht werden für neue Anforderungen. Genau diese Anpassungen sind aufgrund des geringen Abstraktionsgrads von Low-Code-Anwendungen schwierig.

Es gibt auch einen anderen Ansatz, weniger Code zu produzieren: die funktionale Programmierung. Funktionaler Code fällt zwei- bis 15-mal kürzer aus als entsprechender objektorientierter Code. Dank des dennoch hohen Abstraktionsgrads und der flexiblen Verwendung von Komponenten verbindet dieser Ansatz Programmiertiefe und Effizienz in einer robusten Softwarearchitektur.

Nicht umsonst etabliert sich die funktionale Programmierung derzeit als zeitgemäße Herangehensweise an die Softwareentwicklung. In Verbindung mit der bereichsspezifischen Modellierung ist die funktionale Programmierung sowohl effizienter als auch besser anpassbar an individuelle Geschäftsanforderungen.

Funktionale Programmierung erweist sich als effizient und robust

Funktionale Programmierung richtet sich nicht nur an versierte Programmierer, denn sie ist auch für IT-Allrounder relativ leicht erlernbar. Sie bietet ein effizientes und robustes Gerüst für den erweiterten Lebenszyklus einer Anwendung – von der Idee, über die Entwicklung und den produktiven Einsatz bis hin zur späteren Anpassung. Genau dieser ganzheitliche Aspekt ist es, der diesem Ansatz gegenüber Low-Code-Plattformen einen strategischen Vorteil verschafft.

* Dr. Michael Sperber ist Geschäftsführer der Active Group GmbH und international anerkannter Spezialist für funktionale Programmierung. Er besitzt über 25 Jahre Erfahrung in der praktischen Software-Entwicklung für die unterschiedlichsten Anwendungsgebiete und hat das Konzept der Grundausbildung für den Studiengang Informatik an der Universität Tübingen entworfen.

(ID:46574419)