BTP Architecture Design: Use Cases and Decision Patterns

JinJin48

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

May 14, 2026 · 14 min read

Where This Article Sits#

References#

1) The Architecture and Operations Landscape#

The decisions that shape a BTP architecture cluster into three distinct domains. Each one answers a different question and is operated by a different person ( SAP BTP Account Model).

These three domains interact at deployment time but are designed independently. They are not substitutes.

2) How It Connects to S/4HANA#

The diagram below represents the typical placement of BTP relative to an S/4HANA backend in a side-by-side extension scenario.

  ┌─────────────────────────────────────────────────────────────┐
  │                   SAP BTP Global Account                    │
  │                                                             │
  │  ┌───────────────────┐   ┌───────────────────────────────┐  │
  │  │  Dev Subaccount   │   │       Prod Subaccount         │  │
  │  │  ┌─────────────┐  │   │  ┌─────────────────────────┐  │  │
  │  │  │  CF Runtime │  │   │  │  CF Runtime / Kyma       │  │  │
  │  │  │  (CAP App)  │  │   │  │  (CAP App, event-driven) │  │  │
  │  │  └──────┬──────┘  │   │  └───────────┬─────────────┘  │  │
  │  └─────────┼─────────┘   └──────────────┼────────────────┘  │
  │            │  Destination service         │ Destination svc   │
  │            │  (OnPremise)                 │ (OnPremise /      │
  │            │                              │  Private Link)    │
  └────────────┼──────────────────────────────┼───────────────────┘
               │                              │
         Cloud Connector               Cloud Connector
         (Dev tunnel)                  (Prod tunnel)
               │                              │
  ─────────────┼──────────────────────────────┼──── On-premises network
               ▼                              ▼
        S/4HANA Dev                    S/4HANA Prod
        (ABAP system)                  (ABAP system)

The Cloud Connector is installed in the customer’s on-premises network and initiates an outbound tunnel to the BTP subaccount — no inbound firewall ports are required ( SAP BTP Connectivity). Applications in BTP consume backend connections through the Destination service, which acts as the runtime configuration store for endpoint URLs and credentials.

Key point: Each BTP subaccount maps to its own Cloud Connector logical location, which is why Dev and Prod subaccounts must be kept separate — you cannot safely share a single Cloud Connector tunnel across lifecycle stages.

3) Maturity Map#

Use this table to assess how production-ready each capability area is before committing to a design. For runtime cost comparisons, see the SAP Architecture Center cost of ownership reference.

4) Requirements Checklist#

The checklists below capture the minimum requirements before you can commit an architecture pattern to a project. Work through each one before the solution design sign-off. The BTP account hierarchy — Global Account → Directories → Subaccounts — is the structural basis for all entries in this section ( SAP BTP Account Model).

Runtime environment selection#

Connectivity architecture#

Account structure design#

Event-driven architecture#

5) Decision Criteria#

Q1: Where is the pain or inefficiency?#

Identify the specific scenario that triggers the BTP investment. Common triggers and their runtime implications:

• Side-by-side extension of S/4HANA (UI, workflow, reporting not possible in core ABAP): Cloud Foundry or Kyma depending on team skills and scale.
• Cloud-native ABAP development or migrating existing ABAP logic: ABAP environment only.
• High-volume, event-driven integration (inventory sync, order events, IoT): Kyma with SAP Integration Suite Advanced Event Mesh.
• Internal SaaS platform-as-a-product for multiple business units: Multi-tenant SaaS pattern on Cloud Foundry or Kyma ( SAP Architecture Center — Multi-Tenant SaaS Reference Architecture).

If the pain cannot be articulated as a specific bottleneck, do not proceed to architecture decisions.

Q2: Where does the data live and who owns it?#

Data residency and ownership determine connectivity architecture and account structure in ways that cannot be refactored cheaply later.

• On-premises SAP or non-SAP system: Cloud Connector required, Destination ProxyType OnPremise.
• Backend hosted on Azure or AWS: SAP Private Link service is the preferred path to avoid internet traversal ( SAP Architecture Center — Secure Connectivity with SAP Private Link).
• Data residency regulation applies: BTP subaccount must be created in the specific compliant region; verify Kyma availability in that region before committing to the runtime.
• Multiple countries or subsidiaries: Directory-per-region account structure rather than department-based grouping.

Q3: Who is the sponsor and what is the budget model?#

Budget authority and commercial model drive both runtime cost optimization and the licensing table.

Licensing reference#

6) Common Failures#

SAP Cloud Transport Management should run in its own dedicated subaccount alongside other shared services to maintain separation of concerns — a principle that underlies several of the failures below ( SAP Architecture Center — DevOps with SAP BTP).

Failure 1: Single subaccount for all lifecycle stages

Teams create one subaccount for Dev, Test, and Prod to reduce overhead, then discover that Destination names must be unique per subaccount and that the Cloud Connector tunnel exposes the production backend to development-side deployments. Untangling this requires recreating service instances and re-deploying all applications, often during a live programme.

Failure 2: Kyma selected without Kubernetes expertise

Kyma is chosen because it sounds more modern or because another team used it, without confirming that the project team can operate Kubernetes CRDs, configure service meshes, or manage Helm charts. The result is a runtime that is nominally running but not maintained, monitored, or tuned — security posture degrades and cost runs above Cloud Foundry without any of the architectural benefits.

Failure 3: Cloud Connector mapped to a single subaccount

A single Cloud Connector instance is mapped only to the production subaccount. When development needs to call on-premises backends, teams either share the production connector (introducing risk) or route through internet-facing proxies (introducing latency and security exposure). The correct pattern is a Cloud Connector mapped separately to each lifecycle-stage subaccount from the start.

