Application Development on SAP BTP: Overview and Capability Map

JinJin48

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

May 10, 2026 · 13 min read

Where This Article Sits#

References#

1) The Application Development Landscape#

SAP BTP does not have one “development tool.” It has four families, each built around a different developer persona and a different runtime. Treating them as interchangeable is the most common requirements-stage mistake in this space.

They are not substitutes. A Build Apps no-code project does not become a CAP service; an ABAP Cloud extension cannot be repackaged as a Build Code microservice without a rewrite. Family choice is a one-way door for the lifetime of the asset and belongs in the requirements stage.

2) How It Connects to S/4HANA#

Every BTP development family talks to S/4HANA, but the direction, coupling, and contract differ:

                         SAP BTP — Application Development
   ┌────────────────────────────────────────────────────────────────────┐
   │  Pro Code:    Build Code / BAS / CAP   ─── Cloud Foundry / Kyma    │
   │  Low Code:    Build Apps / Build Process Automation                │
   │  ABAP:        BTP ABAP Environment (Steampunk, side-by-side)       │
   │  Portal:      Build Work Zone (standard + advanced)                │
   └────────────────────────────┬───────────────────────────────────────┘
                                │ Released APIs, OData, events
                                ▼
   ┌────────────────────────────────────────────────────────────────────┐
   │  S/4HANA Cloud (public or private edition)                         │
   │  ┌──────────────────────────────────────────────────────────────┐  │
   │  │  Embedded Steampunk (in-stack ABAP extensions, tight-coupled)│  │
   │  └──────────────────────────────────────────────────────────────┘  │
   └────────────────────────────────────────────────────────────────────┘
                                ▲
                                │ Released APIs (RFC where still allowed)
                                │ via SAP Cloud Connector
   ┌────────────────────────────┴───────────────────────────────────────┐
   │  S/4HANA on-premise                                                │
   └────────────────────────────────────────────────────────────────────┘

Key point: Side-by-side BTP development is decoupled from the S/4HANA upgrade cycle and can use any language; embedded (in-stack) ABAP is tightly coupled and can only be ABAP. Choosing the wrong side of that line is what produces extensions that block upgrades or extensions that drift away from the core.

3) Maturity Map#

4) Requirements Checklist#

Each family has a different set of questions to clear before you commit to it. Treat these as gating items — if any line is unanswered at requirements stage, the project is not ready to enter design.

Pro Code (Build Code, BAS, CAP)#

Low-Code / No-Code (Build Apps, Build Process Automation)#

ABAP (BTP ABAP Environment + Embedded Steampunk)#

Portal (Build Work Zone)#

5) Decision Criteria#

The three questions to ask first#

Q1. What is the measurable inefficiency the new app must remove?

Without a measurable starting point — hours per week, FTE cost, error rate, customer wait time — every “let’s modernise” pitch eventually loses funding. The question forces a real number before any tool is named.

Q2. Which side of the S/4HANA core does the data live on?

If the logic operates directly on a standard S/4HANA table or a custom field on a standard business object, the right answer is in-stack (Embedded Steampunk or Key User extensibility). If it operates on data mostly outside the core — partner data, IoT data, customer-facing portals — side-by-side on BTP is correct.

Q3. Who owns this app for the next three years?

A pro-code CAP project with no permanent owner becomes legacy faster than a low-code app does. Citizen-built apps without a sponsor become shadow IT. ABAP extensions without an upgrade-test owner become upgrade blockers. Naming the owner is gating.

Domain selection by project context#

Licensing and cost#

6) Common Failures#

Failure 1: Picking SAP Build for everything

“SAP Build” is a marketing umbrella, not a single product. Teams that say “Build” without specifying Apps, Code, Process Automation, or Work Zone end up procuring the wrong subscription. Force a family-and-tool choice at requirements stage and write it into the charter.

Failure 2: Side-by-side when Embedded Steampunk fits

A custom field on a standard S/4HANA table can almost always be done in Embedded Steampunk and is included with the S/4HANA Cloud entitlement. Building it on BTP burns credits and requires data round-trips for no functional gain. Trigger phrase: “we’re paying BTP credits for an extension that is just a custom field.”

