SAP BTP Architecture: Patterns, Mistakes, and Decision Frameworks for 2026

BTP Is Not One Platform — It Is Twelve

The single biggest misunderstanding in the SAP ecosystem right now is that SAP Business Technology Platform is a platform. It is not. It is a marketing umbrella over a dozen distinct services with different runtimes, pricing models, operational characteristics, and use cases.

When SAP says "build on BTP," they could mean any of the following:

• Integration Suite — middleware for integration flows, API management, event mesh, and partner connectivity
• Cloud Foundry Runtime — a PaaS for deploying Java, Node.js, and Python applications
• Kyma Runtime — a managed Kubernetes environment with serverless functions and Istio service mesh
• ABAP Environment (Steampunk) — a cloud ABAP runtime with full CDS and RAP support
• SAP Build Apps — low-code application development (formerly AppGyver)
• SAP Build Process Automation — workflow and RPA (formerly iRPA and Workflow Management)
• SAP Build Work Zone — centralized launchpad and content federation
• SAP Analytics Cloud — planning, BI, and predictive analytics
• SAP AI Core / AI Launchpad — ML model training and deployment
• HANA Cloud — managed HANA database as a service
• SAP Datasphere — data warehousing and federation (formerly Data Warehouse Cloud)
• Identity Authentication / Identity Provisioning — IAM services

Each of these services has its own documentation, its own skill requirements, and its own cost structure. A team that is excellent at Cloud Foundry deployment may have zero Kyma experience. An integration architect who knows Cloud Integration inside-out may never have touched Event Mesh.

Most failed BTP projects fail at the selection stage, not the implementation stage. The team treats BTP as a single thing, picks the first service that seems relevant, and discovers six months later that they chose the wrong runtime, the wrong integration pattern, or the wrong pricing model.

The rest of this guide is about making those decisions well.

The Three Extension Patterns Every SAP Architect Needs

In a Clean Core world, custom logic does not live in the S/4HANA core. It lives somewhere else. The question is where. There are three distinct extension patterns, and each has a specific architectural profile.

In-App Extensions (ABAP Cloud / RAP)

This is the safest pattern. Extensions run inside the S/4HANA system but use only released APIs and extension points. Development follows the ABAP Cloud model with the Restricted Language version, enforced by ATC cloud-readiness checks.

When to use it: Your extension is tightly coupled to an S/4HANA business process, needs transactional consistency with core data, and SAP has released the required APIs and extension points.

When not to use it: SAP has not released the extension point you need (and no, using classic ABAP to bypass the restriction is not Clean Core). The extension serves multiple consumers beyond S/4HANA. The extension needs a technology stack outside ABAP.

The RAP (RESTful Application Programming Model) framework provides the structure: CDS views for data modeling, behavior definitions for business logic, and OData services for exposure. It is well-architected but limited by the extension points SAP has released. If the released API surface does not cover your use case, you cannot force this pattern to work without breaking Clean Core principles.

Side-by-Side Extensions (BTP Applications)

This is where 60 to 70 percent of new custom development should land in a Clean Core architecture. Extensions run on BTP as standalone applications, communicating with S/4HANA through APIs and events.

The typical stack is CAP (Cloud Application Programming Model) deployed on Cloud Foundry or Kyma. CAP provides a framework for building OData and REST services with CDS-based data modeling, and it handles much of the boilerplate for authentication, multitenancy, and S/4HANA connectivity.

When to use it: Custom UI applications. Custom business logic that does not need transactional locking with core data. Extensions serving multiple systems. Extensions using non-ABAP technology. Any net-new application development.

Event Mesh is the critical infrastructure here. Instead of polling S/4HANA for changes, your BTP application subscribes to business events (business partner changed, sales order created, material posted). This is the shift from synchronous, tightly coupled integration to asynchronous, event-driven architecture.

Hybrid Extensions (On-Premise + BTP)

This is the transitional pattern that nobody wants to talk about but everybody needs. Your landscape has on-premise systems that will not move to the cloud for years. You still need to build new capabilities on BTP. The bridge is SAP Cloud Connector — a reverse-invoke proxy that provides secure tunneling between BTP and on-premise systems without opening inbound firewall ports.

Common patterns include RFC-to-REST bridging (wrapping on-premise BAPIs as REST APIs), replicating master data to HANA Cloud for reporting, and running integration flows that orchestrate between cloud and on-premise endpoints.

Plan to sunset this pattern. Design every hybrid integration with a clear migration path to a fully cloud-based alternative. But do not pretend you can skip it. If your landscape includes on-premise ECC or S/4HANA systems, hybrid extensions are a reality for the next three to five years.

