IT-Praxis: Wie sich die dwpbank mit einem agilen Release-Management für die hybride Welt rüstet

Hybride Infrastrukturen und wachsende Anforderungen von Regulatoren und Kunden zwingen Finanzinstitute, die Effizienz ihrer Software-Releases zu verbessern. Vor diesem Hintergrund hat die dwpbank ein agiles und deutlich verschlanktes Release­Verfahren entwickelt, um Ressourcen zu schonen, Risiken zu minimieren und Kundenerwartungen schneller umzusetzen. Ein Blick hinter die Kulissen.

von Dr. Thilo Müller, Leiter Steuerung & Services, und Stephan Junker, Leiter Release- und IT-Changemanagement bei der Deutschen Wertpapierservice Bank

Als führender Dienstleister für Wertpapierservices in Deutschland betreibt die Deutsche WertpapierService Bank (dwpbank) eine der größten und leistungsfähigsten IT-Anwendungslandschaften im deutschen Finanzsektor für das Wertpapiergeschäft. Unsere zentrale Wertpapierplattform wird von rund 200.000 Anlageberatern und Angestellten in über 1.000 Kundeninstituten aus allen drei Säulen des Bankensystems genutzt. Kundenerwartungen und regulatorische Anforderungen unterliegen dabei einem dynamischen Wandel.

Für unsere Kundeninstitute wollen wir den Handel, die Abwicklung und Verwahrung von traditionellen Wertpapieren, zunehmend auch vermehrt für digitale Wertpapiere weiterhin auf höchstem Niveau stabil erbringen.”

Auch für weitere Wertpapierservices, klassische Back- und Middle-Office-Aufgaben sowie um neue Anforderungen zügig erfüllen zu können, ist Stabilität und Performance wichtig und somit ein effizientes Software-Releaseverfahren von elementarer Bedeutung.

Die dwpbank hat daher ihr Releaseverfahren von Grund auf erneuert – und dadurch mehr Qualität, höhere Risikotransparenz und eine deutliche Aufwandsreduzierung erreicht.

Anstoß zu Veränderungen

In der Vergangenheit setzte die dwpbank die meisten Softwareänderungen an drei großen Release-Terminen pro Jahr um. Eine immer noch branchenübliche Vorgehensweise, die bei bis zu 300 Einzelvorhaben in einem Release mit langen Vorlaufzeiten, einer Vielzahl an Beteiligten und vielen Abhängigkeiten zwischen den Vorhaben einherging. Die geforderte Transparenz über Themen und Abhängigkeiten zu gewährleisten, wurde mit hohem zeitlichem und personellem Aufwand bezahlt. Zeigte der Entwicklungsprozess qualitative Schwächen auf, war ein Zurück im anstehenden Release nicht ohne weiteres möglich.

Insgesamt war der Release-Prozess zu restriktiv, komplex und statisch, um den Anforderungen eines sich schnell verändernden Umfelds und agiler Softwareentwicklung gerecht zu werden.”

Konkrete Anstöße für eine notwendige Veränderung des Release-Prozesses entstanden vor allem aus

• der agilen Transformation in der dwpbank,
• neuen methodischen und technologischen Ansätzen wie die sukzessive Ablösung der Mainframe-basierten Plattform durch eine cloudfähige Plattform auf Basis von Mircoservices und
• dem Anspruch die Deployment-Qualität und letztlich die Produktionsstabilität bei gleichzeitig kürzerer Time-to-Market Anforderung weiter zu verbessern.

Ziel war ein optimierter Prozess, der die oben beschriebenen Anforderungen weitestgehend automatisiert umsetzt und nicht zuletzt auf regulatorische Anforderungen wie die BAIT und die DORA einzahlt.”

Iterative Entwicklungsschritte

Erste Voraussetzungen für das neue Release-Verfahren wurden mit der Einführung eines Sprintrelease-Verfahrens speziell für die neue Microservice-Plattform geschaffen. Dies kommt neben dem Standard-Release-Verfahren der dwpbank ergänzend zum Einsatz, um die Anforderungen aus der agilen Welt zu erfüllen.

