Development Testing

Qualität in SAP-Systemen verbessern

SAP-Systeme sind in fast jedem großen Unternehmen vorhanden und für Außenstehende oft eine Blackbox. SAP-Teams agierten viele Jahre in einer eigenen Welt, in der Best Practices der Softwareentwicklung wenig verbreitet sind. Der Artikel zeigt einen Weg, aus dieser Isolation auszubrechen und Entwickler zu mehr Qualität zu motivieren.

Dominik Panzer

Author

10.04.2024
Lesezeit: 17 Minuten
279 Views

Menschen außerhalb des SAP-Kosmos kennen SAP-Systeme meist kaum und haben nur Kontakt, wenn sie Schnittstellen zu diesen Systemen benötigen.

Ein Blick in die historische, monolithische SAP-Welt

Ein SAP-System wird klassisch mit einer eigenen Programmiersprache namens ABAP auf einem zentralen Applikationsserver durch die Kunden selbst weiterentwickelt. Datenzugriffe sind nicht eingeschränkt und das System kann erweitert und angepasst werden, sowohl durch Veränderung von Einstellungen als auch durch Programmierung. Hierzu werden auch Implementierungen, die durch die SAP ausgeliefert werden, kopiert und geändert. Historisch wird als Oberfläche die SAP GUI verwendet, Versionsmanagement erfolgt mit einer SAP-eigenen Lösung.

Oft finden sich in SAP-Teams Quereinsteiger, die gängige Prozess- und Entwicklungsmodelle nicht kennen oder nicht anwenden. Durch Fluktuation, auch von externen Beratern, sind viele Entwicklungen in verschiedenen Stilen programmiert, was die Wartung erschwert.

Objektorientierte Programmierung ist möglich, wird aber oft nur genutzt, um altes Coding in Klassen zu kopieren, ohne deren Vorteile zu nutzen. Automatisiertes Testen auf verschiedensten Ebenen ist kaum verbreitet.

Der Druck auf Unternehmen wächst

Lange Zeit konnten Unternehmen trotz dieser widrigen Gegebenheiten erfolgreich am Markt agieren. Die Möglichkeit, SAP-Systeme nahezu unbegrenzt anpassen zu können, war dabei ihre größte Stärke. Heute ist dies ihr größtes Problem: Es haben sich über Jahre riesige Mengen an Legacy-Code angesammelt. Es steigen der Kosten- und der fachliche Innovationsdruck. Flankiert wird dies technologisch durch moderne webbasierte UI-Oberflächen, Programmiermodelle und Cloud-Lösungen der SAP.

Der Umzug in neue SAP S/4HANA-Systeme ist bei vielen Unternehmen verbunden mit dem Fokus auf Restandardisierung von Prozessen hin zu dem, was die SAP ausliefert. Dabei wird die strikte Trennung zwischen dem SAP-Coding und den Eigenentwicklungen – die sogenannte Clean-Core-Strategie – verfolgt, um das System langfristig wart- und evolvierbar zu halten.

Ohne Tooling keine Qualität?

Das SAP-Ökosystem ist im ABAP-Bereich seit vielen Jahren ausreichend ausgestattet, um hochqualitative Software zu entwickeln. Ergänzt werden sie von vielen Open-Source-Erweiterungen wie abapGit [abap-Git], ABAPLint [abaplint] oder Cacamber [GitHPan].

In den neueren Bereichen des Systems, die mit dem webbasierten SAPUI5 als Frontend arbeiten, können spezialisierte Tools wie wdi5 [wdi5] angewendet werden, aber auch alles, was im JavaScript-Ökosystem vorhanden ist.

Starting the Change – Änderungen bottom up initiieren

Nachfolgend wird beschrieben, wie eine Organisation schrittweise eine Verbesserung der Qualität von SAP-Systemen erzielen kann. Der Fokus liegt beispielhaft auf klassischer ABAP-Entwicklung, da dort meist die größten Probleme herrschen, ist aber auch darüber hinaus anwendbar.

1. Initialisierung

