Extensibility Models and Trade-offs Under Clean Core

Explanation

Once an architect accepts clean core as the guiding principle, the next decision is which extensibility model to use for a given requirement, because each model carries different trade-offs in flexibility, governance, upgrade safety, and skill requirements. SAP's extensibility framework generally recognizes three categories, and understanding when to apply each is central to architect-level decision-making. In-app extensibility (key-user extensibility) allows business users or citizen developers to add custom fields, custom logic via simple rule-based tools, custom CDS-based views, and adapt UIs using low-code tools built into the Fiori launchpad experience, without writing traditional ABAP. This is available in S/4HANA Cloud Public Edition and, to varying extents, in private cloud and on-premise systems that have the extensibility tools enabled. The trade-off: it is fast and safe (upgrade-stable because it uses SAP-released extension points) but limited in complexity — it is not suited for elaborate business logic, complex integrations, or performance-critical processing. Developer extensibility (on-stack) allows ABAP developers to write custom code inside the S/4HANA system itself, but constrained to the 'released' API and class allowlist (in S/4HANA Cloud, this is enforced through the ABAP Cloud programming model and the released object catalog; in on-premise/private cloud it is more permissive but still recommended to follow the same allowlist discipline). This gives more power than key-user tools — custom business logic, custom apps using Fiori elements, custom CDS views with complex logic — while still theoretically remaining upgrade-safe if only released objects are used. The trade-off is that if a developer strays outside the released object list on private cloud or on-premise (which is technically possible there but not recommended), the clean core principle is broken and upgrade risk returns. Side-by-side extensibility moves the custom logic entirely outside the ERP core, typically onto SAP BTP, using ABAP Cloud Environment, Java, Node.js, or a low-code platform like SAP Build. The extension application communicates with S/4HANA exclusively through released, versioned APIs (OData, REST, or events via integration technology) and is deployed, scaled, and upgraded independently of the core system. This is the strongest form of clean core because the core is never touched, and the extension's lifecycle is fully decoupled — you can even swap the underlying core system's version without breaking the extension, as long as the API contract is preserved. Trade-offs include additional integration complexity, potential latency for real-time processes, the need for separate authentication/authorization design (often via principal propagation), and the operational overhead of running and monitoring a separate BTP landscape. A practical decision framework for architects: use in-app extensibility for simple field or UI-level changes owned by business users; use developer/on-stack extensibility for logic tightly coupled to core transactions where near-zero latency matters and released APIs already exist; use side-by-side extensibility for complex, evolving business logic, multi-system integrations, or capabilities that need independent release cycles or reuse across multiple core systems (e.g., a shared pricing engine reused by both S/4HANA and a separate CRM system). Across deployment models, the enforcement differs: S/4HANA Cloud Public Edition mandates released APIs and key-user/developer extensibility within the ABAP Cloud programming model — there is no option to deviate. Private cloud and on-premise give more latitude technically, but choosing to exceed the released object catalog reintroduces the very upgrade risk clean core exists to prevent, so governance policy (not platform enforcement) is the control mechanism there. Architects must therefore pair the extensibility model decision with a governance model: who approves exceptions, how extensions are cataloged, and how the released API/object list is monitored over time as SAP updates it.

Code example

* Example: developer extensibility using a released BAdI-style enhancement* (illustrative pattern only - actual BAdI/class names must be verified against* the customer's released object catalog for their SAP release) CLASS zcl_im_pricing_extension DEFINITION  PUBLIC FINAL  CREATE PUBLIC .  PUBLIC SECTION.    INTERFACES if_ex_pricing_procedure_bAdI. " illustrative interface name onlyENDCLASS. CLASS zcl_im_pricing_extension IMPLEMENTATION.  METHOD if_ex_pricing_procedure_bAdI~adjust_condition.    " Only released, documented BAdI methods should be implemented here.    " Business logic stays isolated in this custom class rather than    " modifying the standard pricing routine directly.    IF iv_customer_group = 'PREMIUM'.      cv_discount_percent = cv_discount_percent + 2.    ENDIF.  ENDMETHOD.ENDCLASS.

Real project scenario

A manufacturing company running S/4HANA Private Cloud needed a custom rebate calculation that varied by regional sales organization. Instead of modifying the standard pricing routine (as they had done in ECC), the architecture team implemented the logic as a released BAdI implementation confined to the ABAP Cloud-released object catalog, keeping it inside the core for latency reasons since rebate calculation happened during every sales order save. Separately, the same company built a supplier collaboration portal as a side-by-side app on SAP BTP that consumed S/4HANA APIs for purchase order status, deliberately keeping that far more volatile and UI-heavy logic outside the core so it could be updated weekly without touching the ERP system.

Common mistakes

• Defaulting to on-stack ABAP development for every requirement instead of evaluating whether key-user tools or side-by-side apps are more appropriate. • Using non-released APIs or classes in private cloud/on-premise developer extensibility because they are technically accessible, quietly reintroducing upgrade risk. • Choosing side-by-side extensibility for latency-sensitive, transaction-critical logic without accounting for network round-trip and authentication overhead. • Failing to maintain a living inventory of which extensions use which extensibility model, leading to governance blind spots during upgrades. • Assuming key-user extensibility can scale to handle complex conditional business logic without hitting real functional or performance limits.

Best practices

• Build and maintain a decision matrix mapping requirement characteristics (latency, complexity, ownership, reuse) to the appropriate extensibility model. • Restrict on-stack developer extensibility to the released object/API catalog even where the platform does not enforce it. • Prefer side-by-side extensibility for logic likely to change frequently or be reused across multiple backend systems. • Maintain a central extension registry documenting which model, which released APIs, and which business owner apply to each extension. • Reassess the extensibility model choice periodically, since SAP continues to expand the released API/object catalog over time.

Interview angle

Expect scenario-based questions like 'a client wants a custom discount rule that must fire during order entry — which extensibility model would you choose and why?' Strong candidates walk through the decision framework (latency needs, complexity, ownership, lifecycle independence) rather than giving a single memorized answer, and they explicitly separate what is enforced by the platform (public cloud) versus what is a governance choice (private cloud/on-premise).