BTP Architecture Design: Overview and Key Decisions

JinJin48

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

May 13, 2026 · 16 min read

Where This Article Sits#

References#

1) The BTP Architecture Landscape#

SAP BTP architecture design spans five interconnected structural layers, each with a distinct decision owner and different reversibility characteristics. The SAP BTP Account Model defines the organizing principle: a global account maps to one SAP contract, under which directories and subaccounts are structured to reflect organizational and operational boundaries.

These layers are not substitutes. A solid runtime choice does not compensate for a poorly designed account hierarchy.

2) How It Connects to S/4HANA#

BTP does not run S/4HANA; it extends it. Every BTP architectural decision must trace back to a defined relationship with the SAP core. The SAP BTP Guidance Framework formalizes this relationship: side-by-side extensions on BTP decouple business logic from the S/4HANA kernel, enabling upgrades without breaking custom code.

┌─────────────────── Global Account ──────────────────────┐
│  ┌── Directory: Core ERP ───────────────────────────┐   │
│  │  Subaccount: S4-Ext-Dev / Test / Prod (CF)       │   │
│  └──────────────────────────────────────────────────┘   │
│  ┌── Directory: Integration ────────────────────────┐   │
│  │  Subaccount: IS-Dev / IS-Prod (Integration Suite)│   │
│  └──────────────────────────────────────────────────┘   │
│  ┌── Directory: Platform Services ──────────────────┐   │
│  │  Subaccount: cTMS  │  Subaccount: CI-CD          │   │
│  └──────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────┘
         │ Cloud Connector (RFC/HTTP)     │ Private Link
         ▼                                ▼
  ┌── On-Premise ──────────┐   ┌── Hyperscaler VPC ────┐
  │ SAP S/4HANA (ECC/OP)  │   │ SAP S/4HANA (RISE)   │
  └────────────────────────┘   └───────────────────────┘

S/4HANA extensions on BTP use a side-by-side pattern: custom logic in BTP subaccounts communicates with S/4HANA via OData, RFC, or events. The Clean Core principle requires all customization to live on BTP rather than in the S/4HANA kernel.

Key point: The BTP subaccount structure must mirror S/4HANA landscape stages (dev/test/prod) and organizational boundaries, not merely the deployment stages of a single application.

3) Maturity Map#

The maturity assessments below are grounded in SAP’s published documentation and community announcements. In-Metro DR RPO/RTO figures and the AWS/Azure-only restriction are sourced from the SAP Community announcement on In-Metro Disaster Recovery. Terraform state-drift behavior is documented in the SAP BTP Terraform Provider community blog.

4) Requirements Checklist#

Account model prerequisites#

The SAP BTP Account Model documentation and account model best practices guide underpin every item in this checklist — particularly the five-level directory maximum, naming convention guidance, and the universal recommendation to isolate production subaccounts.

Region and provider selection#

Region selection is irreversible at subaccount creation — a point confirmed in the SAP BTP Regions help article, which documents that each subaccount is associated with exactly one region and that region cannot be changed after creation.

Runtime environment prerequisites#

The SAP Community comparison of BTP runtime environments establishes the key selection principle: Cloud Foundry, Kyma, and ABAP are separate products with separate licensing and cost profiles, not interchangeable hosting options.

Connectivity prerequisites#

The SAP Cloud Connector help article documents both the HA master/shadow configuration requirement and the access control list (ACL) design that must restrict which back-end resources are exposed to each subaccount.

IAM prerequisites#

The SAP BTP Identity and Access Management help article documents that role collections do not propagate across account levels and that a custom IAS tenant is required for production corporate IdP federation.

5) Decision Criteria#

The three questions to ask first#

Q1. What is the measurable business inefficiency or technical pain point this BTP implementation will solve?

If the answer is “digital transformation” or “modernization,” the project has not identified a real requirement. A valid answer names a specific process, a quantifiable cost, and a named business owner. Without this, architecture decisions default to platform exploration.

Q2. Where does the data live, who owns it, and which jurisdictions govern its residency?

Region selection is irreversible at subaccount creation. Data sovereignty regulations (GDPR, PDPA, sector rules) determine which BTP regions are permissible. The SAP BTP Regions documentation confirms that region is chosen per subaccount and cannot be changed afterward. Legal/Compliance must answer this and document it as an approved constraint before any subaccount is created.

Q3. Is there an internal sponsor with confirmed budget authority covering both implementation and ongoing consumption costs?

BTP services produce recurring costs independent of the project budget. The Entitlements and Quotas help article explains that consumption is tracked against quota allocated per subaccount — a sponsor who approved a one-time implementation cost but not the operational budget is not a confirmed sponsor. Runtime and HA tier decisions must be validated against an approved consumption budget.

Domain selection by project context#

Licensing and cost#

6) Common Failures#

The failures below represent requirements-stage omissions sourced from SAP’s published guidance. Terraform state-drift behavior is documented in the SAP BTP Terraform Provider community blog. Private Link AWS/Azure-only limitations are covered in the SAP Cloud Connector and Connectivity help article.

Failure 1: Region lock-in discovered post-provisioning

