SOA statt Mainframe

Der Autor ist Geschäftsführender Gesellschafter der Softwareloft IT-Solutions GmbH in Hamburg Die Vokabel «Change» grenzt schon fast an Untertreibung. Es ist eher eine Revolution, die sich da – verstärkt seit 2005 – in Bern-Liebefeld abspielt: der Austausch des kompletten Kernbankensystems durch eine neue Service-orientierte Architektur (SOA). Das aus dem Servicevertrag zwischen RTC und HP hervorgegangene HP Banking Service Center (HP BSC) wechselt damit quasi sein komplettes Antriebssystems aus. Wenn das mehr als 30 Jahre alte Mainframe-System abgelöst ist, hat das Unternehmen eine neue IT-Infrastruktur, mit der es endlich schnell auf die aktuellen Anforderungen des Finanzmarkts reagieren kann. Ein Kraftakt in einem schwierigen Umfeld, denn für die geplante Technologie gab es für den Einsatz bei Kernbankensystemen keine Erfahrungswerte. Heute, fünf Jahre nach dem Umstiegs­beschluss, ist das von RTC entwickelte Kernbankensystem Ibis 3G – inzwischen unter der Ägide von HP – zu einem grossen Teil implementiert. Das HP BSC wird nach der Fertigstellung über eine modulare, flexible, und kostengünstige IT-Infrastruktur verfügen, mit der man nun am Markt in die Offensive gehen will.

System mit Altersschwächen Die Geburtsstunde der Ibis-Banken-Software schlug 1973. Die Eigenentwicklung der Firma RTC AG wurde zwar stets weiterentwickelt, zeigte aber mit den Jahren Schwächen. Die grösste: Das System auf Mainframe-Basis war nicht mehr flexibel. Change-Prozesse und Kundenanforderungen, etwa der Wunsch nach neuen Produkten, oder schlicht neue gesetz­liche Anforderungen (Stichwort Basel III), konnten nicht schnell genug umgesetzt werden. In Ibis liefen mehrere Systeme aufgrund des historischen Wachstums nebeneinander, Änderungen mussten auf verschiedenen Ebenen und an verschiedenen Stellen gleichzeitig vorgenommen werden. Das war zwar möglich, aber aufwendig und teuer. Die Banken als Kunden suchen auf der Produktseite Alleinstellungsmerkmale gegenüber den Wettbewerbern – ein Wunsch, den sie an ihren Bankendienst-leister weiterreichen. Dieser muss in der Lage sein, schnell und individuell Kundenwünsche umzusetzen. Dem Unternehmen war klar: Es muss sich etwas grundlegend ändern. Statt weiter in die vorhandene monolithische Mainframe-Architektur zu investieren, sollte eine leichte, modular erweiterbare SOA-Architektur die Anforderungen des Bankengeschäfts der kommenden Jahrzehnte abdecken. Der Plan war, nach dem Best-of-Breed-Prinzip neue eigene Anwendungen, neue Systeme von Entwicklungspartnern aber auch Marktprodukte in einem neuen Kernbankensystem zu vereinen – und zwar mit einem konsequenten Serviceansatz: Keine Dubletten, einzelne Services und Systeme müssen allen Modulen zur Verfügung stehen, Änderungen sollen stets nur an einer Stelle erfolgen und dann umgehend in Produktion gehen.
 
Ganz oder gar nicht Von Anfang an entschied man sich, den Wechsel komplett zu vollziehen und nicht zunächst auf bestimmte Abteilungen zu begrenzen. Denn wenn Teile des Unternehmens nicht mitgenommen werden, versuchen sie in der Regel, sich selbst zu helfen. Das führt im schlimmsten Fall zu Konkurrenzsituationen, zu gegenseitiger Behinderung und zu einem unnötigen Aufbau von Parallelressourcen. Das Bewusstsein für den grossen Schritt nach vorne war im ganzen Unternehmen vorhanden – sowohl horizontal als auch vertikal. Natürlich gab es auch Skeptiker, kein Umbauprojekt dieser Dimension kommt ohne sie aus. Es kommt darauf an, mit diesen richtig umzugehen. Die Unternehmensführung hat die
Organisationsstruktur schnell und wirksam der jeweiligen Situation angepasst. Die Skeptiker wurden zudem ins neue Projekt eingebunden und waren wichtige Informationsquellen für interne und externe Projektteilnehmer. Diese organisatorische Führung sorgte dafür, dass hinreichend Know-how in die Teilprojekte einfloss. Andererseits gehört zu einem klaren Change-Kurs auch, dass man den Mut haben muss, sich von Blockierern zu trennen.