Extension Pattern Decision Matrix

Runtime Selection: Cloud Foundry vs Kyma vs ABAP Environment

Once you have decided on a side-by-side extension pattern, you need to pick a runtime. This decision is more consequential than most teams realize, and switching later is expensive.

Cloud Foundry

Cloud Foundry is the default runtime that most teams reach for, and it is a reasonable choice for straightforward application deployment. It uses buildpacks to package Java, Node.js, and Python applications, and it handles scaling, health monitoring, and routing out of the box.

Strengths: Familiar PaaS model. Good CAP integration. Lower operational overhead than Kubernetes. Broad language support. Mature documentation and community.

Limitations: No Kubernetes-native features. No fine-grained networking control. No sidecar containers. Limited observability compared to Kyma. Buildpack-based deployment constrains packaging options.

Cloud Foundry is the right choice when your team has traditional application development skills, your applications are request-response (not event-driven), and you do not need Kubernetes features.

Kyma

Kyma is SAP's managed Kubernetes offering, built on the open-source Kyma project. It includes Istio service mesh, serverless Functions, and native eventing infrastructure for consuming S/4HANA business events.

Strengths: Full Kubernetes capabilities. Serverless functions for lightweight event handlers. Istio for traffic management, mutual TLS, and observability. Native Event Mesh integration. Container-based deployment gives maximum flexibility.

Limitations: Operational complexity. Your team needs Kubernetes skills — pod lifecycle, resource limits, horizontal pod autoscaling, ingress configuration, debugging container networking. The learning curve is real.

Kyma is the right choice when your extensions are event-driven, when you need microservice architecture with service mesh capabilities, or when your team already has Kubernetes experience.

ABAP Environment (Steampunk)

ABAP Environment is a full ABAP Cloud runtime on BTP. It runs the same ABAP Cloud stack as S/4HANA Cloud but as a standalone system. You get CDS, RAP, ABAP RESTful services, and the full ABAP development toolset in ADT.

Strengths: Familiar to ABAP developers. Full RAP stack. CDS-based data modeling. Reuses existing ABAP skills. Good for teams with deep ABAP expertise transitioning to cloud development.

Limitations: ABAP only. No polyglot development. Higher runtime cost than CF or Kyma for simple workloads. Smaller ecosystem of open-source libraries compared to Node.js or Java.

The Common Mistake: Defaulting to Cloud Foundry

The most frequent error we see is teams defaulting to Cloud Foundry because it is the first option in the documentation, not because it is the best fit. Specifically:

• Event-driven extensions with lightweight processing logic are better served by Kyma Functions than by a full CF application
• Teams with Kubernetes experience often fight Cloud Foundry constraints instead of using the Kubernetes-native capabilities Kyma provides
• ABAP shops building ABAP-based extensions sometimes deploy CAP applications on CF when ABAP Environment would let them use the skills they already have

Integration Suite Architecture — Beyond Point-to-Point

Integration Suite is the most widely deployed BTP service, and it is also the most frequently under-architected. Too many implementations treat it as a simple message broker — point-to-point flows that move data from A to B. The platform is capable of far more.

The Four Capabilities

Integration Suite is actually four services under one license:

1. Cloud Integration (CPI) — the iFlow engine for message processing, transformation, and routing. This is what most people mean when they say "Integration Suite." If you are migrating from PI/PO, the migration guide covers the technical path in detail.

1. API Management — a full API gateway with rate limiting, security policies, analytics, traffic management, and developer portal. This is the capability most implementations skip, and it is a mistake.

1. Event Mesh — publish-subscribe eventing for asynchronous integration. Business events from S/4HANA, SuccessFactors, and other SAP applications flow through Event Mesh to subscribers.

1. Open Connectors — pre-built connectors to third-party SaaS applications (Salesforce, ServiceNow, Workday, etc.). Useful for rapid integration but limited in depth.

The Shift to Event-Driven Architecture

The traditional SAP integration model is polling-based: a scheduled job runs every N minutes, queries the source system for changes, and pushes them to the target. This model wastes resources when nothing has changed and introduces latency equal to the polling interval.

