Legacy-Systeme basieren oft auf monolithischen Strukturen
In der Vergangenheit bauten Finanzdienstleister ihre IT-Infrastruktur auf Altsystemen und Frameworks auf, die für die Abwicklung bestimmter Geschäftsfunktionen konzipiert waren. Diese Systeme waren oft monolithisch und zentralisiert mit produktorientierten Silos, die das Rückgrat des Betriebs bildeten. Die ESB-Netzwerkarchitektur (Enterprise Service Bus) war die bevorzugte Methode zur Integration verschiedener Geschäftsanwendungen und -dienste in einem Unternehmen. Sie fungierte als zentraler Knotenpunkt, der die Kommunikation und den Datenaustausch zwischen verschiedenen Systemen, Anwendungen und Datenbanken ermöglichte. Softwarearchitekten verwendeten für die Implementierung des ESB meist Mainframes, proprietäre Software und Closed-Source-Frameworks wie IBM Integration Bus (IIB), Oracle Service Bus (OSB) oder TIBCO ActiveMatrix BusinessWorks. Diese Tools wurden eingesetzt, um große Transaktionsvolumina zu verarbeiten und gleichzeitig die Systemstabilität und -zuverlässigkeit zu gewährleisten, die die Grundlage für das Überleben eines Unternehmens bilden, insbesondere im Bankensektor.
Hauptprobleme und Einschränkungen bei ESB-orientierten Architekturen
Mit stetig wachsendem Kundenstamm, Transaktionen und Serviceangebot entstanden neue Abteilungen und Dienste, die unabhängig voneinander betrieben und entwickelt werden mussten. Die heutige, sich schnell verändernde Umgebung erfordert ebenfalls große Flexibilität bei der Kommunikation mit und Integration von verschiedenen Anwendungen und Datenquellen, einschließlich öffentlicher Cloud-Dienste von Drittanbietern wie z. B. AWS (Amazon Web Services). Die Idee von «Smart Endpoints und Dumb Pipes» hat sich durchgesetzt, um Anwendungen schnell zu entkoppeln oder hinzuzufügen, z. B. für Änderungen oder Upgrades, was keine Stärke von SOA (serviceorientierter Architektur) ist. Auch für die Analyse und Verarbeitung großer Datenmengen in Echtzeit, für die Datenpersistenz oder die Datenwiedergabe ist sie wenig geeignet. Angesichts zunehmendem Workload für teure Mainframe-Infrastruktur und der inakzeptablen Verzögerungen durch Batch-Processing sind ESB-Architekturen für Echtzeitanwendungen wie Instant Payments und Betrugserkennung unpraktisch geworden. Darüber hinaus besteht bei proprietären ESBs die Gefahr, dass die Kosten im Laufe der Zeit durch die Anbieterabhängigkeit steigen.
Transformation des Bankwesens mit Real-Time Data Mastery
ESB-Architekturen werden zwar weiterhin nützliche Anwendungen haben, aber es findet ein Wechsel zu datengetriebenen Anwendungen statt, bei denen Datenströme in Echtzeit verarbeitet werden müssen. Die ereignisgesteuerte Architektur (EDA) ist besser geeignet, um diese Anforderungen zu erfüllen; sie fördert eine bessere Entkopplung und Flexibilität zwischen den Diensten, auch mit Legacy- und externen Partnersystemen. EDA ermöglicht Unternehmen, problemlose Änderungen, Weiterentwicklungen und Skalierung, ohne monolithischen Code anzufassen, auf eine zentralisierte Implementierung zu warten oder laufende Systeme zu gefährden. Es ist kein Zufall, dass Apache Kafka, ein quelloffenes, verteiltes EDA-Framework, immer beliebter wird und sich zum Industriestandard für die Live-Datenverarbeitung entwickelt. Neben Schweizer Unternehmen wie z.B. Generali und Ricardo* nutzen auch Finanzdienstleister die Möglichkeiten von Apache Kafka für Sofortzahlungen, zur Betrugserkennung und zur Analyse des Kundenverhaltens in Echtzeit. Sprechen Sie mit uns und finden Sie heraus, wie wir Ihnen helfen können, den digitalen Wandel zu meistern.
*Quelle: https://www.confluent.io/customers/
Frequently asked questions
Ähnliche Artikel