Innerhalb der SAP-Entwicklungsabteilung gibt es in der Regel mindestens eine Person, die mit dem Status quo besonders unzufrieden ist oder sich auch für neue Technologien interessiert – vielleicht sogar außerhalb des SAP-Kosmos. Sie bildet sich oft eigenständig weiter, möchte Konferenzen besuchen und bildet neue Mitarbeiter aus. Meist ist sie ein respektiertes Mitglied im Unternehmen aufgrund ihrer technischen und sozialen Kompetenzen, auch ohne hierarchische Beziehungen. Vielleicht sind Sie diese Person sogar selbst oder können diese werden.

Diese Person oder gar mehrere bilden den Ursprung einer möglichen Veränderung hin zu einer gemeinsamen Vision. Existiert keine solche Person, ist es erfahrungsgemäß aus folgenden Gründen nur schwer möglich, die Qualität nachhaltig zu steigern:

Qualität liegt in der Kompetenz der Entwicklungsteams, dem Management fehlt meist die technische Expertise. Daher werden Managementvorgaben als von oben herab betrachtet und sind nicht motivierend. Maßnahmen werden unzureichend umgesetzt oder gezielt umgangen. Incentivierungsmodelle haben unserer Erfahrung nach nur einen kurzfristigen Effekt.
Ohne Key-Player, die das Thema nachhalten, verankert sich kein Qualitätsbewusstsein im Team, sodass früher oder später Qualität wieder zugunsten von Features geopfert wird.
Oft sind auch Steuerung und Qualitätsprüfung für externe Mitarbeiter notwendig. Hierfür ist eine Person notwendig, die aus intrinsischer Motivation heraus das Thema begleitet und die Steuerung übernimmt.

Hilfreich ist es, externe Coaches zusätzlich für eine längere Begleitung bereitzustellen.

Einmalige Coaching-Events verpuffen, da die Komplexität des Tagesgeschäfts nicht hinreichend berücksichtigt werden kann. Wichtige Kriterien für externe Unterstützung sind:

Kenntnisse der innerhalb von SAP verfügbaren Tools sowie Erfahrung im Refactoring von SAP-Code.
Kenntnisse der SAP-Welt und grundlegenden Entwicklertechniken wie Unittests, Test-Isolation, Automatisierung usw., aber insbesondere auch der Restriktionen, da zum Beispiel keine lokale Entwicklung und Testing möglich ist und Datenbanken nicht einfach ausgetauscht werden können.
Sensibilität im Coaching, sodass die Entwicklungsteams ihren eigenen Weg finden können, statt nach starren Vorgaben zu agieren.

2. Verbündete finden

Der Key-Player allein kann kaum einen Change bewirken. Er benötigt Unterstützer, die dann in den einzelnen Teams als Multiplikatoren wirken: Beispielsweise kann auf einem Abteilungsmeeting darüber gesprochen werden, dass zwar grundsätzlich eine Basis wie Entwicklungsrichtlinien bestehen, die Entwickler aber aufgrund von zeitlichem Druck und der Last des Legacy-Codes keine Qualität liefern können. Das führt für zu Bugs, Mehrarbeit und unzufriedenen Usern.

Dies kann schrittweise geändert werden, indem man gemeinsam regelmäßig ohne Druck übt, was gutes Coding bedeutet. In freiwilligen Coding Dojos können kleine Programmierübungen, sogenannte Katas, mit Fokus auf hohe Qualität und modernes ABAP durchgeführt werden. Die Erkenntnisse können ins Tagesgeschäft transferiert werden. Hierbei sollte der Fokus auf "Spaß beim gemeinsamen Programmieren" gelegt werden.

Katas für Coding Dojos

Nicht jedes Kata ist für ABAP-Entwicklung geeignet. So können keine Konsolen-Anwendungen entwickelt werden und das Einlesen von Dateien ist im Vergleich zu anderen Sprachen aufwendiger. Dies kostet wertvolle Zeit. Beachten Sie dies bei der Auswahl, passen Sie die Katas an oder nutzen Sie spezialisierte Portale wie Pastafahndung [PastaF] oder GitHub.

Eine Unterstützung des Marketings ist ebenfalls hilfreich:

Aufbau einer Intranetseite für die neue Initiative mit Informationen zur Gruppe und Veranstaltungen. Hier wurde zum Beispiel als Gruppennamen "Clean Code Advocates" und "ABAP Ninjas" gewählt.
Sticker, T-Shirts, Zoom-Wallpaper und andere Materialien mit dem Logo der Initiative, um sie im Alltag sichtbar zu machen. In Anlehnung an Coding Dojos wurde in verschiedenen Initiativen ein Ninja in den SAP-Farben gewählt.
Nutzung von Marketing-Kanälen wie Newsletter, Firmen-Blog und Expert Sessions.

