This is Part 2 of our SAP Business Data Cloud for Data Engineers series. In Part 1 we covered what BDC is, why SAP built it, and why it matters for data engineers coming from Azure and Databricks. Now we go inside the architecture — layer by layer, concept by concept, mapped to the data engineering mental models you already have.
The architecture conversation that keeps happening
Marie is six months into the RetailCo project. She knows SAC well now. She has built Stories, designed Planning Models, configured Data Access Controls, and led the connection architecture between Azure and SAC.
Then the project scope expanded.
RetailCo’s CTO came back from SAP Sapphire 2026 with a slide deck and a decision. RetailCo was moving to SAP Business Data Cloud. The existing SAC implementation would become part of the BDC platform. The Azure Data Lake workloads — the e-commerce pipeline, the loyalty programme data, the demand forecasting models in Databricks — would need to connect to BDC rather than directly to SAC.
Marie was asked to lead the technical architecture workstream. She opened her laptop, pulled up the SAP BDC architecture diagram from the slide deck, and stared at it for a long time.
Five boxes. Multiple arrows. Terms like Business Data Fabric, Data Product Studio, Foundation Services, Intelligent Applications, and Hyperscaler Integration. She had seen more confusing architecture diagrams. But she had also seen clearer ones.This is the explanation she wished she had been given that morning.
The core architectural principle — and why it is different from what you know
Before going through each layer, you need to understand the single idea that BDC is built around. Because once you understand the idea, every architectural decision starts to make sense.
Rather than introducing another analytics or data warehousing layer, BDC re-architects how SAP data is unified, governed, enriched, and consumed across analytics, planning, and AI.
The key word there is re-architects. Not adds another tool. Re-architects.
In a standard modern data stack — the one Marie knows from Azure — data moves between layers. Source systems produce data. Pipelines extract and move it. A storage layer holds it. A transformation layer cleans and models it. A semantic layer defines business metrics. A consumption layer visualises it. Each layer is a separate tool. Data moves between them.
The core architectural principle of BDC’s business data fabric strategy is to enable seamless and scalable access to mission-critical business data with the semantics and business context preserved.
That last part is what changes everything. Semantics and business context preserved. Not extracted and reconstructed. Preserved in place.
In the Azure world Marie knows — when you extract financial data from S/4HANA into ADLS Gen2, the data arrives as rows and columns. The profit centre hierarchy that existed in SAP is gone. The cost centre allocation logic is gone. The currency conversion rules are gone. The fiscal year variant is gone. You spend weeks rebuilding it in dbt models and Databricks notebooks. Then SAP’s organisational structure changes and you spend another week fixing the pipelines.
BDC’s architecture is designed so that data never loses that context in the first place. The business semantics travel with the data through every layer of the platform. The profit centre hierarchy is not something you rebuild — it is something you inherit from the data product that SAP ships as part of the platform.
Hold that thought. It becomes the lens through which every architectural layer makes sense.
Layer 1 — Source Systems: Where BDC starts
At the heart of SAP BDC is SAP Datasphere, which provides the data modelling layer on top of the data products. Non-SAP applications can be connected to Datasphere to combine SAP data with non-SAP data.
BDC connects to two categories of source systems and the distinction matters architecturally.
SAP source systems — S/4HANA, SuccessFactors, Ariba, IBP, BW, ECC. These connect to BDC natively. No extraction pipeline. No connector configuration that you build yourself. The connection exists because BDC and these systems are designed by the same vendor to work together. When S/4HANA sends financial data to BDC it sends it with all of its business context intact — organisational structures, currency settings, fiscal year variants, authorisation concepts. The context is not an afterthought. It is part of the data transfer.
Non-SAP source systems — everything else. Your Azure Data Lake. Your Databricks Delta Lake tables. Google BigQuery. Snowflake. Amazon Redshift. Microsoft Fabric.
Data from external non-SAP sources such as Google BigQuery and Amazon Athena can be connected directly with the SAP Datasphere layer of SAP Business Data Cloud. Sources such as Amazon Redshift, Microsoft Fabric, and Databricks Delta Lake leverage Smart Data Integration and the Data Provisioning Agent for connectivity — acting as a proxy layer enabling secure and efficient connections to hyperscaler sources. (Sap)
Marie’s immediate reaction to this — which is the correct data engineer reaction — was to ask about data movement.
“Does the data physically move from our Azure Data Lake into BDC or does BDC query it in place?”
The answer is both — and choosing between them is one of the first architectural decisions on any BDC project.
Federation — BDC queries your external data source in place using virtual tables in Datasphere. Your Azure Data Lake data stays in Azure. BDC reads it when needed. No duplication. No movement costs. The trade-off is query performance depends on network latency and the external system’s availability.
Replication — BDC copies your data from the external source into its own storage layer via Replication Flows. Data from SAP sources can be replicated out to external hyperscaler stores such as Google BigQuery, Amazon S3, and Azure Data Lake Storage Gen2 via SAP Datasphere through its Replication Flow feature. Faster query performance. Data exists in two places. Movement costs and synchronisation lag. Sap
The pattern Marie used for RetailCo — federate the e-commerce data from Azure because it changes constantly and latency is acceptable for the reporting use case. Replicate the loyalty programme data into BDC because it is queried heavily and performance matters for the real-time dashboards. No single right answer. Context determines the choice.
Layer 2 — Foundation Services and Data Products: The concept that has no perfect Azure equivalent
This is the layer that takes longest to click for data engineers — not because it is technically complex but because the concept is genuinely new.
Data Products in SAP Business Data Cloud streamline data sharing, integration, and analytics across domains. Supported by high-quality metadata, Delta Sharing protocols, and decentralised ownership principles, they are optimised for intensive reads and managed with a product mindset. (Sap)
A Data Product in BDC is a governed, documented, business-ready dataset that is published for consumption by other teams and applications.
The closest analogy in the data engineering world is a dbt semantic model published to a data catalogue — a curated, tested, documented dataset with clear ownership, defined SLAs, and a stable interface that consumers can rely on. But with one critical addition — BDC Data Products carry SAP business semantics as part of their definition.
When SAP ships a Financial Statement Data Product for S/4HANA — it does not just contain revenue and cost numbers. It contains the account hierarchy structure. The profit centre mapping. The currency conversion rates. The intercompany elimination logic. The fiscal year calendar. All of the business context that makes financial data meaningful in an SAP environment.
You do not build this. SAP ships it as part of the platform. You install it.
The Data Product Studio allows data teams to bundle curated datasets into standardised data products — business-ready, documented, governed data packages that non-technical users can discover, understand, and subscribe to through a self-service catalogue. (SAVIC Technologies)
In practice this means two types of Data Products exist on a BDC project.
SAP-delivered Data Products — pre-built by SAP, covering standard business processes. Financial Accounting. Procurement Analytics. HR Headcount. Supply Chain Inventory. These arrive with the platform and connect to your SAP source systems automatically after configuration. The equivalent of a dbt package published by the data vendor rather than built by your team.
Customer Data Products — built by your data engineering team using the Data Product Studio. You take SAP-delivered Data Products as inputs, join them with non-SAP data from your Azure lake or Databricks tables, add custom business logic specific to your organisation, and publish the result as a governed Data Product that the rest of the organisation can consume.
Marie’s team built three Customer Data Products for RetailCo. The first combined S/4HANA financial data with e-commerce transaction data from Azure — creating a unified revenue view that neither SAP nor Azure could produce alone. The second joined SuccessFactors headcount data with Databricks ML model outputs for attrition risk scoring — exposing a governed dataset that the HR team could consume in SAC without needing to understand either SuccessFactors or machine learning. The third federated loyalty programme data from Azure with SAP Ariba procurement data — enabling a margin analysis that considered both cost and customer lifetime value simultaneously.
None of those would have been possible to build as governed, shareable data products without BDC’s data product framework. In the old world they would have been ad-hoc Databricks notebooks or one-off Power BI datasets — useful but not governed, not discoverable, and not reusable.
Layer 3 — SAP Datasphere: Your governed semantic and modelling layer
SAP Datasphere has undergone a positioning shift in 2026 that many SAP customers have not fully absorbed. It began as SAP Data Warehouse Cloud. It evolved into SAP Datasphere. In 2026 it has become something more fundamental — the intelligent data fabric that every SAP AI initiative depends on for trusted, governed data.(SAVIC Technologies)
Datasphere is the layer that sits above the Data Products and below the consumption tools. It is where Data Products are assembled into analytical models, where business logic is applied, where governance is enforced, and where the semantic layer that business users and AI tools consume is defined.
The Azure data engineering mapping that works best for Datasphere is this combination:
Datasphere as storage = Delta Lake gold layer. Governed, ACID-compliant, optimised for analytical reads.
Datasphere as modelling = dbt semantic layer. Dimension tables, fact tables, calculated metrics, hierarchies — defined once, consistent everywhere.
Datasphere as governance = Unity Catalog. Data lineage, access control, data classification, discovery catalogue.
Datasphere as federation = Azure Synapse Analytics external tables or Databricks Delta Sharing. Query external data sources in place without moving them.
All four of those Azure capabilities exist in Datasphere as a single integrated platform — which is both its strength and its learning curve. Strength because everything is in one place with one governance model. Learning curve because a data engineer used to assembling these capabilities from separate best-of-breed tools has to adjust to a more opinionated integrated environment.
SAP Analytics Cloud uses SAP Datasphere as the storage layer for planning. This approach integrates data persistence and planning logic more tightly while SAP Analytics Cloud remains the front end for modelling, simulation, and visualisation. (BARC)
This is a significant architectural change from earlier SAC implementations. In the past SAC had its own internal data storage separate from Datasphere. In 2026 SAC planning models use Datasphere as their storage layer. The practical implication — your planning data and your analytical data live in the same governed layer. Budget versus actual comparison that previously required connecting two separate data stores now queries a single governed Datasphere layer. One source of truth. Genuinely.
The key Datasphere objects that a data engineer needs to understand:
Remote Tables — virtual tables pointing to external data sources. Query your Azure Data Lake table from Datasphere without copying the data. Performance depends on the external source. Governance lives in Datasphere.
Local Tables — physical tables inside Datasphere’s storage layer. Data replicated from source systems. Fast query performance. Datasphere manages the storage.
Views — transformation logic defined in Datasphere’s graphical or SQL editor. The equivalent of dbt models. Take Remote or Local Tables as input, apply transformations, expose a clean view to consuming applications. Version controlled. Documented. Governed.
Analytic Models — the semantic layer objects that SAC and AI tools consume. Define measures, dimensions, hierarchies, and access controls at the model level. The equivalent of a Power BI semantic model or a dbt metrics layer. Define once, consume everywhere.
Replication Flows — the data movement pipelines. Extract data from SAP source systems and load it into Local Tables in Datasphere. The equivalent of Azure Data Factory copy activities. Managed by Datasphere. No separate pipeline tool required for SAP-to-BDC movement.
Layer 4 — SAP Analytics Cloud: The consumption layer you already know
If you have followed the SAC series on this blog — you know SAC well. In the BDC architecture context its role is more precisely defined than in standalone SAC implementations.
SAP Analytics Cloud is the presentation tool to develop advanced dashboards combining analytics and planning. The AI agents and intelligent applications layer is the consumption layer of SAP BDC. (SAP Learning)
In the BDC architecture SAC is a pure consumption layer. It does not store data. It does not transform data. It does not govern data. All of that happens in Datasphere underneath. SAC connects to Datasphere Analytic Models and visualises them — dashboards, planning input forms, AI-assisted forecasting, What-If scenario modelling.
The data engineering analogy — SAC in BDC is like Power BI connecting to an Azure Synapse Analytics semantic model. Power BI does not store the data. It does not transform the data. It connects to the semantic model and provides the business user interface. SAC does the same thing with Datasphere as the semantic model layer.
The implication for data engineers on a BDC project — your primary work is in Datasphere and the Data Product layer, not in SAC. SAC configuration and Story building is typically handled by SAC specialists or functional consultants. Your value is in the data architecture underneath that makes SAC’s reports accurate, consistent, and trustworthy.
Layer 5 — Joule and Intelligent Applications: The AI consumption layer
Joule is SAP’s AI-powered co-pilot. Joule uses context-rich data to provide answers to business users’ questions and to provide additional insights. Intelligent Applications are data-rich AI-powered dashboards delivered by SAP and extended by customers — built using SAP Analytics Cloud. (SAP Learning)
Joule and Intelligent Applications sit at the top of the BDC architecture as the AI consumption layer. This is the layer that justifies the entire architectural investment underneath.
In data engineering terms — Joule is an AI application with a retrieval-augmented generation (RAG) architecture. Business users ask questions in natural language. Joule retrieves relevant data from BDC’s governed Datasphere layer, interprets it with the business context preserved in the Data Products, and generates answers that are both linguistically natural and factually grounded in governed data.
The reason this matters architecturally — Joule’s answer quality is directly dependent on the quality and completeness of the Datasphere semantic layer underneath it. A poorly governed Datasphere model with incomplete hierarchies and missing business context produces Joule answers that sound plausible but are factually wrong. A well-governed Datasphere model with complete business semantics produces Joule answers that finance teams and supply chain managers can act on.
The most significant 2026 Datasphere update is Joule GA. Joule is now embedded directly in the Datasphere interface — data architects, analysts, and business users can navigate the platform, execute tasks, and get answers using natural language. (SAVIC Technologies)
For data engineers the practical implication — when you design Datasphere models and Data Products on a BDC project, you are not just designing for SAC dashboards. You are designing for Joule. Every business term you define clearly in a Datasphere Analytic Model is a concept Joule can answer questions about accurately. Every hierarchy you define correctly is a drill-down path Joule can navigate. Every access control you implement correctly is a security boundary Joule respects.
Good data engineering in BDC makes the AI better. That is a genuinely new and genuinely important responsibility.
Layer 6 — Hyperscaler Integration: Where your Azure and Databricks skills matter most
SAP Business Data Cloud connects all data by leveraging business data fabric principles, making it easier to discover, share, govern, and model data across platforms like Snowflake, Azure, GCP, AWS, and Databricks. (Sap)
This is the layer where Marie’s background became her superpower on the RetailCo project. And where yours will too.
BigQuery integration is scheduled for H1 2026 GA, enabling zero-copy federation between SAP transactional data and BigQuery analytical workloads. Microsoft Fabric is planned for Q3 2026. (SAVIC Technologies)
The hyperscaler integrations are designed around a zero-copy principle — SAP data accessible in external platforms without extracting and duplicating it.
A Databricks notebook can query S/4HANA financial data through BDC without a pipeline that moves that data into the lakehouse first. A BigQuery ML model can train on SAP supply chain data with business context intact. A Microsoft Fabric dataflow can join SAP customer data with external market data without an ADF extraction pipeline.
The practical architecture pattern emerging on enterprise BDC projects in 2026 — use BDC as the governed source of truth for all SAP data, use hyperscaler platforms for the workloads they do best (Spark-scale transformations in Databricks, ML training in Azure ML, large-scale SQL analytics in BigQuery), and use the BDC hyperscaler integrations to connect them without data duplication.
For RetailCo the architecture Marie designed looks like this:
S/4HANA financial data flows into BDC natively — no pipeline. The Financial Statement Data Product installs from SAP Business Content — no build. Datasphere Analytic Models expose clean financial KPIs to SAC — no custom semantic layer development.
The RetailCo e-commerce transaction data stays in Azure Data Lake Gen2. Datasphere connects via federation — no replication, no movement cost. The Databricks ML demand forecasting models read SAP inventory data from BDC via BDC Connect for Databricks — no extraction pipeline. Model outputs write back to a Datasphere Local Table — no separate storage layer.
SAC dashboards combine all of it — financial data from S/4HANA via BDC, e-commerce data from Azure via federation, ML forecasts from Databricks via BDC Connect — in a single governed view that the CFO opens every Monday morning.
One platform. Multiple sources. Zero extraction pipelines between SAP and the analytics layer. That is the architecture BDC is designed to enable.
The BDC architecture summary — one reference view
Here is the complete BDC architecture in one view that you can refer back to:
| BDC Layer | What it does | Azure/Databricks equivalent |
|---|---|---|
| SAP Source Systems | Produce business data with context | Operational databases and SaaS apps |
| Non-SAP Sources | External data connected via federation or replication | External data sources |
| Foundation Services | Data Products with SAP business semantics | dbt packages plus data catalogue |
| Data Product Studio | Build and publish custom data products | dbt project plus data mesh tooling |
| SAP Datasphere | Governed semantic and modelling layer | Delta Lake plus Unity Catalog plus dbt |
| Replication Flows | Move data from sources to Datasphere | Azure Data Factory copy activities |
| Remote Tables | Federate external data in place | External tables in Synapse or Databricks |
| Analytic Models | Semantic definitions for consumption | Power BI semantic model or dbt metrics |
| SAP Analytics Cloud | Business user consumption — dashboards and planning | Power BI plus Anaplan |
| Joule | AI assistant consuming governed data | Azure OpenAI on governed data |
| Intelligent Applications | Pre-built AI-powered analytical apps | Pre-built Power BI apps plus ML |
| BDC Connect for Databricks | Spark compute on BDC data | Native Databricks — already know this |
| Hyperscaler Integration | Zero-copy access from BigQuery, Fabric, Snowflake | Delta Sharing protocols |
What Part 3 covers
Part 2 gave you the architecture layer by layer. Part 3 goes deep on the SAP and Databricks partnership — the technical details of BDC Connect, how to design a joint architecture, when to use Databricks compute versus Datasphere compute, and the real-world patterns emerging on enterprise BDC and Databricks implementations in 2026.
The complete BDC for Data Engineers series:
- Part 1 — What is SAP Business Data Cloud and why should data engineers care? (published)
- Part 2 — SAP BDC Architecture — the data engineer’s translation guide (you are here)
- Part 3 — SAP BDC and Databricks — partners not competitors (coming soon)
- Part 4 — Data Products in SAP BDC — what they are and why they matter
- Part 5 — Connecting SAP BDC to Azure — the integration architecture
- Part 6 — SAP BDC vs your current stack — honest migration considerations
- Part 7 — SAP BDC governance and security — for engineers who care about data quality
- Part 8 — SAP BDC certification guide — C_BCBDC for data engineers
Subscribe below to get notified when Part 3 publishes.
Related reading on Data Cloud Insights
- SAP Business Data Cloud for Data Engineers — Part 1
- SAP BDC Architecture Explained with Real Examples
- SAP Analytics Cloud for Data Engineers — Part 1
- SAP Analytics Cloud Complete Beginner’s Guide
Published by the Data Cloud Insights team — SAP data professionals with hands-on implementation experience across Europe, bridging modern cloud data engineering and the SAP BDC ecosystem.
Interesting. You could argue that Marie was coming from a background of SAP BPT. Whereby she had SAP SF -> DSP -> SAC and now she wonders why what she has build in her AM is no longer necessary as she has to use a SAP BDC Data Product for her Workforce Planning Dashboard …
Pingback: SAP Business Data Cloud and Databricks: Integration Guide for Data Engineers 2026 (Part 3)
Pingback: SAP Business Data Cloud Data Products: Design, Governance and Engineering Decisions (Part 4)