Über die Schweizer Finanz-IT schwappt die Gesamtbankenlösungswelle. Dabei werden nicht nur die in die Jahre gekommenen Kernbankensysteme ausgewechselt, sondern parallel dazu die ganze Applikationslandschaft modernisiert. Für die jeweiligen Verantwortlichen bedeutet dies in erster Linie Architekturplanung. Die Anwendungslandschaft soll so gestaltet werden, dass neue Anforderungen und Techniken oder allenfalls künftig ausgelagerte Services möglichst flexibel eingebunden werden können.
Markus Freuler, bei der Raiffeisen Informatik AG, der IT-Dienstleistungstocher der Raiffeisen-Gruppe, für die Applikationen zuständig, will für diese Aufgabe auf der Grundlage von SOA (Service-oriented Architecture) und MDA (Model Driven Architecture) eine generische Software-Architektur-Roadmap schaffen. Diese soll es ihm ermöglichen, die wichtigen, denkbaren strategischen Entscheide, die an bestimmten Punkten durch die Geschäftleitung gefällt werden, mit möglichst wenig Aufwand umsetzen zu können. Die Roadmap ist Teil des 2003 gestarteten Projekts Rainova, mit der sich Raiffeisen bis 2010 eine flexible Integrationsplattform schafft.
Die heutige Applikationslandschaft der Raiffeisen-Gruppe kann grob in fünf Bereiche eingeteilt werden. Das Corebanking-System BOSS sowie die Spezial- und Führungssysteme werden dabei zentral betrieben. Demgegenüber betreiben die 420 Mitgliedsbanken der Genossenschaft mit ihren rund 1200 Geschäftsstellen die von Raiffeisen selber entwickelte Gesamtbankenlösung DIALBA2000 jeweils vor Ort, genauso wie ihre eigenen Spezial- und Führungssysteme. Als fünfter Bereich kommen schliesslich Leistungen dazu, die von externen Partnern wie Bank Vontobel, Telekurs oder Swift bezogen werden. Zusammengehalten wird das Ganze durch die Integrationssysteme, die heute im wesentlichen aus einem Message- und einem File-Broker sowie dem Datawarehouse bestehen.
Mit Rainova will man nun die IT stärker zentralisieren. So soll
DIALBA2000 zu einer zentral betriebenen Applikation migriert und ein Portal geschaffen werden, über das die einzelnen Mitgliedsbanken auf die Systeme zugreifen. Auf der Middleware-Ebene ist geplant, den File-Broker vollständig durch eine Messaging-Infrastruktur abzulösen. Eine einheitliche Sicherheitsschicht schliesslich soll beispielsweise ein rollenbasiertes Single-Sign-on über das Portal ermöglichen. Die Herausforderung für Freuler: Viele der Komponenten der künftigen IT sind noch nicht im Detail bestimmt. So ist es trotz grundsätzlicher Strategieentscheidung vor drei Jahren (siehe Kasten) immer noch möglich, dass sich Raiffeisen aufgrund von veränderten Umständen in ein paar Jahren für eine Gesamtbankenlösung entscheidet. Die Angebote der Hersteller haben sich in den letzten Jahren funktional massiv verbessert, wie Freuler zu Bedenken gibt. Zur Zeit evaluiert deshalb Raiffeisen eine mögliche Corebanking-Plattform, um vorerst die Kernbankfunktionalität für die zentralen Services zu standardisieren.
Strategische Entscheide sind bei der Raiffeisen nicht absolut in Stein gemeisselt. Flexibilität und Wirtschaftlichkeit sind genauso wichtig wie auch die laufende Überprüfung der Strategie. Dies gilt je nach gewählter Kernbanken- respektive Gesamtbankenlösung auch für die Entwicklungsplattformen. Grundsätzlich will sich Raiffeisen künftig aber bei Eigenentwicklungen ausschliesslich auf die Java 2 Enterprise Edition (J2EE) für strategische, geschäftskritische Applikationen beziehungsweise J2SE für andere Applikationen beschränken. Legacy-Sprachen wie Cobol, Natural, Assembler und PL/1 sollen innerhalb der nächsten zwei bis drei Jahre abgelöst werden. Andere Sprachen und Entwicklungsumgebungen wie C/C++, Powerflex, ATLAS-Framework, Visual Studio, Lotus Developer oder Borland Delphi werden zwar in den nächsten Jahren noch parallel weiter eingesetzt, sollen aber langfristig verschwinden.
Die Raiffeisen-Architektur heute und morgen
Mit einem strategischen Architekturleitbild und einer darauf aufbauenden generischen Software-Architektur-Roadmap will Freuler den schrittweisen Umbau im Griff behalten und gleichzeitig an jedem Entscheidungspunkt möglichst lange möglichst flexibel auf wirtschaftliche und technische Entwicklungen reagieren können. Die Flexibilität soll so in der Architektur fest verankert und mittels Toolunterstützung teilautomatisiert werden. Momentan arbeitet Freuler an einem Entscheidungsbaum, der für die wichtigen denkbaren Entscheidungsmöglichkeiten ein Architekturszenario bereit hält. Mit dem Entscheidungsbaum will Freuler vor allem ein gut lesbares Managementinstrument in die Hand bekommen, um die Softwareplattformmodernisierung gezielt steuern zu können.
Der Umbau der einzelnen Applikationen wird in vier Schritten durchgeführt. Zuerst werden alle Plattformen anhand eines relativ einfachen Rasters analysiert . Die Visualisierung aller relevanten Aspekte in jeweils drei Abstufungen schafft einen schnellen Überblick und ermöglicht eine sinnvolle Prioritätensetzung für die eigentliche Migration. Im zweiten Schritt werden die technischen Konzepte für die einzelnen Plattformen erstellt, wobei beispielsweise für die DIALBA-Ablösung auch ein gewisses Prozess-Reengineering nötig sein wird, weil die so massiv umgebaute Applikation künftig zentral betrieben wird. Als Folge davon werden verschiedene Dienste, die heute BOSS und DIALBA noch getrennt betreiben wie beispielsweise die Stammdatenverwaltung, künftig zentral für alle Applikationen angeboten werden.
Im dritten Schritt werden Proof of Concepts durchgeführt, mit denen gezeigt werden soll, ob auf dem geplanten Weg die Komplexität der Legacysysteme schrittweise aufgebrochen und auf der neuen Plattform vereinfacht werden kann. Dabei kommen Code-Scanning-Werkzeuge zum Einsatz, die die detaillierten Abhängigkeiten der einzelnen Module und Funktionalitäten sichtbar machen. Davon ausgehend werden dann die Umsetzungs-Projekte gebildet und schrittweise durchgeführt.
Verschiebung der notwendigen Mitarbeiterqualifikationen
Treiber für solch umfassende Architekturvorhaben gibt es heute etliche. Zum einen zwingt der steigende Kostendruck die Banken zu Kooperationen und zum Outsourcing ganzer Geschäftsprozesse. Zum anderen wird die Differenzierung zwischen den Finanzinstituten immer schwieriger. Sie ist insbesondere noch beim direkten Kundenkontakt möglich. Die Entwicklungskapazitäten sollen darum heute vor allem in diese Schnittstellen, zu denen zum Beispiel das Internetbanking oder Beratertools gehören, investiert werden. Die dahinter liegenden Systeme werden mehr und mehr zum Industriestandard, den man wirtschaftlicher ab Stange kauft oder als Geschäftsprozess auslagert.
Zu diesen Business-Treibern kommen technische Implikatoren dazu. Die Legacy-Systeme drohen zu Komplexitätsfallen und damit zu unberechenbaren Risikofaktoren zu werden. Parallel zur Komplexität steigen zudem auch die Betriebskosten. Als weiteren Faktor versprechen moderne Architekturen zudem durchgängigere und zeitnähere Analysesysteme, die einen messbaren wirtschaftlichen Nutzen bringen.
Im Einzelnen ist die Wirtschaftlichkeit von Architekturvorhaben jedoch meist schwer zu berechnen. Dies ist vielleicht auch der grösste Bremser von Plattformmodernisierungen. Denn für Projekte, deren finanzieller Nutzen nicht im Detail offensichtlich gemacht werden kann, ist die Finanzierung heutzutage sehr schwierig. Damit trotz der nur bedingt möglichen Wirtschaftlichkeitsrechnung die Kosten nicht aus dem Ruder laufen, wurde bei Raiffeisen ein globales Budget pro Vorhaben gesprochen, das laufend überprüft und jährlich den Gegebenheiten angepasst wird.
Im Verlauf der Migration sind allerdings Konfliktpunkte zwischen IT und Business praktisch vorprogrammiert. Während die Geschäftsseite immer möglichst schnell neue Funktionalitäten in Produktion nehmen will und muss, muss die IT ihrerseits sicherstellen, dass trotzdem die Vorteile einer sauberen Architektur erhalten bleiben. Zudem widersprechen sich die vom Business gleichzeitig geforderten möglichst tiefen Kosten und die möglichst grosse Flexibilität grundsätzlich. Hier muss immer wieder ein Optimum gefunden werden. Auch dabei können Instrumente wie die Software-Architektur-Roadmap helfen.
Um auf veränderte Rahmenbedingungen eingehen und immer die wirtschaftlich sinnvollste Variante finden zu können, hat Freuler einen vierteljährlichen Sourcing-Check eingerichtet. In dessen Rahmen werden unter anderem auch immer wieder die notwendigen Rollen und Fähigkeiten der Mitarbeiter unter die Lupe genommen. Gewisse Funktionen hat Freuler zudem institutionalisiert, um konsistente Abläufe sicherzustellen. So wurden Plattformarchitekten bestimmt, die die Aktivitäten innerhalb der Bereiche koordinieren, und eine zentrale Architekturabteilung stellt die Konformität der einzelnen Aktivitätsbereiche sicher. Um die Umstellung auf die Java-Plattform bewerkstelligen zu können, wurde zudem ein Java-Kompetenzzentrum gegründet. Innerhalb von anderthalb Jahren wurde mit dessen Hilfe etwa ein Drittel der heute rund 125 Entwickler auf Java umgeschult.