Darauf aufbauend wurde an einem einheitlichen, schlanken und standardisierten Release-Prozess gearbeitet, der unabhängig von der Entwicklungsmethode und der Zielplattform ist. Nachhaltige Prozessverbesserungen setzen voraus, dass der Wandel von den Beteiligten aktiv mitgetragen und gestaltet wird.

Wir haben daher die Neuentwicklung des Release-Verfahrens nicht als Projekt durchgeführt, sondern aus der Linie heraus im ständigen Austausch mit den Anwendern entwickelt und über eine Pilotphase in der Bank eingeführt.”

Somit konnten Aspekte und Besonderheiten aus der klassischen, wasserfall-basierten Entwicklung der Mainframe-Welt iterativ in das neue Verfahren integriert und überprüft werden. Die Teams und alle verantwortlichen Fachabteilungen waren Teil der Entwicklung des Modells und konnten ihre Ideen und Anforderungen beisteuern. Hier liegt aus unserer Sicht ein Schlüssel für die gelungene Einführung des Prozesses. Nach einer Parallelphase von altem und neuem Verfahren verlief der finale, produktive Übergang in den neuen Standardprozess nach zwei Jahren Vorbereitung so fast unbemerkt.

Autarke Themenpakete als Game-Changer

Das neue Release-Verfahren wurzelt in der agilen Welt und in der Prozessoptimierung nach ITIL4. Zugleich berücksichtigt es die Gegebenheiten aller aktuell im Einsatz befindlichen Technologie-Stacks wie dem Mainframe, der dezentrale und der Microservice-basierte Plattform der dwpbank.

Die wichtigsten Aspekte und Ablaufschritte des neuen Release-Verfahrens sind:

1.Phase: Vorbereitung in der Staging-Umgebung

Die Anforderungen werden in unabhängige Pakete aufgeteilt, die jeweils autark den Entwicklungsprozess durchlaufen und von einem sogenannten Paketverantwortlichen mit fachlich-technischem Wissen geführt werden. Ein Game-Changer, mit dem intransparente Abhängigkeiten der Vergangenheit angehören. Kleinere Pakete sind effektiver zu bearbeiten und zu verantworten. Sie lassen sich damit in höherer Qualität einführen. Die Pakete vorab zu strukturieren, hat auch die Qualitätssicherung wesentlich erleichtert. Die Beschreibung von Testfällen und die Berücksichtigung von Abhängigkeiten hat sich maßgeblich vereinfacht. So kommen Anforderungen letztendlich aus den verschiedenen Entwicklungsumgebungen über ein schlankes Staging-Verfahren in den Release-Kreislauf.

2.Phase: Fachliche Testabnahme

Das Einbringen in diese Umgebung erfolgt mit wenig formalen Vorgaben. Für den fachlichen Abnahmetest stehen in der Regel drei Wochen zur Verfügung. Erst am Ende dieses Zeitfensters meldet sich der Paketverantwortliche für das kommende Release offiziell an, kann sich aber auch für ein zukünftiges Einsatzdatum entscheiden, wenn die Reife des Pakets für ihn noch nicht ausreichend ist. Dabei wird der Paketverantwortliche vom Releasemanagement-Team kontinuierlich begleitet und unterstützt.

3.Phase: Erste Abnahme im ersten Quality Gate

Im ersten Quality Gate erfolgt die finale fachliche Abnahme durch den Paketverantwortlichen und den Releasemanager. In diesem Schritt werden formale Anforderungen wie Dokumentation, Freigaben und Testabnahme geprüft. Dieses Quality Gate stellt sicher, dass die Pakete bereit für die nächste Phase sind.

4.Phase: Tests in der PreProd-Umgebung

Im Anschluss erfolgt die Übernahme in die PreProd-Umgebung zum betrieblichen Abnahmetest (u.a. Last- und Performance-Tests) und den Prüfungen des RZ-Dienstleisters, z.B. der technischen Lauffähigkeit der Softwareprodukte. Diese Phase dauert in der Regel eine Woche.

Notwendige technische Korrekturen bis zur Produktionsübergabe sind noch möglich.

Der Paketverantwortliche und der Releasemanager können während des gesamten Verfahrens eingreifen, Themen ins nächste Release verschieben oder Änderungen durchführen, sofern sie den Ablaufplan oder die technische Integration nicht gefährden.”

