Ratepay erneuert selbst entwickeltes Kernsystem

Fintechs und Startups genießen den Ruf, besonders flexibel zu sein und wegen ihrer agilen IT etablierten Unternehmen das Leben schwer zu machen. Einer der Gründe: veraltete IT. Doch die digitalen Angreifer bemerken nicht immer, dass sich auch ihre vermeintlich moderne IT selbst in Legacy verwandeln kann.

Wie Legacy-IT entsteht

Legacy-IT ist wie ein großes Wollknäuel. Wer an einem Faden zieht, kann kaum noch vorhersagen, was dann passiert. In der IT entstehen solche Situationen, wenn Entwickler nah an der Kernlogik programmieren und das IT-Knäuel dadurch immer komplexer machen. Anfangs mag das noch okay sein, damit neue Features zügiger online gehen. Wer sich bewusst auf diese technischen Schulden einlässt, kann sich kurzfristig tatsächlich Vorteile verschaffen, wie etwa eine schnellere Time-to-Market. Entscheidend ist aber, einmal aufgenommene Schulden auch wieder zu tilgen. Sonst droht eine IT, die sich immer schwerer warten lässt, in der sich Fehler häufen und die immer mehr Zeit beansprucht.

Ratepay blieb davon nicht verschont. Das Angebot richtet sich zunächst vor allem an Online-Händler, die ihren Kunden möglichst viele Zahlungsarten anbieten möchten, darunter auch den Kauf auf Rechnung und in Raten. Weil solche Forderungen manchmal offen bleiben, suchen sie nach Partnern, die ihnen dieses Risiko abnehmen und zudem die nachgelagerten Prozesse für sie abwickeln. Dafür muss Ratepay diese Risiken in Echtzeit bewerten, damit die Kunden ohne zu warten ihre Einkäufe abschließen können. Das System fragt zu diesem Zweck Daten bei den einschlägigen Auskunfteien ab, setzt aber auch auf eigene Methoden und Machine Learning, um selbst für so unterschiedliche Warengruppen wie Flugtickets, Möbel oder Bekleidung schnell entscheiden zu können, ob ein Risiko übernommen wird oder nicht.

Schwierigkeiten bereitete jedoch zunehmend das selbst entwickelte Kernsystem, das über ein Jahrzehnt lang gewachsen ist und die nachgelagerten Abläufe steuert. Dazu zählt etwa, an welcher Stelle das Kundenlogo auf der Rechnung erscheint und ob Kunden gesiezt oder geduzt werden. Das Kernsystem berücksichtigt auch unterschiedliche Gebührenstrukturen, bereitet Daten auf und gibt sie an angeschlossene Systeme weiter. Mit der Zeit wurde all das ziemlich unübersichtlich. Darum  sollte das System abgelöst werden. Bei der Ausschreibung hat sich bewährt, in erster Linie das Problem genau zu beschreiben (vgl. Kasten) statt sich von vornherein auf eine bestimmte Lösung festzulegen. Dadurch hat das Projektteam gleich mehrere Vorschläge bewerten und sich sicher sein können, eine dem aktuellen Stand der Technik entsprechende Architektur aufzubauen.

Das Kernsystem aufbauen

Ein Kernsystem selbst zu entwickeln, bedeutet vor allem, sich für die richtige Architektur zu entscheiden. Das setzt jedoch voraus, zu verstehen, welche fachlichen Anforderungen abzubilden sind. Das Problem: Während der Startup-Phase wurden die einzelnen Programmteile aus dem ersten System nicht vollständig dokumentiert. Das Projektteam musste deshalb mehr als 200.000 Zeilen SQL-Code lesen, um die damals abgebildete Fachlichkeit zu rekonstruieren und gleichzeitig die teils ineinander verwobenen Abläufe zu entflechten. Daraus entstand ein Prozessmodell, das sich in fachlich eng gekapselte Aufgabenblöcke aufteilen und in einzelnen Microservices beschreiben ließ.

