Mehr Flexibilität durch serviceorientierte Architekturen

Mehr Flexibilität durch serviceorientierte Architekturen. Auch in Banken können serviceorientierte Architekturen helfen, ­Anwendungen flexibel zu verbinden. Dadurch lassen sich fachliche und technische ­Anforderungen und damit Business und IT besser in ­Einklang bringen.

Mehr Flexibilität durch serviceorientierte Architekturen

Der deutsche Bankenmarkt unterliegt in den nächsten Jahren durch Fusionen, Kooperationen, Gewinnung von Großkunden und Sourcingstrategien wei­terhin starken Veränderungen. Ein Wandel, der auch die Anpassung und Optimierung der IT-Strategien notwendig macht. Die neuen Business-­Szenarien erfordern die Anbindung bisher unverbundener Systeme. Innerhalb einer Bank sind die Systeme der verschiedenen Geschäftsbereiche bereits mehr oder minder stark verbunden. Organisatorische Veränderungen erfordern jedoch gravierende Änderungen in den Prozessen, etwa bei der Ausgründung einer Transaktionsbank. Teilprozesse werden dann durch Kooperationspartner abgewickelt. Der erforderliche Neuzuschnitt der IT-Landschaft und die Veränderungen in einzelnen Systemen sollen in ihren Auswirkungen kontrollierbar und lokal begrenzt bleiben.
Beide Anforderungen, Integration und Entkopplung, lassen sich mit einer serviceorientierten Architektur (SOA) abdecken. Durch das Service-Enabling von Legacy-Anwendungen und den Aufruf der entstandenen Service-Funktionen durch neue Service-Nehmer können Systeme integriert werden, ohne zu starke Abhängigkeiten zu erzeugen. Wird das Service-Enabling innerhalb eines Systems auf dessen Komponenten angewandt, kann von einer intransparenten anwendungsinternen Integration auf Funktionsaufrufe umgestellt werden. Dadurch werden Anwendungsteile entkoppelt. Sie sind dann unabhängig voneinander änder- und austauschbar.

Anwendungsintegration in zwei Dimensionen
Die Geschäftsbereiche einer Bank bringen typischerweise verschiedene Voraussetzungen für die Umsetzung von Integration und Servicefähigkeit mit. Im Core Banking bestehen die zentralen Abwicklungsfunktionen aus einer kleinen Zahl komplexer und untereinander vergleichsweise stark integrierter Hostanwendungen. Im Investment Banking hingegen herrschen Einzelanwendungen vor, die in der Regel bereits untereinander und mit den Abwicklungssystemen der Bank lose integriert sind. Bei Filialanwendungen schließlich werden dezentrale Anwendungen mit Zugriff auf die zentralen Abwicklungs- und Stammdatensysteme in Multikanalstrategien genutzt.
Verallgemeinert lässt sich der Grad der Anwendungsintegration in einem Geschäftsbereich in zwei Dimensionen darstellen: dem Grad der Zergliederung und der Stärke der Integration. Zu ­beachten ist, dass die Integration ins­besondere bei komplexen Individual­anwendungen auch über die Daten­ebene stattfinden kann, ohne dass API-Aufrufe zu einer Anwendung verwendet werden. Daher müssen bei einer Ent­kopplung von Anwendungen in Un­ternehmen mit einem integrierten ­Datenhaushalt auch das logische und das physische Datenmodell entkoppelt werden.
Die Kommunikation zwischen Softwarekomponenten kann in verschiedenen Ebenen kategorisiert werden. SOA befasst sich primär mit der Kommunikation zwischen Unternehmen und Service-Domänen. Die Kommunikation innerhalb einzelner Service-Domänen wird von der SOA nicht definiert. Mit Fortschreiten der SOA-Umsetzung können auch einzelne Anwendungen und deren Komponenten innerhalb einer Service-Domäne servicefähig werden. Das Ebenenkonzept ist wichtig, um mit dem Service-Enabling auf dem richtigen Level zu beginnen.

Übersicht