Sven: Christian, was war eigentlich deine Motivation, dich mit dem Thema Softwarequalität auseinanderzusetzen?

Christian: Ich habe mir zwei Fragen gestellt: “Wie schaffen wir mehr Releasesicherheit?” und “Wie kommen wir zu einer besseren Paketstruktur innerhalb unseres SAP Systems?” Beides motiviert aus meiner Funktion als Softwarearchitekt.

Zur ersten Frage: In der Regel erweitern Kunden der SAP ja die SAP-Standardfunktionalität. Dabei gehen sie ein mehr oder weniger großes Risiko ein, da die Eigenentwicklungen nach einem Upgrade dieser Standardfunktionalität nicht mehr wie gewünscht funktionieren. Je enger die Verzahnung mit SAP-Standardobjekten ist, desto größer das Risiko. SAP bietet zwar Tools, um problematische Stellen zu erkennen, letztendlich lässt sich das aber nur durch große, aufwendige Integrationstests verifizieren.

Zur Zeit führen wir alle 2 Jahre Releasewechsel durch und dabei sind auch weitere SAP-Systeme involviert, wie zum Beispiel ein CRM. Die Dynamik in einem älteren SAP ERP ist lange nicht so hoch wie z.B. in den modernen S/4-HANA-Systemen. Dort wird auch für die im eigenen Rechenzentrum betriebenen Systeme (S4 Hana on Premise) der Takt vom Cloud-Produkt (S/4 Hana Cloud) vorgegeben, da SAP für beide Welten eine gemeinsame Codebasis vorsieht. Vielleicht wollen wir in einem S/4-System künftig jedes Jahr modernisieren und deshalb ist die Frage nach den Abhängigkeiten zentral.

Und zur zweiten Frage: Wir kommen aus einem 46C System, wo es nur die Entwicklungsklasse gab und keine weitergehende Paketstruktur. Diese Möglichkeit kam erst später hinzu und die Entwickler haben das nicht angenommen, jedenfalls nicht durchgängig. Daher gibt es in unserem System sehr große Pakete mit Tausenden von Entwicklungsobjekten. So würde man State-of-the-Art nicht mehr schneiden.

Da spielt auch rein, dass wir dezentral aufgestellt sind. Das bedeutet, wir haben Abteilungen und Gruppen, die immer den entsprechenden Geschäftsführungsbereichen gespiegelt sind. Für den  Bereich Finanzen gibt es eine IT-Abteilung, die sich speziell mit deren Anforderungen beschäftigt. Der Vertrieb genauso. Die Gruppen dieser Abteilungen entwickeln relativ autark und entscheiden bottom-up über die Implementierung. Das merkt man natürlich auch im Code, wenn man z.B. schaut wie viel noch prozedural ist und wo schon objektorientiert programmiert wird. Oder halt bei der Architektur, die – zumindest aus der Historie heraus – nicht zentral von oben verordnet wurde, sondern aus der Entwicklungstätigkeit in den einzelnen Gruppen entstanden ist.

Mit diesen beiden Fragestellungen bin ich losmarschiert und wollte mehr Transparenz erzeugen. Zuerst habe ich einfach mal gezählt: Wie viele Objekte rufen wir intern auf? Und wie viele Objekte rufen wir Richtung SAP auf? Und so kam dieses Bild zustande, das du schon kennst:

Treemap der Paketstruktur in der Eigenentwicklung und den verwendeten SAP-Paketen. Die Größe der Pakete korreliert mit der Anzahl enthaltener Entwicklungsobjekte. Die Verbindungen zeigen die Abhängigkeiten.

Das hätte ich auch vertiefen können, aber klar war: Jetzt Stop! Weil das hilft nur zum Erschrecken und nicht als Arbeitsgrundlage.

Und gleichzeitig kam die Erkenntnis: Es geht nicht nur um die Funktion von Analysetools, sondern darum, wie ich mit den Ergebnissen umgehe! Die Tools auf dem Markt würden für unsere Anforderungen wahrscheinlich fast alle funktionieren. Aber die Frage ist: Funktioniert der Prozess dahinter bzw. kann man einen funktionierenden Prozess darauf aufbauen?