Failure 3: Kyma without Kubernetes operations

Kyma is genuinely cloud-native, but it is Kubernetes — node pools, RBAC, network policies, observability. Teams that pick it because it sounds modern, without already running Kubernetes elsewhere, lose the saved development time to operations firefighting. Cloud Foundry remains the safer default.

Failure 4: Citizen-built apps for systems of record

Build Apps is excellent for departmental tools and prototypes. Once a citizen-built app hosts master data, generates audit-relevant transactions, or feeds financial reporting, it is no longer citizen-built. Use a documented sunset-or-promote rule: at a defined threshold, IT rebuilds it in a pro-code family.

Failure 5: Process automation without a process map

Build Process Automation is a multiplier on whatever process you give it. If the process is undocumented, the automation amplifies the chaos and produces an opaque dependency. Requiring a documented process map as input to any SBPA scope is the cheapest defence.

Failure 6: BTP credit budget tied to month one, not month twelve

Credits look generous on day one because nothing is running yet. By month twelve, an event-driven CAP app with HANA Cloud, Joule calls, and Build Apps front-ends consumes credits faster than the pilot assumed. Build the year-twelve curve into the commercial case from the start.

Failure 7: No ownership for ABAP extensions across upgrades

Embedded Steampunk extensions follow S/4HANA Cloud’s quarterly release cadence. Without a named owner running ATC checks and regression tests on each release candidate, an extension that worked at go-live becomes an upgrade blocker by year two.

FAQ#

Q: Can on-premise SAP customers use these BTP development families?

Yes. BTP development is independent of whether the source system is S/4HANA Cloud or S/4HANA on-premise. Side-by-side patterns (CAP, ABAP Environment, Build Apps) all work against on-premise systems through SAP Cloud Connector and released APIs. Only Embedded Steampunk requires S/4HANA Cloud, because it lives inside that runtime.

Q: How does licensing work — is it one bill or many?

It depends on the commercial model. With BTPEA (BTP Enterprise Agreement), most BTP development services share a single credit pool and you draw against it as services are activated. Standalone subscriptions (BAS, some Build editions) are billed separately. HANA Cloud is almost always billed as a separate line, even within BTPEA. Model the total of credit + subscription + database before committing.

Q: When should we descope a development family from a project?

When Q1 (measurable pain) returns “we want to modernise” with no number, descope. When Q3 (three-year owner) returns “we’ll figure that out later,” descope. When the family is being chosen by what the team knows rather than what the problem requires, escalate to the architecture lead and document the constraint explicitly.

Q: How do we document the development-family requirement properly?

In the project charter, write one line per asset: Asset X uses Family Y, tool Z, runtime R, owned by O, sized for usage profile P. Five fields, one line. Any empty field means the requirement is not ready. Longer documents tend to hide gaps.

Q: Do we need Joule for Developers from day one?

No. Joule is GA in core scenarios and SAP’s stated efficiency gains (around 20% writing time, 25% testing time) are real, but it is not a prerequisite for any of the four families. Treat Joule as an accelerator that a team adopts when the development practice itself is already healthy. Adding it to a team without CI/CD or test discipline does not fix the underlying problem.

Q: How does Clean Core extensibility map to these families?

Clean Core “Level A” means custom code lives outside the digital core, accessed via released APIs and events. All four families can produce Level A extensions when used correctly: ABAP Cloud (in-stack or side-by-side), CAP, and SAP Build all qualify. The family choice is about the team and the use case, not the cleanliness rating itself.

Summary#

SAP BTP’s application development surface is four families: Pro Code, Low-Code, ABAP, and Portal. Each maps to a specific developer persona, runtime, and commercial line. They are not substitutes, and the family decision is a one-way door for the lifetime of each asset.

In 2026 every family is production-ready. The safest defaults remain Cloud Foundry for pro-code and BTP ABAP Environment for ABAP teams. Kyma rewards customers already running Kubernetes; Joule for Developers accelerates teams whose development practice is already healthy.

The consultant’s job is to refuse “let’s use SAP Build for everything,” translate one measurable pain into one family, and defer the others until a second pain appears. B02 through B08 drill into each family individually and converge on the decision patterns in B08.

What to Read Next#