Inside the Platform: A Guide to SAP BTP Architecture and Services
In the first blog of this series, we explored why the smartest organizations are moving from a system mindset to a platform mindset. The core idea was simple. Your SAP ERP is the digital backbone, but the real value comes from what you build around it. SAP Business Technology Platform is the layer that makes that possible.
But knowing why BTP matters is only the first step. The next question is, what does this platform actually look like? How is it structured? What are the building blocks? And how do you make sense of the hundreds of services SAP offers without getting lost in a product catalogue?
This post gives you the architectural blueprint. A clear mental map so you can have informed conversations with your teams, your SAP account manager, and your implementation partners.
Before we look inside BTP, it helps to understand where it fits in the broader cloud landscape. If you have been in conversations about cloud strategy, you have likely heard three terms: IaaS, PaaS, and SaaS. These are the three layers of cloud computing, and understanding them makes the rest of this article much easier to follow.
Infrastructure as a Service (IaaS) gives you the raw building blocks virtual machines, storage, and networking, the cloud equivalent of a data center. You are responsible for everything on top: the OS, middleware, applications, and patching. AWS EC2, Azure Virtual Machines, and Google Compute Engine are examples. Think of it as renting an empty warehouse: the space and electricity are yours, but you bring everything else.
Platform as a Service (PaaS) goes a step further. It gives you both the infrastructure and a managed platform to build and run applications on top of it. You do not worry about provisioning servers or managing operating systems. The provider handles the infrastructure underneath and gives you a platform layer, things like runtime environments, development tools, databases, and middleware, so you can focus entirely on building your application. Think of it as renting a fully equipped kitchen. The building, the ovens, the fridges, the utensils are all there and maintained for you. You bring the recipe and the ingredients.
Software as a Service (SaaS) is the most complete layer. You get a finished application that you simply use. No building, no configuring infrastructure, no managing updates. Gmail, Salesforce, and SAP SuccessFactors are examples. Think of it as eating at a restaurant. The kitchen, the chef, the menu are all taken care of. You just order and eat.
SAP BTP follows the PaaS model, providing infrastructure and a managed platform built around runtime environments like Cloud Foundry and Kyma. SAP handles the servers, scaling, patching, and availability. Your teams focus on building what the business needs.
What makes BTP distinctive is that on top of this PaaS foundation, SAP also offers ready-to-use SaaS services : SAP Integration Suite, SAP Build Work Zone, SAP Analytics Cloud, that you subscribe to and use immediately without building anything.
This gives you both approaches under one roof, under the same commercial agreement, governance model, and security framework. You use whichever fits the problem
Figure 1: Cloud delivery models and where SAP BTP sitsBTP does not run on SAP’s own data centers. It runs on the major hyperscale cloud providers: Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). This is a deliberate architectural decision that matters for three practical reasons.
Data residency and compliance. You can choose which cloud provider and which geographic region your BTP services run in If regulations require data to stay within a specific country or region, BTP supports that. You pick the region, and your data stays there
Alignment with existing cloud investments. If your organization already has a strategic relationship with AWS or Azure, BTP can run on the same provider. This simplifies procurement conversations, consolidates vendor relationships, and can improve network performance between BTP and other workloads you already have running on the same hyperscaler.
Resilience and availability. Running on established hyperscalers means BTP benefits from their global infrastructure, their security certifications, and their uptime guarantees. You are not relying on a separate, smaller cloud footprint.
The key takeaway for the decision maker is that BTP is cloud agnostic by design. You are not locked into a single provider, and the choice of hyperscaler is a conversation you have with your team based on your specific requirements, not a constraint imposed by SAP.
Figure 2: BTP multi cloud foundation
Once BTP is in place, the next question is how do you organize and govern it? SAP has built a clean structure that maps to how most businesses already think about their operations. There are two levels that matter from day one, with an optional third for larger organizations.
Global account. Your actual contract with SAP and the master container for everything on BTP. When you sign a BTP agreement, a global account is created, defining which services SAP makes available to you. All administration and entitlements flow from it.
Subaccounts. Where the real work happens. Each subaccount is an isolated environment for deploying applications, activating services, and managing user access. Most organizations create at least three: Development, Test, and Production, but subaccounts are flexible. They can represent environments, departments (finance, HR, supply chain), geographic locations (EMEA, APAC, Americas), or any combination that fits. Larger enterprises often create separate subaccounts per region or subsidiary.
Directories (optional). As your BTP footprint grows, directories let you group subaccounts into logical clusters by region or business unit. Purely organizational, and not needed on day one, but valuable at scale.
Why does this matter? The structure directly answers three questions that always come up early. Who can do what? Access policies and roles are set at the subaccount level. What is this costing us? Usage and spend are tracked per subaccount, giving clean visibility without reverse-engineering a combined bill. Are we staying compliant? Security policies set at the global account level flow down consistently, define the rules once, and they apply everywhere.
Figure 3: BTP account model and governance
Three components hold the platform together and make BTP feel like one coherent system rather than a collection of separate tools.
Cloud Connector. A lightweight agent installed in your on-premise network. It creates a secure, outbound only tunnel from your data center to BTP. No inbound firewall changes required. This is how BTP communicates with your on-premise SAP systems safely.
Destinations. Centrally stored connection details. Instead of all application hardcoding credentials and endpoints, they reference a Destination. One change point, consistent security, and no scattered configuration files.
SAP Build Work Zone. The unified entry point for users. It brings everything together into a single portal. Standard SAP applications, custom BTP extensions, workflows, and information. One login. One interface. Users do not need to know which system is doing what behind the scenes.
How BTP is licensed directly affects how you plan and budget. SAP offers several commercial models depending on where you are in your journey.
BTPEA (SAP BTP Enterprise Agreement). Introduced in 2024 as the evolution of CPEA. You purchase a pool of prepaid credits and draw them down as you consume services across BTP. This is SAP’s recommended model for new agreements. It gives you access to the full catalogue of BTP services, including the newest additions like SAP Build, AI tools, and SAP Analytics Cloud. Best for organizations building a broad BTP footprint with multiple capability areas in scope.
CPEA (Cloud Platform Enterprise Agreement). SAP’s original consumption model, still active for existing accounts. Similar to BTPEA in structure, prepaid credits consumed as services are used. However, the CPEA service catalogue is no longer being extended with new services. If you are on CPEA today, it is worth having a conversation with your SAP account team about transitioning to BTPEA to access the latest services.
Pay As You Go. No upfront commitment. You are billed monthly for what you consume at standard list prices. No volume discounts, but no risk either. Includes free tier plans for select services. This is the natural starting point for proof of concepts, pilots, and early exploration.
Subscription based model. Some SaaS services, like SAP Integration Suite or SAP Analytics Cloud, can be procured at a fixed annual fee rather than from a credit pool, useful when you want predictable costs for services you know you will use consistently. Many organizations combine this with BTPEA, subscribing to heavy-use services while consuming everything else from credits.
Both SaaS subscriptions and PaaS consumption can draw from the same BTPEA credit pool, or sit alongside it as standalone subscriptions: one commercial framework covering both build and buy
The practical path. Start with Pay As You Go to validate your first use case. Move to BTPEA once you have a clear roadmap and multiple capability areas in scope. The economics improve significantly at scale, and BTPEA gives you access to everything SAP is building next.
Three patterns come up repeatedly in enterprise BTP engagements. They are not mutually exclusive. Mature implementations often use all three simultaneously as the platform footprint grows.
Pattern 1: Side by side extension. A custom application on BTP runs alongside the ERP, reading and writing via published APIs. The ERP core stays clean, stable, and upgrade safe. This is the most common starting point for organizations adopting BTP, and it directly supports SAP’s Clean Core strategy. The quality inspection app and the accounts payable automation described earlier are examples of this pattern.
Pattern 2: Integration hub. BTP sits at the center as the integration broker. All systems, SAP and non-SAP, connect to BTP rather than to each other. BTP handles routing, transformation, and orchestration. This replaces the point-to-point integration tangle that grows increasingly fragile over time. The retail order flow connecting S/4HANA, Shopify, and the logistics provider is an example of this pattern.
Pattern 3: Unified user experience. BTP becomes the presentation layer. SAP Build Work Zone provides one portal and one login. Employees interact with processes spanning S/4HANA, SuccessFactors, custom BTP apps, and third-party tools without knowing or caring which system is doing what behind the scenes. The experience feels like one platform, even though multiple systems are working underneath.
The architecture is intentionally modular. A well-scoped integration project or a single side-by-side extension delivers tangible value quickly and builds the confidence to go further. You do not need to adopt everything at once.
BTP is not one thing. It is a PaaS foundation with SaaS services on top, running on the hyperscale of your choice, governed by a clean account model, under a single commercial framework. Understanding this structure lets you make informed decisions about where to start, what to invest in, and how to grow.
Most enterprises we work with at Intellect Consulting start with one capability area , usually integration or a targeted extension and expand from there. The architecture supports that approach by design.
In the next post, we go deeper into Application Development and Automation on SAP BTP: what it takes to build and run custom applications, how SAP Build is changing delivery speed, and what low code and pro code mean in practice.
At Intellect Consulting, we understand both the technology and the business behind it. We help organizations put the right architecture in place so your BTP investment delivers real value from day one.
Follow along with this series, and when you are ready to talk, we are just a conversation away.