SAP BTP for Analytics matters when analytics must connect to actions, workflows, applications, or governed custom logic. Current SAP learning and platform material keeps BTP broad on purpose: account model, application development, automation, integration, data and analytics, AI, and security are all part of the platform story. Since SAP Sapphire 2026, SAP positions BTP inside the new SAP Business AI Platform, together with SAP Business Data Cloud and SAP Business AI. That makes BTP strategically useful, but it also makes it easy to overuse. Teams often reach for platform language too early, when the real problem is weaker semantics, unclear ownership, or basic integration discipline across systems such as Salesforce, ServiceNow, Workday, or external data platforms. The right question is not whether BTP is powerful. The right question is whether the analytics problem truly requires a platform-runtime layer around the decision flow.
BTP is strongest when decisions need workflow follow-through, custom runtime logic, or application-linked action paths. It is weaker when the organization simply wants dashboards, cleaner semantics, or better cross-system integration fundamentals.
SAP BTP is not the analytics presentation layer, the semantic layer, or the integration topic by itself. In analytics design, it becomes relevant when teams need a governed runtime surface for action, orchestration, extension, or application-centric execution around both SAP and non-SAP signals. The six service areas—Runtime, AI/ML, Data, Integration, Extension, and DevOps—combine to create a platform where analytics can trigger, extend, orchestrate, and operate.
BTP is modular. SAP's product page groups its capabilities into areas such as application development and automation, data, AI for developers, and core platform capabilities, with SAP Integration Suite for integration. For analytics, the most common combinations are: (1) Datasphere + HANA for data, (2) Integration Suite for APIs and events, (3) Cloud Foundry or Kyma for custom logic, (4) SAP AI Core and its generative AI hub for custom and foundation models, (5) SAP Build or CAP for extensions. The account model and the commercial model (BTPEA, CPEA for existing contracts, or pay-as-you-go) tie it all together.
Cloud Foundry: Application platform for stateless microservices and APIs. Best for RESTful services, data transformations, and traditional app development. Simpler learning curve for Java and Node.js teams.
Kyma: SAP-managed Kubernetes runtime based on the open-source Kyma project, with modules for serverless functions, eventing, and API exposure. Best for workflows triggered by events, asynchronous processing, and containerized services. It replaced the discontinued SAP BTP serverless runtime for function-based patterns.
Datasphere: Semantic modeling and analytic foundation. Define KPIs, business rules, and governed data products. This is where analytics meaning lives. Inside SAP Business Data Cloud, it is also where custom data products are created and shared.
HANA Cloud: In-memory database that Datasphere runs on. Also available standalone for applications and high-volume analytics, and since 2026 natively inside SAP Business Data Cloud, sharing one capacity pool with Datasphere and SAC.
SAP Business AI Platform (2026): Announced at SAP Sapphire 2026, it brings SAP BTP, SAP Business Data Cloud, and SAP Business AI together, with SAP Knowledge Graph at its core. SAP plans to make BDC data products available inside Joule Studio (GA planned for Q1 2027).
Integration Suite: Default backbone for cloud integration, API management, and connectors. Handles message routing, transformation, and orchestration between systems.
Event Mesh: The Event Mesh capability of SAP Integration Suite covers starter and moderate-volume event scenarios; SAP Integration Suite, advanced event mesh covers high-volume, distributed event networks. Publish-subscribe for analytics events, alerts, and triggered workflows across the landscape.
AI Core: Managed service for training, deploying, and serving custom ML models. Home for custom models, specialized use cases, and a controlled model lifecycle (managed in SAP AI Launchpad).
Generative AI hub: Governed access to models from OpenAI, Anthropic, Google, Mistral AI, Amazon, Meta, Cohere, Perplexity, and SAP, with orchestration for templating, grounding, content filtering, and data masking. SAP's tabular model SAP-RPT-1.6 is in the SAP AI Core model library. Use when you need foundation models without custom training overhead.
CAP (Cloud Application Programming): Development framework for SAP applications. Build custom analytics apps, extensions, and business services on top of SAP data.
SAP Build: One unified offering with low-code tools (SAP Build Apps, SAP Build Process Automation, SAP Build Work Zone) and pro-code tools (SAP Build Code, ABAP Cloud). Create guided experiences, custom UX, and workflow apps without deep coding skills.
Account structure: Global account, directories, subaccounts define deployment boundaries and entitlements. This is architecture, not administration.
Commercial model: Consumption-based services are paid from cloud credits under the SAP BTP Enterprise Agreement (BTPEA, introduced in April 2024 as the evolution of CPEA; CPEA continues only for existing accounts and gets no new services) or pay-as-you-go, alongside subscriptions. Since January 1, 2026, Datasphere and SAC are no longer eligible for new BTPEA, CPEA, or pay-as-you-go subscriptions; they are licensed through SAP Business Data Cloud.
BTP earns its place when a decision process must connect analytics to operational behavior rather than stopping at insight alone.
Analytics identifies an exception or decision point, and a workflow or process step must follow in a governed way.
Typical fit: approvals, escalations, controlled business actions, and operational routing.
A business-facing experience needs custom behavior around a standard analytics flow.
Typical fit: task-driven workbenches, guided exception handling, or application-specific action surfaces.
SAP plans to make Business Data Cloud data products available inside Joule Studio (GA planned for Q1 2027, per SAP's TechEd 2026 guide), so agents and apps can build on governed data products instead of private extracts.
Typical fit: agent and app scenarios that need trusted business data, prototyping on governed data products, cross-functional tools. Until then, apps reach the same data through Datasphere consumption APIs or BDC Connect.
The use case depends on event handling, sequencing, or managed logic that sits outside the dashboard itself. Typical building blocks are the Event Mesh capability or advanced event mesh, SAP Build Process Automation, and Kyma or Cloud Foundry services, with Datasphere task chains handling the data side.
Typical fit: orchestrated processes, triggered services, reusable platform-controlled execution steps, data quality automation across BTP and Datasphere.
The organization needs a durable place to build around analytics without scattering unreviewed scripts or ad hoc logic.
Typical fit: controlled extensions, reusable services, and operating discipline for custom analytics-adjacent behavior.
The workflow story is the real reason BTP enters many analytics discussions. The point is not to add platform complexity. The point is to make sure insight can lead to controlled action without losing ownership or traceability.
Start from a governed metric, threshold, or business event rather than from custom logic without analytic context.
Decide who must act, what must be triggered, and which step must remain visible to operators and reviewers.
Place extension or orchestration logic where ownership, release control, and recoverability are explicit.
Return outcomes to the analytic context so teams can learn whether the workflow actually improved decisions.
SAP BTP is powerful, but it is not needed for standard analytics delivery. Many teams misuse it because they confuse platform capability with business necessity. These boundaries clarify when BTP is real overhead and when it is justified.
If the use case is dashboards, exploration, planning, and decision support, SAC usually provides everything required. Adding BTP just because the platform exists adds cost and complexity without benefit. Standard analytics does not need runtime extension.
SAP Datasphere is the place for business meaning and analytic models. BTP does not improve semantic design; it adds orchestration and extension around semantics. If the real issue is defining KPIs, weak governance, or unclear business meaning, BTP is the wrong answer.
BTP cannot fix unstable KPI definitions, weak business vocabulary, or unresolved ownership of analytic meaning. Custom logic built on weak foundations just amplifies the underlying problem.
If the real problem is system connectivity or data movement, solve that directly with SAP Integration Suite instead of wrapping it in platform-runtime language. Not every cross-system handoff needs a platform layer around it.
Custom logic increases control needs rather than reducing them. Permissions, release checks, observability, and stewardship still need named owners. BTP extension actually expands the governance surface, not simplifies it.
BTP should only be used when a team can commit to owning the extension, controlling its lifecycle, supporting its integration, and monitoring its behavior. Platform work without clear operating responsibility creates a maintenance nightmare.
The cleanest way to evaluate BTP is to ask whether the use case crosses from analysis into governed runtime behavior. If not, the answer is often elsewhere.
If the need is mostly dashboards, planning views, scorecards, or business-facing decision support, stay in the analytics layer first.
If the main challenge is shared meaning, reusable models, or semantic consistency, fix the semantic layer before adding runtime complexity.
If the primary issue is cross-system movement or interoperability, treat it as an integration problem until proven otherwise.
SAP BTP evolves quickly. These are the capabilities that matter most for analytics teams in 2026 and beyond.
Cloud Foundry and Kyma are both production-ready for analytics workloads. Kyma replaced the discontinued SAP BTP serverless runtime for function-based patterns. CAP is SAP's programming model for custom cloud applications, including analytics services.
AI Core is established for custom models. The generative AI hub is the governed entry point for foundation models from OpenAI, Anthropic, Google, Mistral AI, and others; SAP-RPT-1.6 covers tabular predictions (SAP-RPT-1 retires by the end of 2026). Joule Studio, part of the SAP Business AI Platform, offers more than 70 models for building agents.
Datasphere is the primary data modeling layer, running on HANA Cloud. Business Data Cloud adds SAP-managed data products and intelligent content. BDC Connect is generally available for Databricks (since October 2025), Snowflake (May 4, 2026), and Google BigQuery (July 2026); Microsoft Fabric is in public preview with no GA announcement, and Amazon Athena is planned for H1 2027.
Integration Suite is mature for APIs, cloud integration, and event mesh. Open Connectors offers more than 160 prebuilt connectors to popular third-party cloud applications. This is the first stop for cross-system analytics connectivity.
CAP, SAP Build, and ABAP Cloud all support analytics use cases. Agents built in Joule Studio support MCP and A2A to work with SAP and third-party tools. Extensions built today follow cloud-native patterns.
Consumption-based services are bought with cloud credits under BTPEA (CPEA for existing accounts) or pay-as-you-go, alongside subscriptions. Datasphere and SAC moved to Business Data Cloud licensing for new contracts from January 1, 2026, so plan them in BDC capacity units, not BTP credits.
The same BTP discussion means different things depending on who is reading it. Good architecture work makes that explicit.
Learn that BTP is not "more analytics." It is a platform layer used when analytics must connect to action, workflow, or controlled extension.
Check whether the real need is orchestration, extension, integration, or semantics before proposing runtime work. Use the decision path. Choose SAC, Datasphere, or Integration Suite first.
Design clear boundaries for runtime ownership, custom logic, and operational controls around analytics-led action paths. Choose the commercial model (BTPEA or subscriptions) deliberately and track credit consumption. Map service areas to use cases before committing.
Invest in BTP where it shortens the path from trusted signal to governed action, not where it simply adds technical prestige. Measure ROI on workflow acceleration and decision cycle time, not just "platform adoption."
Current SAP BTP learning and help material is useful because it keeps platform fundamentals visible. In analytics programs, that means runtime design has to be tied to account structure, entitlements, integration services, automation, and security rather than to vague "platform capability" language.
Global accounts, directories, subaccounts, entitlements, quotas, regions, and runtime environments are part of architecture, not just administration. They shape what can safely be built and where.
Cloud integration, API management, SAP Event Mesh, and open connectors belong in the first platform conversation whenever analytics must leave the report and interact with the landscape.
Application development and workflow automation can improve analytics-led action paths, but only if runtime ownership, support, and release controls are explicit from the start.
Generative AI on SAP BTP, SAP AI Core, identity, and security services should be treated as deliberate platform decisions. They are not just add-ons for a later phase.
These SAP sources are the right baseline for account structure, integration capability, and AI-platform design before a team starts translating an analytics use case into BTP services.
SAP BTP runs on AWS, Azure, and GCP, allowing organizations to anchor analytics workloads in their preferred cloud environment while maintaining SAP semantic consistency and integration control. The platform layer sits between raw infrastructure and analytics services, managing subaccounts, entitlements, and environments as part of enterprise-scale architecture rather than operational administration.
In practice, an enterprise analytics landscape on BTP often looks like this: a global account uses directories to separate development, test, and production, and each directory holds subaccounts for specific analytics domains (finance, supply chain, sales). Each subaccount is tied to one region, chosen for data residency, latency, or cost. Within a subaccount, Cloud Foundry or Kyma hosts custom CAP services and event handlers, SAP HANA Cloud stores application data, and Integration Suite connects on-premise systems such as SAP S/4HANA through the Cloud Connector. SAP Datasphere and SAP Analytics Cloud run as their own tenants and connect to these services. Entitlements and quotas set which services and plans each subaccount can use, and directories help monitor usage and costs as the landscape grows.
CAP is not just for transactional applications. It is SAP's framework for building services on BTP, including analytical APIs and semantic extensions. CAP services expose OData V4 endpoints that support data aggregation through $apply, use CDS annotations to describe how measures aggregate, and run on Cloud Foundry or Kyma. Analytics teams use CAP to put business logic and authorization around data in SAP HANA Cloud and to publish custom analytical APIs that enforce governance without losing flexibility.
CDS (Core Data Services) lets developers declare analytical behavior in the data model. Annotations such as @Aggregation.default set how each measure rolls up, and custom aggregates can be exposed explicitly. The CAP runtimes then answer OData V4 $apply requests (grouping, aggregation, filtering) without custom aggregation code, including hierarchy requests from UI5 tree tables.
Because CAP services accept OData V4 $apply requests, UI5 apps can request groupings, totals, and drill-downs from the same service, and one service can serve apps, SAC, and downstream integrations. SAC consumes a generic OData service through an import connection, not a live connection, so plan SAC refreshes as scheduled imports.
CAP runs before-read and after-read handlers, allowing services to enforce row-level security, apply pricing rules, convert currencies, or apply classification logic to analytics data. This logic lives in the API boundary, visible to development and security teams, rather than scattered across reporting expressions or data models.
CAP applications deploy to Cloud Foundry or Kyma as their own services, with scaling and health checks handled by the runtime. Teams version analytics APIs independently of dashboards or data models. API versioning allows old clients to continue working while new clients consume enhanced semantic layers.
A typical CAP analytics service might look like this: a CDS model declares an analytical view that joins sales transactions to product hierarchies, applies a pricing factor, and annotates aggregatable measures (revenue, quantity). A Node.js or Java handler enforces regional sales permissions based on user context at query time. The service is exposed as OData V4 and runs on Cloud Foundry or Kyma with several instances. SAC imports from it on a schedule; a custom web portal calls the same API; and CAP's built-in Event Mesh support publishes change events for a downstream planning application. The same service serves multiple clients without custom integration per consumer.
ABAP developers do not need to leave the ABAP environment to build analytics. In the SAP BTP ABAP environment (ABAP Cloud), teams model analytical CDS views (dimensions, cubes, and queries) in ABAP Development Tools, expose the queries through an InA service binding, and consume them live in SAP Analytics Cloud, without middleware. A customer service representative can see customer lifetime value, open orders, and response history next to the screen where they manage the relationship. The data comes from ABAP CDS views running on the SAP HANA database of the same ABAP system.
ABAP developers build dimension and cube views on transactional tables and define analytical queries on top, with calculations and drill-down hierarchies. A query is exposed through an InA service binding, and SAP Analytics Cloud consumes it live to build models, stories, and multidimensional reports. No separate analytics stack; the same developer owns transactional and analytical semantics.
A Fiori app built with RAP can open or embed an SAC story and pass filter values through the SAC URL API, so the story opens in the user's task context; a filter passed this way applies only to that view and is not saved. The same story also runs standalone for exploration.
ABAP CDS views pull aggregates directly from transactional tables without ETL delay. A sales dashboard showing today's orders, returns, and revenue is real-time because it queries HANA in-memory tables that transactional processes update immediately. No data lake; no nightly batch. This is operational analytics, not analytical data warehousing.
ABAP developers who built the customer master application can now build the customer analytics view, the approval workflow for exceptions, and the dashboard that monitors SLA compliance. One team, one codebase, end-to-end ownership reduces handoff complexity and improves change velocity.
Both runtimes run on the same subaccount infrastructure, but they serve different patterns. Cloud Foundry suits traditional microservice architectures: RESTful APIs, scheduled batch jobs, synchronous request-response flows. Kyma suits event-driven patterns: responding to S/4HANA business events, aggregating data from multiple sources, complex asynchronous orchestration, and serverless scaling. The choice shapes how analytics integrates with the broader platform.
Use Cloud Foundry when analytics demands synchronous APIs, scheduled transformations, or traditional microservice patterns. Examples: a CAP service exposing analytics data as OData, a scheduled job that runs nightly aggregations, a webhook handler that receives data from an external system and persists to HANA. CF scales based on request volume, includes built-in health checks and deployment governance, and integrates with traditional DevOps pipelines (CI/CD).
Use Kyma when analytics must respond to events, orchestrate complex workflows, or process data streams asynchronously. Examples: S/4HANA publishes OrderCreated event; Kyma subscribes and enriches the event with historical customer data, validates against forecasts, and publishes OrderValidated; downstream systems subscribe to that event. Retries, dead-letter handling, and ordering depend on the eventing backend Kyma uses (SAP Event Mesh or NATS) and on how subscribers are built, so specify them for each event flow.
Cloud Foundry apps publish events to Event Mesh; Kyma services subscribe. A Cloud Foundry scheduled job completes an aggregation and publishes AggregationComplete; Kyma functions respond by refreshing a cache or triggering a downstream notification. The same event can have multiple subscribers, decoupling producers from consumers.
Real analytics systems use both. A Cloud Foundry API serves interactive dashboards (synchronous). A Kyma workflow processes batch uploads and validates data quality asynchronously. An ABAP process publishes transactional events to Event Mesh, triggering both synchronous analytics recalculation (Cloud Foundry webhook) and asynchronous notifications (Kyma function). Architects model these as separate concerns, not as a single runtime choice.
SAP Build brings low-code and pro-code tooling to analytics workflows in one unified offering. SAP Build Apps creates custom UIs with drag-and-drop tools instead of frontend code. SAP Build Process Automation adds workflows, decisions, forms, and bots for approvals and report follow-up. SAP Build Work Zone gives users one entry point to SAC stories, BW reports, and custom analytics apps. Teams use SAP Build to accelerate analytics adoption without hiring more developers.
Citizen developers use the visual drag-and-drop tools of SAP Build Apps to create apps that call OData or REST services, such as Datasphere consumption APIs or a CAP service, through BTP destinations. Pages are assembled from prebuilt components, with no HTML or CSS required, and apps can be deployed to the web or as mobile apps.
Automate the people side of analytics workflows: route data-quality exceptions to owners, collect approvals for plan or master-data changes, and notify stakeholders when results are ready. Actions call APIs (for example an Integration Suite flow or a Datasphere or SAC API) through BTP destinations, decisions encode business rules, and bots handle repetitive desktop steps. All of it is modeled in visual designers.
Create a central entry point that brings together SAC stories, BW reports, apps built with SAP Build, and other SAP and third-party apps. Role-based content means users see only the analytics relevant to them, and single sign-on works when the connected apps trust the same identity provider. SAP Build Work Zone reduces navigation friction and increases analytics adoption by meeting users where they work.
Joule in SAP Build Process Automation generates and edits processes, decisions, forms, and scripts from natural-language prompts, and agents built in Joule Studio can be connected to a process when a step needs reasoning rather than fixed rules. This accelerates workflow design and reduces the training burden for automation developers.
SAP's event brokers, the Event Mesh capability of SAP Integration Suite and SAP Integration Suite, advanced event mesh, enable publish-subscribe patterns for analytics. S/4HANA publishes business events (for example, for sales orders, material movements, or quality notifications), and subscribers react as events arrive: a material movement can update an operational inventory view, an order event can feed a sales pipeline, and a quality notification can open an escalation. SAC itself reads data through live or import connections, so events must first land in an application or data store that SAC can read. This is analytics driven by business events, not only by scheduled batch jobs.
Organizations define an event taxonomy: what events exist, what fields they contain, who can publish and subscribe. This becomes part of analytics semantics. SAP documents the standard events of its applications in SAP Business Accelerator Hub, so teams can start from published event structures. Event sourcing patterns preserve complete audit trails for compliance.
SAC does not subscribe to event topics. Instead, a subscriber (a CAP service or a Kyma function) writes each event to a table in SAP HANA Cloud or SAP Datasphere, and an SAC story on a live connection shows the new state the next time it queries. That gives near-real-time views without nightly batch loads.
SAP Integration Suite, advanced event mesh (based on Solace PubSub+) can bridge its event brokers to Kafka clusters, so Spark, Databricks, or custom stream processors can consume SAP business events. (The Event Mesh capability itself speaks AMQP, MQTT, and REST, so Kafka bridging is an advanced event mesh feature.) External platforms consume SAP events without point-to-point code. This is true event-driven architecture, not SAP-isolated.
Both brokers support dead message queues for events that cannot be delivered, and advanced event mesh can also replay logged messages. Operators review, correct, and reprocess them; subscribers should be idempotent so a replay doesn't double-count. This preserves data integrity in real-time analytics, where dropped events mean missing insights.
API Management in Integration Suite controls how analytics APIs are consumed. Rate limiting ensures fair resource use. API keys and OAuth 2.0 authenticate callers. Built-in analytics track usage and performance. The Developer Hub (called API business hub enterprise in older documentation) publishes analytics APIs for internal and partner discovery. Some organizations monetize analytics APIs with rate plans that charge partners per API call, which requires API Management to meter consumption and enforce quotas.
Quota and spike-arrest policies throttle analytics API calls per product or consumer tier (for example free, professional, enterprise). This prevents one consumer from monopolizing shared analytics infrastructure. Quotas reset per time interval, such as daily or monthly, which supports usage-based pricing models.
Analytics APIs are authenticated with API keys or OAuth 2.0 tokens. Where the backend supports it, principal propagation passes the caller's identity to the backend system (for example SAP S/4HANA through the Cloud Connector), so the backend's own authorizations decide which rows the caller sees. A partner queries an analytics API, and the backend enforces what that partner can see at query time.
The Developer Hub publishes API products with their documentation, lets developers test them, create applications, and subscribe, and can also list governed MCP servers for AI agents. Internal teams discover what analytics APIs exist without contacting development, and SAP's own APIs and events are documented in SAP Business Accelerator Hub. External partners can register and request access through the same portal.
Both are valid for analytics APIs. OData suits dimensional queries (drill-downs, roll-ups) and is what SAP Datasphere's consumption APIs use. GraphQL suits flexible exploration where clients request only the fields they need. CAP can serve the same service over OData and GraphQL (through its open-source GraphQL adapter), letting consumers choose.
SAP AI Core manages the lifecycle of custom machine learning models: training pipelines run as batch jobs, trained models are deployed as inference endpoints, and artifacts and metrics are tracked through one API, with SAP AI Launchpad as the management UI. The generative AI hub in SAP AI Core provides governed access to foundation models from OpenAI, Anthropic, Google, Mistral AI, and others, plus SAP models such as SAP-RPT-1.6 for tabular predictions, without managing infrastructure. Together they let organizations build custom AI-augmented analytics applications. SAC's own AI features ship with SAC (Premium AI features are paid in AI Units), so customers don't provision AI Core for them.
Use AI Core when organizations need custom models trained on proprietary data: demand forecasting trained on years of internal sales, churn prediction trained on customer behavior, or anomaly detection trained on equipment sensor readings. AI Core runs the training pipelines, tracks metrics, and serves trained models as inference endpoints. Applications call those endpoints and write predictions where dashboards and planning models can read them.
Custom apps and agents call foundation models through the generative AI hub, whose orchestration adds templating, grounding on your own documents, data masking, and content filtering, and lets teams switch models without changing client code. Agents built in Joule Studio choose from more than 70 AI models. The generative AI hub is metered in capacity units, not per GPU-hour.
SAC Smart Predict (classification, regression, and time-series forecasting), Smart Insights, and just ask run inside SAC, and analytical insights in Joule build on just ask. None of them needs a separate AI Core setup. These features are analytics first, not infrastructure focused, so teams think in terms of predictions and insights, not model training pipelines. Reach for AI Core only when a use case needs a model SAC does not offer.
SAP Document AI (formerly Document Information Extraction) extracts structured data from documents such as contracts, invoices, and regulatory filings, using schema-based extraction with generative AI in more than 100 languages. Loaded into Datasphere, this data enables document-driven analytics (how many contracts exist, what the key terms are, which entities are mentioned).
Analytics on BTP must reach on-premise systems securely. The Cloud Connector opens a secure tunnel from the on-premise network to BTP, so SAC import connections and tunnel live connections can reach systems such as SAP BW or SAP S/4HANA, Datasphere can replicate from on-premise SAP systems, and cloud apps can call on-premise web services. SAP Cloud Identity Services (Identity Authentication and Identity Provisioning) connect corporate identity sources, such as Microsoft Active Directory, an LDAP directory, or an existing identity provider, to BTP, enabling single sign-on across analytics tools and consistent access control.
Cloud Connector runs on-premise and acts as a reverse invoke proxy: it opens the connection to BTP from inside your network. BTP applications reach only the systems and resources you expose through it, without exposing them to the internet. A Datasphere replication flow reads from an on-premise SAP system through the Cloud Connector, and an Integration Suite iFlow calls an on-premise web service the same way. Connections are audited, and no inbound firewall ports need to be opened.
Destinations define connection parameters and credentials for backend systems (username, password, URL, protocol). Cloud Foundry applications reference destinations by name, not by embedding credentials in code. Rotating credentials happens centrally, not in deployed applications. Destinations support certificate-based authentication, OAuth2, and SAML bearer token propagation.
IAS acts as SAML 2.0 or OpenID Connect identity provider for BTP applications and SAC. Users authenticate once, then open SAC, Datasphere, and custom apps without re-entering credentials. IPS syncs users and groups from corporate directories such as LDAP into IAS and the connected apps, keeping identity current. With a live connection, SAC passes the user's identity to Datasphere, so Datasphere data access controls apply row-level security per user.
When organizations use both SAP analytics (SAC, Datasphere) and third-party platforms (Tableau, Looker, Databricks), IAS can act as the identity provider for all of them, or proxy to the corporate identity provider. Users have one identity and one sign-on; permissions are still granted in each platform, but against the same user context, which simplifies compliance and access reviews.
BTP offers two commercial models. Under the consumption-based model, the SAP BTP Enterprise Agreement (BTPEA) gives access to all eligible services from prepaid cloud credits with an annual commitment, billed annually in advance, with overages billed at list price; pay-as-you-go needs no commitment and is billed monthly in arrears; and CPEA, BTPEA's predecessor, has been limited to existing contracts since April 2024, with a service scope that will not be extended. Under the subscription model, you pay a fixed fee per subscribed service. Each service has its own metric, listed in the SAP Discovery Center service catalog. Since January 1, 2026, Datasphere and SAC are licensed in SAP Business Data Cloud capacity units, not BTP credits. Teams estimate costs by sizing the architecture: how many users, how much data, how many integrations, what's the peak load.
BTPEA suits organizations with well-established, planned use cases that want to switch services on and off without being tied to one service: multiple subaccounts, several runtimes, AI and integration services. Subscriptions suit a fixed set of services at a predictable cost, and pay-as-you-go suits use cases that are not yet well defined, such as a proof of concept in a productive environment. Volume-based discounts apply to BTPEA, while pay-as-you-go charges are non-discountable; the right mix depends on how predictable your usage is.
Each BTP service has its own metric and price, published in the SAP Discovery Center service catalog and on SAP's BTP pricing pages; the generative AI hub, for example, is priced in capacity units. Datasphere and SAC are sized in SAP Business Data Cloud capacity units, priced on request, and SAP's BDC estimator helps translate users and data volumes into capacity. Under BTPEA, every service draws on the same cloud credits, so watch consumption per service in the monthly balance statement rather than assuming a bundle hides it.
Estimate SAC users (viewers, planners, developers). Estimate the SAP HANA working set (fact table size, aggregation requirements). Estimate monthly data volume loaded into Datasphere. Estimate integration flows and event message volume. Sum these across all subaccounts. The estimators on sap.com and the usage and cost views in the BTP cockpit help teams right-size without overpaying for unused capacity.
SAP sells analytics as part of larger packages: SAP Business Data Cloud combines Datasphere, SAC, and SAP HANA Cloud in one capacity-based contract, and SAP Build is included in SAP Business Suite. Check what your existing contracts already include before buying BTP credits for the same capability. This aligns purchase incentives with analytics adoption and simplifies vendor management.
BTP for Analytics creates value when analytics decisions need to trigger actions and workflows. These scenarios are composites of common project patterns, not named customer cases; they show how organizations extend analytics into orchestration and custom applications.
Organizations need task-focused analytical experiences where standard dashboards feel too generic. A procurement manager needs procurement analytics, KPIs, and action buttons in one screen without context switching.
Real-time dashboards need to respond to business events (orders, shipments, quality notifications) without relying on nightly ETL.
Supply chain teams want predictive analytics: demand forecasts, lead time anomalies, supplier risk scores. Standard analytics shows historical data; predictive analytics shows "what if."
Manufacturing planners needed a domain-specific application that showed capacity constraints alongside forecasts and could trigger supplier notifications when stock fell below a threshold. Standard SAC could not orchestrate these multi-step workflows.
A logistics company had IoT sensors on delivery trucks sending real-time location and condition data. They wanted to route this data to SAP dashboards and trigger alerts when conditions deviated.
A technology company wanted Joule to answer questions specific to their industry and internal systems, with action routing to Jira and Salesforce. Standard Joule patterns were not enough.
BTP is easiest to understand when read beside adjacent topics that define what it is not.
Sapphire and TechEd 2026 update. At SAP Sapphire 2026, the new SAP Business AI Platform unified SAP BTP with SAP Business Data Cloud and SAP Business AI. Joule Studio became the build layer — intent-based development, pro-code support for frameworks such as LangChain, Pydantic AI and LlamaIndex, an n8n environment for visual workflows, and a Vercel partnership for front-ends — with agents running on a Joule Studio runtime that uses NVIDIA OpenShell for secure execution. At SAP TechEd 2026 (Berlin, October 27–29), SAP said general availability of Joule Studio is rolling out in phases: design-time tooling is free under fair-use limits, the SAP-managed runtime is free through December 2026 for select customers, and n8n workflows are with early adopters, with general availability planned for Q1 2027. Read the full Sapphire 2026 analysis →