Blog | Building a Future-Ready SAP Landscape with SAP BTP and Side-by-Side Extensibility
For many SAP customers, every upgrade raises the same question: which custom developments will break? The problem is not customization itself. It is the long-term coupling between custom business logic and ERP internals. SAP Clean Core provides a disciplined way to keep the enterprise system adaptable without giving up business differentiation.
In a North Star architecture discussion, Clean Core acts as a guiding principle for the desired future state: standard processes in the core, stable integration contracts, and extensions placed where they can evolve independently.
A clean core favors SAP standard functionality, upgrade-stable extensibility, governed data and integration, and observable operations. It is not a blanket rule that all ABAP must move to the cloud. A released on-stack extension can be entirely appropriate; so can a side-by-side service. The decision depends on business needs, supported interfaces, latency, transactional consistency and lifecycle ownership.
| Dimension | Practical architectural question |
| Processes | Can standard SAP Best Practices or configuration meet the requirement? |
| Extensibility | Is the customization implemented using supported, upgrade-stable mechanisms? |
| Integration | Are released APIs, events and managed integration patterns used? |
| Data | Is data ownership clear, with minimal duplication and controlled access? |
| Operations | Are monitoring, security, testing and change governance in place? |
Key-user extensibility is well suited to supported fields, forms and lightweight business adaptations. On-stack developer extensibility using released objects and ABAP Cloud patterns fits logic that belongs close to ERP transactions. Side-by-side extensibility using SAP BTP CAP is appropriate for decoupled applications, cross-system workflows and independent release cycles.
A practical decision tree begins with fit-to-standard, then key-user adaptation, then released on-stack development, and finally side-by-side extensions for requirements that genuinely need independent services.
At the foundation, SAP S/4HANA owns core procurement, finance and master-data processes. Released APIs and business events provide governed access. SAP BTP hosts CAP services, SAP Fiori user experiences, optional SAP Build capabilities, and HANA Cloud extension data. SAP Integration Suite mediates complex hybrid or cross-enterprise flows. SAP Cloud Identity Services, auditability, monitoring and automated tests span all layers.
The architecture is not a mandate to insert middleware between every application and S/4HANA. Integration components should be selected based on clear requirements such as transformation, security mediation, event distribution and lifecycle governance.
Imagine an ECC-era approval cockpit that reads custom tables and directly changes PR status. During an S/4HANA transformation, the team first assesses standard Flexible Workflow and approval apps. If a unique exception-review dashboard is still required, it can be implemented using Fiori and CAP on SAP BTP, retrieving PR details via released APIs. Approval decisions should continue through supported workflow interfaces, preserving the source of truth and authorization checks.
This example illustrates a clean-core design decision, not a documented production deployment. API coverage and workflow extensibility vary by SAP S/4HANA edition and release and must be checked during solution design.
Phase 1 — Assess: map custom developments, business criticality, integration dependencies and upgrade sensitivity.
Phase 2 — Rationalize: retire unused functionality, adopt standard capabilities and prioritize remediation.
Phase 3 — Architect: classify each requirement as configuration, key-user, released on-stack or side-by-side. Define API and data ownership.
Phase 4 — Implement: use secure interfaces, automated contract tests, observability and documented architecture decisions.
Phase 5 — Govern: continuously track exceptions, upgrade compatibility, incident trends and realized business value.
Moving every customization to SAP BTP without a fit-to-standard review simply relocates complexity. Duplicating ERP master data without governance creates reconciliation problems. Treating unreleased interfaces as stable APIs undermines upgrade safety. Implementing approval logic twice can create inconsistent decisions and audit risk. Clean Core requires design governance, not just a new technology stack.
Track the percentage of custom objects retired or remediated, adoption of released interfaces, upgrade regression effort, API error rates, approval cycle times and exceptions approved by architecture governance. These metrics show whether the architecture is actually becoming easier to change.
Clean Core is a continuous architectural discipline: keep the ERP core focused on standard business capabilities, extend using supported mechanisms, and manage integration, data and operations deliberately. SAP BTP enables this approach when side-by-side capabilities are warranted—but the first design question should always be whether customization is needed at all.
