Sonatype stellt Abhängigkeitsmanagement der nächsten Generation vor | Pressemitteilung

Agile Transformation bei TD Bank

Nexus-Plattform verschiebt Governance

Seit mehr als 150 Jahren räumt die TD Bank dem Komfort und dem Service für ihre Kunden Priorität ein. Die Bank öffnete ihre Türen 1852 als Portland Savings Bank. In den folgenden anderthalb Jahrhunderten wuchs das Unternehmen durch eine Reihe von Fusionen und Übernahmen. Anfang der 2000er Jahre war die Bank unter dem Namen BankNorth bekannt und erweckte das Interesse der TD Bank Group aus Toronto, Kanada. Das kanadische multinationale Unternehmen wurde schnell zum Hauptaktionär von BankNorth und schloss die Übernahme im Jahr 2007 ab.

In Bezug auf ihre Software-Entwicklung verfolgte der Bereich Anwendungsentwicklung der TD Bank bis 2014 einen traditionellen Wasserfall-Ansatz. Etwa zu dieser Zeit erkannte man den Modernisierungsbedarf, sowohl hinsichtlich des Ansatzes als auch hinsichtlich der Werkzeuge. Infolgedessen stieß man einen Prozess der agilen Transformation an.

Bill McArthur, Leiter der Entwicklungsabteilung, und Sladjana Jovanovic, VP im Bereich Enterprise Payments Technology, waren beide maßgeblich an der umfangreichen Teamleistung beteiligt, die zu dieser Transformation führte. Für einen Teil dieser Modernisierung griffen sie auf die Nexus-Plattform von Sonatype zurück, einschließlich Nexus Lifecycle und Nexus Repository. Jason Hills, der als Leiter der Anwendungssicherheit hinzukam, half ihnen dabei, den Einsatz dieser Werkzeuge weiter voranzutreiben.

Die Herausforderungen:

Wie jeder Veteran einer solchen Initiative bestätigen wird, ist eine agile Transformation an und für sich schon ein ernsthaftes Unterfangen. Allzu oft geht die Notwendigkeit einer Veränderung viel tiefer, als lediglich eine andere Methode des Projektmanagements zu verfolgen und eine andere Form von Team-Meetings einzuführen. Unternehmen müssen ihre Philosophien, technischen Verfahren und Werkzeuge verändern.

Dieser Bedarf an Veränderungen, die über die Einführung agiler Verfahren hinausgehen, stellte die TD Bank vor ihre erste große Herausforderung: die Einführung von Werkzeugen und Automatisierungen, die eine agile Bereitstellungskadenz ermöglichen würden. Wie McArthur es ausdrückte, brauchte man moderne Werkzeuge, um agil arbeiten zu können.

Die Notwendigkeit der Automatisierung zu erkennen, war nur ein Teil der Geschichte. Der nächste Schritt bestand darin, bestimmte Mängel zu untersuchen, die richtigen Werkzeuge zur Behebung dieser Mängel auszuwählen und dann einen Business Case für die Werkzeuge zu erstellen. Unternehmenstransformationen erfolgen selten monolithisch, wobei TD Bank hier keine Ausnahme war. Als frühe Verfechter der Transformation mussten McArthur und Jovanovic diese Probleme im Rahmen von Machbarkeitsstudien angehen und dann die Geschichte auf andere Bereiche des Unternehmens übertragen. Ziel sollte es letztendlich sein, diese Lösungen zum akzeptierten Unternehmensstandard zu machen.

Eine besondere Herausforderung bestand beispielsweise darin, dass sie einen Build- und Deployment-Prozess hatten, der einen umständlichen, manuellen Prozess für die Nachweisbarkeit vorsah. Ohne einen rechtzeitigen Nachweis von Build-Komponenten oder der tatsächlichen Software Bill of Materials dauert es viel länger, die Software in einer Produktionsumgebung bis zu ihrer ursprünglichen Quelle zurückzuverfolgen. Dies ist eine unhaltbare Situation für Teams, die Software bereitstellen, warten und verwalten und gleichzeitig die gestiegenen Anforderungen an eine Continuous Delivery erfüllen müssen.

Eine weitere Herausforderung war die Verwaltung und Genehmigung für den Einsatz von Open-Source-Komponenten. McArthur beschreibt die Situation folgendermaßen:

„Es gab eine zentralisierte Gruppe, die mit Blick auf sämtliche Open-Source-Komponenten nachvollziehen musste, wer sie benutzte, warum man sie benutzte, wo man sie benutzte und welche Versionen erlaubt waren. Man musste also immer erst eine Genehmigung einholen, um etwas verwenden zu dürfen.“