Das Marketing unterstützt hier unserer Erfahrung nach gerne, da die Initiative auch außenwirksam genutzt werden kann, beispielsweise für das Recruiting.

3. Erste Schritte gemeinsam gehen

Nun gilt es, für die Initiative eine Struktur zu schaffen und zu entscheiden, was ein logischer neuer Schritt ist, um die Qualität zu verbessern. Hier bieten sich erfahrungsgemäß zwei Themen an:

Statische Code-Analyse

SAP Code Inspector (SCI) ist ein Linter für ABAP mit verschiedensten Prüfungen beispielsweise aus den Bereichen Konventionen, Security und Performance. Der SCI kann von Entwicklern genutzt werden, um Code automatisch zu analysieren, und QA-Teams als ein erster schneller Check dienen. Zum SCI gibt es weitere Prüfungen auf Open-Source-Basis namens ABAP Open Checks [GitHHvam]. Alternativ kann auch die Open-Source-Lösung ABAPLint verwendet werden.

Auf den ABAP-Clean-Code-Empfehlungen [GitHJue] basiert der ABAP Cleaner [Git-HABAPC]. Er setzt die Empfehlungen automatisch in der IDE um und passt das Coding automatisiert an.

Die Nutzung solcher Tools scheint auf den ersten Blick schnelle Erfolge liefern zu können. Das ist der Fall, wenn sich die Teams auf einheitliche Konfigurationen einigen können. Dies kann sehr einfach sein, zum Beispiel indem sie die Standardeinstellungen verwenden. Oder kann zu ausufernden langen Diskussionen führen, die einzelnen Prüfungen durchzugehen. Empfehlung ist, mit wenigen Prüfungen zu starten – diese aber konsequent einzuhalten. Zu viele Prüfungen auf einmal senken erfahrungsgemäß die Akzeptanz, da auch die Lernkurve der Entwickler beachtet werden muss.

Ein guter Startpunkt ist hier eine Restriktion der Methodenlänge für eine bessere Codestrukturierung. Für ABAP eignet sich ein Wert von 20 bis 30 Codezeilen als Startpunkt, von dem aus gegebenenfalls weiter reduziert werden kann. Wird direkt mit einem noch geringeren Wert gestartet, sinkt unserer Erfahrung nach die Akzeptanz.

Zusätzlich bietet es sich an, die zyklomatische Komplexität einzuschränken und auf Lösungsoptionen wie Guard Clauses und CHECKs hinzuweisen.

Als Ergebnis ist im SAP-System dann „schönerer, lesbarer Code“ und eine höhere innere Qualität. Ist dies ein entscheidender Fortschritt? Ein großes Problem mit hoher Außenwirkung besteht weiterhin: die funktionale Korrektheit.

Funktionale Korrektheit

In einem betriebswirtschaftlichen System wie SAP ist funktionale Korrektheit sehr wichtig. Das System muss verlässlich und wiederholbar das richtige Ergebnis liefern. Code kann so schön, modern und sauber programmiert sein, wie nur irgend möglich. Aber wenn er Prozesse fehlerhaft durchführt oder nebenläufig Bugs entstehen, ist dies problematisch.

Fokus liegt auf einem Test-first-Vorgehen mit ABAP Unit, das in Coding Dojos gelehrt wird: Es darf nur dann Produktionscode geschrieben werden, wenn zuvor ein fehlschlagender Test existiert. Dabei ist es erlaubt und erwünscht, vorher einen groben Entwurf der Software zum Beispiel auf Papier zu erstellen. Der Schwierigkeitsgrad sollte schrittweise gesteigert werden: simple Funktionen, gefolgt von Funktionen mit Abhängigkeiten (Datenbank/Funktionsbausteinen/Datum, Klassen und ganze Applikationen). Legacy-Code als Basis für die Übungen sollte erst einmal vermieden werden. Ein gutes Regelwerk neben "Zeige das beste Coding" können Kent Becks "4 rules of simple design" [Fow15] sein:

alle Tests erfolgreich,
Intention ist ersichtlich,
keine Duplikate,
geringstmöglicher Code.