Hier zeigt sich auch eine deutliche Optimierung zum alten Verfahren, da dies aufgrund der wesentlich höheren Qualität der Release-Pakete inzwischen eher die Ausnahme darstellt.

5.Phase: Endabnahme im zweiten Quality Gate

Das zweite Quality Gate erfolgt kurz vor der Produktionsübernahme. Im Release-Board, bestehend aus den Paketverantwortlichen, Releasemanagern und Vertretern des RZ-Dienstleisters, werden letzte Abstimmungen zum Deployment-Ablauf durchgeführt und die finale Bestätigung zur Produktionsübernahme erteilt.

Im Gegensatz zum alten Prozess konnte die Anzahl der Quality Gates von fünf auf zwei reduziert und vereinfacht werden.”

Zudem sind auch nur noch die Paketverantwortlichen in dem Board vertreten statt diverser fachlicher und technischer Vertreter. Ein Meilenstein hinsichtlich klarer Verantwortlichkeiten, Transparenz und Schlankheit des Prozesses.

6.Phase: Umsetzung

Das eigentliche Release wird am Wochenende eingeführt. Rein technische Themen können bereits im Vorfeld oder unmittelbar nach dem Release eingesetzt werden. Durch die gründliche Vorbereitung, die Entzerrung der Aufgaben und die effizienten Prozesse hat sich die Zeit für das Deployment nahezu halbiert und die Qualität der Softwareeinführungen deutlich verbessert.

Verschlankter und transparenter Release-Prozess

In der Praxis der ersten neun Monate hat sich das neue Release-Verfahren uneingeschränkt bewährt.

Der Prozess ist sehr performant und dabei spürbar schlanker, transparenter und verbindlicher geworden.”

Die Zahl der notwendigen Anpassungen nach einem Release konnte drastisch reduziert werden. Oft sind im Nachgang gar keine Eingriffe mehr nötig.

Dieser positive Effekt zeigt sich insbesondere in der Gesamtzahl der Software-Deployments in der dwpbank. Seit Einführung des Piloten ist die Zahl der kurzfristigen Einzelchanges außerhalb des standardisierten Releases sukzessive zurückgegangen, denn viele dieser Themen können heute in das Release-Verfahren integriert werden. Dank der fachlichen und technischen Aufteilung und der Parallelisierung von Themen während der Umsetzung bleiben die neuen Releases dennoch gut handhabbar. Zukünftig könnte der Prozess für weiterhin komplexe Themen zum Einsatz kommen, die aktuell noch im Rahmen von Sonderchanges umgesetzt werden, um Risiken weiter zu minimieren und die Entwicklungsaufwände zu reduzieren. Das neue Release-Verfahren stellt damit keinen Schlusspunkt, sondern einen wesentlichen Zwischenschritt bei der Optimierung unserer Prozesse im Rahmen des IT-Changemanagements und der agilen Transformation der dwpbank dar.

Fazit

Mit der Etablierung eines vierwöchigen und standardisierten Release-Verfahrens in der dwpbank haben wir einen essentiellen Schritt in Richtung Effizienz und Flexibilität unserer IT-Prozesse gemacht.

Wir haben zum einen für unsere Kunden und Partner einen signifikanten Mehrwert durch eine verbesserte, kundenorientierte Time-to-Market und Risikominimierung geschaffen.”

Themen können flexibler umgesetzt und besser getaktet werden, die Reaktionsfähigkeit – also die Möglichkeit, Themen kurzfristiger aufzunehmen oder zurückzuziehen – ist ein wesentlicher Vorteil.

Andererseits konnte durch die frühzeitige Einbindung aller Prozessbeteiligten und den konstruktiven Dialog eine hohe Akzeptanz für agilere Vorgehensweisen erreicht werden.”

Es ermöglicht uns, die Komplexität der neuen hybriden IT-Landschaft zwischen Mainframe und Cloud besser zu bewältigen. Diese positiven Erfahrungen fließen jetzt in Verbesserungen des übergeordneten IT-Changemanagements ein.Dr. Thilo Müller und Stephan Junker, dwpbank