Die Anbieter neuer IT-Softwarepakete haben die Legacy-Systeme – vor allem im Finanzbereich – schon einige Male für tot erklärt. Legacy, dieser englische Begriff bezeichnet etablierte, historisch gewachsene Anwendungen im Bereich der Unternehmenssoftware. Legacy ist das englische Wort für Vermächtnis, Hinterlassenschaft, Erbschaft oder aber auch Altlast. Diese meist über Jahrzehnte gewachsenen Altsysteme halten sich zäh. Ungeachtet aller erfolgten technologischen Neuerungen stellen sie auch im Jahr 2007 weiterhin den harten Kern der Applikationslandschaft dar. Auch bei der Bank Julius Bär.
Weltweit sind bei den meisten Finanzinstituten noch Tausende von ausgereiften und bewährten Legacy-Applikationen im Einsatz. Die Anwendungen, die auf den Host-Systemen laufen, sind meistens in Cobol, PL/1 oder Assembler-Maschinensprachen programmiert. Die Systeme laufen seit vielen Jahren fehlerfrei. Sie sind im praktischen Einsatz getestet und an die unternehmenseigenen Bedürfnisse angepasst. Rund 70 Prozent aller unternehmenskritischen Anwendungen laufen auf diesen Systemen. Insbesondere in kritischen Bereichen, bei grossen Transaktionsaufkommen und bei hohen Benutzerzahlen sind Legacy-Systeme in der Performance und Stabilität auch heute noch den «modernen» Systemen in der Regel überlegen.
Das Kernsystem der Bank Julius Bär besteht aus einem IBM-Mainframe-Rechner, auf welchem Cobol-Programme laufen. Darunter fallen die typischen Kernbanken-Applikationen wie Kontoführung, Depotführung oder Corporate Action. Darum herum gibt es Satellitensysteme, beispielsweise ein SAP-System für die Buchhaltung und das Management-Informationssystem, ein Portfolio-Management-System sowie verschiedene dezentrale Handelssysteme.
Analysiert man die unterschiedlichen Wege, kommt man zu folgenden Ergebnissen: Die komplette Neuentwicklung einer Anwendung mit modernen Technologien kann sich über Jahre hinwegziehen und ist enorm kostenintensiv. An neuer Geschäftsfunktionalität würde ein Unternehmen aber nur wenig gewinnen.
Hingegen wäre das Risiko bei der Ablösung des alten Systems meist sehr hoch. Bis das neue System die Ausgereiftheit und Stabilität des alten Systems erreicht hat, vergeht noch mehr Zeit. Zudem darf nicht unterschätzt werden, dass man vom Requirement Management bis hin zum Testing wieder von vorn beginnen müsste. Der Druck infolge neuer Produkte und Dienstleistungen seitens des Business zwingt zum Handeln.
Die Alternative ist der Einsatz von Standardsoftware. Man sucht eine Lösung, die genau die Funktion erfüllt, die bisher von der Legacy-Anwendung abgedeckt wird. Dieser Weg empfiehlt sich aber nur, wenn die Standardsoftware optimal passt. Die Erfahrung zeigt allerdings, dass nur wenige Unternehmen eine Standardsoftware finden, die 80 Prozent der bisherigen Legacy-Funktionen anbietet.
Für die fehlenden 20 Prozent muss ein Unternehmen also entweder von differenzierenden Fähigkeiten Abschied nehmen oder dennoch eigene Lösungen programmieren, was mit weiteren Kosten und Risiken verbunden ist. Und selbst wenn eine Standardsoftware gefunden wird, erfordert die Lösung doch eine risikoreiche Migration der Daten und Geschäftsprozesse.
Die Einführung einer Standardlösung sollte in der Regel weniger lange dauern als der Eigenbau einer neuen Software, jedoch ist die IT-Organisation während dieser Zeit vollkommen blockiert und kann nicht auf veränderte Anforderungen reagieren, wie beispielsweise die Integration einer zugekauften Bank in die bestehende IT-Infrastruktur.
Heute wird bei einer breiten Mehrheit der Finanzinstitute die konsequente Buy-before-Make-Strategie verfolgt. Sie hat das klare Ziel, Standardsoftware bestmöglich einzusetzen.
Bei der Bank Julius Bär dagegen verfolgen wir einen leicht modifizierten Ansatz: Für sämtliche Bereiche, in denen sich das Unternehmen nicht differenzieren kann, sollten standardisierte Produkte eingesetzt werden. Die «Legacy» in den Kernbanken-Funktionen transformieren wir in einem evolutionären Approach hin zu höherer Agilität, flexiblerer Integration in (sich ständig verändernde und optimierende) Geschäftsprozesse und benutzergruppengerechterer User-Interfaces. Dafür sprechen auch ökonomische Gründe.
Bei der Bank Julius Bär setzen wir «Make» nicht mit «Basteln» gleich, und «Buy» ist für uns kein genereller Weg zu einer modernen, sauberen Architektur. Der Alltag hat in der Vergangenheit gezeigt, dass durch «Buy» oft eine grosse Bastelei entsteht, bei «Make» dagegen kennt man zumindest die Risiken und kann sie managen. Häufig werden bei «Buy»-Entscheidungen auch die langfristigen Kosten in Betrieb und Wartung unterschätzt.
Anhand verschiedener Projekte konnten wir unseren Ansatz in den vergangenen Monaten validieren und haben festgestellt, dass die in der Grafik aufgeführten Kriterien im Sinne des Architected Make-or-Buy Approach wichtig sind.
Bei der Analyse der Lösungsoptionen für eine Neugestaltung des Steuerreportings haben wir gut ein halbes Dutzend Standardsoftwarepakete evaluiert und uns dann letztlich für eine Eigenentwicklung entschieden. Obwohl dieses Problem initial betrachtet ein «Standardproblem» ist, mussten wir feststellen, dass unsere Kriterien nicht vollständig erfüllt werden konnten:
- Klare Domain Ownership für Daten: Viele Produkte erfordern die Bewirtschaftung von Daten (v.a. Stammdaten) im entsprechenden Paket. Dies steht oft im Widerspruch zu unserer Referenzarchitektur, welche andere Systeme als Master für die jeweiligen Daten vorsieht. Durch eine Aufweichung dieser klaren Master-Slave-Zuordnung ergeben sich Integritätsprobleme und Prozess-Ineffizienzen und damit verbundene Kosten.
- Plattformstandard und Betreibbarkeit: Einige Standardlösungen bieten aufgrund des Designs nicht die für einen modernen und qualitativ hochwertigen Betrieb notwendigen Möglichkeiten an. Viele Produkte – vor allem im Front-Bereich – werden auf schicke Funktionalität getrimmt, die Betreibbarkeit und Stabilität dagegen sind im Grunddesign häufig vernachlässigt.
- Erweiterbarkeit: Viele Lösungen haben kein klares Produktkonzept, das die eigentlich zu erwartenden Vorteile umfasst, wie beispielsweise die Verteilung der Produktentwicklungskosten auf viele Käufer oder der Zugang zu funktionalen Erweiterungen für alle Anwender.
- Erfüllung der funktionalen Anforderungen: Aufgrund des hochspezialisierten Private-Banking-Geschäfts lassen sich wenige Produkte finden, die die notwendige Flexibilität für unser Geschäftssegment bieten.
- Integrierbarkeit: Viele Produkte haben Probleme nach aussen verlagert, das heisst in die bereits bestehenden Legacy-Applikationen.
In einem anderen Beispiel haben wir uns im Bereich Portfolio-Management für den Einsatz eines Standardprodukts entschieden, da neben dem technologischen Fit sowie der Zusicherung des Herstellers, die für uns wichtigen Industriestandards zu berücksichtigen, die wesentlichen Architekturkriterien für die funktionale Domäne erfüllt sind:
- Klare Domain Ownership für Daten: Die portfoliomanagementrelevanten Daten (z.B. Portfolio, Instrumente, Preise) verbleiben als Master in den entsprechenden Systemen.
- Plattformstandard und Betreibbarkeit: Das Produkt basiert auf Standardkomponenten und ist konfigurierbar.
- Erfüllung der funktionalen Anforderungen: Das System bietet State-of-the-art-Funktionalität für das Portfolio-Management und gilt als führendes Produkt am Markt.
- Integrierbarkeit: Die Granularität der Schnittstellen entspricht weitgehend der Struktur der bestehenden Systeme.
Fazit
Wir bei der Bank Julius Bär folgen einem Architected Buy-or-Make Approach, der die verschiedensten Faktoren einbezieht. Die Wiederverwendung von Legacy Services minimiert die Risiken der Softwareentwicklung und reduziert die Kosten. Zudem lassen sich vorhandene Qualifikationen weiter nutzen, sodass mit einer Modernisierung gleichzeitig ein optimaler Investitionsschutz erreicht wird.
In nächster Zukunft steht bei uns die Renovation der gesamten IT-Plattform an. Wir sind überzeugt, mit unserem Architected Buy-or-Make Approach bestens für diese Aufgabe gerüstet zu sein.
Die Julius Bär Gruppe ist der führende reine Vermögensverwalter in der Schweiz. Die Gruppe konzentriert sich ausschliesslich auf die Bereiche Private Banking und Asset Management für Privatkunden und institutionelle Anleger. Mit weltweit mehr als 3800 Mitarbeitenden verwaltete die Gruppe per Ende Juni 2007 Vermögen von über 400 Milliarden Franken. Die weltweite Präsenz der Julius Bär Gruppe umfasst mehr als 30 Standorte. Die verglichen mit anderen Instituten schlanke IT der Bank Julius Bär umfasst rund 300 interne und 100 externe IT-Mitarbeiter. Sie sind für den Betrieb, Unterhalt und die Weiterentwicklung der mehr als 100 verschiedenen Anwendungen verantwortlich. Derzeit laufen über 90 Prozent dieser Applikationen – gemessen an Lines of Code – auf dem Host (IBM zOS Mainframe) der Bank.
Mario Crameri ist Leiter IT und Thomas Wölfle Leiter Architektur, Security & IT Risk, beide bei der Bank Julius Bär.
