Porträt

Von Cobol in die Cloud: Wie diese Estin Banken aus dem IT-Mittelalter führt

Vilve Vene, CEO und Co-Founderin von Modularbank. (Foto: Vilve Vene)

Lesezeit: 9 Min.
Artikel merken

Veraltete Systeme und große Legacy-Codebases sind ein Problem, das die Finanzwelt seit Jahren umtreibt. Vilve Vene hat Erfahrung mit deren Modernisierung und weiß: Der Code ist nur ein Teil des Problems.

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.

Ein Treffen in Coronazeiten

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.

Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

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.“

Die damalige Hardware: Mainframes

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.

Kaum Legacy-Code in Estland

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.

30 Jahre Erfahrung mit Legacy-Systemen

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.

Wie modernisiert man eine Bank?

„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.“

Digitale Transformation heißt die eigentliche Challenge

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.“

Fass ohne Boden

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.

Es geht nicht nur um die Software

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.“

Ebenfalls interessant: Nachhaltige Investments: Was steckt hinter Conscious Fintechs?

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.

Das könnte dich auch interessieren

Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

4 Kommentare
egal
egal

C ist von Anfang der 70er.

Antworten
W
W

Super Artikel, danke dafür!

Antworten
davidmueller85
davidmueller85

Und weshalb nutzt man Cobol? Soweit ich weiß hat Cobol durchaus seine Berechtigung und es gibt auch entsprechende Nachfolgesprachen. Ich kann nicht programmieren bzw. kenne die Hintergründe leider nicht gut genug, aber ich glaube es hatte etwas mit Gleitkommazahlen zu tun. So sind andere Programmiersprachen auf 3-5 Nachkommastellen genau, Cobol speichert aber die Bruchzahlen und errechnet das Ergebnis immer wieder neu. So oder so ähnlich. Wäre schön wenn der Artikel auf sowas eingegangen wäre. https://www.theverge.com/2020/4/14/21219561/coronavirus-pandemic-unemployment-systems-cobol-legacy-software-infrastructure https://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b

Antworten
ZEP
ZEP

Ich bin kein Cobol-Programmierer, möchte aber mal für diese Partei ergreifen. Klar kann man Spaghetti-Code programmieren und sicher gibt es auch Cobol-Monolithen. Die meisten Programmierer beherrschen aber ihren Job und produzieren gute, performante und auch lesbare Programme. Es gibt zum Beispiel Objektorientiertes Cobol. Das Cobol in vielen Ausbildungsgängen nicht mehr gelehrt haben nicht die Programmierer zu verantworten. Das liegt mehr daran, dass die Verantwortlichen Cobol nicht mehr „sexy“ finden.

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!

Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Digitales High Five
Holger Schellkopf (Chefredakteur t3n)

Anleitung zur Deaktivierung

Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder