Das Clean Core Level-Konzept im Detail

SAPs Level-Konzept für Clean Core bietet einen nuancierten Rahmen zur Bewertung und Planung der Compliance. Anstatt Custom Code einfach als "compliant" oder "non-compliant" zu kategorisieren, erkennt das Level-System an, dass Organisationen unterschiedliche Grade technischer Schuld und unterschiedliche Wege nach vorne haben. Das Verständnis dieses Konzepts ist entscheidend für eine realistische Bewertung und praktische Remediations-Planung.

Diese vertiefende Betrachtung untersucht jeden Level im Detail - was ihn charakterisiert, welche Implikationen er mit sich bringt und wie man strategisch über die Bewegung zwischen den Levels nachdenkt.

Das Fundament des Level-Konzepts

Bevor wir in einzelne Levels eintauchen, hilft das Verständnis der Begründung hinter diesem Ansatz, ihn effektiv anzuwenden.

Warum Levels statt binärer Compliance

Eine binäre Compliance-Betrachtung (compliant oder nicht) ist problematisch. Die Realität besteht aus Abstufungen - unterschiedliche Probleme haben unterschiedliche Schweregrade und erfordern unterschiedliche Lösungsansätze. Dieses Verständnis ermöglicht sinnvolle Priorisierung, da unterschiedliche Probleme unterschiedliche Dringlichkeit haben. Es ermöglicht realistische Planung, da Organisationen innerhalb von Einschränkungen arbeiten und Prioritäten setzen müssen. Es gibt einen Migrationspfad, da sich Organisationen Level für Level statt alles auf einmal verbessern können. Und es ermöglicht eine richtige Ressourcenzuweisung, da Aufwand auf die wirkungsvollsten Bereiche konzentriert werden kann.

Die vier Levels

SAPs Framework definiert vier Levels, vom niedrigsten Risiko (Level A) bis zum höchsten Risiko (Level D). Level A repräsentiert volle ABAP Cloud Compliance, Level B stabile klassische APIs, Level C nicht klassifizierte APIs und Level D keinen API-Zugriff (Direktzugriff). Jeder Level repräsentiert einen anderen Grad der Kopplung an SAPs interne Implementierungsdetails, mit entsprechenden Implikationen für Stabilität und Upgrade-Aufwand.

Level A: Volle ABAP Cloud Compliance

Level A repräsentiert den Zielzustand für nachhaltige Erweiterungen.

Charakteristiken von Level A Code

Code auf Level A folgt ABAP Cloud-Einschränkungen. Er verwendet nur freigegebene APIs (mit C1-Freigabe), folgt dem ABAP Cloud-Programmiermodell, verwendet keine deprecated Muster oder Statements, ist kompatibel mit SAP BTP ABAP Environment und kann in Cloud-Szenarien deployt werden.

Warum Level A der Zielzustand ist

Level A bietet maximale Zukunftssicherheit, da Code gegen stabile Schnittstellen geschrieben ist. Er bietet Upgrade-Resilienz, weil Änderungen an SAP-Interna Ihren Code nicht beeinträchtigen. Er ermöglicht Unterstützbarkeit, da SAP APIs unterstützt und Kompatibilitätsprobleme adressiert. Und er bietet Flexibilität, da Code in Cloud-Umgebungen deployt werden kann, wenn nötig.

Wie Level A Code aussieht

Level A Code zeigt bestimmte Muster. Beim Datenzugriff verwendet er freigegebene CDS-Views statt direktem Tabellenzugriff, etwa SELECT FROM I_Product statt MARA. Für Geschäftslogik verwendet er freigegebene Klassen und BAPIs statt Funktionsbausteinen. Für Erweiterungen verwendet er freigegebene BAdIs mit korrekter Implementierung. Für die UI-Entwicklung erfolgt diese über Fiori mit RAP-Backend-Services.

Herausforderungen beim Erreichen von Level A

Während Level A ideal ist, gibt es praktische Herausforderungen. Es existieren API-Lücken, wenn benötigte Funktionalität nicht via freigegebener APIs verfügbar ist. Altsysteme haben Legacy-Muster, da existierender Code auf nicht-A-Mustern basiert. Es gibt eine Lernkurve, da Teams neue Muster und Ansätze erlernen müssen. Und der Entwicklungsaufwand steigt, da neue Muster initial mehr Aufwand erfordern können.