A team selects a BTP region without consulting Legal/Compliance. At UAT, legal review identifies that customer PII cannot leave the country and the chosen region is non-compliant. Because subaccounts cannot be moved to a different region, the entire landscape must be rebuilt.

Failure 2: Scope assumption — “BTP is just a deployment platform”

Teams provision a single subaccount for all environments and services, treating BTP like a folder structure. When Integration Suite is added mid-project, destination naming conflicts arise and the Cloud Connector exposes production back-end systems to developers. Each subaccount is a complete isolated tenant, not a container within a shared tenant.

Failure 3: Identity provider trust configured too late

Corporate IAM is engaged only in the final sprint. IAS-to-corporate-IdP trust requires network changes, certificate exchange, and attribute mapping across security, AD, and network teams — none on the project. Go-live is blocked by identity federation work that was never scheduled.

Failure 4: Exception handling omission in connectivity design

A single Cloud Connector instance passes all pre-go-live tests. Six months later, OS patching takes the SCC host offline for 15 minutes and all on-premise-dependent BTP applications stop. HA master/shadow SCC is a requirements-stage item, not an implementation detail.

Failure 5: Data governance delay in multi-region DR

A cross-region DR architecture is partially built before Legal identifies that the secondary region violates the data residency contract. The architecture must be redesigned. Legal review of the secondary region must precede architecture approval, not follow it.

Failure 6: Terraform state drift from mixed provisioning

The platform team provisions all BTP resources via Terraform. A Global Account Administrator creates one subaccount manually via the cockpit. The Terraform state no longer matches reality; the next terraform apply makes unexpected changes. IaC-only or cockpit-only governance must be a day-zero decision.

Failure 7: Entitlement starvation in production

A project allocates most CPEA quota to development during prototyping. When the production subaccount is created, the required service plan quota is exhausted and reallocation requires procurement cycles. Entitlement consumption must be modeled across all planned subaccounts before any quota is assigned.

FAQ#

Q: Can SAP BTP architecture decisions be changed after go-live?

Region is immutable per subaccount — the SAP BTP Account Model documentation confirms that region selection is made at subaccount creation and cannot be changed afterward. Naming conventions, directory hierarchy, and IAM trust are all expensive to fix retroactively. Front-loading architecture decisions is always cheaper than retrofitting.

Q: Does BTP architecture apply to on-premise SAP S/4HANA?

Yes. BTP is designed to extend on-premise SAP systems. The SAP Cloud Connector provides secure reverse-invoke tunneling without inbound firewall openings. The challenge is not whether connectivity is possible but ensuring the SCC is HA-configured and its access control list (ACL) is scoped to the minimum required back-end resources.

Q: How does BTP licensing work, and what must be confirmed before architecture is finalized?

BTP is licensed under CPEA or BTPEA — a prepaid credit balance consumed at published rates. The Entitlements and Quotas help article explains how quota flows from global account to directories to subaccounts. Confirm: total balance and duration, services metered separately, expected monthly burn rate, and whether ABAP environment or Integration Suite require separate subscription agreements.

Q: When should multi-region HA/DR requirements be descoped?

If In-Metro DR satisfies the business requirement, cross-region architecture is unnecessary overhead. The SAP Community In-Metro DR announcement documents contractual SLAs of RTO ≤ 2 hr and RPO ≤ 5 min. Cross-region DR doubles subaccounts, requires stateless application design, and demands a tested failover runbook. Challenge the requirement if the business cannot quantify the cost of a 2-hour outage.

Q: How should BTP architecture decisions be documented?

Capture each as an Architecture Decision Record (ADR): decision area, options considered, chosen option, constraints satisfied, and decision owner. The SAP BTP Guidance Framework provides decision guides and reference architectures that can anchor each ADR to a defensible rationale. Region, runtime, connectivity, IAM trust, and HA tier must be countersigned by architect and sponsor before any subaccount is created.

Q: What is the correct approach to documenting on-premise connectivity requirements?

List every on-premise system: system ID, hostname/IP, RFC or HTTP path, consuming subaccount, and data classification. This drives the SCC access control list (ACL), firewall change requests, and HA sizing. Without it, the SCC is typically misconfigured with allow-all access — a finding in every security audit.

Q: Is a single SAP IAS tenant sufficient for all BTP subaccounts?

Yes, for most organizations. Per the SAP BTP IAM documentation, a single custom IAS tenant can be scoped to multiple subaccounts via trust configurations. Multiple tenants are warranted only when subsidiaries have unconsolidated corporate IdPs or security policy requires strict isolation between production and non-production identity stores.

Summary#

SAP BTP architecture design is a set of ten interconnected structural decisions, most of which are irreversible once a subaccount is provisioned. The decisions span account hierarchy, region, runtime, connectivity, identity federation, entitlement management, HA/DR tier, and infrastructure automation. The most common failure mode is not a wrong technical choice but a deferred governance decision: region selection without legal review, SCC without HA, IAM trust without corporate IdP engagement, or Terraform without state governance. The SAP Architecture Center and SAP BTP Guidance Framework provide reference architectures that anchor each decision to a defensible rationale.

What to Read Next#