Ein Großteil der IT des Finanzsektors weltweit läuft auch heute noch auf Cobol, einer Programmiersprache, die es bereits seit den 60er Jahren gibt. Gewartet werden diese Systeme oft von Programmierern, die kurz vor dem Ruhestand stehen, angefasst wird der Legacy-Code nach Möglichkeit nicht.

Vilve Vene kämpft gegen alten Code: Die 58-jährige Estin ist CEO und Mitgründerin des estnischen Fintechs Modularbank und hat die Mission, die mittelalterliche IT-Welt der Banken die moderne Cloud zu überführen. Eine Mammutaufgabe, bei der Vene immer wieder feststellt: Am Ende geht es gar nicht nur um Software, die Aufgabe ist größer.

Vene hat Erfahrung mit der Modernisierung von Finanzsystemen, leistete in den 90er Jahren Pionierarbeit im Bereich Onlinebanking und modernisierte das estnische Steuersystem. Lange bevor Fintech ein gängiger Begriff wurde, entwickelte sie bereits innovative Finanztechnologien. Im Gespräch mit t3n erklärt sie, warum eine Modernisierung der alten Legacy-Systeme so schwierig umzusetzen ist und welchen Ansatz sie dabei verfolgt.

Ich treffe die lebhafte Estin in einem Zoom-Call, die Corona-Pandemie inklusive Ausgangsbeschränkungen ist in vollem Gange, an ein persönliches Treffen nicht zu denken. Für einen Tag Anfang Mai ist es ungewöhnlich kalt. Vene sitzt mir in einem ledernen Sessel gegenüber, im Hintergrund brennt ein Kaminfeuer, die eine Wand, die ich über das Zoom-Fenster sehen kann, ist holzvertäfelt. Ebenfalls zugeschaltet ist Venes deutschsprachiger Consultant, der das Treffen organisiert hat. Er wird sich das Gespräch über im Hintergrund halten.

Sie habe Mathematik studiert, erzählt Vene auf die Frage, wie sie zur Finanz-IT kam. Algorithmen und Logik waren Teil des Studiums. Auch Programmieren habe dazugehört. Ihre Augen blitzen, sie rückt etwas näher an die Kamera, während sie erzählt: „An der Universität lernten wir zuerst Assembler, eine sehr alte, maschinenorientierte Programmiersprache. Mir hat die Arbeit damit großen Spaß gemacht – Assembler ist eine Programmiersprache, bei der man immer exakt sehen kann, was welche Eingaben wo in einem System bewirken.“

Als nächstes lernte sie Fortran, eine Programmiersprache, die ein ähnliches Alter aufweist wie Cobol, die Programmiersprache, auf der seit den 70er Jahren ein signifikanter Teil der Finanz-IT basiert. In den ersten drei Jahren ihres Berufslebens programmierten Vene und ihre Kollegen vornehmlich in Fortran – auf Mainframes. Estland befand sich damals unter sowjetischer Besatzung. Das Aufkommen der ersten Desktop-PCs Ende der 80er Jahre änderte alles, erinnert sie sich. Neue Programmiersprachen kamen auf. Mit der neuen Hardware wurde Programmieren auf einmal sehr viel interaktiver, als das zu Zeiten der Lochkarten der Fall war: „Man konnte Befehle tippen und hatte auf einmal einen Bildschirm.“ Ende der Achtziger wurde C, eine Programmiersprache aus den Siebzigern, die heute immer noch verwendet wird, immer populärer. „Ich habe all diese Veränderungen mitgemacht“, sagt Vene.

Cobol, das schlecht gealterte Sorgenkind der Finanz-IT, hat die Estin nie gelernt. Zu ihrer Studienzeit hatte man die Programmiersprache bereits aus dem Curriculum der Universitäten verbannt. Die meisten Cobol-basierten Systeme wurden in den 70er Jahren entwickelt. Über die nächsten 20 Jahre vergrößerten sich die Code-Monolithen, Features wurden ergänzt und umgeschrieben, Bugs gefixt – oft ohne, dass jemand sich berufen fühlte, Änderungen zu dokumentieren. In westlichen Ländern gibt es zusammengenommen etwa zwei Milliarden Zeilen Cobol-Code, den heutzutage niemand mehr anrühren will.

