Ben Weisheit ist Lead-Developer im SAP-Umfeld der Netze BW GmbH. Seit knapp
eineinhalb Jahren nutzen er und seine Kolleginnen und Kollegen Teamscale, um die Qualität abzusichern. Im Interview mit Sven Amann (CQSE) erzählt Ben, was es bisher gebracht hat.
Sven: Lass uns damit einsteigen, dass Du mir ein bisschen Kontext gibst. Was genau macht ihr mit Teamscale und mit der CQSE?
Ben: Wir haben 2022 mit einem Teamscale-POC begonnen und Anfang 2023 dann eine Lizenz für das SAP-Umfeld der Netze BW gekauft. Dieses Jahr haben wir sie auf einen deutlich größeren Bereich ausgerollt, auch auf die EnBW und weitere Tochterfirmen. Wir analysieren inzwischen mehrere Systeme und unterstützen um die 100 Entwicklerinnen und Entwickler mit Teamscale.
Sven: Was ist Deine Rolle dabei?
Ben: Ich bin Lead-Developer im SAP-Umfeld und als solcher verantwortlich für den Prozess und die Richtlinien. Und ich bin auch der, der damals Teamscale angeschleppt hat (lacht). Ich kannte Teamscale schon von woanders her und wollte das auch hier haben.
Sven: Du hattest also Vorerfahrung und hast gesagt: “Teamscale bringt uns was”?
Ben: Ja, ich fand gerade die Visualisierungen der Qualitätsmessungen klasse, das ist einfach super dargestellt.
Sven: Was war denn eure technische Ausgangssituation bei Netze BW?
Ben: Wir haben eine große Codebasis aus einem viele Jahre alten R/3 System nach S/4HANA migriert. In diesem altgedienten Code gibt es aus der Historie heraus viele Low-Level-Findings und nicht immer ganz optimale Abhängigkeiten. Vor dem Einsatz von Teamscale hatten wir den CodeProfiler als Analysewerkzeug im Einsatz. Dort haben wir die Findings aber vor allem beim Deployment (“Transport” heißt das im SAP-Umfeld) gesehen und nicht selten einfach weggeklickt, auch weil das Baselining nicht wirklich gut umgesetzt war und deshalb immer wieder alte Findings hochkamen.
Sven: Und was hat sich jetzt verändert?
Ben: Mit Teamscale ist das alles visualisiert und für jeden immer greifbar. Ich sehe z.B. den Trend der Analyse-Findings und der Lines of Code. Und diese ständige Transparenz führt dazu, dass die Leute von sportlichem Ehrgeiz gepackt werden und die Findings in ihren Bereichen loswerden wollen. Das flankieren wir immer wieder mit Retrospektiven, zu verschiedenen Themen rund um den Code und die Qualität. Bei Netze BW haben wir im Kleinen erlebt, dass sich der Trend auf diese Weise umkehrt und die Findings nicht weiter anwachsen und Teamscale dann auf weitere Konzerneinheiten und Systeme der EnBW ausgerollt.
Sven: Du hast gerade gesagt, dass das System bei Netze BW kleiner war und das bei EnBW größer ist. Von welcher Größenordnung sprechen wir da?
Ben: Netze BW hat hier ungefähr 1,5 Million Lines of Code. Die EnBW nochmal 1,5 Million Lines of Code im System und nochmal 1 Million Lines of Code, die von anderen Konzerneinheiten oder gemeinsam genutzt werden. Inzwischen haben wir noch ein größeres System, mit 8 Million Lines of Code, dazugenommen. Was ich toll finde, ist, dass wir den Schmerz jetzt sichtbar machen können, auch gegenüber dem Management.
Sven: Wie genau hilft euch Teamscale denn, Themen nach oben ins Management zu tragen?
Ben: Da muss ich etwas weiter vorne anfangen: Die Entwicklung in der neuen SAP HANA-Welt ist ein bisschen anders als in der alten R/3-Welt. Es gibt neue Programmiermodelle und andere Themen, die jetzt wichtig werden, wie z.B. Cloud-Readyness. Auch unsere Programmiersprache ABAP hat sich über die Jahre stark weiterentwickelt und wir müssen unsere Arbeitsweise an vielen Stellen anpassen. Außerdem machen es uns die verschiedenen, alten Programmierparadigmen, die wir im Rahmen unserer Brownfield-Migration geerbt haben, schwer, die bestehenden Lösungen so anzupassen, dass wir von der neuen Plattform auch einen Vorteil haben. Die Visualisierungen in Teamscale sind da wertvoll, weil sich jeder jederzeit selbst darüber informieren kann, wo wir bei der Modernisierung gerade stehen. Und zwar anhand objektiver Messungen und visuell so dargestellt, dass Klone, Modularitätsmetriken, Test Gaps, Dead Code oder Architekturanalysen sehr gut zugänglich sind. Damit kann man Probleme und deren Wichtigkeit schnell und klar aufzeigen, ohne dabei zu tief in technische Details eintauchen zu müssen.
Zum Beispiel kann man die Visualisierungen nutzen, wenn es darum geht, an welcher Stelle man zuerst in Verbesserungen investieren sollte. Das sehen auch die Kollegen in anderen Bereichen, die ähnliche Rollen haben, und waren deswegen auch schnell von Teamscale begeistert.
Sven: Was war denn die größte Hürde, die Du überwinden musstest, bis Du die Qualität so zeigen konntest?
Ben: Unser POC im Umfeld der Netze BW, war ja nicht so kostenintensiv und hat schnell einen Mehrwert geliefert. Ein bisschen länger hat es gedauert, den Codeprofiler konzernweit abzulösen. Da waren schon einige Abstimmungen und Vorstellungstermine nötig.
Sven: Was würdest Du sagen, ist das wertvollste, was Teamscale euch bringt?
Ben: Die ständige Transparenz und die starke Visualisierung. Also Transparenz über den aktuellen Zustand und Visualisierung der technischen Schulden. Das zusammen öffnet ganz neue Möglichkeiten, sich über Software auszutauschen und mit den beteiligten Personen zu kommunizieren. Und wie erhofft wurde das neue Tool von den Entwicklerinnen und Entwicklern auch super angenommen. Eventuell war es hier auch hilfreich, dass wir vorher den CodeProfiler im Einsatz hatten und das Thema statische Code-Analyse nicht neu für uns war. Ich habe den Eindruck, dass das Tool als hilfreich empfunden wird und bei vielen den sportlichen Ehrgeiz anspricht, das finde ich super!
Sven: Das klingt nach einer konstruktiven Atmosphäre.
Ben: Total. Und vor diesem Hintergrund ist es uns auch wichtig, jeden dabei mitzunehmen und die entsprechende Unterstützung anzubieten.
Sven: Mit welchen Teamscale-Features arbeitet ihr denn viel?
Ben: Wir machen viel mit der Architekturanalyse. In unserer über lange Jahre gewachsenen Welt mit viel altem Code sehe ich dort endlich mal die “Ist”-Architektur (Abb. 1). Wir haben da auch Entwicklungen dabei, die 20 Jahre alt sind und von denen ich nicht immer genau weiß, was dieser Code eigentlich macht und ob wir ihn überhaupt noch brauchen. Die Architekturanalyse nehme ich dann als Grundlage, um mit Entwicklern und Fachbereichen zu sprechen, den fachlichen Kontext zu erfragen und darüber zu bewerten, ob eine technische Abhängigkeit zwischen Projekt X und Projekt Y gerechtfertigt ist oder nicht.
Abb. 1: Modellierung der Architektur in Teamscale.
Dieses Übereinanderlegen der Fachlichkeit und der Ist-Architektur soll dann zum Ausgangspunkt werden, um sich in Richtung lose gekoppelter Domänen weiterzuentwickeln. Das ist das, was mich gerade am meisten reizt.
Was ich auch total gut finde, ist, dass ich auf einen Schlag den Dead Code im ganzen System sehen kann. Über die Treemaps finde ich schnell zusammenhängende tote Stellen (Abb. 2) und kann mich dann aufmachen, um herauszufinden, ob wir diesen Code vielleicht doch noch brauchen. Gerade im Rahmen der Clean-Core-Umstellung, die vor uns liegt, ist es wichtig, zunächst den Dead Code loszuwerden, um keinen unnötigen Aufwand bei der Migration und der Wartung zu haben. Und dafür ist diese Sicht natürlich super wertvoll.
Und wenn andere Entwicklerinnen und Entwickler Teamscale zum ersten Mal kennenlernen, sind sie oft beeindruckt und entwickeln nicht selten diesen Ehrgeiz, die Statistik zu verbessern, indem sie Findings ausbauen. Dass man diese Verbesserungen dann auch direkt und langfristig sieht, ist total motivierend! Außerdem nutzen wir die Findings als gemeinsame Basis, um in unseren Retros über Code zu sprechen.
Abb. 2: Die “Execution Treemap” zeigt, welche Teile der Codebasis auf dem Produktivsystem zur Ausführung kamen.
Sven: Jetzt erwähnst Du zum zweiten Mal eure Retros. Kannst Du dazu noch ein paar Worte sagen?
Ben: Ja, das sieht man hier ganz schön: Die Lines of Code sind lange Zeit relativ parallel zu den Findings gewachsen (Abb. 3). Nachdem wir mit den Retros angefangen haben und seitdem gemeinsam über Codequalität sprechen, gehen die Kurven deutlich stärker auseinander. Später haben wir auch die Deployment Freigabe in Teamscale eingeführt und seitdem gehen die Findings nochmal weiter runter!
Abb. 3: Entwicklung der Anzahl der Findings und der Lines of Code über ein Jahr.
Sven: Wer nimmt an den Retros teil?
Ben: Bisher das SAP-HANA-Entwicklungsteam für die Instandhaltung der Netze, aber wir wollen das Format auch auf weitere Bereiche ausrollen. Als Vorbereitung für so eine Retro suche ich passende Findings zum jeweiligen Thema raus, über die wir dann reden. Angefangen haben wir mit den Security Vulnerabilities, da diese Themen wenig polarisieren und wir uns so erstmal auf das Format an sich konzentrieren konnten. Weitergemacht haben wir dann mit dem Dead Code und dem Modernisierungsblock. Und so hangeln wir uns vor und erarbeiten uns eine gemeinsame Sicht auf das Thema Softwarequalität.
Außerdem versuchen wir, in den Retros immer konkrete Todos herauszuarbeiten. Die Security-Findings haben wir z.B. bereits zu großen Teilen abgebaut. Zunächst für die internen, und dann auch für die extern geleisteten Entwicklungen. Um die Governance zu verbessern, dürfen Externe auch keine kritischen Findings überspringen, sondern müssen sie vor dem Deployment von Internen freigegeben lassen.
Sven: Verstehe. Und auf Ebene der Lead Developer, habt ihr da einen Austausch oder eine Plattform geschaffen, um Teamscale in die Breite zu tragen?
Ben: Ja. Es gibt eine Lead-Developer-Runde, in der ich die Erfahrung der Netze mit Teamscale geteilt habe. Sie ist der Multiplikator, der zum Beispiel dafür sorgt, dass das Thema Retros auch in die anderen Bereiche getragen und als Diskussionsgrundlage etabliert wird.
Sven: Stichwort Diskussionsgrundlage. Du hast eben von “Governance” gesprochen. In Teamscale pflegt ihr dafür ja Analyseprofile, in denen ihr festlegt, was ihr prüfen wollt und worauf ihr Wert legt. Wer setzt denn diesen Rahmen?
Ben: Anfangs haben wir die Prüfungen zunächst nur nach den Vorstellungen der Netze konfiguriert und dann mit dem Feedback aus dem POC nach und nach verfeinert. Mit dem Roll-out auf die weiteren Systeme und Bereiche übernimmt die Lead-Developer-Runde diesen inhaltlichen Teil. Da SAP so viele Prozesse und Entwicklungen integriert und die Prüfungen damit auch viele Leute betreffen, ist es für die Akzeptanz wichtig, hier eine breite Basis zu haben.
Sven: Das heißt, da ist noch viel Wachstum und Veränderung, die ihr vorantreibt?
Ben: Sagen wir mal so: die Basis ist gelegt. Wir haben starke Werkzeuge und einen Satz an sinnvollen Prüfungen und jetzt gilt es, damit zu arbeiten und die Themen zu priorisieren. Wo habe ich Anwendungen mit Security-kritischen Findings? Wo sind Backdoors, Architekturverletzungen und was baue ich zuerst aus? Welche Teile des Systems werden nicht mehr genutzt und können entfernt werden? Wollen wir uns als Team einigen, dass Methoden und Klassen in Zukunft kleiner sein sollten? Da geht die Arbeit jetzt los. Im darüber Sprechen und in konkreten Arbeitspaketen.
Und für neue SAP Systeme, die wir im Greenfield aufbauen, planen wir von Anfang an Teamscale in Kombination mit ein paar SAP-eigenen Mechanismen einzusetzen, damit solche Themen gar nicht erst entstehen.
Sven: Wo Du die SAP-eigenen Mechanismen ansprichst. Habt ihr euch auch Alternativen zu Teamscale angeschaut?
Ben: Ja, wir haben SonarQube für ABAP ausprobiert und hatten den CodeProfiler im Einsatz. Auch wenn es nicht die billigste Lösung war, haben wir uns trotzdem bewusst für Teamscale entschieden. SonarQube erschien uns für das Thema ABAP recht schwach aufgestellt zu sein. Der CodeProfiler kommt zwar mit mehr Checks, aber er kann sie weder gut visualisieren, noch deckt er die Breite an Qualitätsthemen ab. Das war für uns ausschlaggebend.
Sven: Vielen Dank für diese Einblicke! Möchtest Du noch etwas hinzufügen?
Ben: Ja, ich möchte an dieser Stelle auch den tollen Support loben. Ihr kümmert Euch nicht nur um Updates, sondern seid bei Fragen oder Problemen auch direkte Ansprechpartner für unsere Entwicklerinnen und Entwickler und helft dann immer tatkräftig und zeitnah. Das funktioniert längst nicht bei allen Lösungen, die wir im Konzern haben, so gut und ist super angenehm, weil es mir den Rücken frei hält.
Sven: Super, vielen Dank für das Interview, Ben!