dwpbank führt agiles Release-Management ein

Als 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. Die 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 die Kundeninstitute soll der Handel, die und digitalen Wertpapieren stabil sein. 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-Release-Verfahren von elementarer Bedeutung.

Die dwpbank hat daher ihr Release-Verfahren von Grund auf erneuert. Das Ergebnis: höhere Qualität und Risikotransparenz bei deutlich reduzierten Aufwänden.

Release-Prozess war zu restriktiv

In der Vergangenheit setzte die dwpbank die meisten Software-Aktualisierungen an drei großen Release-Terminen pro Jahr um. Eine 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 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 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 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 Anwendernentwickelt 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üftwerden. Die Teams und alle verantwortlichen Fachabteilungen waren Teil der Entwicklung des Modells und konnten ihreIdeen 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, die dezentrale und die Microservice-basierte Plattform der dwpbank.
Die wichtigsten Aspekte und Ablaufschritte des neuen Release-Verfahrens sind:

Phase 1: 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.

Phase 2: 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.

Phase 3: 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.

Phase 4: 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.

Phase 5: 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.

Phase 6: 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.

Essentieller Schritt in Richtung Effizienz und Flexibilität

Mit der Etablierung eines vierwöchigen und standardisierten Release-Verfahrens in der dwpbank ist ein essentieller Schritt in Richtung Effizienz und Flexibilität der IT-Prozesse erfolgt. Dies schafft zum einen für Kunden und Partner einen signifikanten Mehrwert durch eine verbesserte, kundenorientierte Time-to-Market und Risikominimierung. 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, 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.

Stephan Junker

verantwortet bei der Deutschen WertpapierService Bank AG die Abteilung Release- und Changemanagement.