In Estland nicht: Als 1991 das Baltikum seine Unabhängigkeit von der Sowjetunion wiedererlangte und die estnische Republik gegründet wurde, waren viele Prozesse innerhalb des kleinen Staates noch nicht digitalisiert, Datenerfassung und dergleichen hatten bisher in Papierform stattgefunden. Aufstrebende neue Geschäftsmodelle und Neugründungen entstanden ohne jede technologische Basis, auf der sie aufsetzen konnten, „aus dem Nichts“, beschreibt Vene die damaligen Zustände. Auch der öffentliche Sektor war eine Leerstelle innerhalb der neugegründeten Republik: „Wir hatten Glück, dass wir dieses Cobol-Erbe nicht hatten. Wir konnten komplett bei Null anfangen. Weil damals kein Geld da war, mussten wir Esten unsere Systeme selbst bauen, wir hatten gar keine andere Wahl“, erklärt sie.

Ihrem Lebenslauf entnehme ich, dass sie über mehr als 30 Jahre Erfahrung mit der Modernisierung von Finanzsystemen verfügt. Ich frage, wie denn so eine Transformation eines auf Cobol basierenden Systems überhaupt abläuft.

„Wie gesagt: Ich habe nie mit Cobol entwickelt“, stellt Vene noch einmal klar. „Aber natürlich hatten wir Kunden, Banken, die Cobol inhouse in Verwendung hatten“, sagt sie. „Natürlich ist es ein Problem, dass es keine Programmierer dafür gibt. Aber das ist nicht der Punkt! Wir können neue Programmierer ausbilden. Wir können ihnen ein gutes Gehalt anbieten, dann werden sich schon Entwickler finden, die bereit sind, sich auf die Sprache einzulassen. Das wird uns mittelfristig aber nicht weiterbringen. Diese Technologien sind so alt, sie erfüllen unsere heutigen Anforderungen nicht mehr.“

Venes Stimme ist anzuhören, dass das genau ihr Thema ist: „Man nehme nur einmal Time-to-Market im Bankensektor“, sagt sie. Neobanken können schnell und agil handeln, traditionelle Banken nicht. Datenbasierte personalisierte Services, Datenanalyse und der Einsatz von KI oder auch das plattformübergreifende Zusammenspiel mit Angeboten und Plattformen anderer Unternehmen – all das sei unmöglich mit in Cobol gecodeter Software, die auf Mainframes basiert. Cobol wird in sogenannten Batches prozessiert. „Wie sollen da Onlineservices in Echtzeit möglich sein?“, fragt sie, nur um sich die Frage gleich selbst zu beantworten: „Gar nicht, das ist schlicht nicht darstellbar.“

Lies auch: Senior Programmer händeringend gesucht – für 60 Jahre alte Programmiersprache

Es gebe aber noch einen anderen Aspekt, spricht die mehrfache Gründerin weiter. Die Code-Monolithen, an denen über Jahrzehnte weitergeschrieben wurde, seien riesig. Cobols Syntax lade förmlich dazu ein, Spaghetti-Code zu schreiben: „Modularität und komponentenbasierte Programmierung waren damals noch kein Thema. Sie schüttelt lebhaft den Kopf. Neue Programmierer hätten kaum eine Chance zu verstehen, wie sich eine Änderung an einer Stelle innerhalb eines solchen Programms auf den Rest des System auswirkt – letztlich sei das der Grund, warum die Leute soviel Angst davor hätten, den Legacy-Code anzufassen.

„Okay“, sage ich. „Aber wie macht man das dann, wie modernisiert man eine Bank?“