Level B: Stabile klassische APIs

Level B repräsentiert einen pragmatischen Mittelweg.

Charakteristiken von Level B Code

Level B Code verwendet klassische APIs, die nicht für ABAP Cloud freigegeben sind, aber stabil bleiben. Er verwendet Funktionsbausteine und Klassen ohne C1-Freigabe, aber mit Stabilitätshistorie. Er greift auf Tabellen zu, die sich selten ändern. Er nutzt Enhancement-Punkte außerhalb des freigegebenen Frameworks. Diese APIs sind nicht formal freigegeben, haben aber konsistente Stabilität über Releases hinweg gezeigt.

Level B im Kontext

Level B Code hat ein moderates Upgrade-Risiko - Änderungen sind möglich, aber historisch selten. Die Remediation-Priorität ist niedriger als Level C/D, aber Migration zu Level A sollte stattfinden, wenn Alternativen verfügbar werden. Dokumentation ist wichtig, da diese APIs dokumentiert werden sollten für spätere Migration.

Wann Level B akzeptabel ist

Einige Situationen rechtfertigen den Verbleib auf Level B. Wenn keine Alternative existiert und benötigte Funktionalität über freigegebene APIs nicht verfügbar ist, kann Level B angemessen sein. Wenn das Upgrade-Risiko gering ist und historische Stabilität minimale Upgrade-Auswirkungen nahelegt. Bei kontrollierten Abhängigkeiten mit klarer Dokumentation und Migrationsplänen. Und bei begrenztem Scope mit geringer Anzahl von Level B-Nutzungen.

Level B-Nutzungen verwalten

Verwalten Sie Level B sorgfältig durch Dokumentation jeder Level B-Nutzung mit Begründung. Erstellen Sie einen Migrationsplan mit Zeitplan für die Migration wenn Alternativen eintreffen. Führen Sie Upgrade-Tests durch, um Level B Code während Upgrade-Projekten zu testen. Überprüfen Sie periodisch, ob freigegebene Alternativen verfügbar geworden sind.

Level C: Nicht klassifizierte APIs

Level C repräsentiert höheres Risiko und verdient Aufmerksamkeit.

Charakteristiken von Level C Code

Level C Code verwendet APIs ohne Stabilitätsklassifizierung. Er nutzt interne SAP-Funktionsbausteine und -Klassen, zugreift auf SAP-Tabellen direkt ohne freigegebene Views und verwendet Enhancement-Technologien, die möglicherweise instabil sind. Diese Nutzungen haben keine Stabilitätsgarantie und können sich ohne Vorankündigung ändern.

Risiken von Level C

Level C Code birgt signifikante Risiken. Unvorhersagbare Änderungen können ohne Vorankündigung zwischen Releases auftreten. Upgrade-Unterbrechungen erfordern möglicherweise Code-Änderungen während Upgrades. SAP wird keine Kompatibilitätsunterstützung bieten, wenn Probleme auftreten. Und es schafft Migrationsdruck, da die Migration zu stabileren Alternativen priorisiert werden sollte.

Remediation-Ansätze für Level C

Adressieren Sie Level C durch aktive Suche nach freigegebenen Alternativen, da jede Level C-Nutzung überprüft werden sollte, ob eine freigegebene Alternative existiert. Verwenden Sie API-Request, um SAP zu kontaktieren wenn kritische Funktionalität nur über nicht klassifizierte APIs verfügbar ist. Kapselung reduziert das Risiko durch Wrapping nicht klassifizierter Aufrufe in Ihren eigenen Klassen. Und Priorisierung ist wichtig, um sich auf hochfrequent genutzte Level C-Nutzungen zu konzentrieren.

Level D: Kein API (Direktzugriff)

Level D repräsentiert das höchste Risiko und erfordert vorrangige Aufmerksamkeit.

Charakteristiken von Level D Code

Level D Code umgeht APIs vollständig. Direkter Datenbanktabellenzugriff via SELECT von SAP-Tabellen, Modifikationen am SAP-Standardcode, direkte Manipulation interner Datenstrukturen - diese Muster schaffen fragile Abhängigkeiten von Implementierungsdetails.

