Classifying Extension Types: In-App, Developer, and Side-by-Side Trade-offs
Provides a structured framework for evaluating in-app, developer, and side-by-side extensibility options against requirement characteristics, deployment model constraints, and long-term maintenance cost.
Explanation
Once an organization accepts that extensibility choices carry architectural weight, the next skill is a repeatable classification method rather than case-by-case improvisation. This lesson builds a decision framework across the three broad extension categories and explains the trade-offs an architect must weigh for each specific requirement. In-app extensibility covers configuration-driven changes and key-user tools that operate within the boundaries SAP has explicitly released for customer use, such as custom fields, custom business logic using released extension points, and custom UI adaptations built with supported tools. The strength of in-app extensibility is that it is generally upgrade-stable, requires less specialized skill, and keeps everything inside the core system's lifecycle. Its limitation is scope: it cannot address requirements that need complex custom business logic, external system orchestration, or capabilities outside what SAP has released for that layer. In public cloud editions, in-app extensibility is often the primary or even the only sanctioned path for functional gaps, because deeper access is restricted. Developer extensibility, in on-premise or private cloud contexts, allows custom ABAP development using released APIs and extension points, typically within a defined namespace and following strict rules against modifying SAP standard objects. This gives more power than in-app tools while still aiming to preserve upgrade compatibility, provided developers use only released, stable interfaces rather than internal or unreleased objects. The risk here is real: if developers use non-released objects because they appear convenient, the organization reintroduces the exact upgrade fragility that clean core principles are meant to prevent. Governance must therefore include technical guardrails, such as code checks against release status, not just policy documents. Side-by-side extensibility moves custom logic entirely outside the digital core, typically onto SAP BTP, communicating with the core system through APIs, events, or other integration technologies. This is the most flexible option, supporting custom applications, complex integrations, machine learning scenarios, and functionality that has no equivalent inside the ERP layer at all. It is also the most operationally complex: it introduces a separate platform to secure, monitor, scale, and pay for, plus integration latency, error handling, and data consistency considerations that in-app or developer extensibility do not usually face to the same degree. Side-by-side is often the only viable pattern in public cloud editions when in-app extensibility genuinely cannot meet the requirement, since deep developer extensibility inside the core is generally not available there. A sound decision framework asks, for each requirement: does a released in-app capability already cover this, even partially, with acceptable trade-offs on flexibility. If not, is developer extensibility inside the core available in this deployment model, and can it be implemented using only released, upgrade-stable objects. If neither is sufficient or available, does the requirement's complexity, scale, or need for independent lifecycle management justify a side-by-side application on BTP, accepting the added integration and operational overhead. Architects must also weigh non-functional dimensions: latency tolerance (side-by-side introduces network hops), data residency and security boundaries (extending core data outside the system has compliance implications), team skill availability (BTP development requires different skills than ABAP extension development), and total cost of ownership over multiple years, not just initial build cost. A cheap-looking in-app workaround that gets stretched beyond its intended use can become harder to maintain than a properly designed side-by-side application.
Real project scenario
A retail company on S/4HANA public cloud needed a complex freight cost optimization engine that considered dozens of external carrier rate feeds and ran what-if simulations. In-app extensibility could not support this complexity, and developer extensibility inside the core was not available at the depth required in that public cloud edition. The architecture team designed a side-by-side application on BTP that consumed released APIs from the core for order and shipment data, ran the optimization logic externally, and wrote results back through released integration APIs. This kept the core clean while delivering the complex capability, at the cost of additional BTP subscription expense and a dedicated integration monitoring effort that had to be budgeted and staffed.
Common mistakes
• Choosing side-by-side extensibility by default because it feels more modern, without checking whether in-app or developer extensibility could meet the need more cheaply • Using non-released or internal APIs and objects in developer extensibility, undermining the upgrade-stability the pattern is supposed to provide • Underestimating the ongoing operational cost of side-by-side applications, including monitoring, patching the BTP components, and managing API version changes • Ignoring latency and data consistency implications when moving logic out of the core for scenarios that need near-real-time consistency • Failing to revisit classification decisions when SAP releases new in-app capabilities that could later replace a more complex extension built earlier
Best practices
• Apply extension classification in a fixed order of preference: in-app first, then developer extensibility with released objects only, then side-by-side as the last resort • Re-evaluate existing extensions periodically against new SAP-released in-app capabilities that may allow simplification • Include non-functional criteria such as latency, data residency, and team skill availability in every extension classification decision, not just functional fit • Enforce technical guardrails, such as static checks for released-object usage, rather than relying purely on documented policy • Budget for the full operational lifecycle of side-by-side applications, including monitoring, API versioning, and platform subscription costs, not just initial development
Interview angle
Architect interviews frequently present a business requirement and ask the candidate to classify it into in-app, developer, or side-by-side extensibility, then defend the choice against alternatives. Strong candidates explicitly mention deployment model constraints, released-object discipline, and total cost of ownership rather than jumping straight to a single preferred pattern.