Clean core in practice — what it costs and what it buys
Clean core is easy to agree with and hard to hold. What it actually requires, what it costs upfront, and why it reverts within a year without governance.
Written by APx Technology
Nobody argues against clean core. Everybody’s core gets modified anyway. The gap between the principle and the practice is worth examining, because it is a governance failure rather than a technical one.
What clean core actually requires
Three things, all of which have to hold simultaneously.
Extensions live outside the core. Custom logic runs on SAP BTP, side by side, rather than inside the S/4HANA core.
You only consume released APIs. Extensions use SAP-released interfaces and extension points, which SAP commits to keeping stable. The moment you read directly from a core table that is not part of a released contract, you have taken on upgrade risk even if no modification was made.
Exceptions are governed. There is a written policy, a named owner, and a decision record for every exception granted.
The third is the one that fails.
The real cost
Side-by-side extension is more expensive upfront. That is simply true, and pretending otherwise damages credibility with the people approving budgets.
You need BTP subscription and consumption. You need developers comfortable with CAP or RAP rather than only classical ABAP. The architecture has more moving parts, so design takes longer. A simple enhancement that could have been a user exit in an afternoon becomes a service with an interface contract and a deployment pipeline.
For a single requirement, in-core is cheaper. This is not close.
What it buys
The return does not arrive on the first build. It arrives on the third upgrade.
Every in-core modification must be re-validated at every upgrade. Some break and need rework. Across a few hundred objects, this becomes a standing tax — and it is the reason upgrades at some organisations take nine months and at others take six weeks.
Clean core converts a recurring, compounding, unpredictable cost into a higher fixed cost at build time. Over a system lifetime it wins clearly. Over one quarter it looks like overspending, which is exactly why it erodes.
Why it reverts
The failure mode is consistent and worth naming.
An urgent requirement arrives with a hard date. The side-by-side approach takes three weeks; the user exit takes two days. The business pressure is real, the deadline is real, and there is no governance forum empowered to say no.
The exception gets granted. It is documented as temporary. It is never revisited.
Six months later this has happened eleven more times, and clean core is now something the architecture diagram claims rather than something the system has.
What actually holds
A written policy that states what may touch the core, what must be side-by-side, and what the exception criteria are. Vague principles do not survive deadline pressure.
A named owner with authority to refuse. Not a committee that meets monthly — an individual who can say no on Tuesday afternoon.
An exception register that is reviewed. Every exception gets a remediation date and someone checks the list quarterly. Exceptions that are never revisited are just modifications with better paperwork.
Honest costing in the business case. If clean core is presented as cheaper, the first comparison against an in-core estimate undermines it. Present it as an investment against future upgrade cost, with the numbers.
The pragmatic position
A core with twelve documented, owned, remediation-scheduled exceptions is in considerably better shape than one claiming zero while carrying two hundred undocumented ones.
Aim for governed, not pure.