GASTBEITRAG: Das Problem der Banken mit uralten IT-Systemen

Falls Sie ein IT-Profi sind und sich strickt weigern, für eine Bank zu arbeiten, dann kenne ich wahrscheinlich den Grund dafür. Sie werden sicherlich vom Horror der „Legacy-Systeme“ gehört haben. Vieles wurde darüber geschrieben, aber nicht alles stimmt.

Ich habe mein gesamtes Berufsleben in der IT-Abteilung großer US-Banken verbracht. Die meisten Programmierungen, die ich gesehen habe, haben einen Modultest und eine gründliche Prüfung durchlaufen und lassen sich daher vergleichsweise leicht implementieren. Die Qualität der einzelnen Anwendungen steigt. Doch darunter versteckt sich oft noch ein Uraltcode.

Wieso die Legacy-Codes ein so großes Problem darstellen

Um zu verstehen, wieso Banken ein so großes Problem mit ihren Altsystemen haben, müssen Sie erst einmal verstehen, wie sie strukturiert sind.

Die IT-Abteilungen gehören mittlerweile zu den personalintensivsten Bereichen einer Bank. So stellen IT-Fachkräfte etwa ein Viertel der gesamten Goldman Sachs-Belegschaft dar und JP Morgan beschäftigt 50.000 Mitarbeiter in ihrer IT.

Damit ist die IT-Abteilung von JP Morgan größer als diejenigen von Facebook und Uber zusammen. Die meisten Probleme von Banken sind technisch vergleichsweise simpel, aber funktional extrem schwierig. Die meisten Banker besitzen tausende von Entwicklern, die in Silos organisiert sind. Jedes davon versucht, ein großes funktionales Problem zu lösen. Dies stellt den historischen Grund dafür dar, dass die Systeme so grundverschieden und anfällig sind.

Welche Probleme die Altsysteme für eine Bank darstellen, lässt sich daran illustrieren, wie schwierig es für Großbanken ist, einen einzigen Trade zu buchen. Es ist schon erstaunlich, mit welcher Zahl an Systemen und Anwendungen dieser im Laufe seines Lebenszyklus zu tun bekommt. Der Trade wird aus unterschiedlichen Gründen diverse Male modelliert, was aus allen Richtungen gespeist wird. Wenn Sie ein Diagramm über all die Zusammenhänge zeichnen wollen, dann sieht das wie abstrakte Kunst aus. Die inneren Zusammenhänge, Verknüpfungen und die organisatorische Komplexität machen das System anfällig und einen Systemwechsel schwierig. Daher kann es zu einem Schmetterlingseffekt in der gesamten Bank führen, wenn Sie ein Altsystem abzulösen versuchen.

Zu welchen Problemen sich das auswachsen kann, zeigt das Beispiel der britischen Bank TSB. Diese wollte von ihrem Kernbankensystem, welches von ihrem früheren Eigner Lloyds Bank Group stammte, zu dem ihres neuen Eigentümers Sabander wechseln. Das folgende Chaos ließ den Aktienkurs von Sabadell um 4 Prozent einbrechen.

Doch ein solcher Wechsel ist nicht nur schwierig, sondern auch aus finanziellen und operationellen Gründen riskant.

Banken können ihre Altsysteme nicht einfach abschalten

Die Probleme werden noch durch den Umstand verschlimmert, dass die Banken ihre Altsysteme nicht einfach abschalten können.

So hat sich Google kürzlich dazu durchgerungen, Google+ dichtzumachen. Damit wurden eine gesamte Produktlinie und das dazugehörige Ökosystem einfach unter den Teppich gekehrt. Also braucht das Programm auch keine Wartung mehr. Einen solchen Luxus besitzen die IT-Teams der Banken nicht.  Die meisten Systeme der Banken wurden geschaffen, um interne Geschäftsabläufe zu automatisieren und das stellt eine langlebige Angelegenheit dar. Alte Systeme herauszunehmen und abzuschalten, ist sehr teuer, weshalb meist gilt: „Solange es noch funktioniert, lassen wir es weiterlaufen.“ Dies ist der Grund, wieso man so viele jahrzehntealte Cobol-Systeme oder andere veraltete Technologien in den Banken findet.

Da hilft es auch nicht weiter, dass Banken meist von ehemaligen Tradern und Investmentbankern gemanagt werden, die in keine IT-Systeme investieren wollen, wenn sich die Investitionen nicht unmittelbar, sondern in Jahren auszahlen.

Altsysteme stellen auch ein politisches Problem dar

Das Problem mit den Altsystemen wird durch den ständigen Wechsel in den IT-Teams der Banken nur noch verschlimmert. Ich habe schon miterlebt, wie umfangreiche Anwendungen nach den Vorstellungen des Front Office in London und New York geschaffen und implementiert wurden. Anschließend wurde das IT-Team reorganisiert oder aufgelöst und die Anwendung an ein anderes Team in Indien übergeben, ohne einen ausreichenden Wissensaustausch.

Besonders problematisch wird es, wenn IT-Führungskräfte wie z.B. Managing Directors die Bank verlassen. Die neuen Mitarbeiter bringen ihre eigenen Vorstellungen mit, weshalb die bereits entwickelten Anwendungen und Plattformen nicht weiterverfolgt werden.

Wie die Banken versuchen, von Altsystemen loszukommen (und ihre IT-Jobs interessanter zu machen)

Die Banken wissen mittlerweile, wie abschreckend die Altsysteme auf neu einzustellende IT-Profis wirken. Keiner möchte an einem System mit hunderten von verwirrenden und veralteten Abhängigkeiten arbeiten.

JP Morgan ist dabei schon weiter. Die Bank hat recht erfolgreich ein Programm mit dem Namen „Kill the tail“ durchlaufen. Dabei handelte es sich um ein bankweites IT-Projekt, bei dem unnötige Systeme identifiziert und abgeschaltet oder aber auf neu geschaffene Lösungen verlagert wurden.

Die Deutsche Bank hat ein ähnliches Programm angestoßen und erntet jetzt die ersten Früchte. Dies belegt, dass die Rationalisierung von Anwendungen und Infrastruktur sich finanziell auf lange Sicht auszahlt.

Ich persönlich denke, dass in diesem Fall die Conway-Folge gilt: „Organisationen, die Systeme entwerfen… sind dazu gezwungen, solche Systeme zu entwerfen, die Kopien der Kommunikationsstrukturen ihrer Organisationen darstellen.“ Auch wenn die Bankchefs gerne sagen, sie seien Tech-Unternehmen, solange sie an ihren alten Organisationsstrukturen festhalten, sind sie zu unglaublich komplizierten IT-Systemen verdammt.

Wenn ich ein Bankchef wäre, dann würde ich mir eine der erfolgreichen Direktbanken zulegen und mir anschauen, wie sich eine Retailbank vom Grund auf aufbauen lässt, um eine große Zahl von Kunden und Produkten zu bewältigen.

Bei Sam Garrett handelt es sich um ein Pseudonym. Er arbeitet als Entwickler für eine Bank in London.