An Ekonbee playbook
"Clean core" started as a marketing phrase. For us it became a contract — a set of rules we agree with customers on day one and enforce in CI from day one. The promise: take every S/4HANA release without rework.
If it means writing custom code on BTP instead of patching a standard program, we write it on BTP. The handful of times we've allowed an exception, we've regretted it.
The boundary is clear: if a functional consultant can own it, they do. Only when we need code does it go to a developer — and only on BTP, side-by-side.
Business events leave the core. Integrations come back in through well-governed APIs. No file drops. No direct table access. No shortcut wins a review.
If no one owns it and no one can say when it gets retired, it doesn't ship. Harsh, effective.
We tried "no process-level enhancements, period." It was too strict — some industries genuinely need them. We now allow them via SAP's extension points, reviewed quarterly. Be rigid on principles, flexible on mechanisms.
Rules without teeth don't last. We enforce clean-core in three places: architecture review on every design, a linter in CI that fails the build on a modification, and a quarterly "clean-core audit" where we score every customer 0–100. Below 85 triggers a remediation sprint.
The payoff is simple: each S/4HANA release upgrade costs less and ships faster, because there's less to test, less to fix, and no modifications to regress. Most importantly — your team sleeps better during patch weekends.