Von 3 auf 12: dwpbank stellt Release-Verfahren agil neu auf

Deutschlands führender Wertpapierdienstleister modernisiert sein Software-Release-Management: Statt drei großer Updates gibt es nun alle vier Wochen ein Release. Wie die dwpbank dabei Risiken minimiert und die Time-to-Market verkürzt.

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 Releaseverfahren entwickelt, um Ressourcen zu schonen, Risiken zu minimieren und Kundenanforderungen schneller umzusetzen.

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

Kundenerwartungen und regulatorische Anforderungen wandeln dabei dynamisch. 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. 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. Das Ergebnis: höhere Qualität und Risikotransparenz bei deutlich reduzierten Aufwänden.

Anstoß zu Veränderungen

In der Vergangenheit setzte die dwpbank die meisten Softwareaktualisierungen an drei großen Releaseterminen 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 Releaseprozess zu restriktiv, komplex und statisch, um den Anforderungen an eines sich schnell verändernden Umfelds und agiler Softwareentwicklung gerecht zu werden.

Konkrete Anstöße für eine notwendige Veränderung 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 Cloud-fä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 und weitestgehend automatisierter Prozess, der nicht zuletzt auf regulatorische Anforderungen wie die BAIT und die DORA einzahlt.

Iterative Entwicklungsschritte

Erste Voraussetzungen für das neue Releaseverfahren wurden mit der Einführung eines Sprintrelease-Verfahrens speziell für die neue Microservice-Plattform geschaffen. Dies kommt neben dem Standard-Releaseverfahren 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 Releaseprozess gearbeitet, der unabhängig von der Entwicklungsmethode und der Zielplattform ist. Nachhaltige Prozessverbesserungen setzen voraus, dass der Wandel von den Beteiligten mitgetragen und gestaltet wird. Wir haben daher die Neuentwicklung des Releaseverfahrens 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 Releaseverfahren 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, die dezentrale und die Microservice-basierte Plattform der dwpbank.

Die wichtigsten Aspekte und Ablaufschritte des neuen Releaseverfahrens 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 den intransparenten 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 Releasekreislauf.
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 Releasepakete 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 Prozess

In der Praxis der ersten neun Monate hat sich das neue Releaseverfahren 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 Releaseverfahren 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 Releaseverfahren 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 Releaseverfahrens in der dwpbank haben wir einen essentiellen Schritt in Richtung Effizienz und Flexibilität unserer IT-Prozesse gemacht. Wir haben damit 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.