Warum Level D kritisch ist

Level D Code stellt vor mehrere Herausforderungen. Maximal fragil, da jede SAP-Änderung potenziell Code brechen kann. Upgrade-Blocker können Upgrade-Projekte erheblich komplizieren. Supportprobleme können entstehen, da schwer zu diagnostizierende Probleme auftreten können. Und Cloud-Inkompatibilität bedeutet, dass eine Cloud-Migration unmöglich ist ohne Remediation.

Remediation-Strategien für Level D

Die Adressierung von Level D erfordert entschiedenes Handeln. Ersetzen Sie direkten Tabellenzugriff durch CDS-Views, indem Sie freigegebene Views für Datenzugriff finden oder erstellen. Entfernen Sie Modifikationen, indem Sie zur Standardfunktionalität zurückkehren oder freigegebene Erweiterungspunkte verwenden. Refaktorieren Sie zu APIs durch Neudesign von Funktionalität zur Nutzung unterstützter Schnittstellen. Erwägen Sie Business-Entscheidungen, um zu evaluieren, ob die Funktionalität noch benötigt wird.

Strategische Level-Planung

Das Verständnis der Levels informiert die strategische Planung.

Realistische Zielsetzung

Setzen Sie erreichbare Ziele basierend auf der aktuellen Position. Kurzfristig sollte kein neuer Level D Code eingeführt werden, existierender Level D wird bei Möglichkeit migriert, und Level C wird dokumentiert und überwacht. Mittelfristig werden alle Level D-Nutzungen eliminiert, Level C wird reduziert, neue Entwicklung erfolgt auf Level A. Langfristig ist das Ziel eine überwiegend Level A-Codebasis mit dokumentierten Level B-Ausnahmen.

Priorisierungs-Framework

Priorisieren Sie die Remediation basierend auf Level (D vor C vor B), Nutzung (häufig genutzt vor selten genutzt), Geschäftskritikalität (kritische Prozesse vor Hilfsfunktionen) und Upgrade-Impact (von Upgrades betroffene Bereiche zuerst).

Ressourcenzuweisung

Erwägen Sie dedizierte Remediation-Teams für fokussierte Level D/C-Remediation, opportunistische Remediation während regulärer Wartung und Prävention, um sicherzustellen, dass neue Entwicklung Level A-Muster folgt.

Level-Messung und -Tracking

Die Messung der Level-Verteilung ermöglicht Fortschrittsverfolgung.

Metriken

Verfolgen Sie die Level-Verteilung nach Prozentsatz der Objekte auf jedem Level, Prozentsatz der Codezeilen auf jedem Level, Trend der Level-Verteilung über die Zeit und neue Entwicklung nach Level.

Reporting

Berichten Sie regelmäßig über die Level-Verteilung. Executive Dashboards zeigen die Gesamtverteilung und den Trend. Team-Reports zeigen detaillierte Aufschlüsselung nach Bereich. Developer-Reports zeigen spezifische Objekte und Findings. Upgrade-Reports zeigen Level-Implikationen für geplante Upgrades.

Fazit

Das Level-Konzept bietet einen praktischen Rahmen für das Verständnis und die Adressierung von Clean Core Compliance. Anstatt überwältigende binäre Anforderungen zu stellen, ermöglicht es eine nuancierte Bewertung und priorisierte Remediation. Der Fokus auf Level D als höchste Priorität, die Verwaltung von Level C mit klaren Migrationsplänen, das Akzeptieren von Level B wo angemessen mit Dokumentation und das Streben nach Level A für Neuentwicklung und strategische Bereiche machen den Ansatz handhabbar.

Die Reise zu Clean Core ist ein Marathon, kein Sprint. Das Level-Konzept hilft Organisationen, stetige Fortschritte zu machen und gleichzeitig Investitionen realistisch mit verfügbaren Ressourcen und Geschäftsprioritäten in Einklang zu bringen. Verstehen Sie die Levels, messen Sie Ihre Position, und machen Sie schrittweise Fortschritte in Richtung einer nachhaltigeren SAP-Landschaft.