Dieser Prozess hatte eine lange Zykluszeit und war arbeitsintensiv. Eine ganze Gruppe von Mitarbeitern musste umfangreiche manuelle Forschung betreiben, während die verschiedenen Teams im Bereich Anwendungsentwicklung einfach auf ihre Ergebnisse warteten. Dies schuf einen suboptimalen Anreiz, der von McArthur folgendermaßen beschrieben wurde: Der Prozess zur Erlangung der Genehmigung für die Verwendung jeglicher Open-Source-Komponenten war äußerst mühsam. Daher verzeichnete das Unternehmen naturgemäß eine nur begrenzte Umsetzungsquote.

Trotz dieser Herausforderungen in den frühen Tagen der agilen Transformation konnten McArthur, Jovanovic und TD Bank Business Cases für ihre Lösungen entwickeln und große Fortschritte erzielen. Aber mit dem Fortschritt kamen neue Herausforderungen auf.

Als Hills einige Jahre später 2018 zu TD Bank kam, stieß er auf eine allgegenwärtige Herausforderung im Bereich der Anwendungssicherheit. Zwar verfügte die TD Bank im Bereich Release-Sicherheit und Schwachstellen über mehr Daten als je zuvor, doch waren diese Daten nicht auf das Geschäftsrisiko kalibriert. Mit SAST-Tools (Static Application Security Testing) lassen sich Sicherheitsmängel zuverlässig identifizieren, jedoch fehlt den Tools der Kontext, um aussagekräftige Scores für den Schweregrad zuzuordnen. Um aussagekräftige KRIs (Key Risk Indicators) und Abhilfepläne zu erstellen, sind mehr risikobasierte Informationen erforderlich. „Wir stimmen unsere automatisierten Tools kontinuierlich ab und passen sie an, um die Genauigkeit zu verbessern, und überführen diese Ergebnisse dann in eine Engine zur Anpassung des Schweregrads“, so Hills.

„Die Nexus-Plattform unterstellt nicht, wie Sie sie nutzen wollen. Sie versorgt Sie mit Informationen. Sie stellt Ihnen Daten zur Verfügung und gibt Ihnen dann die Werkzeuge an die Hand, um diese Informationen heranzuziehen, sie anzupassen und mit ihnen zu machen, was Sie wollen.“

– Jason Hills, Head of Application Security, TD Bank

Die Lösung

Als die TD Bank mit ihrer agilen Transformation begann, erkannten McArthur und Jovanovic schnell, dass sie tiefgreifende Veränderungen bei den Werkzeugen, der Praxis und der Philosophie benötigen würden. Eines der Kernprinzipien agiler Methoden ist die frühzeitige und häufige Bereitstellung funktionsfähiger Software. Für ein Unternehmen mit einer langen Historie der Entwicklung nach dem traditionellen Wasserfall-Prinzip, wie die TD Bank, erforderte dies mehr als nur das Setzen verschiedener Release-Meilensteine. Es bedurfte einer umfassenden Überholung der eingesetzten Werkzeuge.

Die TD Bank machte sich dies mit McArthur und Jovanovic als frühen Anwendern zu eigen. So beschreibt McArthur die Einführung der Werkzeuge, die ihre agile Transformation begleiteten, wie folgt:

„Um agil arbeiten zu können, mussten wir die Werkzeuge modernisieren, mit denen wir früher erfolgreich waren. Also nutzten wir die Gelegenheit, um dies innerhalb der Entwicklung mit all unseren CI-Werkzeugen zu tun. Damals entschieden wir uns für einen Atlassian-Stack und setzten die Nexus-Plattform ein. Aus CI-Sicht war das der Moment, als wir anfingen, uns vorwärts zu bewegen.“

Diese Werkzeugauswahl war wichtig, um die Herausforderung der Agilität zu bewältigen – die Forderung nach einer schnelleren Release-Kadenz. Es gab dem Team auch die Möglichkeit, andere Herausforderungen zu meistern. Zum Beispiel stellte diese schnellere Auslieferungskadenz die Bank vor zusätzliche Hindernisse, was die rechtzeitige Nachweisbarkeit und die Verbuchung von Komponenten in der Produktion betraf. Durch die Einführung von Nexus Repository war TD Bank in der Lage, alle in einer Produktionsumgebung eingesetzten Komponenten schnell und endgültig zu verfolgen und zu dokumentieren.

