Clean Core: een schone core vraagt om een schone integratielaag

Clean Core is inmiddels een veelbesproken principe: houd het kernsysteem standaard en verplaats extensies naar de juiste laag. Wat in vrijwel elk artikel ontbreekt, is dat de integratielaag geen veilige uitwijkroute is. Ook daar moet je opruimen.

In de praktijk zien we wat er gebeurt als je dat punt overslaat. Logica die niet meer in S/4 mag, verschuift naar een iFlow. Een paar regels conversie groeien uit tot een script met bedrijfsregels, drempelwaardes en uitzonderingen voor één partner. Op papier is de core schoon. In werkelijkheid is het probleem alleen van plek veranderd — naar een omgeving waar het ondoorzichtiger is, minder testbaar en moeilijker over te dragen.

Drie plekken voor drie soorten logica

Bij elke integratie helpt het om eerst de vraag te stellen: waar hoort deze logica eigenlijk thuis? Drie vuistregels.

In S/4 zelf, wanneer de logica direct met de bedrijfsdata moet werken — bijvoorbeeld validaties op een verkooporder of berekeningen die op meerdere processen leunen. Met de huidige extensibility-modellen (key user-extensies, developer-extensies, side-by-side via BTP) zijn er voldoende openingen om dit netjes te doen zonder de standaard te raken.

In een BTP-extensie, wanneer het gaat om functionaliteit die buiten S/4 leeft maar een eigen toepassingslaag heeft: een portaal voor leveranciers, een goedkeuringsstroom, een beheerinstrument voor stamdata. CAP of SAP Build geven daar een nette plek aan.

In een iFlow, wanneer de logica gaat over het verplaatsen, vertalen of routeren van berichten — en niets daarbuiten. Een mapping, een protocolconversie, een routing op berichtinhoud, een retry-mechanisme. Dit hoort op de integratielaag thuis. Bedrijfsregels horen daar niet.

Het anti-patroon waar bijna elk team in trapt

Het meest voorkomende anti-patroon: iFlows met inhoudelijke beslislogica. Een Content Modifier die rekent met kortingsdrempels. Een Router die kiest tussen drie partners op basis van een tabel die alleen de bouwer kent. Een Groovy-script dat een bedrijfsregel implementeert omdat er geen tijd was om die in S/4 te onderhouden.

Het werkt — totdat de regel verandert. Dan begint het zoeken in een omgeving zonder ABAP-debugger, zonder transports met versie-informatie en zonder dat een functioneel beheerder bij de logica kan. De ontwikkelkosten zijn dan al lang verzonken; de onderhoudskosten beginnen pas.

Realisme: brownfield en bewuste uitzonderingen

In een conversietraject met honderden bestaande koppelingen is een schone integratielaag op dag één geen haalbare belofte. Dat is geen reden om het principe op te geven, wel om het pragmatisch in te richten. Een uitzondering die je bewust accepteert, markeer je in de iFlow-naam of in metadata zodat hij achteraf vindbaar blijft. Opruimwerk plan je per release in, niet als losse “ooit”-actie. En per koppeling stel je de logica-vraag opnieuw: wat tien jaar geleden terecht in PI/PO stond, hoort vandaag vaak ergens anders.

Clean Core werkt alleen als het over de hele keten loopt. Een schone core met een vervuilde integratielaag is geen oplossing. Het is een verplaatsing van het probleem.