Clean Core

2025-12-02

"Zwanzig Jahre lang habe ich in jedem Projekt diesen Standardreport kopiert und ihn auf meine Anforderungen angepasst und jetzt kommt ihr mit diesem Clean-Core-Müll und sagt, das geht nicht mehr?"

Das rief ein Kollege neulich sichtlich empört angesichts neuer Regeln für die Entwicklung kundeneigener Reports. Kollegenschelte ist unschön, aber "pragmatisch" muss nicht unbedingt "hemdsärmelig" bedeuten. Ich habe in vielen Jahren oft genug erlebt, dass man ab Tag 1 lieber programmiert hat, als sich die Mühe zu machen, das Standard-Customizing zu verstehen. Die Anwender des Kunden finden das super: "endlich nimmt jemand unsere Anforderungen ernst!" Aber schon sehr bald stellt man fest, dass jedes angefasste Objekt ein langfristiges Wartungsthema ist. Und für den Report, den der Kollege oben kopieren wollte, gibt es momentan 27 Korrekturen von SAP. Wer pflegt die ein?

Klar kann man argumentieren, dass Clean-Core in erster Linie ein wirtschaftlicher Vorteil für SAP ist, da damit die gemeinsame Nutzung von Cloud-Ressourcen einfacher wird. In Wirklichkeit ist Clean Core aber gerade auch ein wirtschaftlicher Vorteil für den Kunden: er wird zu Standardprozessen gezwungen. Und dort, wo das nicht reicht, erfolgt die Zusatzentwicklung mit klaren architektonischen Vorgaben.

Bedeutet aber auch: andere Anforderungen für uns Berater und Architekten. Denn wir müssen uns mehr als bisher im Detail mit den Möglichkeiten im Standard auseinandersetzen und können nicht jeden Kundenwunsch an ein Offshore-Entwicklerteam abschieben.

Gerade weil ich als Architekt beide Seiten kenne und täglich abwägen muss - Standardprozess oder Zusatzentwicklung - und ich mehr implizite Enhancement-Points von Innen gesehen habe, als mir lieb war, oute ich mich gerne als bekennender Clean-Core-Fan!