Why Side-by-Side Extensibility Exists and When to Use It
Introduces the business and technical rationale for side-by-side extensions, contrasting them with in-app and classic ABAP extensions, and explains the core decision criteria for choosing this pattern.
Explanation
Side-by-side extensibility means building custom functionality on a separate platform, most commonly SAP BTP, that communicates with the SAP S/4HANA digital core through APIs rather than being deployed inside the core system itself. This is one of three broad extensibility patterns SAP customers historically use: classic extensibility (custom ABAP objects inside the ECC or S/4HANA on-premise stack, using constructs like user exits, BAdIs, or custom reports), in-app extensibility (key-user tools such as low-code app building or field extensibility running inside S/4HANA Cloud within released extension points), and side-by-side extensibility (separate applications and services running on a platform like BTP, integrating with the core via APIs, events, or middleware). The reason side-by-side exists as a distinct pattern is the clean core principle: SAP S/4HANA Cloud public edition heavily restricts custom code inside the core to protect upgradability, since the public cloud is updated frequently by SAP. Even in private cloud and on-premise editions, where classic extensibility remains technically possible, many architects deliberately push new custom logic to a side-by-side model to reduce upgrade friction, isolate blast radius of custom code failures, and enable independent scaling and lifecycle management of extensions. When should an architect choose side-by-side over in-app extensibility? Key decision drivers include: the extension needs capabilities not available as released in-app extension points (for example, complex workflow orchestration, machine learning, or heavy integration fan-out to multiple systems); the extension must scale independently of the core system's compute capacity; the extension needs a different technology stack (Java, Node.js, Python) than ABAP; the extension serves multiple SAP and non-SAP backends, not just one S/4HANA instance; or organizational reasons such as a separate team owning the extension with independent release cadence. Conversely, in-app extensibility is preferable when the change is simple (a custom field, a small business logic adjustment at a defined BAdI-like extension point, or a custom CDS-based analytical app) and when minimizing integration complexity and latency matters more than platform flexibility. Classic extensibility remains relevant primarily in on-premise or private cloud editions for deep, tightly coupled logic where API-based communication would be architecturally inappropriate (for example, extending core posting logic that must run synchronously within the same LUW). A critical nuance: side-by-side extensions are not free of coupling to the core. They still depend on the stability of the APIs they consume (OData services, SOAP, RFC-enabled function modules exposed via API endpoints, or event channels). If the core team changes or deprecates an API without a deprecation window, the side-by-side extension breaks just as surely as a modified include would in classic extensibility - the difference is where the risk lives, not whether risk exists. Architects must therefore treat API contracts as first-class governance artifacts, not assume that 'side-by-side equals safe.' Another important distinction is between S/4HANA on-premise/private cloud and public cloud regarding this choice. In public cloud, in-app options are curated and limited by SAP, and anything beyond them essentially forces a side-by-side decision. In private cloud and on-premise, the architect has more classic extensibility latitude, so choosing side-by-side is more of a strategic governance decision than a technical necessity, and it should be justified against the added integration and operational cost.
Real project scenario
A retail company migrating from ECC to S/4HANA Cloud public edition needs a custom promotions engine that calls out to a third-party pricing API and applies complex discount rules not supported by standard condition technique. Because public cloud restricts custom ABAP, the architect designs a side-by-side extension on BTP using CAP (Cloud Application Programming model) that reads sales order data via released APIs, applies the custom logic, and writes back adjusted pricing conditions, keeping the S/4HANA core clean and upgradable.
Common mistakes
• Assuming side-by-side automatically means zero risk to core upgrades, ignoring that API changes still cause breakage • Choosing side-by-side for simple field extensions that in-app extensibility could handle more simply and cheaply • Underestimating integration latency and failure handling needs when moving logic out of the core's synchronous transaction boundary • Failing to document why side-by-side was chosen, leading to inconsistent extensibility decisions across projects • Treating classic, in-app, and side-by-side as mutually exclusive when a landscape often needs a deliberate mix
Best practices
• Default to in-app extensibility for simple, core-adjacent changes before considering side-by-side • Treat consumed APIs as governed contracts with versioning and deprecation policies regardless of extension pattern • Document the extensibility decision rationale per use case for future architects and audits • Evaluate team skills and ownership model as part of the side-by-side decision, not just technical fit • Revisit extensibility choices periodically as SAP releases new in-app capabilities that may reduce the need for side-by-side
Interview angle
Interviewers commonly ask candidates to explain the three extensibility patterns and give a decision framework for choosing between them; strong answers reference clean core, API dependency risk, team ownership, and cloud edition constraints rather than just naming BTP as 'the cloud way to extend SAP.'