4. Feedback und Metriken

Feedback kann strukturiert erfolgen über Online-Fragebögen, mit der "Return On Time Invested"-Skala [ROTI] am Ende von Code Katas, aber auch in persönlichen Gesprächen.

Prüfen Sie auch, wie sich das Coding im SAP-System verändert: Ändern sich die Strukturen? Kommen Unittests hinzu? Falls keine oder nur wenige Tests geschrieben werden, gilt es herauszufinden, wieso der Sprung vom Code Kata in den Alltag Schwierigkeiten bereitet. Weiterhin sollte beobachtet werden, wie sich Bugs im System entwickeln.

5. Nächste Schritte

Der Startpunkt ist gesetzt – in der Regel kommen weitere Themen auf, die in der Gruppe, die sich vielleicht schon zu einer Community of Practice weiterentwickelt hat, gemeinsam priorisiert bearbeitet werden können. Die Entwickler entscheiden selbst, welchen Weg sie gehen möchten und welche Probleme es zuerst zu lösen gilt. Die Möglichkeiten im Bereich Qualitätssicherung sind groß:

Automatisierungen für die Codeprüfungen: Das Bestehen von Codeprüfungen des SCI kann als Voraussetzung genutzt werden, um Code in die Produktion zu bringen.
Code-Review: Wenn asynchrone Code-Reviews gewünscht sind, können diese mithilfe von ABAPGit und Pull Requests durchgeführt werden. Es ist zu beachten, dass dies nebenläufig zum SAP-Transportwesen läuft und daher ohne weitere Anpassungen kein echtes Quality Gate ist.
Entwicklungsprozess: Es lohnt ein Blick mit der Lean- und Kanban-Brille auf die bestehenden Entwicklungsprozesse. Oft sind diese nicht in der Hand der Entwicklungsteams – dies ist unserer Erfahrung nach aber notwendig. Als Key-Player ist hier die Aufgabe, gemeinsam mit den Stakeholdern den Gesamtprozess zu überarbeiten, indem mit dem einfachstmöglichen Prozess begonnen wird. Unterstützen können dabei Agile Games, um agile Werte und Vorgehen zu lehren, sowie Simulationen WIE TWIG – THE WIP GAME [TWIG].
Behavior Driven Development: Mit Cacamber existiert eine Open-Source-Lösung, um Tests in Gherkin zu formulieren und in ABAP Unit zu integrieren. Die Fachbereiche können mit Coachingunterstützung durch den Key-Player standardisierte Akzeptanztests bereitstellen.
Refactoring-Techniken: Die Eclipse ABAP Development Tools bieten einige automatisierte Refactorings, welche die Arbeit erleichtern. Hier kann der Key-Player bestehende Refactoring Katas nutzen, die die spezielle Struktur der technischen Probleme von ABAP adressieren, wie „Meter Data Manager“ [GitHPan-b].
Organisation von ganztägigen Entwickler-Events wie dem Global Day of Code Retreat, die wiederum dem Coaching dieser Techniken dienen. Hier ist zu beachten, dass die Übung für ABAP eingekürzt wird, da es zeitlich kaum möglich ist, eine sinnvolle Menge an Code zu erzeugen.

ABAP Development Tools for Eclipse (ADT)

Seit 10 Jahren liefert die SAP eine neue Entwicklungsumgebung für ABAP basierend auf Eclipse aus. Ohne deren Nutzung ist erfahrungsgemäß der Aufwand für qualitativ hochwertigen Code und automatisierte Tests viel zu hoch. Entwickler führen kaum Refactorings durch, wenn diese nicht sicher und automatisch erfolgen. Nutzen Sie daher unbedingt die ADT. Die Deutschsprachige SAP Anwendergruppe e.V. hat hierfür einen Leitfaden mit Best Practices [DSAGADT] bereitgestellt.

Dabei muss individuell die Situation des Unternehmens, der Systeme, der Teams und der Teammitglieder betrachtet werden. Unserer Erfahrungen nach gibt es im Change-Prozess oft folgende Hindernisse:

Das Management unterstützt den Change nicht

Trotz offensichtlicher Probleme unterstützt das Management nicht, da die SAP-Welt als speziell und "völlig anders" angesehen wird, sodass nicht an eine Verbesserung geglaubt wird. Oft wird auch ein hoher Zeitaufwand befürchtet. Unserer Erfahrung nach ist das nicht so. Hier gibt es drei Lösungsansätze:

