PRODUKTE6. Mai 2020

IBM Financial Services Workbench – will Banken und Versicherer in eine moderne API-Ökonomie bringen

Die schlechten Nachrichten für Finanzinstitute scheinen nicht abzureißen. Geschäftsmodelle stehen auf dem Prüfstand, und damit einhergehend stellen sich Fragen, wie die nach der richtigen Anzahl an Filialen, der zu bedienenden Kanäle oder der passenden Qualifikationen der Mitarbeiter. Gleichzeitig steigen die Anforderungen für IT-Abteilungen dramatisch. Nun will IBM mit der Financial Services Workbench helfen.

IBM Financial Services Workbench
IBM
In der Realität setzt die überwiegende Anzahl der Finanzinstitute nach wie vor auf monolithische Anwendungen, angereichert mit Insellösungen oder nachträglich implementierten Funktionalitäten, denen wiederum eine gemeinsame Datenbasis oder standardisierte Schnittstellen fehlen. Jede Änderung an den bestehenden Strukturen birgt das Risiko in sich, andernorts Schwierigkeiten zu produzieren. Der Ausweg aus diesem gewachsenen Dickicht ist eine API-Ökonomie, die auf Micro-Services aufsetzt und auf DevOps setzt.

Applikationslandschaft nach Microservices-Architektur

Allerdings sei damit die Frage nach dem „Wie“ nicht beantwortet, sondern führe vielmehr auf eine weitere Abstraktionsebene: Ist ein IT-Stratege an diesem Punkt angelangt, stellt sich zwangsläufig die Frage, wie Funktionen systematisiert, zusammengefasst und gegliedert werden können. Gefragt sei letztlich eine modulare Abbildung aller Schritte einer Geschäftsfunktion. Ist diese Übung einmal absolviert, lassen sich auf den entstandenen Modulen eigene Services entwickeln, sowie Services von Dritten einbinden und nutzbar machen. Dann erst folgt der Schritt, auf dieser Basis produktive, sichere und robuste Anwendungen zu gestalten und einzuführen. Am Ende dieser Überlegungen steht die Vision einer Applikationslandschaft, die gemäß Microservices-Architektur aufgebaut ist. Fachliche Domänen werden analog eines entsprechenden fachlichen Referenzmodells gestaltet und als Applikation zur Verfügung gestellt, selbstverständlich cloud-native. Durch einen solchen Ansatz ist es zudem möglich, bereits von Beginn an Prinzipien der Open Architecture zugrundezulegen. Damit ist die nachträgliche Implementierung, Änderung oder Löschung von Services – eigenen oder solchen von Drittanbietern – ohne Schwierigkeiten möglich.

Soweit die Blaupause.

Um dies allerdings umzusetzen, fehlt es in aller Regel an vielem: Zeit, Budget und nicht zuletzt technisch entsprechend versiertem Personal, das mit den Möglichkeiten und der Schnelligkeit, in der heute neue Technologien und Frameworks veröffentlicht und verfügbar gemacht werden, umgehen kann.“

Schließlich ist der Lernaufwand erheblich, und das Kuratieren der verschiedenen Frameworks und nicht zuletzt die Kenntnis über deren Kompatibilität zueinander erfordern sehr viel Zeit und Know-how.

Gemeinsame Vorgaben versprechen schnelle Erfolge

Die IBM Financial Services Workbench (Website) nehme sich nun dieser Herausforderungen an. Die Grundmotivation der FSW (IBM Financial Services Workbench) sei es, die Zeitspanne von Produktidee über Umsetzung bis hin zur Inbetriebnahme für Banken auf ein Minimum zu reduzieren.

Um dies zu erreichen, setzte die FSW dabei auf die Prinzipien der Microservices-Architektur und der Cloud.
Der Einstieg erfolge über den FSW Solution Designer. Hier könnten Business-Architekten und Entwickler gemeinsam nach den Prinzipien des Domain Driven Designs an der Business Logik und dem Design der Applikation arbeiten. Konkret legen beide beispielsweise gemeinsam fest, welche internen und externen Schnittstellen es bereits gibt oder implementiert werden müssen, welche Datenobjekte ein Service voraussetzt, welche Zustände diese Datenobjekte haben müssen und welche Events Änderungen dieser Zustände auslösen.