Sven: Jetzt habt ihr uns ja im ersten Schritt für einen Audit beauftragt und gar nicht für eine Prozesseinführung. Wie kam das zustande?

Christian: Mich haben damals Themen wie Softwarequalität, technische Schulden und Refactoring umgetrieben. Was macht man denn mit einem organisch gewachsenen System? Wie geht man da vernünftigerweise vor? Und dabei ist es ja unerheblich in welcher Programmiersprache ich mich bewege. Die Fragestellungen sind immer die gleichen. Also bin ich 2018 zum Architecture Gathering gefahren, weil es da genau um diese Themen ging. Und dort habe ich in der Präsentation der CQSE zu Teamscale gesehen: Die können auch ABAP! Was für mich ein Entscheidungskriterium war (lacht).

Anschließend haben wir erstmal einen Audit für ein System beauftragt. Eine Standortbestimmung. Es ging uns dabei nicht primär darum, das konkrete System zu verbessern, sondern wir haben offen gefragt: Wie kommen wir nachhaltig zu mehr Qualität? Wie kommen wir dahin, dass die Findings des Analysetools begleitend bearbeitet werden und nicht im Nachgang sanktioniert werden müssen?

Der Audit hat uns Trends gezeigt. Bewegt sich das System zum Guten? Zum Schlechten? Bleibt es neutral? Das gab uns die Chance zu steuern. Zu agieren, statt zu reagieren. Und darauf kann man einen (Tool-gestützten) Prozess aufbauen.

Sven: Wie habt ihr denn das System ausgewählt, mit dem ihr gestartet seid?

Christian: Wir haben nicht versucht vorsichtig zu sein und zu sagen: “Ok, wir sondieren erstmal so ein kleineres System, das tut ja nicht weh.” Sondern wir haben das zentrale Entwicklungssystem, unsere ERP-Landschaft, genommen. Da sind die Schmerzen beim Releasewechsel auch ziemlich groß. Das heißt, da stringenter zu werden, das ist schon reizvoll!

Sven: Und dann kam der Auftrag für Quality Control?

Christian: Mit der Standortbestimmung habt ihr bewiesen, dass Teamscale ein tolles Produkt ist, mit dem man ausgezeichnet Findings detektieren kann. Mit der Transparenz kam aber auch der Wunsch nach Verbesserung und wir haben schnell gemerkt, dass der Weg über eine nachhaltige Verbesserung der Qualität nicht über das Tool, sondern über den Prozess geht.

Sven: Klingt jetzt so, als wäre das alles ein Selbstläufer gewesen. Wahrscheinlich gab es aber doch diverse Herausforderungen solche Projekte zu motivieren und zum Laufen zu kriegen, oder?

Christian: Sehr suggestiv die Frage (lacht).

Tatsächlich gab es keine Widerstände aus dem Management. Und auch die Kollegen aus der Entwicklungskoordination und die Entwicklerteams sind sehr offen und interessiert in das Thema eingestiegen. Selbstverständlich ist nicht zu vernachlässigen, dass, bis alles aufgesetzt ist und alle abgeholt sind, bei einem größeren Unternehmen trotzdem ein paar Runden zu drehen sind.

Das Risiko auf Widerstände zu stoßen, ist natürlich insbesondere dann gegeben, wenn man mit konkreten Findings in die Diskussion geht. Und deswegen war mir ja auch wichtig, dass es über den Audit hinausgeht. Am Ende wollen wir eben nachhaltige Qualitätsverbesserung haben und da hilft es uns nichts, wenn wir eine riesige Liste bekommen, diese dann in die Abteilungen streuen und sagen: “So, macht mal unser System wieder schön.” Denn dann kommt genau das zustande, was gerne passiert: Es wird eingeplant – aus Kapazitätsgründen kann das dann durchaus auch mal länger gehen, bis es umgesetzt wird – es wird eine Risikoabwägung durchgeführt und dabei diskutiert, warum jetzt dieses eine Finding vielleicht doch nicht so schlimm ist, wie wir vielleicht gedacht haben. Das sind genau die Themen, die ich vermeiden wollte. Mir ging es um das Gesamtsystem und um den Prozess. Ich wollte in einen vernünftigen Regelkreis kommen.