Jeder Microservices erfüllt eine genau festgelegte Aufgabe. Das macht sie leicht zu warten und zu erweitern. Beispielsweise nimmt die Payment-API in Echtzeit Aufträge von einer Händler-Webseite entgegen und beauftragt spezielle Microservices damit, Schufa-Abfragen einzuholen das Risiko zu kalkulieren und zu entscheiden, ob einem Kunden erlaubt wird, seine Bestellung auf Rechnung oder in Raten zu bezahlen. All das läuft in weniger als einer halben Sekunde ab. Sobald ein Händler die Ware versendet, starten die weniger zeitkritischen Microservices im sogenannten Downstream. Ein Event Bus verteilt die anfallenden Daten ereignisgesteuert zwischen den Diensten (vgl. Grafik).

Im Downstream laufen alle Dienste ab, auf die der Händler nicht mehr in Echtzeit angewiesen ist, nachdem ein Kunde seine Bestellung also aufgegeben hat. Dazu gehört beispielsweise, Gebühren und Ratenpläne zu berechnen, Rechnungen und Mahnungen zu verschicken sowie Buchungen in SAP vorzunehmen und das Cash Management abzuwickeln. Ein Händlerportal ist ebenfalls im Downstream-Bereich angesiedelt. Als letztes Erbstück des Legacy-Systems haben die Entwickler im Frühsommer den Datenbank-Monolithen abgeschaltet und ein neues Data Warehouse für das Reporting eingerichtet.

Know-how absichern

Die asynchrone Architektur des neuen Kernsystems bietet viele Vorteile. Einzelne Services lassen sich nacheinander aufschalten. Während des Projekts hat das eine Migration in kleineren Schritten ermöglicht und das Risiko verringert, das mit einem Big Bang häufig einhergeht. Zudem lässt sich das System einfacher erweitern und anpassen, weil nur die jeweils unmittelbar betroffenen Dienste angefasst werden müssen und nicht gleich die ganze Plattform stillsteht, falls etwas anzupassen ist. Um unabhängig zu bleiben, empfiehlt sich sicherstellen, dass noch während des laufenden Projekts das nötige Know-how in die Organisation einfließt (Ownership).

Modular zu arbeiten, passt darüber hinaus zu agilen Methoden. Microservices erlauben, große in kleine Aufgaben zu zerlegen, um zügiger zu ersten Ergebnissen zu gelangen. Solche Kleinstdienste lassen sich zudem auch zwischendurch in Betrieb nehmen, um zu beobachten, wie sich das System insgesamt verhält. Etwaige Fehler fallen so früher auf und das Team kann leichter daraus lernen. In der Software-Entwicklung gilt „fail fast“ als ein Prinzip, das auch einzelnen Teams helfen kann, aus starren Strukturen auszubrechen. Häufig stehen Monolithen nicht nur in der IT, sondern auch in Organisation – und behindern dort die besten Ideen.

Fünf Regeln für das Legacy-Retirement

1. Beschreiben Sie das Problem und nicht die Lösung: Sagen Sie, was Sie beschäftigt und bewerten Sie anschließend, was Ihnen mögliche Dienstleister vorschlagen zu tun.
2. Holen Sie sich das richtige Operationsbesteck: Machen Sie sich vorher klar, wie viel Zeit, Geld und welche Fähigkeiten Sie im Team brauchen, damit das Projekt aufgeht.
3. „Say no by default“: Halten Sie sich möglichst eng an den festgelegten Scope und lassen sich nicht zu viel zusätzlich aufladen. Das verzögert Projekte oder lässt sie gar scheitern.
4. Machen Sie extern eingekauftes Know-how zu Ihrem eigenen: Stellen Sie Ihr Team aus internen und externen Experten zusammen und sorgen Sie dafür, dass die Organisation später die Hoheit beziehungsweise die Ownership über die Weiterentwicklungen hat.
5. Vermeiden Sie den „Big Bang“: Nach und nach zu migrieren, lässt sich leichter planen und viel einfacher wieder rückgängig machen, falls etwas schiefläuft.