Failure 4: Private Link not evaluated for hyperscaler-hosted backends

SAP Private Link is available for workloads hosted on Azure or AWS but is frequently not evaluated during the connectivity design phase because the team is familiar with Cloud Connector. The result is that sensitive backend data (e.g., S/4HANA hosted on Azure VM) travels over the public internet unnecessarily, creating a compliance gap that surfaces during security review after go-live.

Failure 5: Event Mesh selected for enterprise-scale event volumes

A project selects the Event Mesh capability within SAP Integration Suite for a use case that eventually processes millions of events per day across heterogeneous brokers. Event Mesh is appropriate for starter and moderate workloads; the migration to Advanced Event Mesh mid-project disrupts event schema governance, requires rebinding of all consumer applications, and incurs unplanned licensing cost.

Failure 6: No shared services subaccount

SAP Cloud Transport Management, SAP Cloud ALM, and central monitoring are deployed into application subaccounts rather than a dedicated shared services subaccount. When the project entitlements are reorganised or the application subaccount is decommissioned, the transport management configuration is lost. Shared services must be isolated from the beginning to survive application lifecycle changes.

Failure 7: Architecture decided before Q1 pain is articulated

A solution is designed around a technology — “we will use Kyma and Advanced Event Mesh” — without a concrete business pain point driving the choice. Six months later, the project is building infrastructure for integration patterns that the business does not actually need yet, while the real bottleneck (a manual approval workflow in S/4HANA) goes unsolved. Architecture decisions must trace to a named inefficiency.

FAQ#

Q: Our S/4HANA is on-premises. Can we still use Cloud Foundry on BTP?

Yes. Cloud Foundry on BTP connects to on-premises backends through the Cloud Connector and Destination service. The Cloud Connector is installed in your on-premises network and establishes an outbound tunnel to the BTP subaccount — no inbound firewall rules are required on your side ( SAP BTP Connectivity). The BTP application then consumes the on-premises connection using a Destination with ProxyType set to OnPremise. This is the most common connectivity pattern for S/4HANA on-premises extensions.

Q: When does Kyma’s higher cost become worth it?

Kyma costs approximately 25–30% more than Cloud Foundry for equivalent tenant counts, with the primary cost difference coming from the managed Kubernetes cluster. That premium is justified when: (a) the team already has Kubernetes skills and will not pay a learning-curve tax, (b) the workload is event-driven and serverless, where Kyma’s built-in event infrastructure and service mesh reduce custom integration work, or (c) the application requires advanced network security (service mesh, mTLS between services) that Cloud Foundry does not provide natively.

Q: What should we descope if the project timeline is at risk?

Start by descoping the event-driven integration layer — replace Advanced Event Mesh with direct RFC or API calls in the short term and plan a phased upgrade. Second, collapse to a simpler account structure (fewer directories, fewer subaccounts) during initial delivery, but document the target structure so it can be implemented before the first tenant onboarding. Do not descope the Dev/Test/Prod subaccount separation — the rework cost if this is removed and later needs to be restored almost always exceeds the time saved.

Q: How should we document architecture decisions so they survive team turnover?

Architecture Decision Records (ADRs) stored in the project repository are the minimum. Each ADR should record: the decision made, the alternatives considered, the rationale (linked to the Q1 pain point), and the date. For BTP-specific decisions, capture: runtime chosen and why, connectivity pattern per backend system, account structure diagram, and the naming convention document reference (see BTP-F05). These documents are more useful than slide decks because they are versioned alongside the code.

Q: We are building an internal SaaS product for multiple business units. Which runtime and data isolation strategy should we use?

The canonical pattern uses a provider subaccount (hosts the application) plus one consumer subaccount per business unit ( SAP Architecture Center — Multi-Tenant SaaS Reference Architecture). For runtime, Cloud Foundry or Kyma both work — the CAP framework supports both. For data isolation, SAP recommends HANA HDI container schema separation (one HDI container per tenant) as the balance between cost and isolation. Column discriminator is viable only for very low risk data. Dedicated databases per tenant provide maximum isolation but substantially increase HANA Cloud costs. ABAP environment does not support multi-tenant SaaS in this model.

Q: What is the right event tooling for S/4HANA Cloud business event consumption?

SAP Cloud Application Event Hub is the right starting point for consuming native business events from S/4HANA Cloud, SuccessFactors, and other SAP cloud applications. It connects directly to supported SAP cloud applications and exposes events to BTP extension apps without requiring custom event channel configuration. For heterogeneous or high-volume scenarios spanning non-SAP systems, SAP Integration Suite Advanced Event Mesh provides the multi-broker backbone and centralised visibility.

Summary#

BTP architecture decisions in the real world cluster into three areas: runtime selection, connectivity design, and account structure. These decisions compound — a wrong runtime choice does not stay isolated; it affects the connectivity options available, the cost model, and the operational burden on the team.

The patterns in this article reflect what actually works at enterprise scale: Cloud Foundry for most extension scenarios, Kyma when the team is Kubernetes-capable and event-driven architecture is central, ABAP environment only when ABAP Cloud development is the explicit objective. Connectivity follows the backend’s physical location — on-premises means Cloud Connector, hyperscaler-hosted means Private Link evaluation ( SAP Architecture Center — Secure Connectivity with SAP Private Link), internet means Destination service with ProxyType Internet. Account structure must separate lifecycle stages from day one and must isolate shared services from application subaccounts.

Treat the decision criteria questions (Q1 through Q3) as a gate, not a formality. Projects that skip Q1 — articulating the concrete pain point — routinely over-engineer their BTP architecture and under-deliver on business value.

What to Read Next#