Cluster III · Article xxii of forty

SAP clean core.

The SAP clean-core framework preserves the standard digital core through three extensibility paths (key-user, developer, side-by-side) on BTP. The framework reads at conversion, at adoption and at renewal. The Admodum read on the architecture, the renewal-time levers and the disposition framework.

ClusterSAP
Read11 minutes
AuthorDiane K. Caldwell
PublishedMarch 2025

Key takeaways

Section i

The clean-core framework.

The clean-core framework is the SAP-recommended extensibility discipline against the S/4HANA digital core. The discipline preserves the standard digital core (the SAP-published S/4HANA application code, the embedded HANA database structures, the standard process configuration) and runs all customer-side extensions outside the core through one of three published extensibility paths. The framework reads against the inverse: the modification-of-core path on the ECC track, where customer ABAP customisations modify the standard SAP code base and require regression testing against each release upgrade.

The clean-core framework therefore is the architectural answer to the ECC customisation-debt problem: by separating the customer-side extensions from the core, the framework allows the core to upgrade on the SAP-published cadence without breaking the customer-side extensions. The wider S/4HANA conversion planning spoke reads the conversion methodology; the wider SAP Public Cloud spoke reads the Public Edition standard-core preservation.

Section ii

The key-user path.

The key-user path is the low-code configuration inside the SAP-published in-app extensibility framework. The path supports custom fields (added to standard business objects, populated through configuration, visible on standard UIs without code), custom business objects (modelled inside the in-app framework, with standard CRUD UIs auto-generated), custom logic at published business-object events (the in-app extensibility framework publishes an event-handler surface for select business-object events), and custom analytics (custom CDS views against the standard data model, custom analytics tiles).

The path reads for line-of-business configuration changes that do not require developer involvement. The path is the natural first stop on the clean-core discipline: the configuration is owned by the line-of-business team, runs on SAP-published frameworks, and survives every upgrade.

Section iii

The developer path.

The developer path is the ABAP Cloud language subset against an SAP-published API surface inside the digital core. The path runs developer code inside the system boundary but only against published, stable APIs (the modification-free principle). The developer cannot modify the standard SAP code base; the developer can only call published APIs from custom ABAP code in customer-namespace classes.

The path reads for custom logic that needs to run inside the system boundary (latency-sensitive logic, high-volume batch logic, transactional logic against the standard data model) but where the side-by-side architecture would carry an unacceptable network-latency or transactional-consistency cost. The API surface against which the developer path runs is SAP-published and stable, and is therefore portable across the upgrade cadence.

Section iv

The side-by-side path.

The side-by-side path is the full developer extensibility on BTP outside the digital core. The BTP-side application is connected to the core through SAP-published APIs and consumes BTP CPEA credits against the BTP subscription line. The path supports the full BTP stack: SAP Build, the Cloud Application Programming Model (CAP), the SAP HANA Cloud database, the BTP Integration Suite, the Mobile Services, the BTP-side AI services (Joule, the generative-AI hub, document-information-extraction services).

The path reads for substantive customer-side applications that justify their own deployment surface: the bespoke customer portal, the bespoke supplier portal, the bespoke partner integration, the bespoke industry-specific process. The path carries the BTP CPEA credit consumption obligation. The wider SAP BTP overview spoke reads the BTP architecture.

Section v

The renewal-time read.

The renewal-time read on the clean-core discipline is the BTP CPEA credit consumption against the BTP subscription line, the standard-core preservation against the upgrade cadence, and the extensibility-path inventory against the licensing perimeter. The BTP CPEA credit consumption is the variable line: the side-by-side extensions consume BTP credits against the buyer's annual BTP commitment, and the renewal-time read reconciles the actual consumption against the contracted commitment.

The standard-core preservation is the qualitative line: the buyer's S/4HANA instance carries no modifications, no Z-objects in the core, no user exits, and therefore upgrades cleanly on the SAP-published cadence. The extensibility-path inventory is the per-path catalogue: the count of key-user extensions, the count of developer-path classes, the count of side-by-side applications. The wider SAP RISE renewal spoke reads the wider renewal architecture.

Section vi

The disposition framework.

At the renewal moment, the buyer is in one of four published positions on the clean-core discipline. The first is the fully-clean position: all customer-side extensions run on the three published paths, the core carries no modifications, the upgrade cadence runs without regression. The second is the mostly-clean position: the bulk of the extensions run on the clean-core paths but a small modification surface (legacy Z-objects, legacy user exits) remains in the core. The third is the hybrid position: a substantial modification surface remains in the core alongside the clean-core extensions; the regression-test surface remains substantial. The fourth is the ECC-debt position: the bulk of the customisation remains in the core; the clean-core discipline has not been applied.

The clean core is the extensibility discipline, not the design pattern. The framework reads at conversion, adoption and renewal.

The wider engagement sits in the SAP practice; the aggregated reading list sits in the SAP knowledge hub; active renewal moments route to the Renewal Programme; active audit moments route to Audit Defence.

More from the SAP cluster

Continue the reading.

Article iv

S/4HANA conversion planning

The conversion methodology against the clean-core target architecture.

Article xxiii

SAP BTP overview

The BTP architecture against the side-by-side path.

Article xxi

SAP Public Cloud

The Public Edition standard-core preservation framework.

Engage

Read your clean-core position with a senior advisor.

A senior Admodum SAP advisor will read your extensibility-path inventory, your BTP CPEA credit consumption, your modification-surface debt and your renewal-time BTP-line reconciliation on a private call. Active renewal moments route to the Renewal Programme.

Independence
Admodum is not a partner, reseller, or affiliate of SAP, or of any other software vendor or hyperscaler. No reseller margin, no referral commission, no audit-subcontract relationship.