Bringen Sie das Management mit anderen Unternehmen zusammen, die bereits auf Code-Qualität im ABAP-Bereich setzen. Diese können Sie beispielsweise über die deutschsprachige SAP-Anwendergruppe e. V. [DSAG] oder auf Konferenzen wie der ABAPConf [ABAPC] treffen.
Zeigen Sie auf, wie durch Automatisierungen im Bereich Qualitätssicherung der Zeitbedarf sinkt, indem Sie nebenläufig oder in einem abgestimmten Zeitbudget einen Prototyp, zum Beispiel für den Linter, erstellen.
Überlegen Sie, was passiert, wenn Sie ohne den Segen des Managements starten. Besteht die Gefahr, dass sich etwas verschlechtert, oder können Sie eigentlich nur gewinnen? Nicht jede Veränderung braucht eine Erlaubnis. Ist dies in Ihrer Firmenkultur denkbar?

Zu viel auf einmal

Je mehr Themen parallel angegangen werden, desto höher die Chance, zu scheitern und auch die Entwicklungsteams zu überfordern. Geben Sie dem Thema Zeit und etablieren Sie Grundlagen. Wenn das Tagesgeschäft im Weg steht, bewerten Sie, ob es wirklich ein Problem ist, wenn parallel Zeit in einen Change investiert ist.

Falls Sie in einem Teufelskreis aus Anforderungen und Bugs gefangen sind, ist Qualität wahrscheinlich der einzige mittelfristige Ausweg. Planen Sie ein, regelmäßig an dem Thema zu arbeiten, und sei es nur in kleineren zusammenhängenden Blöcken.

Die Last von ABAP-Legacy-Code

Unserer Erfahrung nach ist eine gute Option, anfangs Legacy-Code soweit möglich zu ignorieren. Dies bedeutet beispielsweise: Die Richtlinien des Linters gelten nur für neuen Code. Muss bestehender Code angepasst werden, so sind diese Anpassungen auszulagern in neue ABAP-Klassen und im Legacy-Code aufzurufen (Sprout Method). Auf alte technische Konstrukte wie Funktionsbausteine soll verzichtet werden. Bestehende sollten in Klassen gewrappt und mit Methoden für die neuen Funktionen mit entsprechender Code-Qualität erweitert werden.

Die Nutzung einer Baseline ermöglicht das Ignorieren von alten Findings des Linters, erzeugt aber weitere Fallstricke.

Technologische Hürden

SAP-Systeme sind nur sehr aufwendig zu updaten. Sollten Sie auf einem alten Stack sein, stehen Ihnen andere oder weniger Funktionen zur Verfügung. Nutzen Sie, was aktuell möglich ist. Letztendlich ist Code-Qualität und Automatisierung mit Unittests hierbei wichtig und kann Ihnen somit als Argument dienen: Wenn das System wieder upgegradet wird, muss sichergestellt sein, dass die kundenindividuellen Entwicklungen weiter funktionieren. Dies ist realistisch manuell nicht möglich.

Komplexe Abhängigkeiten zum SAP-Standard

ABAP-Entwicklungen operieren oft auf sehr vielen verschiedenen Daten und es werden SAP-Objekte verwendet, die nicht unter der Kontrolle der Entwicklerteams sind. Die Strukturierung des Codes und dessen Testbarkeit wird dadurch erschwert. Starten Sie mit einfachen Entwicklungen, die viel kapselbare Logik enthalten, und testen Sie diese, statt komplexe End-to-End-Tests zu schreiben.

Fazit

Hohe Softwarequalität in SAP-Systemen ist durch entsprechendes Tooling und Methoden möglich und schrittweise auch unter komplexen Bedingungen erreichbar. Für Unternehmen bildet diese Qualität eine wichtige Basis, um nachhaltig erfolgreich am Markt bestehen zu können. Ein Change – intrinsisch initiiert „aus dem Herzen der IT heraus“ – vergrößert die Erfolgschancen. Jeder Weg beginnt mit dem ersten Schritt und endet wahrscheinlich nie. Heute ist der beste Tag, um diesen ersten Schritt zu machen. Egal ob klein oder groß.