SAP BTP Extension Strategies: Side-by-Side vs In-App

Deciding whether to extend S/4HANA using in-app key user/developer tools versus building a separate side-by-side application on BTP.

Extension strategy is one of the most practically important architectural decisions in any S/4HANA project, and interviewers ask about the side-by-side versus in-app choice specifically to see whether a candidate can reason about trade-offs (upgrade impact, performance, licensing, team skill fit) rather than defaulting reflexively to whichever approach they personally know best.

In-app extensibility is like building an addition directly onto your existing house using the same foundation and materials - convenient and tightly integrated, but constrained by the house's own structure and upgrade schedule; side-by-side extensibility is like building a separate guest house on the same property connected by a well-defined path (APIs) - it can use entirely different architecture and be renovated on its own timeline, at the cost of maintaining a second structure.

Key Concepts

In-app extensibility (covered in more depth in its own topic) keeps the extension running inside the S/4HANA system itself - key user tools for simple field/logic additions, or developer extensibility (RAP-based, restricted to released APIs) for more substantial custom business objects and Fiori apps - and is the right choice when the extension is tightly coupled to S/4HANA's own data and transactions, needs to run within the same transactional boundary/performance characteristics as core processes, or is simple enough that key user tools suffice without needing separate infrastructure.

Side-by-side extensibility deploys the custom application entirely on BTP (via Cloud Foundry, Kyma, typically using CAP), communicating with S/4HANA over released APIs (OData, event-based via Event Mesh) rather than running inside the S/4HANA system's own process and database. This is the right choice when the extension needs technology or scaling characteristics S/4HANA's ABAP stack doesn't naturally provide (a machine-learning-driven recommendation engine, a customer-facing portal with very different scaling/traffic patterns than internal SAP users, integration logic spanning many non-SAP systems), when the extension's release cadence needs to be decoupled from S/4HANA's own upgrade cycle, or simply when the development team's skill set (Node.js/Java, not ABAP) is a better fit for the technology.

A senior-level answer connects this decision explicitly to the clean-core principle discussed elsewhere - side-by-side extensibility is SAP's preferred direction specifically because it keeps S/4HANA's core completely untouched (zero custom code inside the core system to remediate on the next upgrade), at the cost of needing to manage an additional deployed application and its own lifecycle, security, and integration configuration on BTP; while in-app extensibility, done through the governed key-user/developer-extensibility tiers rather than core modification, remains entirely appropriate and often simpler for tightly-coupled, S/4HANA-data-centric requirements that don't need independent scaling or a different technology stack.