Custom-Code-Refactoring
Stand 2026-09-03
Custom-Code-Refactoring ist das verdeckte Scope-Risiko jeder S/4-Analytics-Migration. Kunden unterschätzen den Refactoring-Backlog regelmäßig um das 2- bis 3-Fache, weil sie „es funktioniert heute" mit „es wird nach dem Upgrade funktionieren" verwechseln. Der ATC-Scan ist die einzig belastbare Methode, den Scope vor der Schätzung zu quantifizieren. Drei Kategorien dominieren den Refactoring-Aufwand: SAPI-Extraktoren (3-8 Tage je Stück), Z-Tabellen-Staging-Schichten (5-15 Tage) und ABAP-Transformationsroutinen (2-10 Tage). Diese Schätzungen in der Architekturphase richtig zu treffen, verhindert Notfall-Nacharbeit im Go-Live-Sprint.
Was Sie lernen
- Einen ABAP-Test-Cockpit-(ATC)-Clean-Core-Kompatibilitätsscan auf einen Analytics-Extraktionsscope anwenden und alle Befunde in Kritisch-/Hoch-/Mittel-Schweregrade klassifizieren, um ein programmreifes Behebungs-Backlog zu erstellen
- Das Vier-Kategorien-Refactoring-Klassifizierungsframework (Stilllegen / Unverändert behalten / Lift-and-Shift zu ODP-CDS / Neuentwurf als BTP-Side-Car) auf jedes Custom-Analytics-Objekt in einem Migrationsinventar anwenden
- Den Refactoring-Aufwand für die drei aufwandsreichsten Kategorien (SAPI-Extraktoren, Z-Tabellen-Staging-Schichten, BW-ABAP-Transformationsroutinen) schätzen — einschließlich Aufwandsbandbreite, Annahmen und Risiko bei Nichtbehebung
- Ein Architektur-Entscheidungsbrief für einen Custom-Code-Refactoring-Scope erstellen: empfohlener Behebungspfad pro Objekt, Sequenzierungslogik, Go/No-go-Kriterien und Anforderungen an das Kunden-Sign-off
Modulüberblick
Custom-Code-Refactoring ist der am konsistentesten unterschätzte Scope-Posten in jedem S/4HANA- oder BDC-Migrationsprogramm, das Analytics berührt, denn er liegt in der Lücke zwischen zwei Teams, die jeweils annehmen, er gehöre dem anderen. Das Basis- und ABAP-Entwicklungsteam sieht ihn als Architekturentscheidung, die von der Analytics-Seite kommen sollte; das Analytics-Architekturteam sieht ihn als Implementierungsdetail, das den Entwicklern gehört. Bleibt er unbesetzt, taucht er mitten im Programm als Welle ungeplanter Change Requests auf — genau an dem Punkt im Zeitplan, an dem sie am teuersten zu absorbieren sind. Kunden führen routinemäßig Hunderte von Z-Programmen, Legacy-ABAP-Extraktoren und Custom-BW-Transformationen mit, die nie für eine CDS-first-, ODP-konforme, Clean-Core-Welt konzipiert wurden, und sie zu refactoren ist keine Aufgabe, die man einem Entwickler mit der vagen Anweisung übergibt, „mach es kompatibel" — es ist eine Architekturentscheidung mit echten Kosten, echtem Risiko und echten Zeitplan-Konsequenzen, die ein Consultant aktiv verantworten muss.
Voraussetzungen
- Fortgeschrittene praktische Erfahrung mit SAP-Analytics-Projekten
- Zunächst die Kernkonzepte durchgehen: C023, C067, C035
Lernergebnisse
- Einen ATC-Clean-Core-Kompatibilitätsscan auf Custom-Analytics-Objekten durchführen und den Schweregrad-Output interpretieren.
- Jedes beliebige Custom-Analytics-Objekt in das Vier-Kategorien-Refactoring-Framework einordnen.
- Aufwandsschätzungen für die Refactoring-Kategorien SAPI-Extraktor, Z-Tabellen-Staging-Schicht und ABAP-Transformationsroutine erstellen.
- Ein Architektur-Entscheidungsbrief für einen Refactoring-Scope liefern, das der Programmprüfung standhält.
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.