„Da gibt es verschiedene Herangehensweisen. Vielleicht sollte ich zuerst erzählen, wie eine solche Modernisierung meistens angegangen wird. Sehr verbreitet sind Compiler, die Cobol zu Java übersetzen. Oder Cobol zu C.“ Am Anfang ihrer Karriere habe sie selbst mit einem solchen Compiler gearbeitet – er übersetzte Fortran zu C-Code. Aber was dabei herauskam, war kein C, es war Fortran, geschrieben in C – metaphorisch gesprochen natürlich. „Nimmt man ein altes, in Cobol geschriebenes System und überträgt es in Java, bekommt man ein System, das genau gleich strukturiert ist wie das alte Cobol-basierte System. Damit ist niemandem geholfen“, ist Vene überzeugt.

Welche Herangehensweise sie stattdessen empfiehlt? „Angenommen, wir wollen ein sehr altes, sehr großes System auf einmal modernisieren. Diese Herangehensweise würde ich nicht empfehlen, aber angenommen, der Kunde will es so, das ist die Vorgabe. Das Beste, was wir dann tun können, ist Folgendes: Wir müssen zunächst verstehen, wofür das System überhaupt gut ist, es starten, uns anschauen, was es macht.“

„Und dann?“

„Man darf bloß nicht anfangen, es in einer anderen Programmiersprache nachzubauen oder es zu übersetzen. Angenommen, die zentrale Aufgabe des Systems ist die Handhabung von Kompositen. Dann schauen wir uns an, welche Komponenten wir dafür brauchen. Und dann bauen wir diese Funktionalität komplett neu, ohne die Architektur des alten Systems zu berücksichtigen. Diese Legacy-Systeme bestehen aus Tausenden Zeilen Code. Heutzutage können wir dasselbe oft mit einer moderneren Sprache in wenigen Zeilen Programmcode sehr elegant lösen.“

Die Challenge, der sich traditionelle Finanzinstitute stellen müssen, ist die der digitalen Transformation. Das ist den Banken auch seit Jahren klar, um das Thema gab es über die letzten Jahre immer wieder ordentlich Buzz. Nur – getan hat sich nichts. Die Codebases sind riesig, die Entwickler, die an ihrer Erstellung beteiligt waren, bereits im Ruhestand und eigentlich weiß keiner mehr, was genau drinsteckt. Vor Jahren fingen einige Banken an, ihre Legacy-Systeme durch ein Bankingsystem namens Temenos zu ersetzen, auch T24 genannt. „Verglichen mit den Cobol-Monolithen der 70er mag T24 ein modernes System sein, im Anbetracht heutiger Anforderungen hat es dieses Attribut nicht mehr verdient“, sagt Vene. Außerdem ist es sehr komplex. Es steckt eine Menge Power dahinter. Die Implementation ist entsprechend mühsam und zeitaufwendig. Einige dieser Projekte laufen bereits seit mehreren Jahren, bis zur Fertigstellung sind weitere Jahre veranschlagt. „Innovation und Weiterentwicklung für fünf bis acht Jahre zu stoppen, um ein solches System zu implementieren, ist einfach unrealistisch“, erklärt sie. „Software ist schnelllebig. Alles auf einmal ersetzen zu wollen, ist die falsche Herangehensweise.“

Mit ihrem aktuellen Startup, ein Fintech namens Modularbank, verfolgt sie deshalb einen anderen Ansatz: „Wir gehen eine solche Modernisierung schrittweise an. Ein Kunde von uns, eine große finnische Bank, bei dem machen wir das so. Anstatt uns komplett von deren Legacy-System zu trennen, nutzen wir die neue cloud-basierte Plattform einfach parallel dazu. Wir haben einige Pilotprojekte mit Verbraucherkreditprodukten auf der neuen Plattform und testen, wie das läuft. Diese neuen Plattformen haben den Vorteil, dass sie modular sind. Sie sind API-basiert und leicht zu integrieren. Das ist ein absolutes Muss: Es muss möglich sein, die neue Plattform mit der alten zu integrieren, je granularer, desto besser. Ansonsten kommt wieder Spaghetti-Code dabei heraus. Momentan arbeiten wir an zwei Verbraucherkreditprodukten, die demnächst auf der neuen Plattform live gehen sollen. Bis Ende des Jahres wollen wir dann alle Verbraucherkreditprodukte von der alten Plattform auf die neue migriert haben. Wir machen das Schritt für Schritt, nicht in einem Rundumschlag, der dann am Ende acht Jahre dauert. Teile des Systems belassen wir wie sie sind, alles, was nicht in Echtzeit passieren muss, kann vorerst bleiben wie es ist.“

