Side by Side Extensibility on SAP BTP

Side by side extensibility is the practice of building custom functionality outside the S/4HANA or ECC system, on SAP BTP, and connecting it back to the core through APIs, events, or UI integration instead of changing the core system's own code. The structural fact that causes most confusion is that it is not one technology but an architectural pattern realizable on several different BTP runtimes: the ABAP environment (built on RAP, for teams staying in ABAP), Cloud Foundry, and Kyma (Kubernetes-based, for Java, Node, Python or containerized workloads). Choosing the runtime is itself a separate architectural decision, not something the pattern hands you. It sits opposite in-app extensibility, which extends the core from within the same system using key user tools or developer extensibility scoped to released objects. Both are considered clean, but they solve different problems and are not interchangeable just because both count as 'not touching the core'.

Use side by side extensibility when the extension logic genuinely needs to live outside the core process: a UI-heavy custom application, a workflow spanning S/4HANA and non-SAP systems, machine learning or analytics workloads, or logic that must survive independently of the core's upgrade cycle and technology stack. It is also the right choice when the team needs a non-ABAP language or wants to reuse open-source libraries the ABAP environment does not support. It is the wrong choice for a simple field addition, a small screen adaptation, or any change tightly coupled to a single core transaction that in-app extensibility already handles with far less overhead. It is also a poor fit where the extension needs tight, high-frequency access to core tables, because every call becomes a network round trip through an API rather than an in-memory lookup.

Below the side by side layer sits the core system exposing its released interfaces: OData services, SOAP or REST APIs, BAPIs wrapped for external consumption, and business events published through an event broker. Above it sits the chosen BTP runtime hosting the extension: the ABAP environment with RAP-built services, or Cloud Foundry and Kyma hosting a custom app built with SAP Business Application Studio or standard tooling. Connectivity between the two layers runs through destinations, communication arrangements, and identity federation (IAS/IPS), with Cloud Connector bridging into on-premise landscapes where relevant. The pattern replaces classic on-stack custom development inside ECC or S/4HANA (user exits, enhancement includes, direct table access) for new builds under a clean core strategy. It does not replace in-app extensibility; the two are complementary tools chosen per requirement, not a hierarchy.

A company needs a custom approval step for purchase requisitions above a value threshold, with a richer UI than the standard app and an audit trail that must not be lost across S/4HANA upgrades. The core system emits a business event when a requisition is created above the threshold. A side by side application built in the BTP ABAP environment using RAP subscribes to that event, calls back into the core through a released OData API exposed via a communication arrangement to retrieve requisition line items and account assignment, and applies the custom approval logic. The decision is written back to the core through a second released API endpoint. The UI is a Fiori elements app generated from the RAP service definition, hosted on BTP and surfaced through the launchpad alongside standard S/4HANA apps so the end user sees no seam. Nothing in this flow touches core dictionary objects or core code; every touchpoint is a released interface or an event subscription, which is what keeps the approach upgrade-safe.

Under a clean core strategy, side by side extensibility is one of the two sanctioned extension paths for S/4HANA, alongside in-app extensibility, and it is specifically the path recommended for anything that would otherwise require modifying core code, using implicit or explicit enhancements, or reaching into objects that are not released for extensibility. This pattern did not exist as a first-class option in classic ECC; it emerged with SAP BTP as the mechanism for keeping the core upgradeable without losing the ability to build custom functionality. What is discouraged now, plainly, is forcing a requirement into side-by-side just to claim it is clean when it actually needs deep coupling to core data that has no released interface; in that case the right move is to get the interface released first, not to build around the gap.

The architect decides between in-app and side-by-side and picks the runtime; the developer builds and maintains the BTP-hosted application and its API or event contracts; the functional consultant defines the triggering business process and confirms the released interfaces actually deliver the fields needed. Handover includes the API and event contract definitions, destination and communication arrangement configuration, and the monitoring setup for the extension.

Read the API management and principal propagation page for the connectivity mechanics that side-by-side apps depend on, particularly authentication across the Cloud Connector boundary. Read the event-driven integration page for the asynchronous trigger pattern used when the core notifies a side-by-side app rather than being polled. Read the integration platform comparison page for how the broader BTP integration layer relates to, and differs from, building a side-by-side extension directly.