The clean core principle is easy to endorse and hard to honor. Nobody argues for the alternative — a modified ERP where every upgrade is an archaeology project and vendor innovation arrives years late because the core is too fragile to accept it. Two decades of heavily customized ECC systems made the case vividly. But here is the uncomfortable arithmetic the slogan skips: the business requirements that produced those thousands of modifications do not disappear when you adopt S/4HANA. The differentiating pricing logic, the industry-specific document flows, the operational workflows that make a company itself — that complexity is real. Clean core doesn't eliminate it. Clean core relocates it. And an organization that has not designed where the complexity goes has only decided where it shouldn't be.
The question that actually matters
The productive framing is not "how do we avoid customization?" but "what is our decision architecture for every requirement standard ERP doesn't meet?" In practice each such requirement has four honest destinations, and the discipline lies in choosing deliberately:
- Adopt the standard. Change the business process to fit the software. This is the right answer more often than business stakeholders initially accept, and less often than architects wish. It requires distinguishing genuine differentiation from accumulated habit.
- Configure within the core. Use the extensibility the vendor explicitly supports and commits to preserving through upgrades — released APIs, in-app extension points, configuration.
- Extend beside the core. Build on a platform such as SAP BTP, connected through stable, released interfaces. This is where true differentiation belongs.
- Buy the adjacent capability. Some "customizations" were always a specialized product waiting to be recognized — incentive management being a classic example, which is precisely the ground Vistex occupies.
An organization with a functioning clean-core practice can show you the log of these decisions and the criteria behind them. An organization with a clean-core aspiration can show you a slide.
Side-by-side extension raises the integration stakes
Here is the consequence that deserves more attention than it gets: moving logic out of the core converts internal dependencies into integration dependencies. What used to be a user exit executing inside the transaction — implicitly consistent, transactionally safe, invisible — becomes a call across a boundary. Multiply that by every extension, and the integration layer becomes the load-bearing structure of the entire architecture.
This is why we describe clean core as an integration strategy. Its viability rests on questions that have nothing to do with the core itself. Are extensions consuming released, versioned APIs, or convenient internal ones that will break silently? Is there a deliberate stance on synchronous versus event-driven patterns, or does every project improvise? When an extension is down, does the core degrade gracefully or halt? Who can see, in one place, every interface the landscape depends on? A side-by-side extension wired to unreleased interfaces has not cleaned the core — it has hidden the modification behind an HTTP call, with worse failure modes and less visibility than the ABAP it replaced.
Governance that survives contact with deadlines
Clean core dies at project crunch time, not in architecture review. Some team, three weeks from a deadline, will propose "one small enhancement" in the core because the side-by-side route takes longer. Without a standing decision forum, published criteria, and leadership willing to absorb a slipped date, the exception gets granted — and the second exception cites the first as precedent. The organizations that hold the line share three traits: the decision criteria are written down and public, the extension platform is paved and productive enough that the compliant path is not dramatically slower than the shortcut, and someone owns the interface inventory as a living asset rather than a migration-era artifact. That last point is quietly decisive. Making the right path easy is more effective than making the wrong path forbidden.
The practical takeaway
Treat clean core as three concrete investments rather than one principle. First, a decision framework — the four destinations above, with named owners and a written log — applied to every requirement that standard doesn't meet. Second, an extension platform treated as a product: paved paths, released-API discipline, and enough developer experience that teams choose it willingly. Third, integration observability commensurate with the new reality that your business logic now spans boundaries. Judge success not by the purity of the core in the go-live snapshot, but by a harder test: two upgrade cycles from now, does the vendor's innovation land in weeks instead of quarters, and is the decision log still being written? A clean core you cannot keep clean was never clean — it was just new.