Business Data Cloud (BDC) is SAP's fully managed data foundation: it curates SAP application data into governed data products, models and integrates data in Datasphere, serves analytics and planning in SAC, and shares data products with platforms such as Databricks, Snowflake, and Google BigQuery through BDC Connect without copying them. It's not your data lake, and it doesn't replace every warehouse you run. The five scenarios below show where BDC creates platform advantage: zero-copy data science on SAP data, a customer 360 that spans Snowflake and SAP, marketing attribution with BigQuery, a governed data mesh, and governed data for AI. What they share is this: BDC enables analytics scenarios that would require months of ETL and governance work if you tried to build them in a traditional warehouse, because sharing, semantic modeling, and governance are platform capabilities rather than projects.
BDC reality: The scenarios here work because BDC turns SAP data into governed data products that are shared instead of copied. Sharing, federation, and replication are all available—the skill is choosing per use case. You define semantics once, in data products and Datasphere models, not per tool. Access is governed in two places: in BDC (which products go where) and on each consuming platform (who can query them). Not a data lake. Not a warehouse replacement. A managed data foundation that makes analytics faster and more trustworthy.
Scenario 1
Zero-Copy Analytics: Databricks ML + SAP Financial Data
Data scientists need SAP financial data for ML models, but copying to Databricks creates governance problems and synchronization delays. BDC Connect enables direct access without data movement.
The Problem
Data science team needs S/4HANA GL data for revenue forecasting models. Current approach: monthly exports, governance gaps, 30-day stale data.
Your data science team in Databricks builds financial forecasting models. They need GL account balances, cost allocations, and variance drivers from SAP S/4HANA. Today's process: a finance analyst exports GL data from SAP monthly, uploads to a Databricks data lake directory, and notifies the data science team. By the time the data lands, it's already 7-10 days old. No audit trail of who accessed which data. No row-level security enforcement in the Databricks model. Models are trained on a snapshot, not live data. The data science team can't validate their 2026 forecast against 2025 actuals because the historical data isn't kept current.
The Solution
BDC Connect for Databricks shares governed SAP finance data products into Unity Catalog. Zero copy. Governed on both sides. As fresh as the last refresh.
BDC Connect for Databricks (generally available since October 2025) shares SAP-managed data products from SAP S/4HANA into your existing Databricks workspace, where they appear as Unity Catalog catalogs with SAP's semantic metadata attached. Your data science team queries them from notebooks—no export, no manual upload. Access is governed in two places: BDC decides which data products are shared with the workspace, and Unity Catalog decides which data scientists can query them, so row-level rules such as "North America only" have to be designed on the Databricks side too. Freshness follows the data product's refresh in BDC rather than a monthly export, and Unity Catalog's auditing records who queried what. Forecasts can be published back to BDC as data products, so SAC planning uses them without another pipeline. The finance team trusts the data science outputs because they can trace every number back to an SAP data product.
SAP Stack
BDC Connect (Databricks GA Oct 2025) + Datasphere + SAC + S/4HANA + Databricks
Business Data Cloud Connect
SAP Datasphere (semantic layer)
SAP Analytics Cloud
S/4HANA (source)
Databricks (destination)
Expected Impact
Fresher training data, less data preparation, and auditable lineage back to SAP.
Speed: Data preparation shrinks because data arrives governed, structured, and described with SAP semantics instead of as a monthly extract to clean. Trust: Finance leadership can audit forecast inputs back to SAP data products, which is what it takes to use data science forecasts in official planning. Scale: With extraction off the critical path, the team spends its time on more models rather than more data wrangling.
Prerequisites
BDC subscription in place, finance data products activated, Unity Catalog workspace ready.
SAP Business Data Cloud is subscribed, with the relevant SAP-managed data products activated (SAP Note 3607594 lists the source prerequisites)
Datasphere contains the financial semantic layer for SAC reporting (GL, cost centers, cost allocations)
S/4HANA GL posting is complete and kept current
A Unity Catalog–enabled Databricks workspace and an admin with CREATE PROVIDER and CREATE RECIPIENT privileges
BDC Connect is provisioned in SAP for Me and budgeted (metered on inter-region transfer and processing requests)
Data governance and row-level security requirements are defined for both BDC and Unity Catalog
Scenario 2
Cross-Platform Customer 360: Snowflake + SAP Customer Data
Marketing and sales need a unified customer view, but customer data is split between Snowflake (engagement data) and SAP (transaction data). BDC Connect shares SAP data products with Snowflake, and Datasphere models the combined view for SAC—without copying data back and forth.
The Problem
Customer engagement data lives in Snowflake, transaction data in SAP. Two separate customer 360s that never reconcile.
Your marketing team has built a comprehensive customer data platform in Snowflake: behavioral data (web visits, email opens, ad clicks), demographic data (age, industry, firmographic attributes), and engagement scores. Your sales team has customer transaction history in SAP S/4HANA and SAP Sales and Service Cloud: account health, order history, contract data, support tickets. Marketing and sales work from separate customer views. Marketing sends targeted campaigns to "high-value prospects" that sales knows have low deal probability. Revenue operations can't create unified account hierarchies because the systems don't talk. Customer intelligence is fragmented: nobody has a complete view of customer health or expansion opportunity.
The Solution
BDC Connect for Snowflake (GA May 4, 2026) brings SAP customer data products into Snowflake, and enriched segments flow back to SAC.
BDC Connect for Snowflake (generally available since May 4, 2026) mounts SAP customer and order data products in your Snowflake account as catalog-linked databases, without replication. Marketing joins them with engagement scores, segments, and campaign membership in Snowflake and publishes the enriched customer segments back to BDC as a data product. In Datasphere, a customer model combines those segments with transaction dimensions from SAP (industry, contract value, last order date, open service tickets), and SAC dashboards show one customer 360: engagement profile plus transaction history plus account health in one view. Marketing targets high-engagement prospects with real deal probability. Sales sees which customers have dropped engagement before they stop buying. Revenue operations builds unified account hierarchies on shared customer IDs.
SAP Stack
BDC Connect + Datasphere + SAC + SAP S/4HANA and Sales/Service Cloud + Snowflake
Business Data Cloud Connect
SAP Datasphere (semantic model)
SAP Analytics Cloud
SAP S/4HANA and Sales/Service Cloud (transaction data)
Snowflake (engagement data)
Expected Impact
Better campaign targeting, earlier churn signals, and sales and marketing working from one customer view.
Conversion: Adding SAP transaction context (account health, open service issues) to Snowflake engagement scores lets marketing drop low-probability prospects from upsell campaigns and focus spend where deals actually close. Retention: Churn models that see contract renewal status and declining order volume alongside engagement can flag at-risk accounts earlier than engagement data alone. Efficiency: List cleaning and manual reconciliation shrink because both teams work from the same governed customer IDs.
Prerequisites
Snowflake and SAP already deployed. Customer IDs mapped. BDC Connect for Snowflake set up.
Snowflake is deployed with customer engagement and segment data (Standard, Enterprise, or Business Critical edition on AWS or Azure)
SAP S/4HANA (and, where used, SAP Sales and Service Cloud) holds the customer transaction and account data
Customer ID mapping between Snowflake and SAP is available or can be created
BDC Connect for Snowflake is provisioned and budgeted (GA May 4, 2026), with Snowflake's connector terms accepted
Datasphere customer semantic model is designed (or can be built)
Marketing and sales teams have agreed on unified customer definitions
Scenario 3
Marketing Attribution: Google BigQuery + SAP Order-to-Cash Data
Marketing attribution models need both marketing spend data (BigQuery) and deal closure data (SAP). BDC Connect for BigQuery (generally available since July 2026) shares SAP data products with BigQuery and lets results flow back, eliminating daily ETL syncs between systems.
The Problem
Attribution models in BigQuery can't see deal closure data in SAP. Marketing impact is unmeasurable.
Your marketing team has invested in a sophisticated multi-touch attribution model in Google BigQuery. It tracks every campaign touch, every email click, every content download, and assigns fractional credit to campaigns based on first-touch, last-touch, and position-based models. But the model breaks at the critical point: actual deal closure. BigQuery can't see which of those attributed leads actually became customers in SAP. Marketing reports "we generated 500 qualified leads from digital campaigns" but sales says "we closed 40 deals." Nobody can bridge that gap. Is marketing's lead quality declining? Is sales missing follow-up? The questions go unanswered because the data lives in two systems that don't integrate.
The Solution
BDC Connect for BigQuery joins campaign data with SAP order-to-cash data products. End-to-end attribution from campaign touch to cash collected.
BDC Connect for BigQuery (generally available since July 2026) makes SAP order-to-cash data products—SAP-managed where available, custom-built in Datasphere where not—queryable in BigQuery and Google's Knowledge Catalog without copying. The attribution model joins campaign-attributed leads to SAP customer accounts and adds deal closure status, order value, contract value, and cash collected. Marketing attribution now extends all the way to revenue. You can answer "which campaigns drive the highest-value deals?" and "which campaigns have the longest sales cycle?" The attribution results can be published back to BDC as a data product, so finance sees campaign ROI in SAC next to actuals. Attribution models are retrained against the complete lead-to-cash pipeline, not just lead-generation metrics.
SAP Stack
BDC Connect + Datasphere + SAC + SAP S/4HANA + Google BigQuery
Budget optimization: When deal value, not lead volume, is the yardstick, the channel mix often looks different—high-touch programs that generate few leads can turn out to drive a large share of revenue, and that is the evidence marketing needs to reallocate budget. Accountability: Marketing can now show not just lead volume but deal value per campaign, along with sales cycle time and win probability. Efficiency: Sales knows which campaigns are sending the highest-quality leads and prioritizes follow-up accordingly.
Prerequisites
BigQuery attribution model deployed. SAP order-to-cash data available as data products. Lead-customer mapping available.
BigQuery contains campaign and lead attribution data
SAP S/4HANA (or SAP Revenue Cloud) contains deal closure and customer data, available in BDC as data products
Lead-to-customer mapping is available (via email, company name, or CRM ID)
BDC Connect for BigQuery is provisioned and budgeted (GA July 2026; BDC tenants on Google Cloud or AWS, Azure-hosted tenants to follow)
Datasphere semantic model includes both marketing and revenue dimensions
Marketing team has defined attribution rules and deal-quality criteria
Scenario 4
Enterprise Data Mesh: BDC as Federated Data Platform
Organizations adopting data mesh architecture need a platform where domains publish data products under shared governance. The BDC catalog and Datasphere provide the semantic and governance layer that data mesh requires.
The Problem
Decentralized data product ownership creates semantic chaos. Finance defines "revenue" one way, Sales another. No unified truth.
Your organization has embraced data mesh: Finance owns revenue data products, Sales owns customer data products, Operations owns supply chain products, each team owns their data, publishes it as a product, and consumers access it. The problem: without a central semantic layer, chaos emerges. Finance's "revenue" includes service fees. Sales' "revenue" includes only product sales. When a dashboard consumes both, the numbers don't reconcile. Finance publishes "customer segmentation" by revenue; Sales publishes it by industry. A data analyst building a cross-domain analysis spends a large share of their time mapping definitions instead of creating insights.
The Solution
BDC Datasphere as the semantic mesh. Domain-owned data products. A shared semantic model creates consistency across domains.
SAP Datasphere and the BDC catalog become your semantic mesh layer. Domain teams (Finance, Sales, Operations) publish custom data products in the BDC catalog, each through its own data provider profile, with terms of use and, since September 2026, steward-approved access. Datasphere's semantic layer creates unified definitions on top: "revenue" is defined once, mapped to each domain's source logic (Finance's GL accounts, Sales' order tables), and published as a standard measure in shared analytic models. Consumers install the data products they need and use the shared models instead of reinterpreting raw data. Mesh participants keep autonomy over their pipelines, while the shared semantic layer enforces a common language. Governance is applied once at the definition level: if a data steward defines "revenue," that definition applies wherever the shared model is used.
SAP Stack
BDC (Datasphere) as mesh hub + domain data products + SAC for consumption
SAP Datasphere (semantic mesh hub)
Business Data Cloud (managed service)
SAP Analytics Cloud (consumption)
Domain data products (Finance, Sales, Operations)
Expected Impact
Semantic consistency across domains. Analyst productivity increases (less reconciliation). Cross-domain insights become fast.
Consistency: Definition disputes fall sharply once Datasphere is the single source of metric truth. Productivity: Analysts spend far less time per project reconciling definitions, and that time goes into analysis instead of data wrestling. Scaling: Cross-domain analyses that used to take weeks (requiring multiple teams to align definitions) now take days because the semantic model is already consistent.
Prerequisites
Data mesh strategy defined. Domain data products designed. Governance model agreed.
Organization has committed to data mesh architecture (decentralized ownership, products, APIs)
Domain data product owners are identified (Finance, Sales, Operations, etc.)
Datasphere governance roles (data stewards, domain owners, consumers) are defined
Semantic model for core metrics (revenue, customers, costs) is designed
Domain data products can be published in the BDC catalog (custom data products from Datasphere file spaces or from BW)
BDC is available and budgeted as the managed service layer
Scenario 5
AI Model Training: Governed SAP Data for External ML Platforms
Data scientists need to train models on SAP data, but governance requirements prevent direct data exports. BDC provides secure, governed access for AI training without compromising security.
The Problem
Data science teams need to train models on customer data. Governance and security policies prevent direct SAP database access.
Your data science team needs to train customer churn prediction models on 5 years of customer transaction history. The data lives in SAP S/4HANA and SAP Sales and Service Cloud. Currently, to get this data, they request an export, IT manually extracts data, redacts sensitive fields, and delivers a CSV. The process takes 2-3 weeks. The data arrives 4 weeks old (lagged). Governance is manual: IT has to verify which data science team members can access which fields. A new team member? Governance review. A new model use case? Approval process. The cycle is slow and inflexible.
The Solution
BDC shares governed SAP data products with your ML platform. Access is approved in BDC and enforced on the platform, not handled through manual exports.
Data products become the governed access layer for AI training. A data steward approves which data products a churn-modeling project may receive, with terms of use attached, and BDC Connect shares them with the team's Databricks workspace or BigQuery project, where Unity Catalog or Google Cloud IAM restricts rows and columns to what the project may see—for example, only its assigned regions and no email or phone fields. Sensitive attributes can also be left out of the shared data product altogether. Queries are logged by the consuming platform, and the approval trail lives in BDC. Models are trained on current data rather than stale exports and can be retrained on each data product refresh; scores can be published back to BDC for SAC and SAP applications. Platforms without a BDC Connect connector, such as Amazon SageMaker, need another path: replication through Datasphere's premium outbound integration, or Amazon Athena once BDC Connect for Athena arrives (planned for H1 2027). The data science team gets faster time-to-model while IT gets better governance visibility.
SAP Stack
BDC + Datasphere + BDC Connect + external ML platforms
SAP Business Data Cloud
SAP Datasphere (semantic/governance layer)
BDC Connect (to ML platforms)
Databricks, or BigQuery with Vertex AI
Expected Impact
Shorter model cycles, auditable access, and fresher training data.
Speed: The weeks spent on data requests, approvals, and manual delivery shrink to a steward approval and a share, so model development cycles shorten. Compliance: Approvals recorded in BDC and queries logged by the consuming platform together show which data scientists accessed which customer data and when; plan explicitly how deletion requests flow through data product refreshes and model retraining. Accuracy: Models are trained on current data instead of monthly snapshots, which supports prediction accuracy.
Prerequisites
SAP data sources are available. Customer data products are defined. ML platform infrastructure exists.
SAP source systems (S/4HANA, SAP Sales and Service Cloud) contain the data required for AI training
Customer data products are defined, with sensitive fields excluded or masked
Data stewardship roles are assigned (who approves data for AI training?)
ML platform infrastructure exists (Databricks, or Google BigQuery with Vertex AI; other platforms need a replication path)
BDC Connect is available and budgeted for your target ML platform
Data governance and compliance requirements are documented (GDPR, CCPA, etc.)
BDC Scenario Selection Framework: Choosing Your First Data Product
The five scenarios above represent different BDC use cases: zero-copy analytics, federated customer 360, governed data for AI, and data mesh. Choosing your first BDC initiative depends on where your greatest pain lives today. Use this framework:
Scenario Type 1: Zero-Copy Analytics (Snowflake/Databricks Already Deployed)
Use When: You want analytics and data science on SAP data in Snowflake, Databricks, or BigQuery without copying it, and partner results back in SAP without another pipeline. Data freshness: as current as the data product refresh. Cost sensitivity: high (avoid duplicate storage and ETL).
Architecture: SAP data products shared through BDC Connect; queries run on the partner platform's engine; Datasphere models serve SAC. No extraction pipelines. Governance applied when sharing (BDC) and when querying (partner platform).
Time to Value: 4-8 weeks. Low complexity: mainly semantic model definition and query optimization.
ROI: Avoided extraction pipelines and duplicate storage. Fastest time to analytics where partner platforms are already strategic.
Right If: You have strong data engineering teams on Snowflake, Databricks, or BigQuery and want them working on governed SAP data rather than private extracts. Check region placement early: cross-region sharing is metered, and partners may cache data in their own regions.
Scenario Type 2: Federated Customer 360 (Multiple SaaS + SAP)
Use When: Customer engagement data lives in Snowflake or Salesforce. Transaction data lives in S/4HANA. You need unified customer analytics. Data freshness: daily to real-time. Cost sensitivity: medium (some data movement acceptable).
Examples: Scenario 2 (Customer 360).
Architecture: Datasphere as semantic hub. SAP customer and order data products shared with Snowflake through BDC Connect, enriched segments published back, and Salesforce or other CRM data brought into Datasphere through replication flows or federation where needed. A unified customer semantic model joins both layers. SAC provides 360 views.
Time to Value: 8-12 weeks. Medium complexity: master data reconciliation (which Salesforce account = which SAP customer?), lineage definition.
Right If: Customer data is your competitive advantage. You have sales and marketing teams who need unified customer insights. You're willing to invest in master data governance.
Scenario Type 3: Data for AI and ML (External ML Platforms)
Use When: Data science teams need governed access to SAP data for model training. They use Databricks, BigQuery, or similar ML platforms. You need to prevent ungoverned exports and data leakage. Data freshness: weekly/daily (training data).
Examples: Scenario 5 (AI Model Training).
Architecture: Governed data products (SAP-managed or custom). BDC Connect shares them with the ML platform; approvals are recorded in BDC and queries are logged by the platform. Data scientists work on governed data without requesting exports.
Time to Value: 6-10 weeks. Medium complexity: data governance rules definition, data lineage for audit, access policy enforcement.
ROI: Faster AI development (no export delays). Data science teams become more productive. Compliance improves (auditable access instead of blind exports).
Right If: You have active data science programs. You value governance over convenience. You need audit trails for compliance/risk management.
Scenario Type 4: Enterprise Data Mesh (Federated Ownership)
Use When: Your organization is moving toward data mesh. Different domains (Finance, Sales, Supply Chain) own their data and publish data products. You need a semantic hub that connects these domains. Data freshness: varies by domain. Cost sensitivity: high (avoid data consolidation into one warehouse).
Examples: Scenario 4 (Enterprise Data Mesh).
Architecture: Datasphere as semantic mesh hub. Each domain publishes data products. The BDC catalog connects domain data products. Governance policies apply uniformly across mesh. Analytics and AI teams consume products.
Time to Value: 6-9 months. High complexity: organizational change, domain ownership models, governance process design.
ROI: Analyst productivity increases (self-service data discovery). Data ownership becomes clear. Semantic consistency improves (single definition of "revenue" across domains).
Right If: You have mature data governance. You're transitioning from centralized to decentralized data ownership. You have multiple analytical domains with different owners and objectives.
Scenario Type 5: Attribution and Marketing Analytics (Multi-Platform Data)
Use When: Marketing attribution requires joining data from BigQuery (marketing events), SAP order-to-cash data (deals), and external data (website analytics, third-party intent signals). Data freshness: daily. Cost sensitivity: medium.
Examples: Scenario 3 (Marketing Attribution).
Architecture: SAP data products shared with BigQuery through BDC Connect, where they are joined with marketing events and campaign metadata; attribution results published back to BDC; SAC dashboards show campaign touchpoint-to-revenue mapping.
Time to Value: 8-12 weeks. Medium-High complexity: attribution logic definition, cross-platform data joins, campaign mapping.
ROI: Marketing budget becomes provably ROI-driven. Campaign decisions shift from "gut feel" to data-driven optimization. Marketing effectiveness becomes measurable.
Right If: You have significant marketing budgets and need to prove ROI. You run campaigns across multiple channels. Marketing and finance need to align on spend effectiveness.
BDC First-Project Selection Guide
Start With Zero-Copy Analytics If: You have large data platforms (Snowflake, Databricks, BigQuery) AND the SAP data you need is available as data products AND you can keep BDC and the partner platform in the same region. Time to value: fastest. Complexity: lowest.
Start With Federated Customer 360 If: Customer experience is your competitive advantage AND you have Salesforce or Snowflake for customer engagement AND you need Sales-Finance-Marketing alignment. Time to value: medium. Business impact: immediate.
Start With Data for AI If: You have active data science programs AND you need to speed up model development AND governance is a concern. Time to value: medium. ROI: AI development velocity improvement.
Start With Data Mesh If: You're large enterprise with 5+ analytical domains AND you need to scale analytics across organization AND you're willing to invest in organizational change. Time to value: long. Scope: organization-wide transformation.
Success pattern
What makes BDC scenarios succeed
All five scenarios share a pattern. They minimize data movement (sharing and federation instead of copies), define semantics once (in data products and Datasphere models, not per tool), govern access deliberately on both sides of every share, and enable analytics and AI that would be impractical with traditional ETL approaches. They succeed because BDC changes where the effort goes: less on extraction pipelines, duplicate storage, and per-project access reviews; more on semantic definitions and governance rules that apply once and benefit all downstream consumers, with capacity units and partner compute as the costs to manage. The result: faster analytics, more trustworthy data, and lower operational effort.
They avoid data copying
Sharing and federation instead of replication. Data products are stored once in BDC and read in place by consumers, with their semantics attached.
They apply governance centrally
Definitions and access terms live with the data product and the Datasphere model, not with each export; each consuming platform enforces query-level access, so both sides are designed together.
They connect silos without consolidation
Snowflake, Databricks, BigQuery, and SAP keep their independence. BDC creates the semantic bridge that makes them work together.
They scale analytically without scaling infrastructure
More domains, more data products, more users. One governance layer applies to all, not a new warehouse per domain.
From scenarios to delivery
Move from "I recognize my challenge" to "here's our plan"
You've read the scenarios. Now identify which one matches your biggest data challenge. Then link into the deeper content hubs below to understand BDC architecture, federation patterns, semantic modeling, and governance implementation for your chosen path.