Low Code in der Bankenwelt – ein Zombie? Oder: Wann kommt die Bankenbranche in der Gegenwart an?
Aktuell taucht in den Medien das Schlagwort „Low Code“ auf. Und bei allen „durchs Dorf getriebenen“ Schlagworten sollte der Leser immer skeptisch sein. Deshalb war die erste Reaktion des Autors auch hier: „Wer möchte sich denn hier wieder substanzlos profilieren?“
Aber nach etwas Nachdenken und Recherche sieht das Thema doch nicht so substanzlos aus und ist es meiner Meinung nach wert, genauer betrachtet zu werden.
Was bedeutet ist eigentlich der „Low-Code-Ansatz“?
Im Endeffekt soll dieser Ansatz Fachleute dabei unterstützen, ihre Anforderungen an IT-Systeme schneller umzusetzen. Entsprechende Tools gibt es schon seit den 90er Jahren. Diese Werkzeuge bieten in der Regel über eine grafische Oberfläche die Möglichkeit, die Anwendungslogik einfach zusammenzustellen. Eine gute und kurze Übersicht über die Geschichte dieses Ansatzes ist wie zu erwarten auf Wikipedia zu finden unter:https://de.wikipedia.org/wiki/Low-Code-Plattform.
Wie ist der aktuelle Stand in der Bankenwelt?
Sicher ist es nicht verkehrt, erst einmal Analogien zwischen der Finanzindustrie und dem klassischen Produktionssektor zu ziehen.
In der klassischen Industrie ist es selbstverständlich, dass Produktionsplanung und Produktentwicklung von Mitarbeitern betrieben werden, die zumindest die wesentlichen Prozesse der Produktion kennen und beherrschen, d. h. im besten Falle auch während ihrer Ausbildung an CNC-Maschinen gearbeitet bzw. diese programmiert haben.
Halten wir weiterhin fest: Das eigentliche Produktionsmittel einer modernen Bank ist die IT! Kaum eine Branche, einmal abgesehen von IT-Unternehmen, ist so sehr von der IT abhängig. Geschäfte und Produkte werden von Maschinen produziert.
Schaut man sich allerdings die Skills der dort beschäftigten Mitarbeiterinnen und Mitarbeiter an, stellt man fest, dass hier eine sehr scharfe Trennung zwischen den Beteiligten verläuft:
- Die Produktentwicklung liegt in der Regel in der Hand von bankfachlich und vertrieblich hochkarätig aufgestellten Einheiten, deren IT-Background allerdings sehr gering ausgeprägt ist.
- Die Umsetzung der Anforderungen obliegt in der Regel IT-Fachleuten, die erfahrungsgemäß nur wenig bankfachliches und vertriebliches Know-how haben. Ausnahmen bestätigen die Regel.
Hier kann also der in der Industrie völlig selbstverständliche Prozess der Produktentwicklung nicht genauso funktionieren!
Was kann ein Lösungsansatz sein?
Die Möglichkeit, Bankprodukte schnell direkt durch Fachleute kreieren und testen zu können, könnte die Innovationsfähigkeit der Institute deutlich voranbringen.
Selbstverständlich ist der Low-Code-Ansatz kein Allheilmittel! Denn IT-Fachleute sind weiterhin notwendig, um die entsprechende Infrastruktur bereitzustellen und professionelle Arbeitsweisen aus der IT-Welt in die Fachwelt zu transportieren! Dazu gehören Dinge wie professionelle Testvorgehen, Dokumentation und die Sicherstellung der Wartbarkeit des so produzierten Codes.
Weitere Ansätze: DSL!
Neben dem „klassischen“ Low-Code-Ansatz gibt es inzwischen weitere interessante und in der Praxis angekommene Lösungsansätze, z. B. der Einsatz von „Domain Specific Languages“ (DSL). Hier werden problemspezifische Programmiersprachen erstellt und den Fachleuten bereitgestellt, die sich durch einfache, oft natürlich-sprachliche Konstrukte auszeichnen. Der Umfang der Sprachen ist dabei begrenzt, um Komplexität zu vermeiden. Der Einsatz von Schleifen und anderen aus der Programmierung bekannten Konstrukten ist dabei möglich und bietet damit weit mehr Einfluss als die oft bereits angebotenen klassischen Konfigurationsmöglichkeiten. Natürlich erfordern diese Freiheiten auch entsprechende Schulungen und optimalerweise automatisierte Tests der erzeugten Konstrukte.
Ein System stellt dabei einfach gesagt eine Ablaufumgebung bereit, welche der Fachfrau/dem Fachmann u. a. in der Entwicklung fachliche Variablen und Event-Trigger zu einem Produkt bietet:
- Die Umgebung sorgt z. B. dafür, dass eine eingehende Buchung ein Event auslöst, auf welches über eine in der DSL geschriebene Funktion mit vorgefertigten Bausteinen reagieren kann.
- Weiterhin injiziert die Umgebung die notwendigen fachlichen Parameter bzw. Variablen wie vereinbarte Zinssätze, auf die die „Programmiererin“ zugreifen kann.
- Die Umgebung übernimmt zudem große Teile des Fehlerhandlings, welches wiederum professionell durch IT-Fachleute implementiert und überwacht werden muss.
Als Vertreter dieser Lösungen seien hier mbeddr (http://mbeddr.com) oder JetBrains MPS (https://www.jetbrains.com/mps/) genannt. Weiterhin bietet Groovy als auf Java basierende Scriptsprache interessante Möglichkeiten, eigene DSLs zu entwickeln und damit einen einfachen Einstieg in das Thema.
Fazit
Wollen Banken und Sparkassen dauerhaft ihre Position verteidigen, müssen sie sich nach Meinung des Autors an den Vorgehensweisen der Industrie orientieren, IT-Know-how bei den Fachleuten aufbauen und Instrumente wie DSLs und andere Low-Code-Tools einsetzen. Dieser Wandel wird selbstverständlich nicht einfach zu vollziehen sein, da sowohl die IT-Spezialisten als auch die Produktfachleute ihre Grenzen überschreiten und aufeinander zugehen müssen. Jedoch können beide Seiten mit Sicherheit voneinander profitieren und am Ende innovative und stabile Produkte entwickeln.