Choosing Between In-App and Side-by-Side Extensibility for a Given Requirement
A practical decision framework for routing a specific extension requirement to in-app key user tools, developer extensibility, or side-by-side BTP extensions, based on data locality, complexity, and lifecycle needs.
Explanation
Once an organization commits to a clean core strategy, the hardest recurring decision is not whether to extend, but where. Architects are regularly asked: should this requirement be built as an in-app extension inside S/4HANA, or as a side-by-side application on BTP? Getting this wrong creates either an over-engineered microservice for a trivial field addition, or a fragile in-app custom code layer that blocks future upgrades. The first filter is data locality and transaction criticality. If the requirement is a small UI adjustment, a custom field, a simple validation, or a minor business rule that must execute synchronously inside a core business transaction (like a sales order save), in-app extensibility using released, stable extension points is usually correct. These extensions live inside the S/4HANA system, use SAP-released APIs or BAdIs designed for extensibility, and are checked by the system for upgrade compatibility. In S/4HANA Public Cloud, in-app extensibility is largely restricted to key-user tools (custom fields, custom logic, custom CDS-based reports) with a curated, stable extension surface. In Private Cloud and on-premise, more developer-level in-app extensibility is possible, but architects must still confirm which objects are on the officially released extensibility allow-list versus classic unrestricted ABAP development. The second filter is process scope and reuse. If the requirement spans multiple systems (for example, a S/4HANA order combined with a non-SAP logistics provider and a customer-facing portal), or needs its own independent release cycle, scaling profile, and UI framework, side-by-side extensibility on BTP is generally preferable. Side-by-side apps run outside the core, communicate via released APIs or events, and can be deployed, tested, and rolled back independently of the core system's upgrade calendar. This isolation is the primary architectural benefit: a bug in a side-by-side app does not block or delay an S/4HANA upgrade, and the core's clean-core posture is preserved. A third filter is skill and tooling ownership. In-app extensions are typically owned by functional/technical teams close to the core system and reviewed under the same change management as core configuration. Side-by-side extensions require BTP platform skills (CAP model, event mesh or integration suite, identity and destination configuration) and a separate DevOps pipeline. Architects should assess whether the organization has, or is willing to build, this platform capability, because side-by-side sprawl without governance creates its own technical debt. A fourth consideration is performance and latency. In-app extensions execute in-process with the core transaction and have near-zero network latency, which matters for logic embedded in high-volume transactional flows. Side-by-side extensions incur network round-trips through APIs, so synchronous calls inside a critical path (like pricing during order entry) need careful design, caching, or asynchronous patterns to avoid degrading core system responsiveness. Finally, license and cost boundaries matter: BTP side-by-side services consume BTP capacity units or subscriptions and add operational cost, while in-app extensibility uses existing S/4HANA capacity but is bounded by the extensibility framework's limits (e.g., quotas on custom fields or CDS views in Public Cloud). Architects should present these trade-offs explicitly to stakeholders rather than defaulting to either extreme, and document the decision rationale so future teams understand why a given requirement lives where it does.
Real project scenario
During a S/4HANA Public Cloud rollout, a subsidiary requested a custom approval workflow with external e-signature integration for high-value purchase requisitions. Initially the team tried to force this into in-app key user extensibility using custom logic, but hit the extensibility framework's boundaries for external HTTP calls and complex multi-step approval state. The architect reclassified it as a side-by-side extension: a CAP-based approval microservice on BTP that consumed the purchase requisition via released APIs and events, called the e-signature provider, and wrote the approval decision back through a released inbound API. This kept the core clean and let the subsidiary iterate on the approval UI independently.
Common mistakes
• Defaulting every custom requirement to side-by-side BTP development even for trivial field or validation changes, adding unnecessary platform overhead • Forcing complex multi-system orchestration into in-app extensibility because it feels 'simpler,' resulting in fragile custom code tightly coupled to core objects • Not checking whether required in-app extension points are actually on the released extensibility allow-list before starting development • Ignoring latency implications of synchronous side-by-side calls placed inside high-volume core transactions • Failing to document the decision criteria, so later teams repeat the same architecture debate without a record of prior reasoning
Best practices
• Maintain a documented decision matrix mapping requirement types to extensibility patterns, reviewed periodically as SAP's released extension points evolve • Validate extension point availability against the current release before committing to an in-app approach • Prototype latency-sensitive side-by-side integrations early to validate performance before full build-out • Assign clear ownership and change management processes separately for in-app and side-by-side extensions • Record architecture decisions (ADRs) for significant extensibility placement choices to preserve institutional knowledge
Interview angle
Interviewers assess whether a candidate can articulate concrete, repeatable decision criteria rather than opinions. Be ready to walk through a specific requirement, name the filters (data locality, process scope, skill ownership, performance, cost), and explain why you would land on in-app versus side-by-side, including what would change your answer for a different deployment target (public cloud vs on-premise).