Understanding SAP BTP architecture means understanding how SAP organizes accounts, environments, and services. Unlike a typical cloud platform, BTP has a hierarchical account model and multiple runtime environments, and the choices you make at the architecture level shape everything from billing to transport management.
Whether you are planning a greenfield landscape or restructuring an existing one, this guide walks through the core architecture building blocks and the best practices that keep production BTP estates maintainable.
SAP BTP Account Model
The account model is the foundation of any SAP BTP architecture. From the top down:
- Global account — The top-level container, tied to your SAP Universal ID and contract. Entitlements (quota for services) are allocated here and distributed downward.
- Directories — Optional grouping layers for organizing subaccounts by business unit, region, or project. Directories can hold entitlements and apply policies, but they do not host applications directly.
- Subaccounts — Where services are actually provisioned and applications run. Each subaccount lives in a region (for example,
cf-eu10orus10) and belongs to exactly one environment. - Spaces (Cloud Foundry) / Namespaces (Kyma) — The finest-grained unit, used to isolate deployed apps and service bindings within a subaccount.
This hierarchy lets you mirror organizational structures — for example, one global account with separate directory trees for Development, Quality, and Production subaccounts, each placed in the right region.
Environments
BTP offers three runtimes, and choosing among them is a key architectural decision.
Cloud Foundry Environment
The most mature and widely used runtime. Applications are deployed as MTA archives, bound to services via service instances, and scaled with Cloud Foundry's standard mechanisms. Best for CAP apps, SAP Fiori deployments, and most general-purpose cloud development.
Kyma Environment
A managed Kubernetes runtime based on Gardener, with serverless capabilities. Use Kyma when you need container orchestration, custom runtime images, or fine-grained control over the execution environment. Service consumption uses the SAP BTP Service Operator (Kubernetes CRDs) instead of cf create-service.
ABAP Environment
A cloud-optimized ABAP runtime for developing with RAP, CDS, and ABAP Cloud. It is the right choice when your team's expertise is ABAP and you are building SAP-centric cloud applications.
Many real landscapes use more than one environment — for example, an ABAP Environment subaccount for backend logic and a Cloud Foundry subaccount for the Fiori frontend.
Key Services
Beyond runtimes, several services are architectural concerns that cut across every landscape:
- SAP Cloud Identity Services (IAS/IPS) — Authentication and user provisioning. Almost every production BTP app integrates with IAS for OAuth 2.0 or OpenID Connect.
- Destination Service and Connectivity Service — Connect apps to remote HTTP and on-premise systems. Cloud Connector extends this safely into your private network.
- Service Manager — Manage service instances and bindings across environments, including cross-environment consumption.
- Cloud Transport Management — Move artifacts between subaccounts following a defined transport route.
- Cloud Logging Service — OpenTelemetry-based observability for logs, metrics, and traces through OpenSearch Dashboards.
These services are the connective tissue of a BTP architecture. Getting their configuration right early saves significant rework later.
Architecture Best Practices
- Mirror your lifecycle with subaccounts — one tree each for Dev, Test, and Prod, with Cloud Transport Management connecting them.
- Match region to your users and systems — keep apps and the SAP systems they call in the same or a nearby region to reduce latency and simplify connectivity.
- Plan identity early — federate IAS with your corporate identity provider before you build apps, not after.
- Use directories for governance — group subaccounts by team or business domain and apply entitlement budgets at that level.
- Decide on multitenancy up front — building a SaaS application changes how you structure subaccounts, app routing, and tenant isolation.
- Automate with the
btpCLI and Infrastructure-as-Code — avoid hand-configuring subaccounts; treat your landscape as code.
AI-Assisted BTP Development
Designing a BTP architecture involves a lot of service-specific knowledge — plans, entitlements, region availability, naming, and transport rules. General-purpose AI assistants often hallucinate service configurations or recommend patterns that do not match SAP's current guidance.
The SAP BTP best-practices skill gives an AI assistant accurate context for account hierarchies, environment selection, security, CI/CD, and governance:
npx skills add secondsky/sap-skills --skill sap-btp-best-practices
Pair it with the core platform skill and the service-specific skills (connectivity, identity, transport management, cloud logging) that match your landscape. With the right context loaded, an assistant can help you plan subaccount structures, draft transport routes, and generate MTA and CI/CD configurations that follow SAP conventions instead of generic cloud patterns.