ICLAAP – eine Chronik der (technischen) Entwicklungsarbeit

Das movisco-Simulationstool „ICLAAP“ ist nun schon seit einiger Zeit live und wir haben dazu schon einiges an positivem Feedback und Kommentare bekommen. Es soll hier nochmal ein kleiner Einblick in den Entwicklungsprozess (mit Fokus auf die technische Seite) gegeben werden, sodass man ein Bild davon bekommt, wie ein kleines Projekt (inkl. Probleme) innerhalb der movisco AG ablaufen kann.

Am Anfang war die Idee. Die zwei Prozesse „ICAAP“ und „ILAAP“ sind schon lange bekannt, aber die Wechselwirkung zwischen beiden wird selten betrachtet. Diese Interdependenzen zu berücksichtigen, würde einen wesentlichen Beitrag für eine genauere Kapital- und Liquiditätsplanung leisten, und um dies zu veranschaulichen, sollte dies in einem Simulationstool grafisch visualisiert werden und dieses sollte als eine Light-Version auf der Website für die Allgemeinheit bereitgestellt werden. Ein ungefähres Ziel war also klar, eine grobe Vorstellung zur Visualisierung gab es auch – man muss dies nur noch umsetzen.

Zuallererst ist das wichtigste Element aufzutreiben, damit man so ein Projekt starten kann: qualifizierte Personen. Da diese Idee im „Team Gesamtbanksteuerung“ entstand und dort das fachliche Know-how und Interesse verfügbar war, war diese Voraussetzung schnell gelöst. Da für die gesamte Umsetzung fachliches, aber auch technisches Wissen notwendig ist, wurden die verfügbaren Ressourcen so aufgeteilt, dass jeder seine Stärken voll einbringen kann. Außerdem wurden regelmäßige Meetings festgelegt, damit die Verzahnung beider Seiten gut funktioniert und Entscheidungen bei Veränderungen auch schnell als Team diskutiert werden konnten, und andere organisatorische Themen wie z.B. Zeitrahmen (in dem Fall sechs Monate) besprochen.

Da der Verfasser dieses Texts, also ich, die einzige Person mit Erfahrung bei der Implementation von kleineren Programmen hatte, war die Entscheidung leicht, dass ich für die technische Umsetzung zuständig sein würde. Da anfangs der Fokus auf der fachlichen Analyse, bei der die notwendigen Voraussetzungen, aber auch Eingrenzungen und Annahmen für die Light-Version, erarbeitet werden, liegen würde, galt es auf technischer Seite zu überlegen, mit welchen Mitteln dies umzusetzen ist. Man könnte das komplette Simulationstool über Excel veranschaulichen oder man kann auch andere Anwendungen, die sich auf Visualisierungen spezialisiert haben (wie Microsoft Power BI) nutzen, doch aus Performanzgründen und auch, um weniger Restriktionen zu unterliegen, wurde sich schnell dagegen entschieden. Das Tool sollte eher als eigenständiges Programm entwickelt und in die Website eingebettet werden. Da es schon Vorerfahrungen mit der Programmiersprache „Python“ gab, lag es nahe, genau dieses Werkzeug zu nutzen. In diesem Blogbeitrag wurde empfohlen, die Mittel zu nutzen, die sich am besten eignen und mit denen man am besten umgehen kann. Die gewählte Programmiersprache ist performant und flexibel genug, dass sie die gewünschten Anforderungen erfüllt. Außerdem ist diese so weit ausgebaut, dass Schnittstellen zu anderen möglichen Programmiersprachen mit hoher Wahrscheinlichkeit vorhanden sind.

Die Website liegt nicht in der Hand vom „Team Gesamtbanksteuerung“. Es galt also, die gewünschte Vorgehensweise mit dem Webentwickler zu besprechen. Hierfür wird in der Regel ein sehr rudimentäres Minimalbeispiel programmiert, sodass man anhand dessen die Problemstellungen diskutieren kann. Und ein Problem ergab sich direkt, denn eine Einbettung von Python in eine Website scheint nicht so leicht oder nur sehr aufwendig möglich zu sein, da ausgerechnet in diesem Fall eine Schnittstelle nicht direkt vorhanden ist. Es wurde also nahegelegt, eine andere Art der Umsetzung zu wählen.

Es stellt sich also nun die Frage: Überlegt man sich einen anderen Weg, d.h. man nutzt ein anderes, passenderes Werkzeug (in dem Fall wurde die gängigste Programmiersprache für Webanwendungen, Javascript, empfohlen), oder folgt man dieser Empfehlung nicht und geht den aufwendigen, aber immer noch möglichen Weg? Ersteres würde bedeuten, etwas komplett neu zu erlernen; zweiteres wäre bequem, da rudimentärer Quellcode für das Simulationstool nun schon vorhanden ist, und man nichts Neues erlernen muss, sondern einfach die eigenen Kenntnisse in der Programmiersprache für die Problemlösung nutzt. Dies wäre besonders im Hinblick auf die Projektlaufzeit ein Vorteil, während beim alternativen Weg der Umfang an Aufwand nicht so leicht abzuschätzen ist. Zeit war zwar noch genügend vorhanden, aber da dieses firmeninterne Projekt zu den normalen Projekten kam, konnte sich das schnell ändern.

Da beide Optionen ihre Vor- und Nachteile hatten, basierte die Entscheidung letztendlich auf dem Grundsatz „Warum nicht beides?“. Nichts wird von Anfang an ausgeschlossen, sondern man führt ein kleines Experiment durch. Man versucht also, Javascript zu erlernen bzw. das vorhandene Minimalbeispiel in dieser Sprache zu reproduzieren und setzt sich hierfür einen Zeitrahmen. Das Ergebnis muss dann zwecks Machbarkeit nochmal mit dem Webentwickler besprochen werden. Falls dieses Vorgehen an einer der beiden Bedingungen scheitert, geht man auf die andere komplexere, aber sicherere Option.

Und der Rest der technischen Entwicklungsarbeit ist Geschichte und Programmierarbeit mit all ihren Höhen und Tiefen: Das Minimalbeispiel in Javascript konnte erfolgreich erstellt werden, die Einbettung wurde vom Webentwickler bestätigt und das rudimentäre Beispiel wurde Schritt für Schritt um die aus der fachlichen Analyse geforderten Funktionen erweitert, bis man nun den Zustand hat, an dem Fehlerbehebungen und das Aufpolieren von bestehenden Funktionen und Elementen die Einführung dieser übertreffen und sich die Light-Version des Simulationstools, was auf den Namen „ICLAAP“ getauft wurde, eher über Feedback von Testern und Nutzern weiterentwickelt.

Dieses ist nun auf der Landing Page des Fachbereichs „Gesamtbanksteuerung“ zu sehen. Es gilt nun als abgeschlossen. Dieses wird also, außer es treten größere Probleme auf, nicht mehr weiterentwickelt. Der Fokus liegt nun auf der Weiterentwicklung der ausführlichen Simulationstools. Doch trotz alledem sind Sie eingeladen, selbst mit der Anwendung herumzuspielen. Falls Sie dazu Fragen oder Anmerkungen haben oder sogar einen Bug finden, dann sprechen Sie uns gerne darauf an!