Sven: Das heißt du siehst den kritischen Punkt vor allem in der Einführung eines solchen Werkzeugs und Prozesses? Also darin zu kommunizieren, dass wir nicht die "Qualitätspolizei" sind, sondern eine Unterstützung der Entwicklung. Und sicherzustellen, dass das auch langfristig so bleibt?

Christian: Definitiv. Und das haben die Qualitätsingenieure der CQSE auch sehr sehr gut gemacht und sehr viel Fingerspitzengefühl gezeigt, wenn zum Beispiel Themen hoch kamen wie Schachtelungstiefe oder Methodenlänge oder überhaupt die Situation des Systems dargestellt wurde. Das ist für mich das A und O. Ich denke, dass wir – auch in Zukunft – hart daran arbeiten müssen, dass auch der letzte Entwickler abgeholt ist und den Mehrwert im Prozess erkennt und ihn lebt. Durch das Etablieren des Prozesses ist noch nichts geregelt, nur der Rahmen geschaffen.

Sven: Was ist denn zu diesem fortlaufenden Prozess aus deiner Sicht der wichtigste Beitrag, den wir liefern können? Oder liefern?

Christian: Ich glaube wir müssen uns damit auseinandersetzen, ob wir als SEW so eine Rolle des Qualitätsingenieurs auch intern besetzen. Es bräuchte ein Onboarding durch die CQSE, aber dann könnte eure Rolle hier schrittweise geringer werden.

Gleichzeitig glaube ich aber, dass es hilfreich ist die CQSE bei Projekten, wo die Entwicklung außer Haus gegeben wird, dabei zu haben. Hier könnt ihr, als neutrale Instanz zwischen Kunde und Lieferant, die Sachebene gewährleisten, was einen klaren Mehrwert bietet.

Sven: Vor dem Hintergrund von allem worüber wir jetzt gesprochen haben, würdest du die Zusammenarbeit mit uns weiterempfehlen? Und wenn ja, warum?

Christian: Ja, unbedingt! Ich sage es nochmal: Ich weiß, dass es Mitbewerber gibt, die wahrscheinlich Tool-seitig mit einem ähnlichen Niveau aufwarten. Der entscheidende Punkt ist für mich aber der Umgang im Prozess. Wie die Leute auftreten und wie sie in den Teams aufgetreten sind. Das ist für mich ein klares Plus. Und ja auch eine Vertrauenssache!

Ich würde jederzeit wieder sagen: Lasst uns ein Team aufsetzen und von der CQSE einen Qualitätsingenieur besorgen, der das Team entsprechend führt und die Denkweise der Entwickler fördert in die Richtung: “Lasst uns über den Sourcecode reden – wie lässt der sich verbessern. Wie seht ihr denn das?” Aus Fehlern lernen wir alle, noch besser aber wenn es gemeinsam geschieht.

Es ist ja nicht nur eine One-Man-Show “Ich sag euch wie ihr es besser macht”. Da wollen wir nicht hin. Ich möchte die Mündigkeit der Entwickler fördern. Und da habe ich viel Vertrauen in die CQSE uns dabei zu unterstützen.

Sven: Vielen Dank, das freut mich. Gibt es noch etwas, das du hinzufügen möchtest?

Christian: Tatsächlich glaube ich die Botschaft ist bei den Beteiligten angekommen. Es geht mir vor allem um den Prozess. Ihr habt das als Unternehmen wirklich sehr gut begleitet und das ist für mich das Ausschlaggebende. Am Ende funktioniert das alles nicht, wenn der Prozess nicht passt und darum geht es. 

Sven: Das ist doch ein schönes Schlusswort, vielen Dank.