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.

Extending S/4HANA means choosing where the extension runs. Inside the system, or beside it on BTP.

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: the extension lives in S/4HANA. Key user tools for fields and simple logic; developer extensibility with RAP and released APIs for custom business objects and Fiori apps.

It fits when the extension is inseparable from S/4HANA's data and transactions — when it must run in the same transaction, with the same performance characteristics, against the same tables.

A custom field on a purchase order, validated when the order is saved, belongs here. Putting it on BTP would mean a network call inside a save.

Side-by-side: the extension runs on BTP and talks to S/4HANA over released APIs and events.

It fits when the extension needs something the ABAP stack does not naturally provide:

  - a different technology — a machine-learning model, a Python library
  - different scaling — a customer-facing portal with traffic unrelated to internal users
  - a different release cadence — weekly deploys, independent of the S/4HANA upgrade cycle
  - a different team — developers who write Node.js or Java, not ABAP

The clean-core argument favours side-by-side, and it is the reason SAP prefers it: nothing custom sits inside the core, so there is nothing to remediate at an upgrade.

The honest cost. A side-by-side extension is another deployed application with its own lifecycle, security, monitoring and connectivity configuration. For adding one field, that is a great deal of machinery for very little.

So the decision, stated plainly.

    tightly coupled to S/4HANA data and transactions   -> in-app
    different technology, scaling or release cadence   -> side-by-side
    simple field or logic addition                     -> key user tools
    needs to be transactional with the core            -> in-app

And the answer that lands. Not "side-by-side, because clean core". That is the direction and not a rule. The reasoning is which of the extension's requirements the ABAP stack serves well, and whether the independence is worth operating a separate application for.

What the interviewer is probing.1. "How do you choose between them?" Probing: the decision. Stalls: "Side-by-side always." Moves up: in-app for small additions tightly coupled to the process; side-by-side for anything with its own lifecycle, UI or non-SAP integration.

2. "What is the clean core principle?" Probing: the strategic point. Stalls: "Keep it tidy." Moves up: no modifications and only released interfaces, so upgrades are routine — which is what makes cloud ERP viable.

3. "What is the cost of side-by-side?" Probing: honesty. Stalls: "None." Moves up: another runtime, deployment pipeline and integration to operate, plus latency across the API boundary.

4. "Where does data live in a side-by-side extension?" Probing: the design question. Stalls: "In S/4." Moves up: ideally the extension's own store for its own data, reading S/4HANA through APIs — duplicating master data is what creates sync problems.