Türen öffnen mit API-orientiertem Banking
von: Pannerselvam D, AVP, Intellect Design Arena
Cloud-basierte Dienste wie SaaS (Software as a Service), PaaS (Platform as a Service), IaaS (Infrastructure as a Service) und NaaS (Network as a Service) sind zu Schlagwörtern auf dem Markt geworden. Einem Bericht zufolge wird der weltweite Markt für Cloud Computing im Jahr 2020 auf stolze 219 Mrd. US-Dollar geschätzt und dürfte bis 2028 auf 791 Mrd. US-Dollar anwachsen1. Während die Pandemie eine Schlüsselrolle bei der Umstellung der Unternehmen auf die Cloud spielte, gab es noch andere Faktoren, die zu dieser Umstellung beitrugen. Einige davon waren geringere Wartungskosten, eine höhere Akzeptanz von Technologien wie KI und ML sowie eine verstärkte Finanzierung der Cloud durch die Industrieländer.
Auch wenn es für Banken sinnvoll ist, auf die Cloud umzusteigen, um die Skalierbarkeit zu verbessern und den Wartungsaufwand und die Kosten zu reduzieren, ist eine reine Cloud-Migration nicht immer die Lösung. Wenn die Bank wächst, wachsen auch ihre Produkte und die Anwendungen, die diese Produkte unterstützen. Es könnte passieren, dass diese Anwendungen weiterhin in Silos funktionieren. Das bedeutet, dass die Bank standardmäßig nicht den vollen Überblick hat. Es ist nicht nur das, es gibt noch mehr.
Wie sollte sich eine Bank auf eine kontinuierliche Skalierung vorbereiten? Können APIs die Antwort sein?
Wie bereits erwähnt, besteht eines der Hauptprobleme der Banken in der Verwaltung der verschiedenen Arten von Anwendungen in ihrer IT-Landschaft. Wenn es eine größere Anzahl von Anwendungen gibt, dann wird die Verknüpfung dieser Anwendungen zu einer mühsamen Aufgabe. Nehmen wir als Beispiel ein führendes, diversifiziertes Finanzinstitut in der APAC-Region, das sowohl institutionellen als auch privaten Kunden eine breite Palette von Finanzprodukten und -dienstleistungen anbietet. Die Bank hatte mehr als 300 Anwendungen mit verschiedenen Technologien implementiert, die sich alle in unterschiedlichen Phasen befanden. Daher sah sich die Bank mit verschiedenen Schwierigkeiten bei der Verknüpfung dieser Systeme konfrontiert. Einige davon waren:
1. Pflege von mehreren Schnittstellensystemen: Jedes System benötigte seine eigenen Schnittstellenfunktionen für die Verbindung mit verschiedenen anderen nachgelagerten Systemen. Dies führte zur Implementierung ähnlicher Arten von Schnittstellenfunktionen in allen Systemen.
2. Enorme Kosten und Zeitaufwand für jede Änderungsanforderung: Da die Schnittstelle des nachgelagerten Systems geändert wurde, mussten alle Schnittstellenfunktionen der betroffenen Anwendungen geändert werden. Diese Schnittstellenänderungen waren teuer und erforderten längere Implementierungszeiträume.
3. Schwierigkeiten bei der Pflege von Schnittstellendokumenten: Da es viele Anwendungen gab, hatte die Bank Schwierigkeiten, die Schnittstellendokumente für alle diese Anwendungen zu pflegen.
4. Schwierigkeiten bei der Auswirkungsanalyse: Die Bank hatte Schwierigkeiten, die Auswirkungen von Schnittstellenänderungen zu analysieren, und es gab Fälle von Produktionsausfällen aufgrund einer unsachgemäßen Folgenanalyse.
5. Hohe Lizenzkosten: Bei einigen Anwendungen wurden die Schnittstellenfunktionen in einer speziellen Middleware wie JBOSS implementiert, was neben den anwendungsbezogenen Kosten zu zusätzlichen Lizenzkosten für die Bank führte.
APIs können die Antwort auf diese Probleme sein. Eine API ist ein Satz von Regeln, die Computer oder Anwendungen anleiten, miteinander zu kommunizieren. APIs fungieren als Vermittlungsschicht zwischen der Anwendung und dem Webserver und verarbeiten den Datentransfer zwischen den Systemen2.
Externe API-Drehscheibe: Diese Schicht umfasst API-Container für jedes Frontend-System, das von der Bank, ihren Tochtergesellschaften und anderen Fintech-Unternehmen angeboten wird. Der Zweck dieser Schicht besteht darin, die funktionalen Anforderungen des Frontend-Systems umzusetzen und jegliche Logik im Frontend-System zu vermeiden. Dies kann auch als Backend für das Frontend-System bezeichnet werden.
Die Funktionen des externen API-Hubs umfassen:
Autorisierung: Autorisierung des API-Zugriffs der einzelnen Frontend-Systeme mit Red Hat Single Sign-On.
Aggregation: Aufrufen mehrerer interner APIs und Aggregation der Ergebnisse für das Frontend-System.
Transformation: Umwandlung von Anfrage- und Antwortnachrichten entsprechend den Anforderungen des Frontend-Systems, wie Filter, Formatierung von Daten, Nachrichtenkonvertierung usw.
Cache: Bereitstellung von Parametern oder statischen Daten für das Frontend-System.
2. Interner API-Hub: Diese Schicht umfasst API-Container für jeden Produktprozessor oder jedes Backend-System. Der Zweck dieser Schicht ist die Bereitstellung von Standard-APIs durch Transformation. Im Falle eines Geldautomaten werden die Nachrichten beispielsweise zu Standardisierungszwecken vom ISO-Format in das JSON-Format umgewandelt.
Dieses neue API-Hub-Design hilft der Bank bei:
Standardisierung von API-Schnittstellen: API Hub stellte sicher, dass alle API-Schnittstellen das JSON-Format haben und dem Standard-API-Design folgen. Dies half den Entwicklern, die Spezifikation und Verwendung der API leicht zu verstehen.
Record Maintenance: Die Spezifikationen aller APIs wurden konsolidiert und als Teil von API Hub gepflegt, so dass sie für jedermann leicht zugänglich sind.
Reduzierung der Lizenzkosten: Die APIs wurden im Apache Camel-Framework entwickelt und als Microservices in der RH OpenShift Container-Plattform bereitgestellt. Dadurch konnten die Lizenzkosten für einzelne JBOSS-Instanzen, die für die Schnittstellenfunktion der Anwendung benötigt werden, reduziert werden.
Auswirkungsanalyse und Änderungsanforderungen: Gemäß dem API-Hub-Design wurden die Anwendungen mit einem System (API-Hub) verbunden, anstatt mit mehreren nachgelagerten Systemen verbunden zu sein. Daher konnten Auswirkungsanalysen und Änderungsanfragen reibungslos gehandhabt werden.
Leistungsverbesserung: Das API-Hub-Design trug dazu bei, die TAT der Frontend-Funktionen zu reduzieren, anstatt mehrere APIs vom Frontend-System aus aufzurufen. Nehmen wir das Beispiel des Geldtransfers: Verschiedene Validierungen, AML-Prüfungen, Kontolimits und OTP wurden durch parallele API-Aufrufe geprüft und dann wurde der eigentliche Geldtransfer eingeleitet. Parallele API-Aufrufe halfen, die Verarbeitungszeit für jeden Vorgang zu verkürzen.
Schlussfolgerung
Die Banken der Zukunft würden nicht nur unsere Bank- und Anlagebedürfnisse befriedigen, sondern als One-Stop-Shop für alle Bedürfnisse rund ums Geld fungieren. Wie die Cloud ist auch eine API keine Universalpille für die digitale Transformation. Banken sollten in Cloud-native Plattformen investieren, die umfassend, zukunftssicher, skalierbar und agil sind.
Quellen
1. https://www.fortunebusinessinsights.com/cloud-computing-market-102697
2. https://www.ibm.com/cloud/learn/api
Teilen Sie
