SAP BTP explained: Business Technology Platform

SAP BTP (Business Technology Platform) is SAP's platform layer: the cloud services used to build, integrate and analyse around an SAP core instead of modifying it. This guide covers what sits on the platform, the work phase by phase, who staffs it, and how the account structure decides what you can deploy.

Services and runtimes, not module codes

BTP has no classic module codes — no FI-GL or MM-PUR. Practitioners name services and runtimes.

Application development — side-by-side apps in ABAP Cloud or the Cloud Application Programming Model (CAP), Fiori and SAPUI5 front ends, SAP Build for low-code.
Integration — the Integration Suite: integration flows, API management, event-driven messaging, and where PI and PO people move (the integration specialism).
Data, analytics and AI — SAP HANA Cloud, SAP Datasphere, SAP Analytics Cloud and the AI services those apps call: the platform half of the analytics area.
Platform operations — subaccounts, entitlements and quotas, the runtimes (Cloud Foundry, Kyma, the ABAP environment), Cloud Connector connectivity, identity, and Cloud Transport Management.

What does a week on a BTP project look like?

Early weeks are extensibility workshops; middle weeks are service-and-Fiori build with connectivity setup; cutover weeks are entitlements, destinations and role collections. The rhythm follows the phase, not the calendar.

Design — what stays standard, what becomes a key-user extension, what becomes a side-by-side app, and who holds the entitlements.
Build — the service and its data model, the Fiori front end, destinations, role collections, and a transport route that matches how the programme is structured.
Test — connectivity is where it hurts: the Cloud Connector, principal propagation, an expired service key.
Cutover — production quotas, destinations repointed, subscriptions and role collections assigned.
Run — platform services update on the vendor's cadence, not the programme's, so a BTP app is maintained continuously, not frozen between upgrades (the AMS side).

In-app extension or side-by-side app?

Clean core means leaving the standard system unmodified and meeting a requirement either as a key-user extension inside it or as an app beside it on the platform; that choice is the judgement that pays. A key-user extension is still transported and re-checked at upgrade, but it ships with the system and has no deployment, runtime, monitoring or on-call of its own; a side-by-side app owns all of those and its own release cycle. Making that call repeatedly turns a builder into an architect, and it shapes the custom-code work in an S/4HANA conversion (what S/4HANA means for a career).

The runtime decides who can staff the work

Each runtime recruits from a different pool: the ABAP environment from ABAP developers, Cloud Foundry and Kyma from cloud engineers, the account layer from landscape people.

From ABAP — released APIs and ABAP Cloud instead of modifications; the shortest move (the developer route).
From outside SAP — cloud developers arriving through CAP, JavaScript and Fiori; the working stack is Git, CI and APIs, so day one needs less SAP vocabulary.
From Basis — platform operations is landscape work in a new place (the Basis route).
From a functional area — owning the extension backlog long enough to own its platform side (crossing the divide).

Evidence beats vocabulary: an app in production, an interface you built and operated. Interviews go straight at connectivity and lifecycle — how an on-premise service reaches a cloud app, how identity travels with it (what interviews test). A trial account produces showable work before a first project.

Global account, subaccount, entitlement

Entitlements and quotas are assigned from the global account down to subaccounts, and the subaccount is where a runtime, its destinations and its role collections live. That decides where code can be promoted: an app that runs in development but cannot be deployed is usually a subaccount never entitled to the service it calls. It also puts role collections on the platform side of authorizations, which is why access work often sits with the platform builder (which combinations work).