Event Mesh flips this model. S/4HANA publishes business events (based on SAP's RAP event infrastructure) when state changes occur. Subscribers — whether BTP applications, integration flows, or external systems — receive those events in near-real-time.

The architectural shift is significant:

• Polling: Integration Suite pulls changes on a schedule. High latency. Wasted processing cycles. Coupled to source system availability during polling windows.
• Event-driven: Source system pushes events when changes happen. Low latency. Processing only when needed. Decoupled through Event Mesh as an intermediary.

Not every integration should be event-driven. Batch data loads, file-based transfers, and high-volume master data replication may still benefit from scheduled processing. But for transactional events — order creation, delivery confirmation, invoice posting — the event-driven model is architecturally superior.

API Management: The Governance Layer You Cannot Skip

Here is a pattern we see repeatedly: a team builds twenty Cloud Integration flows, exposes them as REST endpoints, and provides those URLs directly to consuming applications. No rate limiting. No versioning. No monitoring. No security policies beyond basic authentication.

API Management is the governance layer that prevents this from becoming unmanageable. It sits in front of your integration flows and provides:

• Rate limiting and throttling — protect backend systems from burst traffic
• API versioning — maintain backward compatibility while evolving interfaces
• Security policies — OAuth 2.0, certificate pinning, IP filtering, content validation
• Analytics and monitoring — who is calling what, response times, error rates
• Developer portal — self-service API discovery for consuming teams

If your BTP landscape exposes more than five APIs, you need API Management. It is not optional infrastructure — it is a core architectural requirement.

BTP Cost Modeling — The Numbers SAP Does Not Make Obvious

BTP pricing is complex enough that many organizations do not understand their actual cost until the first invoice arrives. There are two primary models, and choosing wrong can double your spend.

CPEA vs Subscription

CPEA (Cloud Platform Enterprise Agreement) is consumption-based. You purchase a pool of "cloud credits" and services draw from that pool based on usage. This is flexible — you can shift spending between services — but it requires careful consumption monitoring.

Subscription is fixed-price. You purchase specific services at specific tiers for a contract term. Predictable costs, but no flexibility to shift spend.

The general guidance: CPEA for organizations still exploring BTP and unsure of their consumption profile. Subscription for mature deployments with predictable, steady-state workloads. Many enterprises use a hybrid approach — subscription for known high-volume services (Integration Suite, HANA Cloud) and CPEA credits for variable or exploratory workloads.

What Burns Credits Fast

Not all BTP services consume credits equally. Understanding the cost drivers prevents budget surprises:

High credit consumption:

• HANA Cloud compute (especially with large memory configurations)
• Cloud Integration message processing at high volumes
• AI Core model training and inference
• ABAP Environment runtime hours

Moderate credit consumption:

• Cloud Foundry application runtime
• Kyma runtime
• API Management traffic processing
• Event Mesh message throughput

Low credit consumption:

• SAP Build Work Zone (standard plan)
• Static web application hosting
• Identity Authentication (included with most BTP entitlements)
• Business Application Studio (development IDE)

The $50K Evaporation Problem

A $50,000 annual BTP budget sounds reasonable for a mid-size deployment. But without consumption modeling, it can evaporate in three months. The most common scenario: a team provisions a HANA Cloud instance with more memory than needed, runs integration flows with verbose logging and high retry counts, and does not set up consumption alerts.

Always set up BTP cockpit consumption monitoring and alerts before you deploy production workloads. This is not optional governance — it is basic financial hygiene.

Right-Sizing Reference Table

*These are approximate ranges based on list pricing. Actual costs vary by contract terms, region, and negotiated discounts.*

The Hidden Cost: People

The number that never appears on the BTP invoice is the people cost. In Year 1 of a BTP adoption, training, hiring, and consulting costs typically run two to three times the platform cost. Your Cloud Foundry developers need CAP training. Your Basis team needs BTP administration skills. Your integration team needs Cloud Integration certification.

Budget for this. A $100K platform spend with a $20K training budget is a recipe for failure. A realistic Year 1 budget allocates 40 to 50 percent of the total BTP investment to people enablement.

Five BTP Architecture Mistakes We See Repeatedly

After dozens of BTP consulting engagements, certain patterns of failure show up with depressing regularity. Here are the five most common.

1. Building Everything on CF When ABAP Environment Would Be Simpler

An ABAP shop with 15 years of ABAP expertise decides to build their BTP extensions in Node.js on Cloud Foundry because "cloud-native means JavaScript." The team struggles with CAP, the code quality is poor, and delivery takes three times longer than it should.

If your team is ABAP-native and the extension logic is business-process-centric, evaluate ABAP Environment first. Cloud Foundry and Node.js are not inherently superior. The best runtime is the one your team can deliver quality software on.

2. Running Integration Suite Without API Management

Every integration flow endpoint exposed directly to consumers without API Management is an ungoverned API. No rate limiting means a misbehaving consumer can overwhelm your integration tenant. No versioning means every interface change is a breaking change. No analytics means you have no visibility into usage patterns.

API Management is not an add-on. It is a core Integration Suite capability. Deploy it from the start.

3. Ignoring Subaccount Strategy

A single development subaccount and a single production subaccount is not a strategy. It is the absence of a strategy. A well-designed subaccount structure separates:

• Environments: Development, testing/QA, staging, production
• Departments or domains: Finance, logistics, HR (when isolation is needed)
• Security boundaries: Different identity providers, different network policies
• Cost tracking: Subaccounts as cost centers for chargeback

The subaccount design is one of the first decisions in a BTP implementation, and it is one of the hardest to change later. Get it right early.

4. Not Designing for Failover

BTP runs in specific cloud regions (AWS, Azure, GCP). Region outages happen. They are rare, but they are not theoretical. If your entire BTP landscape runs in a single region with no failover design, a region outage takes down every BTP service you depend on.

For critical workloads, design for multi-region or at least have a documented recovery plan. Integration Suite supports content transport between tenants. Cloud Foundry and Kyma applications can be deployed to multiple regions. HANA Cloud supports replication.

5. Treating BTP as a Project Instead of a Platform

This is the most fundamental mistake. BTP is not a project you implement and hand off. It is a platform you operate continuously. It needs:

• A Center of Excellence (CoE) that governs architecture decisions, maintains standards, and provides guidance to development teams
• Platform engineering resources that manage subaccounts, entitlements, identity configuration, and connectivity
• Consumption governance that monitors spend and optimizes resource allocation
• Continuous training as SAP evolves the platform (which it does frequently)

Organizations that treat BTP as a one-time project end up with the same ungoverned sprawl they had on-premise — just in the cloud.

BTP and Clean Core — The Architecture Stack

BTP is not optional in a Clean Core architecture. It is the platform where your custom intellectual property lives. The Clean Core principle says: keep the S/4HANA core standard, extend on BTP. Without BTP, there is nowhere for extensions to go.

The architectural stack in a mature Clean Core landscape looks like this:

• S/4HANA Core — standard processes, released APIs, in-app extensions via RAP where available
• Integration Suite — all integration flows, API governance, event routing
• BTP Runtime (CF/Kyma/ABAP Environment) — side-by-side extensions, custom applications, custom UIs
• HANA Cloud — analytics, data warehousing, cross-system reporting
• SAP Build — citizen development, workflow automation, portal

Every layer communicates through APIs and events. No layer reaches into another layer's internals. This is the architecture SAP is driving toward, and it is the architecture that makes continuous upgrades possible.

For organizations planning an S/4HANA migration, the BTP architecture should be designed in parallel with the core system migration, not as an afterthought. The decisions you make about extension patterns, runtime selection, and integration architecture will shape your landscape for the next decade.

Getting Your BTP Strategy Right

If you are starting a BTP journey or rearchitecting an existing deployment, here are the foundational steps that matter most.

Start with Subaccount Design

Map your organizational structure, environment strategy, and security requirements to a subaccount hierarchy. Document it. Get stakeholder agreement before you provision anything.

Establish Identity Early

Connect your corporate identity provider (Azure AD, Okta, or similar) to SAP Identity Authentication Service as the first BTP configuration step. Every service you deploy afterward inherits the identity foundation. Retrofitting identity after deployment is painful.

Deploy Integration Suite with API Management from Day One

Even if your first integration is simple, deploy the full Integration Suite with API Management enabled. Establish the pattern of governed APIs from the beginning. Adding API Management later means retrofitting every existing consumer.

Build a Cost Model Before You Build Applications

Model your expected consumption across all BTP services. Set up monitoring and alerts. Review consumption monthly. Adjust provisioning quarterly. This discipline prevents the $50K evaporation problem described above.

Invest in People Before Platform

Train your team before you commit to a runtime. Run proof-of-concept projects. Let developers build real applications on CF, Kyma, and ABAP Environment before you make a permanent runtime decision. A two-week PoC on each runtime costs far less than a wrong decision that takes years to unwind.

Establish Governance from the Start

Create a BTP CoE — even if it starts as two people. Define architecture decision records. Establish coding standards for CAP and RAP development. Set up CI/CD pipelines. The governance overhead is minimal compared to the cost of ungoverned sprawl.

---

BTP architecture decisions compound over time. The runtime you choose, the integration patterns you establish, and the governance you put in place (or do not) will shape your SAP landscape for years. Getting these decisions right is worth the upfront investment in analysis and planning.

If you want a BTP architecture assessment tailored to your landscape, let us talk.