Application Development: Use Cases and Decision Patterns

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 10, 2026 · 15 min read

Where This Article Sits#

References#

1) The Application Development Landscape#

This article does not introduce new tools — it covers the same four families described in B01 from a different angle: how to pick between them. Recap of the families, with the decision-making lens this article uses.

They are not substitutes. The selection rules in §5 are the entire reason this series exists — without them, “let’s use SAP Build” defaults to Build Apps and the project pays for it later.

2) How It Connects to S/4HANA#

The four families connect to S/4HANA at different layers, with different coupling strengths. The connection point determines clean-core compliance, release-cadence independence, and which extensibility tier (Key User → Developer → Side-by-side) the work belongs to.

                        SAP BTP — Application Development families
   ┌────────────────────────────────────────────────────────────────────────┐
   │  Pro Code  →  CAP, Build Code, BAS  ──── Cloud Foundry / Kyma          │
   │  ABAP      →  BTP ABAP Environment (Steampunk, side-by-side)           │
   │  Low Code  →  Build Apps, Build Process Automation                     │
   │  Portal    →  Build Work Zone (surfaces apps from above)               │
   └─────────────┬───────────────────────────────────────┬──────────────────┘
                 │ released APIs, OData,                 │
                 │ business events                       │ launchpad / site
                 ▼                                       │
   ┌────────────────────────────────────────────────┐    │
   │  S/4HANA Cloud (public or private edition)     │ ◄──┘
   │  ── Key User extensibility (in-app)            │
   │  ── Embedded Steampunk (in-stack ABAP Cloud)   │
   └────────────────────────────────────────────────┘

Key point: Coupling chooses the family before skill or cost do. If the extension needs direct access to standard S/4HANA tables or BAdIs, the choice is Key User extensibility or Embedded Steampunk — every other family is wrong by construction. Only after coupling is settled do team skill and entitlement narrow the remaining options.

3) Maturity Map#

All four families are production-ready in 2026, but the operational risk profile differs. This map is honest, not promotional — pick the family whose maturity profile your project can actually absorb.

4) Requirements Checklist#

Each capability has its own checklist. Run all four when scoping any non-trivial BTP development; the cross-family checks in §4.5 catch the requirements that span tool boundaries.

Pro Code (CAP, Build Code, BAS) prerequisites#

ABAP (Steampunk + Embedded Steampunk) prerequisites#

Low Code (Build Apps + Build Process Automation) prerequisites#

Portal (Build Work Zone) prerequisites#

Cross-family clean-core and operations checks#

5) Decision Criteria#

Three questions decide whether BTP application development is even the right answer; the domain-selection table picks the family; the licensing table prevents commercial surprises.

The three questions to ask first#

Q1. What is the measurable business pain?

If the answer is “we want to build something on BTP”, the requirement is not ready. The pain must be specific (an approval cycle taking 14 days, a manual data entry costing 20 FTE-hours weekly, a missing customer self-service portal causing call-centre overflow). Without a measurable pain, no tool selection is defensible — and “we have BTP credits to use” is not a pain.

Q2. Who owns the data, and where must it stay?

Tight coupling to S/4HANA tables (custom fields, in-stack logic) is one residency profile; side-by-side on BTP with regional data is another; mixed SAP + non-SAP integration is a third. Data residency, ownership, and the GDPR/SOC2 boundary determine whether the work belongs in S/4HANA, in BTP ABAP Environment, in CAP, or somewhere else entirely.

Q3. Who is the internal sponsor with budget authority?

Central IT, an LoB owner, or a process owner — the answer changes which commercial model fits (subscription vs BTPEA credits vs PAYG) and which family’s price tag is even legible to the sponsor. A tool the sponsor cannot fund is the wrong tool, regardless of technical fit.

Tool selection by use-case shape#

Licensing and cost#

6) Common Failures#

These are requirements-stage failures, not implementation bugs. Each one has been observed often enough that recognising the pattern is faster than re-deriving the lesson.

Failure 1: “Use SAP Build for everything”

SAP Build is four products (Code, Apps, BPA, Work Zone), not one platform. Treating “Build” as a single answer flattens four distinct selection decisions into a single misapplied default — usually Build Apps, because it is the most-marketed pillar. The fix is to use the use-case table in §5 first, then identify which Build pillar (or no Build pillar) matches.

Failure 2: Low-code for an enterprise-critical workload

Build Apps targets departmental apps with simple UI, OData/REST integration, and citizen-developer ownership. Picking it for a customer-facing transactional system or a high-throughput service hits performance, governance, and UI flexibility ceilings that surface during user-acceptance testing — too late to pivot cheaply. The fix is to be honest about scope at requirements time and reach for CAP on Build Code if “enterprise-critical” is a real constraint.