2014 hatte die Commonwealth-Bank of Australia ihre Systeme zu einem cloud-basierten Ansatz migriert. Auf die immensen Kosten des Projekts angesprochen, sagt Vene, sie kenne die genauen Hintergründe nicht. Grundsätzlich komme es auf die gewählte Plattform an, auf deren Alter, und darauf, wie flexibel sich diese konfigurieren lässt: „Es gibt Plattformen, die die Komponenten für die einzelnen Funktionalitäten bereitstellen. Alles zusammenfügen, konfigurieren und anpassen muss die Bank dann selber. Das kostet viel Zeit und Geld, weil die IT der Bank das System am Ende quasi selber bauen muss.“

Vene empfiehlt deshalb, sich die Plattform sehr genau anzuschauen. Abzuwägen, welche Komponenten man wirklich brauche. Software sei heute nicht mehr so monolithisch wie früher und für unterschiedliche Zwecke gebe es unterschiedliche Software. „Diese Software macht bereits das, was man will, man muss nicht mehr alles selbst entwickeln. Die Integration der einzelnen Komponenten ist aber nach wie vor sehr anspruchsvoll.“ Der Leitspruch bei einem solchen Projekt sollte immer sein: „Business first“. Wenn man das beim Design eines neuen Systems nicht berücksichtige, könne die eingesetzte Technologie noch so modern sein, am Ende wird aus so einem Projekt trotzdem ein Fass ohne Boden.

Ich will wissen, wie lang so eine Modernisierung im Schnitt dauert. „Das kommt auf die Größe der Bank an. Ich sage meinen Kunden immer, dass die IT nur etwa 20 Prozent der Anstrengung ausmacht. Man kann die Plattform aufsetzen, alle Features implementieren, die man haben will, und wird trotzdem noch lange nicht fertig sein. Man muss auch die Prozesse modernisieren. Cobol wird in Batches prozessiert. Moderne Systeme funktionieren ganz anders. Entsprechend müssen auch die Workflows innerhalb der IT – oder eigentlich die des ganzen Unternehmens modernisiert werden. Man kann diese Aufgabe nicht einfach an ein Entwickerteam abgeben und sagen: ‚Modernisiert die Systeme‘. Man muss auch Arbeitsprozesse und Teams, eigentlich die komplette Organisation modernisieren.“ In einem anderen Projekt mit einem anderen Kunden habe sie für ein solches Transformationsprojekt ganze drei Jahre gebraucht. „Ginge es nur um die technische Umsetzung, hätten wir das theoretisch in sechs Monaten geschafft“, sagt sie. Die restlichen zweieinhalb Jahre dauerte es, Arbeitskultur und Unternehmensorganisation zu modernisieren.

In Zukunft werde es noch viel stärker darauf ankommen IT, Management und alle anderen Bereichen eines Unternehmens so eng wie möglich zu verzahnen, davon ist Vene überzeugt. Auch deshalb findet sie es so wichtig, dass IT fächerübergreifend an Hochschulen unterrichtet wird: „Informationstechnologie ist heutzutage überall, dem sollten die Lehrpläne Rechnung tragen.“

 

Hinweis: In einer früheren Version des Artikels hieß es, die Programmiersprache C sei in den Achtzigern aufgekommen. Das ist falsch, wir bitten den Fehler zu entschuldigen.