Clean core, translated for developers
"Keep the core clean" gets repeated in every SAP keynote. For developers, it cashes out into concrete constraints on what you can write, which APIs you can call, and how upgrades treat your code.
Strip away the slideware: clean core means your custom code survives upgrades without modification. Everything else — the rules, the ATC checks, the released APIs — is machinery toward that goal.
The three developer-facing rules
1. Use released APIs only. SAP marks stable interfaces as released — these carry an upgrade-stability promise. Unreleased function modules, tables, and classes can change without notice. If it's not released, depending on it is a gamble.
2. Write in the ABAP Cloud language version. New development uses the restricted ABAP Cloud syntax: no direct access to system tables, no obsolete statements, strict typing. The compiler enforces it — this isn't a guideline, it's a gate.
3. Extend, don't modify. Enhancements, BAdIs, key-user extensibility, and (for UI) adaptation projects — the sanctioned extension layers. Classic modifications and implicit enhancements of SAP code are technical debt with an expiry date.
The mindset shift: upgrade safety is a design constraint, not a testing phase. Code written against released APIs in the cloud language version doesn't need an upgrade project — that's the whole point.
What changes in daily work
- ATC becomes a gate, not advice. Clean-core checks run in CI and block transports. Fix findings as you code, not the week before go-live.
- API discovery is a first step. Before writing, check what's released — the API catalog, not SE37 habit. No released API? That's a conversation with SAP, not a reason to use an unreleased one.
- Table access goes through CDS. Direct SELECTs on SAP tables give way to released CDS views — the stable contract SAP commits to.
- Extensions live in layers. Key-user in-app extensibility for simple cases, developer extensibility (custom fields, logic, BAdIs) for the rest, side-by-side on BTP when you need full freedom.
The honest trade-offs
Clean core costs something: released APIs don't cover every edge case, the cloud language version forbids some convenient old tricks, and side-by-side extensions add landscape complexity. Teams feel the friction most in the first project.
But weigh it against the alternative — the classic estate where every upgrade is a archaeology expedition through modifications nobody remembers. The tax is real; clean core just makes you pay it upfront, in design, instead of at every upgrade.
Ask of every custom development: "will this survive the next upgrade untouched?" If the answer needs a paragraph of qualifiers, redesign it.
Where to start
Run the ABAP Test Cockpit clean-core checks on your existing custom code. The findings list is your technical debt inventory — prioritized, with remediation guidance. Start with new development under the rules, then work the backlog by upgrade risk.
Clean core isn't a migration you finish; it's a standard you hold. The teams that treat it that way stop fearing upgrades — which was the goal all along.
How clean is your estate — and what's the ugliest modification still lurking? Tell me in the comments.