Vorig jaar publiceerden we een blog over de voor- en nadelen van een SAP Clean Core-aanpak. We bespraken daarbij specifiek het grijze gebied tussen een volledig modificatievrije omgeving en een landschap vol met maatwerk. In de praktijk merkten we dat de meeste organisaties precies in dat grijze gebied opereerden: er is bijna altijd een bepaalde mate van maatwerk nodig om alle functionele wensen te kunnen vervullen.
In augustus heft SAP een whitepaper uitgebracht waarin het Clean Core-principe is bijgewerkt en uitgebreid. Dit nieuwe model speelt in op klachten dat het vorige model te rigide was. SAP omschrijft de nieuwe definitie als volgt:
“SAP is evolving its extensibility guidelines by introducing the Clean Core Level Concept, a new model designed to simplify qualification criteria and provide a more pragmatic approach to managing custom code in SAP S/4HANA, now including rules for classic ABAP. By evolving the previous 3-tier model, this new maturity model categorizes extensions into four distinct levels (A, B, C, and D) based on their architectural integrity, upgrade safety, and alignment with clean core principles.”
In deze blog analyseren we hoe het oude three-tier model zich verhoudt tot het nieuwe four-level model, en wat dit betekent voor ontwikkelaars die met Clean Core aan de slag gaan.
Recap van het three-tier model
Het oorspronkelijke three-tier extensibility model classificeert extensies op basis van hoe ze gebouwd zijn. Tier 1 werd ook wel “true Clean Core” genoemd. Het bestond uit key user extensibility, side-by-side extensions (op SAP BTP) en het gebruik van released API’s en extension points volgens het ABAP Cloud Development model. Dit was de enige tier die volledig Clean Core-compliant was. Voor SAP S/4HANA Public Cloud was Tier 1 bovendien de enige beschikbare optie.
Wat als er geen released API beschikbaar was voor jouw scenario? Dit is waar Tier 2 relevant werd: een custom wrapper bouwen rondom een unreleased SAP object. Dit was altijd bedoeld als een tijdelijke oplossing. Zodra SAP een officiële API vrijgaf, moest de wrapper worden uitgefaseerd.
Alles wat niet in Tier 1 of 2 paste (zoals legacy ABAP code) viel automatisch in Tier 3. De boodschap van SAP hierbij was duidelijk: Tier 3 moet zoveel mogelijk worden afgebouwd.
Dit model bleek in de praktijk vrij beperkt, vooral voor organisaties met een grote classic ABAP voetafdruk of bedrijven die unieke processen hebben die niet door standaard SAP worden afgevangen.
Van Tiers naar Levels
In het nieuwe four-level model draait de classificatie niet langer om de ontwikkelmethode, maar om welk type SAP object wordt aangeroepen. De mate van stabiliteit en upgrade-veiligheid hangt nu dus volledig af van dat object.
Voor de eerste categorie is de mapping eenvoudig: Tier 1 komt overeen met Level A. Hier worden uitsluitend released API’s, extension points en cloud-compliant ontwikkelmodellen gebruikt.
Tier 2 wordt complexer. Wrapper objecten kunnen in Level B, C of D vallen, afhankelijk van het onderliggende object:
- Als het object een klassieke SAP API of extension point is, valt het binnen Level B.
- Als het object een internal SAP object is (d.w.z. een object dat alleen bedoeld is voor gebruik door interne SAP ontwikkelaars), valt het binnen Level C. Dit wordt door SAP ook wel aangeduid als conditionally clean, mits de juiste governance wordt toegepast (zoals changelog-checks voor upgrades).
- Tenslotte is het ook mogelijk om een wrapper om een SAP object te bouwen waarbij de specificatie onduidelijk is of waarbij er specifiek wordt aangeduid dat het ongeschikt is voor API-gebruik (Level D). Dit wordt afgeraden en zou alleen als laatste redmiddel moeten worden ingezet.
De derde tier komt overeen met Level C of D. Net als bij Tier 2 is dit afhankelijk van welke objecten worden aangesproken. Belangrijk hierbij is de nuance dat classic ABAP niet per definitie “not clean” hoeft te zijn. Veel classic ABAP-oplossingen zijn stabiel, upgrade-safe en passen binnen Level C wanneer de governance goed op orde is. Iets wat het nieuwe model eindelijk erkent.
Wat betekent dit in de praktijk?
Het nieuwe Clean Core model biedt duidelijk meer flexibiliteit en sluit beter aan op de realiteit van veel S/4HANA-landschappen. Tegelijkertijd zien we dat organisaties nog steeds tegen praktische uitdagingen aanlopen. Hoewel SAP het aantal released API’s continu uitbreidt, kan het in sommige situaties nog lastig zijn de juiste API te vinden voor een specifiek business scenario.
Met de nieuwe definitie krijgen organisaties in ieder geval een realistischer en beter hanteerbaar kader om bestaande extensies te classificeren en te beheren, een duidelijke stap vooruit.
Voor SAP Public Cloud blijven de strikte Clean Core-principes leidend. Dit waarborgt upgrade-stabiliteit, ook al betekent het dat sommige scenario’s moeten worden opgelost met alternatieve ontwerppatronen of side-by-side extensions.
Ben je bezig met een SAP Clean Core implementatie, of oriënteer je je nog op een strategie? Dan adviseren wij het volgende:
- Richt je voornamelijk op Level A en Level B extensies om de impact van systeemupgrades te minimaliseren.
- Gebruik Level C alleen selectief en met sterke governanceprocessen.
- Pas Level D alleen toe als er écht geen haalbaar alternatief is.
Wij sluiten ons ook aan bij het advies van SAP dat niet elke wens van de klant meteen geïmplementeerd moet worden. Wees selectief en denk na over de volgende vragen:
- Levert deze requirement strategische waarde voor de klant?
- Is het een onderscheidend proces dat niet in standaard SAP zit?
- Weegt de lange termijn beheerslast op tegen de functionaliteit die het oplevert?
Is het Antwoord op één van deze vragen nee, dan hoor de requirement waarschijnlijk niet thuis in het systeem. Ongeacht of het binnen Clean Core-grenzen geïmplementeerd kan worden of niet.
