TeamBank-IT: Tranchieren und servieren

Gastbeitrag von Rolf Kintscher und Jürgen Brandt, Partner bei Senacor

Die TeamBank will sich zu einem ständigen Liquiditätsbegleiter entwickeln, ihren Kunden also immer und überall Geld anbieten. Wenn sie es brauchen. „Freiheit im Portemonnaie“ sozusagen. Damit die Bank das servieren kann, haben wir gemeinsam mit adorsys und den tollen Kolleg:innen vor Ort zunächst die Kern-IT in Scheiben geschnitten – tranchiert, wie die Gourmets sagen – und das Institut ready for Open Banking gemacht.

Open Banking für Ratenkredite

Via API stellt die TeamBank in erster Linie für die Kunden der genossenschaftlichen FinanzGruppe ihre Produkte und Services bereit. Die Idee: Wenn jemand etwas finanzieren will, überprüft die TeamBank auf Wunsch gleich mit, ob derjenige auch mehr als den angefragten Betrag bekommen kann. Die Finanzreserve lässt sich auch zusätzlich zu anderen Produkten anfragen. Beispielsweise mit einem Girokonto zusammen, das jemand bei einer Partnerbank eröffnet. Anschließend richtet die TeamBank die Finanzreserve mit bis zu 25.000 Euro ein. Wird die Summe oder ein Teil davon per App, telefonisch oder online abgerufen, wandelt sich diese Finanzreserve in einen easyCredit. Liquidität auf Knopfdruck. Ganz einfach.

Kunden bietet das viele Vorteile. Sie müssen keinen Papierkram mehr erledigen, wenn sie im Kaufhaus vor dem Sofa stehen, das sie sich schon immer gewünscht haben, oder statt grauer Betonplatten doch lieber das etwas teurere Terrakotta im Garten verlegen wollen. Ihre Daten können sie auch für sich behalten, weil Scoring und Kreditentscheidung schon vorliegen. Die Kunden brauchen nur noch auf ihr Smartphone tippen und das Geld fließt in Echtzeit auf das Konto, per Instant Payment.

Um genau dieses Services anbieten zu können, war es notwendig, den Java-Monolithen aufzubrechen, der alles, was mit dem easyCredit zu tun hatte, in sich trug und eng mit anderen Anwendungen verwoben war.

Vom Monolithen zu Modulen

Heute steht die IT-Landschaft weitgehend modularisiert dar. Über ein API-Gateway steuern die beiden zentralen Portale – eins für den B2B-Vertrieb über die Partnerbanken, Filialen und den eigenen Vertrieb und eins für die B2C-Kanäle wie den Online-Direktvertrieb – die jeweils benötigten Dienste an (vgl. Abb. 1). Dazu gehören vor allem die Verkaufsstrecken für den easyCredit und die neue Finanzreserve sowie der Bestand und das Account Management. Wo sich diese drei Bereiche überschneiden, arbeiten heute APIs. Früher war die Logik teilweise so stark über die beteiligten Systeme verteilt, dass sie sich insgesamt nur noch sehr aufwendig pflegen und kaum skalieren ließ.

Das zu lösen, ohne von vornherein das komplette System neu entwerfen, ist eine besondere Herausforderung. Gemeinsam haben wir uns deshalb dafür entschieden, den wesentlichen Kern der gesamten IT-Architektur – die easyCredit-Anwendung – nach und nach von allen anderen Systemen abzutrennen, wie in einem Sarkophag zu konservieren, und erst dann die zentrale Anwendung neu aufzubauen. Diese Methode erlaubt es, ein besonders kritisches System in kleinen Schritten statt in einem hochgradig riskanten „Big Bang“ zu migrieren. Modul für Modul. Das lässt sich übrigens auch mit jenen Kernbanksystemen so machen.

Inzwischen routet die TeamBank immer mehr Geschäft auf die neue Antragsstrecke um. Bei den Umsystemen hat sich darüber hinaus auch eine Menge getan. Alle Module lassen sich von jeweils unabhängigen Teams einzeln verwalten, anpassen und auch erweitern. Dafür setzt die Bank auf OpenShift als Container-Plattform. Vom zentralistischen zum föderalistischen Staat, so das Motto. Inwieweit die einzelnen Module noch weiter modularisiert werden, bis hin zu einer möglichen Microservices-Architektur, entscheiden die einzelnen Teams jetzt selbst. Sie sind nicht mehr abhängig von einer übergeordneten Struktur, sondern arbeiten auch insofern hundertprozentig in einem Self Contained System.

Als einzigem „Querlieger“ ist das Identity Access Management übriggeblieben und, wenn man so will, die Datenanalyse.

Agilität statt großer Knall

Insgesamt erfüllt das Projekt die drei goldenen Regeln: Hybrid, modular und kein großer Knall. Hybrid heißt, erhalten, was sich bewährt hat, und neu entwickeln, was mich von der Konkurrenz unterscheidet – hier die geschäftskritischen Abläufe rund um den easyCredit, die neue Finanzreserve und die API-Plattform, durch die sich die TeamBank für neue Wege zum Kunden öffnet. Modular, weil jedes Geschäft inzwischen davon abhängt, schnell auf das, was im Markt passiert, reagieren zu können. Und ohne großen Knall, um punktuell an den Systemen arbeiten zu können. Darüber hinaus wäre es auch nicht konsequent, die gesamte Organisation auf agile Teams zu trimmen und die IT zu modularisieren, das darüber liegende Projekt aber wieder ganz klassisch zu planen.

Was sich nicht nur technisch, sondern auch kulturell bei der TeamBank getan hat, erzählt der Leiter Software-Entwicklung sowie stellvertretender Bereichsleiter bei der TeamBank Alexander Rudat im Interview mit dem IT Finanzmagazin. Wir freuen uns sehr darüber, gemeinsam mit ihm und seinem Team sowie den Kolleg:innen von adorsys über inzwischen mehr als zehn Jahre so vertrauensvoll zusammenzuarbeiten und mit der neuen IT-Architektur auch in den kommenden Jahren maßgeblich zur Wertschöpfung der TeamBank beizutragen.

Interesse an den technischen Details?

Im adorsys Gastbeitrag hier gibt’s einen tieferen technischen Einblick in die Springboot Migration als Sprungbrett in die Open Banking Welt.