Iterativer Prozess Das Thema Kosten spielt in jedem Change-Prozess eine wichtige Rolle. Ein solcher Umstieg ist teuer. Das sind Investitionen, die nicht sofort in neuen Umsatz münden. Deshalb hat man zunächst für klare Verhältnisse bei der Frage nach dem Kostenträger gesorgt. Für die Umsetzungsstrategie wurde ein Change-Ansatz gewählt, der den Kostenaspekt nicht zum Stolperstein macht. Statt jahrelang ein neues Kernbankensystem zu entwickeln und eines Tages nach dem Big-Bang-Prinzip umzustellen, wurde ein iteratives Vorgehen gewählt. Zunächst sollte ein redundant implementierter Geschäftsprozess auf die neue Technologie umgestellt werden. Die Wahl fiel auf den Dispositionsservice, das ist jene Logik, die prüft, ob ein Endkunde (Bankkunde) ein beabsichtigtes Geschäft, etwa eine Zahlung, durchführen kann. Der Disposervice ist anspruchsvoll, auf ihn greifen alle Systeme zu und er unterhält die meisten Schnittstellen. Im Disposervice musste die fachliche Logik der Altanwendung in der neuen Welt abgebildet werden. Wenn dieser funktioniert – so die Logik  – dann funktionieren auch die anderen Prozesse. Der Dispoprozess sollte vor den Mainframe geschaltet werden und so seine Bewährungsprobe liefern. Nach Umbau- und diversen Optimierungsmassnahmen ging der neue Service noch im Jahr 2005 live und übertraf die Erwartungen: Das System war performant, die eingesetzte JEE-Technologie bewältigte die Anforderungen optimal, Änderungen in den Prozessen liessen sich – wie prognostiziert – schnell umsetzen. Das Prinzip, mit einer ersten Applikation schnell live zu gehen, hat aus Change-Management-Sicht den grossen Vorteil, dass die Erfolge transparent werden. Man sieht, dass der gewählte Weg der richtige ist. Das gab dem gesamten Projekt Schub. Das Unternehmen gewann Vertrauen in die neue Strategie. Der erste Erfolgs-Case erhöhte ausserdem die Aussicht, schnell zu Einsparungen zu gelangen, sodass dem Kostenthema der Wind aus den Segeln genommen worden ist. Das iterative Vorgehen hatte obendrein den Vorteil, dass die im Pilot gewonnenen Einsichten in weitere parallel zu entwickelnde Applikationen eingeflossen sind. Strategien der Folgeprojekte konnten nun angepasst, die Organisation neu ausgerichtet werden.

Hilfe von Aussen Auch Offenheit für Input von aussen kann zum Gelingen eines Change-Management-Projekts beitragen. Deshalb wurde früh Softwareloft als Strategie- und Entwicklungspartner an Bord geholt. Damit stärkte man sich mit externem Know-how und erhöhte die Schlagzahl. Die Arbeitsteilung zwischen Eigenentwicklungen (weitere 15 Systeme, darunter das Vorbuchungssystem, die Geschäftssteuerung und die komplette Kartenlösung) und gekauften Anwendungen erwies sich als ideale Mischung. Das Innova­tionstempo konnte dabei ebenfalls gesteigert werden, weil integrativ getestete fertige Systeme bezogen wurden. Softwareloft hat in Hamburg alle relevanten Systeme der Kernbankenlandschaft repliziert und darauf jede gelieferte Anwendung automatisiert funktionsgetestet. Nach der Integration wurde eine zweite Testreihe angeschlossen, und die Neusysteme in den sogenannten Passivbetrieb – auch ein Merkmal des gelungenen Change-Management-Prozesses – geschickt. Im Passivbetrieb liefen Neu- und Altsystem parallel, die Altanwendung wurde erst gänzlich abgeschaltet, als sich die neue Applikation im Praxisbetrieb bewährt hatte. An Pfingsten 2009 wurde die neue Software-Plattform Ibis3G erfolgreich eingeführt. Wie in jedem Grossprojekt gab es auch hier Rückschläge. Jeder Change-Management-Prozess ist schmerzhaft und mit Erfahrungen verbunden. Wichtig ist, dass ein Unternehmen trotzdem nicht resigniert und erst recht nicht umkehrt. Nur so gelingt der Erfolg.