Die Auflistung ist nicht abschließend, aber sie zeige den Weg der gemeinsamen Entwicklung. Als Ergebnis steht ein Domain-Modell, das die grundlegenden Architekturbausteine der neuen Applikation beschreibt. Dieses Domain-Modell wird im nächsten Schritt von der FSW automatisch in Software-Code übersetzt. Ein Entwickler, der an dieser Stufe einsteigt, übernimmt den erzeugten Software-Code in die Entwicklungsumgebung seiner Wahl und vervollständigt die technische Implementierung.

Bereits vorab seien gemeinsam definierte Vorgaben von Business Architekt und Entwickler festgelegt, denen der automatisch generierte Code folgt, das verkürze die Abstimmungsdauer rapide. Zugleich lassen sich auch Entwicklerstunden einsparen: Zeitraubende und abstimmungsintensive Arbeiten wie das Design von Schnittstellen, von Datenmodellen oder die Festlegung des präferierten Kommunikationsmodells sind bereits an die automatisierte Codeerstellung der FSW ausgelagert. Nach Abschluss dieses Schritts kümmere sich der FSW Solution Hub um den Build und das Deployen des Service zu einem oder mehreren Containern. Dieser beherbergt die CI/CD Pipeline und verantwortet die Lifecycle-Governance. Als Runtime-Environment setzt die FSW auf Red Hat Openshift.

Software-Entwicklung mit Tempo – und automatischem Code

Der wichtigste Vorteil dieses neuen Vorgehens der Software-Entwicklung liege in der Verkürzung der Entwicklungszeit von modernen Microservices-Architekturen. Daneben gäbe es aber noch weitere Vorzüge. Das gemeinsame Arbeiten am Grunddesign, verknüpft mit der automatisierten Code-Erstellung, senke die Einstiegshürde auch für Mitarbeiter, die keine oder nur wenig Erfahrung im Design und der Entwicklung von Cloud-native Applikationen mitbringen und andernfalls Orientierung in einer Vielzahl von Frameworks und Plattformen benötigen. Das vorgegebene Framework und die Code-Generatoren legen die grundlegende Architektur der Anwendung bereits zu großen Teilen automatisiert fest. Diese größere Gleichförmigkeit erleichtert auch spätere Wartungen.

Ein weiterer Vorteil: Die Plattform setzt auf state-of-the-art-Technologien, ausgewählt und kuratiert von Experten. Dies erleichtert Banken einerseits die Orientierung unter den zahllosen Möglichkeiten, andererseits sind so Funktionalität, Kompatibilität und Leistungsumfang bereits präzise definiert – und zwar nicht nur für den Moment. IBM stellt sicher, dass diese im Rahmen der FSW weitergepflegt und verfügbar gemacht werden, und auch, dass die FSW weiter um Frameworks oder Technologien ergänzt wird, sollten sich diese etablieren.

Durch die so entstehenden Architekturen könnten laut IBM auch Banken neue Angebote in eigene Leistungsportfolios einbinden, die sonst teure Eigenentwicklungen erfordern würden und infolge der Aufwände vermutlich gar nicht erst umgesetzt würden. Schritt für Schritt entstünde so allmählich eine moderne, zukunftsfähige Banken-IT-Infrastruktur, ohne dass sich Banken dafür komplett neu erfinden müssen und auf diesem Weg riskieren würden, ihr wertvollstes Asset zu verspielen: Das Vertrauen ihrer Kunden.aj

 
Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/105120 
 
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (4 Stimmen, Durchschnitt: 4,00 von maximal 5)
Loading...

 

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

ARUG II: Wie Depotbanken die Kommunikationsflut in den Griff bekommen

Einladungen zur Hauptversammlung und weitere wichtige Informationen von börsennotierten Gesellschaften werden ab September über die Ländergrenzen hinaus übermittelt. Dafür sorgt die neue Aktionärsrichtlinie ARUG II,...

Schließen