Die Vorteile verbesserter Werkzeuge erstreckten sich noch auf weitere Bereiche. So war TD Bank in der Lage, ihren Governance-Zyklus auf einen früheren Zeitpunkt zu verlagern und deutlich effizienter zu werden. Durch den Einsatz von Nexus Lifecycle entschärfte TD zwei wesentliche Problempunkte: einen langen, arbeitsintensiven Evaluierungsprozess für Komponenten und die organisatorische Vermeidung des Einsatzes von Open-Source-Technologien. Dadurch wurde aus einem manuellen Prozess, der unzählige Mitarbeiterstunden erforderte, ein automatisierter Prozess, der es den Entwicklern ermöglichte, sich innerhalb von Minuten selbst zu bedienen.

Auf Basis solcher Erfolge konnten McArthur und Jovanovic den agilen Wandel und die Veränderungen bis zur kritischen Masse vorantreiben. Mit Blick auf einen organisatorischen Wandel weist Jovanovic darauf hin, dass dieser, „wenn er im Verborgenen stattfindet, einfach gar nicht stattfindet“. Sie nutzten diesen anfänglichen Schwung und setzten die Veränderungen im Rahmen einer höchst bedeutsamen organisatorischen Initiative um. „Es bedurfte dieser großen Initiative, um diese Veränderungsprozesse tatsächlich voranzutreiben, zu strukturieren und zu formalisieren“, resümiert Jovanovic.

Agile Transformation, bessere Werkzeuge und organisatorische Anpassung hatten den Wendepunkt erreicht. Dennoch blieben weder die Herausforderungen noch die Innovation aus. Als er zu TD kam, schätzte Hills zwar die vorhandenen Werkzeuge und das Reporting, er erkannte jedoch auch sofort Bereiche mit Verbesserungspotenzial. Die konsolidierte Berichterstattung von TD unterschied nicht zwischen intern entwickeltem Code und Code, der von externen Bibliotheken bezogen wurde. Während SAST-Tools diese Unterscheidung nicht treffen, ist dies bei Nexus Lifecycle der Fall. Hills sagt in diesem Zusammenhang: „Der Software Development Lifecycle ist in hohem Maße anpassbar, wodurch wir nicht nur Komponenten von Drittanbietern identifizieren, sondern auch unsere internen, proprietären Komponenten katalogisieren konnten. Dieser Detaillierungsgrad in unserer unternehmensweiten Bill of Materials ist der Schlüssel zum Verständnis unserer Risikostruktur im gesamten Portfolio. Wenn ich ein Programm zur Anwendungssicherheit von Grund auf neu starten würde, wäre der Aufbau dieser Bill of Materials das Erste, was ich tun würde.“

Während sich die TD Bank weiter verbessert und neue Herausforderungen meistert, stellt die Nexus-Plattform weiterhin die Werkzeuge bereit, um all das möglich zu machen.

Das Ergebnis

Die TD Bank konnte in der Welt der agilen Transformationen etwas Beeindruckendes erreichen. Man erkannte schnell, dass die Umstellung auf eine neue Methodik erhebliche Veränderungen in Bezug auf die Tools und die Infrastruktur mit sich bringen würde, doch das akzeptierte man von Anfang an.

Aufgrund dieses Ansatzes folgte die DevOps-Kultur ganz natürlich der agilen Transformation des Unternehmens. Jovanovic erwähnt, dass man nun formell DevOps-Verfahren eingeführt habe, und McArthur weist darauf hin, dass diese frühe ganzheitliche Strategie dazu geführt hat, dass das Team fast von Anfang an einen DevOps-Ansatz verfolgte. 

Mit guten Werkzeugen, einer soliden organisatorischen Disziplin und werthaltigen Business Cases scheint es unausweichlich, dass diese Änderungen unternehmensweite Akzeptanz finden. Die Tatsache, dass es im Nachhinein offensichtlich erscheint, macht es nicht weniger beeindruckend.

Die organisatorischen Veränderungen sind tiefgreifend. Alle Parteien wissen das Erreichte zu schätzen, vor allem wenn man sich daran erinnert, wie es früher einmal war. Zurückblickend auf den manuellen Evaluierungsprozess für Komponenten, welcher der Nexus-Plattform vorausging, sagt McArthur: „Ich kann mir nicht einmal vorstellen, wie es heutzutage wäre, zu einem manuellen Prozess zurückzukehren. Ich kann mir nicht einmal vorstellen, wie lange das dauern würde. Denn damals, als wir es noch manuell machten, haben wir gezielt weniger Open-Source-Software eingesetzt – einfach weil es so mühsam war.“

Es gibt vielleicht kein besseres Anzeichen für eine erfolgreiche Transformation, als dass die alten Vorgehensweisen dank der Effizienz des gegenwärtigen Zustands undenkbar werden.

VERTRIEB KONTAKTIEREN

Möchten Sie sich selbst von Nexus-Produkten überzeugen?

Sonatype, die Entwicklungslösung der Superlative