Extensibility approaches as an investment decision
What you'll learn
The three extensibility approaches trade cost and risk — pick the lowest-effort one (key-user, then developer, then side-by-side) that fully meets the need; side-by-side is a clean choice for a separate lifecycle, not a penalty.
- Key-user (in-app): cheapest, lowest risk, done by power users — no developers.
- Developer extensibility (on-stack ABAP Cloud): in-system custom code on supported rules — moderate cost.
- Side-by-side on BTP: just as clean for the core, the right choice for a separate lifecycle, but highest cost to own (a second platform).
SAP offers three approaches for building extensions, and each is really a different investment profile. Key-user (in-app) extensibility is done by business power users inside the application itself — adding fields or simple logic. It is the cheapest to own and the lowest risk because no classic development is involved.
Developer extensibility is custom code that lives inside the SAP system but is written against the modern, supported rules (on-stack ABAP Cloud). It needs developers, so it costs more than key-user changes, but it keeps the core clean for anything the in-app tools cannot do. Side-by-side extensibility runs the extension on a separate SAP Business Technology Platform (BTP) and connects back through published interfaces. It is just as 'clean' for the core as the on-stack options — it is the right choice when an extension needs its own lifecycle or runtime — but it carries the highest cost to own, because you now operate a second platform.
The management rule is to pick the lowest-effort approach that fully meets the requirement, and escalate only when you must. Reaching for side-by-side when a key-user change would do is over-engineering you will pay to run for years — but note that side-by-side is a deliberate, clean choice, not a fallback.
Key points
- Key-user (in-app): cheapest, lowest risk, done by power users — no developers.
- Developer extensibility (on-stack ABAP Cloud): in-system custom code on supported rules — moderate cost.
- Side-by-side on BTP: just as clean for the core, the right choice for a separate lifecycle, but highest cost to own (a second platform).
- Always choose the lowest-effort approach that fits the need; escalate only when forced.
Examples
Adding a field to a screen is a key-user decision. A custom transactional app over a custom table is developer extensibility. A heavy custom service with its own release schedule is side-by-side on BTP — and a bigger operating bill.
Source notes: clean-core-curriculum (business synthesis)
Ask Claude
Build a prompt from this lesson + your question and open a fresh Claude chat with it pre-filled — handy for adapting a before/after pattern to your own object.