Failure 3: CAP for a customisation tightly bound to S/4HANA tables

CAP and S/4HANA can connect via released APIs, but a customisation that needs in-stack data access (custom fields on standard tables, on-stack BAdIs) belongs in Embedded Steampunk or Key User extensibility — not in CAP. Building it in CAP forces a brittle integration layer that violates clean-core in spirit, even if it doesn’t violate it on paper.

Failure 4: ABAP Cloud for a non-SAP integration in mixed languages

When the team is ABAP-skilled, every requirement looks like an ABAP requirement. A side-by-side service that orchestrates SAP and non-SAP APIs in Node.js or Java belongs in CAP, not in BTP ABAP Environment. The selection criterion is the work, not the team’s history.

Failure 5: Work Zone scoped as an “application”

“Build the portal in Work Zone” sometimes means “we want a launchpad to surface our existing apps” (correct scope for Work Zone) and sometimes means “we want a custom site with custom logic” (Work Zone is the wrong place). Untangle this in requirements: Work Zone surfaces apps; it is not where the apps are built.

Failure 6: Skipping the clean-core review

When extension placement is decided by team preference instead of by coupling, cadence, data residency, and entitlement, the result is a clean-core violation that surfaces during the next S/4HANA upgrade. The fix is to run the Clean Core extensibility tier classification before the tool decision, not after.

Failure 7: Ignoring commercial entitlement until the build sprint

A “right” tool the customer cannot procure is the wrong tool. BTPEA scopes, CPEA balances, and subscription line items must be confirmed during requirements — not when the developer tries to subscribe to a service mid-build and procurement blocks it.

FAQ#

Q: This is a summary article — should I read B01–B07 first, or can I start here?

Start at B01 for the capability map, then jump to whichever of B02–B07 covers your candidate tools. Use B08 to cross-check the selection. The series is sequenced for first-time readers; veterans can use B08 as a standalone decision aid.

Q: How do I apply this on-premise vs cloud?

The decision pattern is cloud-first by default — BTP is the SAP cloud development platform. For on-premise S/4HANA, Key User extensibility and on-stack ABAP are still relevant; side-by-side options pivot to BTP regardless. The clean-core dimensions (coupling, cadence, data) apply identically; only the runtime catalogue narrows.

Q: We have BTPEA credits and the customer wants to “use them” — is that a valid driver?

No. Credit usage is a financial outcome, not a requirement. The right path is to identify the highest-impact pain (Q1), pick the tool that fits the use-case shape, then check that the tool is in BTPEA scope. If the credits cover the right tool, great. If not, that’s a procurement conversation — not a reason to build the wrong thing.

Q: When should I descope BTP application development from a project entirely?

Three signals: (1) no measurable business pain (Q1 fails), (2) the work belongs in S/4HANA itself (Key User extensibility or RAP in-stack — no BTP needed), or (3) the customer has neither the entitlement nor the operations skills to run a BTP service after handover. Any one of these is enough to remove BTP from scope this round.

Q: How do I document this decision properly so it survives an audit?

Three artefacts: (1) the Clean Core extensibility tier classification with reasoning, (2) the use-case → tool mapping (this article’s §5 table is a defensible template), and (3) the commercial entitlement confirmation from procurement. Reference architecture from SAP Discovery Center, if matched, provides external validation.

Q: Is Joule for Developers a separate tool or a feature of the others?

A horizontal capability across BAS, ADT, and VS Code via Joule Studio. It does not change the family selection in §5 — pick the family for the work, then turn on Joule inside that family. SAP’s quoted productivity gains (~20% write, ~25% test) are family-agnostic.

Q: When does it make sense to combine families instead of picking one?

Frequently. A typical pattern is CAP on Build Code (the service) + Build Apps for an internal admin UI + BPA for the approval workflow + Work Zone to surface it all. The §5 table picks tools for use-case shapes, not for entire projects — most real projects span multiple shapes.

Summary#

BTP application development is solved at requirements time, not at coding time. The four families (Pro Code, ABAP, Low Code, Portal) cover overlapping outcomes through different runtimes and commercial models, and the wrong default — usually “Build Apps for everything” — is far more common than the right one. Apply the four selection dimensions in order: coupling, skill, cadence, entitlement. Use the §5 use-case table as a defensible starting point and the §6 failure list as a sanity check before sign-off. The L2-B series exists so this decision is not improvised.

What to Read Next#