Title here
Summary here
Data and Analytics: Use Cases and Decision Patterns
TL;DR
- The SAP BTP Data & Analytics domain spans four distinct layers: master data governance (MDG), data integration and modeling (Datasphere), analytical consumption (SAC), and in-memory persistence (HANA Cloud) — each covering a non-overlapping function.
- Production readiness varies sharply: SAC and HANA Cloud are fully mature, Datasphere is production-ready with prerequisites, and MDG cloud edition covers only the Business Partner domain as of mid-2026.
- The most important mindset shift is to stop treating these products as alternatives and start mapping each one to its architectural layer — mixing up layers is the primary cause of scope failures.
Where This Article Sits
| ID | Category | Component | Scope |
|---|---|---|---|
| BTP-C01 | Overview | Data and Analytics on BTP | Capability Map and Component Overview |
| BTP-C02 | Data Platform | HANA Cloud | Architecture and Use |
| BTP-C03 | Data Integration | SAP Datasphere | Architecture and Use |
| BTP-C04 | Analytics | Analytics Cloud (SAC) | Architecture and Use |
| BTP-C05 | Data Governance | Master Data Governance | Architecture and Use |
| BTP-C06 | Decision Patterns | Data and Analytics | Use Cases and Decision Patterns (this article) |
References
| Resource | URL |
|---|---|
| SAP Datasphere Product Overview | sap.com → |
| SAP Analytics Cloud Product Overview | sap.com → |
| SAP Business Data Cloud — Sapphire 2025 Innovation Guide | sap.com → |
| SAP Master Data Governance — Cloud Edition | help.sap.com → |
| S/4HANA Embedded Analytics vs. SAC — Enterprise Architecture KB | help.sap.com → |
1) The Data and Analytics Landscape
The following table maps each major component to its primary function and intended user. These capabilities are designed to be combined, not to replace each other (SAP Datasphere product page; SAP Analytics Cloud product page).
| Domain | What it does | Primary user |
|---|---|---|
| SAP HANA Cloud | In-memory relational database and vector store; the persistence layer for Datasphere, SAC planning models, and custom BTP applications | Platform engineer / DBA |
| SAP Datasphere | Data integration, semantic modeling, federation, and data warehousing; the governed data preparation layer | Data engineer / data architect |
| SAP Analytics Cloud (SAC) | Business intelligence dashboards, FP&A planning, predictive analytics, and self-service reporting; the consumption and decision layer | Business analyst / finance controller |
| SAP Master Data Governance (MDG) | Governance workflows, consolidation, and data quality management for master data domains (Business Partner, Material) | Data steward / MDM program lead |
They are not substitutes. A project that deploys SAC without a governed data layer will eventually rediscover why Datasphere exists.
2) How It Connects to S/4HANA
Every component in the Data & Analytics domain has a defined relationship to SAP S/4HANA. Understanding those relationships is the prerequisite for scoping correctly (S/4HANA Embedded Analytics vs. SAC — Enterprise Architecture KB).
S/4HANA sits at the top as the source of record, exposing data via CDS views, CDC, OData, and ABAP APIs. MDG on BTP connects upstream to govern master data quality and publishes clean records via MDI to downstream systems. Datasphere connects to S/4HANA to integrate and model data from both SAP and non-SAP sources. S/4HANA Embedded Analytics handles operational reporting entirely within the S/4HANA boundary at zero incremental license cost — consultants should always establish whether embedded analytics covers the stated requirement before proposing SAC or Datasphere. SAC sits downstream of both Datasphere and Embedded Analytics, consuming governed data for dashboards (via live connection) and planning (via import model). SAP HANA Cloud forms the persistence tier for both Datasphere spaces and SAC planning models.
Key point: Establishing the correct layer for each requirement — persistence, governance, integration, or consumption — is the most important scoping decision on a Data & Analytics engagement (S/4HANA Embedded Analytics vs. SAC — Enterprise Architecture KB).
3) Maturity Map
The maturity ratings below reflect publicly available information as of mid-2026. Claims about MDG cloud edition domain coverage and Seamless Planning GA status are sourced from the SAP Help Portal and SAP Sapphire 2025 Innovation Guide (SAP Master Data Governance — Cloud Edition; SAP Business Data Cloud — Sapphire 2025 Innovation Guide).
| Domain | Maturity | Notes |
|---|---|---|
| SAP HANA Cloud | ✅ Production-ready | Fully GA; acts as the database tier for Datasphere and SAC. Scale-out capacity planning required for large landscapes. |
| SAP Datasphere | ⚠️ Ready with prerequisites | GA and actively developed. Federation-first approach requires careful space architecture and SDI provisioning agent configuration. |
| SAP Analytics Cloud — BI | ✅ Production-ready | Live connection dashboards are GA and widely deployed. Performance tuning for large live models requires query-layer expertise. |
| SAP Analytics Cloud — Planning | ✅ Production-ready | Import-model FP&A is GA. Seamless Planning (SAC data stored in Datasphere) became GA in Q1 2025 but requires collocated tenants and shared IdP. |
| SAP MDG — on S/4HANA | ✅ Production-ready | Mature on-premise product with broad domain coverage. Requires ABAP expertise for custom governance workflows. |
| SAP MDG — Cloud Edition (BTP) | 🔶 Early adopter | Business Partner domain only as of mid-2026. Material Master on roadmap but GA not confirmed. Suitable for cloud-first programs accepting current scope limits. |
| SAP Business Data Cloud (BDC) | 🔶 Early adopter | Single-contract SaaS bundle (Datasphere + SAC + HANA Cloud + Databricks). Recommended for net-new programs; public pricing not yet available. |
4) Requirements Checklist
Use these checklists at the requirements stage — before any technical architecture is finalized. Each item should be answered or explicitly descoped in writing (SAP Datasphere product page; SAP Analytics Cloud product page).
SAP Datasphere prerequisites
| Checklist item | Why it matters |
|---|---|
| Source systems identified and connectivity method confirmed (CDS views, CDC, OData, file, adapter) | Without confirmed connectivity, the federate-first design is an assumption. |
| SDI provisioning agent installation planned for on-premise sources | Real-time replication from on-premise S/4HANA requires the agent; firewall scope must be resolved early. |
| Space architecture defined (team ownership, storage quotas, sharing rules) | Spaces are the core isolation unit; retrofitting boundaries late is expensive. |
| Data ownership and stewardship per domain assigned | Datasphere semantic models require business owners to keep hierarchies and mappings current. |
| CDC streaming infrastructure confirmed if near-real-time replication required | CDC needs the ABAP Pipeline adapter or Confluent Cloud — not available out of the box on all landscapes. |
| Data retention and archiving policies documented | Storage quotas are finite; long-term retention strategies must be defined before go-live. |
| Licensing scope covers Datasphere capacity units and HANA Cloud compute | Datasphere is consumption-based; underestimating federation query compute is a common cost overrun. |
| BW migration scope clarified (BW Bridge, Model Transfer, or full re-implementation) | BW Bridge is an incremental path, not a permanent architecture; agree the long-term target upfront. |
SAP Analytics Cloud prerequisites
| Checklist item | Why it matters |
|---|---|
| Connection type confirmed per use case (live vs. import vs. hybrid) | Planning and Smart Predict require import models; choosing live-only blocks these capabilities. |
| Live connection sources confirmed accessible from SAC (network, CORS, Cloud Connector or SAC Agent) | Browser-based CORS requirements and network issues discovered late delay go-live. |
| Planning scope defined: which entities own which models (finance, supply chain, HR) | Cross-domain planning requires cross-domain ownership; a single sponsor must be agreed. |
| Smart Predict use cases validated against license entitlement | Confirming inclusion avoids unnecessary third-party ML tooling procurement. |
| Seamless Planning tenancy requirements checked: same data center, same identity provider | Seamless Planning fails if tenants are in different data centers or use different IdPs. |
| Story and dashboard governance process defined (who publishes, promotes, retires) | Without governance, tenants accumulate unmanaged stories, degrading performance and trust. |
| User license types mapped to use cases (BI platform user vs. planning professional vs. business user) | A mismatch between license type and capability access creates budget surprises. |
SAP Master Data Governance prerequisites
| Checklist item | Why it matters |
|---|---|
| Master data domains confirmed and mapped to MDG coverage (Business Partner: GA; Material: roadmap) | Scoping cloud edition for Material Master without GA confirmation is an explicit project risk. |
| Deployment model decided: MDG on S/4HANA vs. MDG cloud edition (BTP ABAP Environment) | The two variants have different data models and domain scope; switching mid-project is a re-implementation. |
| MDG governance workflows mapped to business process owners (approver, validator, activator) | Without identified owners, MDG becomes a technical solution without organizational adoption. |
| Integration with MDI scoped: which systems receive clean master data via syndication | MDG without downstream distribution does not improve data quality across the landscape. |
| Data quality baseline measured before go-live (duplicate rate, completeness, accuracy) | Without a baseline, the project cannot demonstrate improvement post-implementation. |
| Change management plan addresses central governance model shift | Business units losing local record autonomy require structured change management. |
SAP HANA Cloud prerequisites
| Checklist item | Why it matters |
|---|---|
| Instance sizing based on measured or estimated data volumes, not default templates | HANA Cloud memory is the primary cost driver; undersizing causes failures, oversizing wastes budget. |
| Multi-environment strategy defined (dev, test, production) | Backup/restore must be planned; instances cannot be promoted between environments like on-premise HANA. |
| Backup and disaster recovery requirements documented | RTO/RPO targets must be confirmed against the service-level agreement before go-live. |
| Security and network access control (private link, IP allowlist) reviewed with security team | HANA Cloud instances are internet-exposed by default; security sign-off is a gate, not an afterthought. |
| User management and privilege model designed before data is loaded | Row-level and column-level security must be designed upfront; it cannot un-expose already-queried data. |
5) Decision Criteria
The three questions to ask first
Q1. What specific, measurable inefficiency or pain does this project solve?
Every data and analytics project must anchor to a stated problem with a measurable outcome — for example, “month-end close takes 12 days because analysts reconcile data from three systems manually” or “60% of sales orders contain incorrect Business Partner data, causing billing delays.” Without this anchor, there is no basis for tool selection or post-go-live success measurement. If the answer to Q1 is “we want better visibility,” the project is not ready to start (S/4HANA Embedded Analytics vs. SAC — Enterprise Architecture KB).
Q2. Where does the data live, who owns it, and are there data residency constraints?
Data residency requirements restrict which BTP data center can be used. Data ownership determines who will curate Datasphere spaces or MDG governance workflows — these are not IT-only responsibilities. Residency constraints must be confirmed with the legal/compliance team before any tenant is provisioned (SAP Datasphere product page).
Q3. Is there an internal sponsor with budget authority and organizational change mandate?
SAP Data & Analytics programs consistently fail not because of technology gaps but because the organizational change required — centralizing master data governance, enforcing stewardship roles, retiring legacy reports — lacks a sponsor with authority and budget to drive it. Confirm a named executive owns the outcome.
Domain selection by project context
| Project context | Recommended starting point |
|---|---|
| Real-time operational reporting entirely within S/4HANA, no non-SAP sources | S/4HANA Embedded Analytics (no incremental license) |
| Cross-system analytics combining SAP and non-SAP data | SAP Datasphere (data preparation) + SAP Analytics Cloud (consumption) |
| Finance FP&A / budgeting / scenario planning | SAP Analytics Cloud with import models (planning license required) |
| Combined reporting and planning in a governed landscape | Datasphere (backend) + SAC (frontend), optionally with Seamless Planning |
| Master data quality is the root cause of the stated pain | SAP MDG (on S/4HANA or BTP cloud edition depending on domain and deployment) |
| Master data governance solved; distribution to cloud systems is the gap | SAP MDI (BTP service, complements MDG — not a replacement) |
| Net-new BTP data and analytics program, no legacy BW constraints | SAP Business Data Cloud (single-contract SaaS bundle; recommended for 2025+) |
| BW modernization with existing BW/4HANA investments | Datasphere via BW Bridge or BW Data Product Generator |
| No clear pain point identified yet | Stop. Go back to Q1. |
Licensing and cost
| Domain | Licensing model | Key question to ask |
|---|---|---|
| SAP Datasphere | Consumption-based (capacity units); storage and compute metered separately | What is the estimated data volume and query concurrency? Get this sized before contracting. |
| SAP Analytics Cloud — BI | Per-user subscription (BI platform user license) | How many users need ad-hoc authoring vs. view-only? License type affects cost significantly. |
| SAP Analytics Cloud — Planning | Per-user subscription (planning professional or business user); Smart Predict included | Is planning integrated with BI in the same tenant? Mixed licenses require correct mix. |
| SAP MDG — on S/4HANA | Included in S/4HANA license for standard domains; custom domains may require add-on | Which domains are in scope — standard or custom? |
| SAP MDG — Cloud Edition (BTP) | SaaS subscription on BTP ABAP Environment | Is Business Partner sufficient, or is Material Master required (roadmap)? |
| SAP HANA Cloud | Consumption-based (capacity units for compute + storage) | Instance sizing drives cost; request a formal sizing exercise before signing. |
| SAP Business Data Cloud (BDC) | Single-contract SaaS bundle; component pricing not public | Request a BDC-specific quote; do not assume cheaper than individual components without comparing. |
6) Common Failures
Failure 1: Treating Datasphere and SAC as alternatives
Datasphere is the data preparation and governance layer; SAC is the consumption and planning layer (SAP Datasphere product page; SAP Analytics Cloud product page). Deploying SAC without a governed data layer pushes data preparation into SAC stories, producing unmaintainable models with embedded business logic that belongs in Datasphere semantic views.
Failure 2: Assuming embedded analytics is insufficient without testing it
S/4HANA Embedded Analytics covers a wide range of operational reporting at zero incremental license cost (S/4HANA Embedded Analytics vs. SAC — Enterprise Architecture KB). Projects that propose SAC or Datasphere without evaluating embedded analytics first leave money on the table. Make this evaluation a formal requirements-phase step, not an assumption.
Failure 3: Scoping MDG cloud edition for Material Master before GA confirmation
As of mid-2026, MDG cloud edition covers Business Partner only; Material Master is on the roadmap (SAP Master Data Governance — Cloud Edition). Committing to MDG cloud edition for Material Master without a confirmed GA date is a documented project risk that the sponsor must accept in writing, with a contingency plan for on-premise MDG.
Failure 4: Selecting live-only SAC connections for a landscape that includes planning
Live connections support read-only dashboards; planning and Smart Predict require import models. Projects that default to live connections discover this when the FP&A team tries to create a budget scenario — at which point changing the connection type requires a data reload and model restructuring.
Failure 5: Skipping the data ownership conversation for Datasphere spaces
Datasphere spaces carry business semantics — cost center hierarchies, currency conversion rules — that must be owned and maintained by business stewards (SAP Datasphere product page). Projects that treat Datasphere as pure IT infrastructure find that semantic models drift from reality within the first year.
Failure 6: Deploying MDG without scoping the MDI distribution layer
MDG governs master data quality; MDI distributes clean records to connected systems. A project that deploys MDG but never integrates MDI has solved governance but not the data quality problem across the landscape. Define MDI scope at the same time as MDG scope — not in a follow-on phase.
Failure 7: Underestimating Datasphere compute costs for federation-heavy landscapes
Federation queries execute at query time and are convenient but costly at scale (SAP Datasphere product page). In high-concurrency scenarios, federation without caching or materialization generates significant capacity unit charges and unexpected load on source systems. Quantify the federation vs. replication trade-off during design.
FAQ
Q: Our S/4HANA landscape is on-premise. Can we still use SAC and Datasphere?
Yes. Datasphere connects to on-premise S/4HANA via the SDI provisioning agent or CDS view extraction with the ABAP Pipeline adapter (SAP Datasphere product page). SAC connects via the Cloud Connector or the SAC Agent. Both paths are production-supported but require firewall and network coordination. Plan a connectivity validation sprint early in the project.
Q: When should we descope SAC planning from the initial project?
Descope SAC planning when: the stated pain point is purely analytical with no FP&A use case; the business has not identified a planning process owner who will maintain models; or the planning license budget has not been approved (SAP Analytics Cloud product page). Start with BI and add planning in a follow-on phase when ownership is confirmed.
Q: What licenses are needed for a basic Datasphere + SAC BI deployment?
At minimum: Datasphere capacity units, SAP HANA Cloud capacity units, and SAC BI platform user licenses. If Seamless Planning is in scope, SAC planning professional licenses are also required. SAP does not publish a public price list — request a formal quote and ask specifically about the BDC single-contract bundle for net-new engagements (SAP Business Data Cloud — Sapphire 2025 Innovation Guide).
Q: How should we document the Data & Analytics architecture requirement formally?
Use a two-artifact approach: (1) a requirements traceability matrix mapping each stated pain point to a specific component and use case; (2) an architecture decision record (ADR) for each major choice — for example, MDG cloud vs. on-premise, live vs. import SAC connection, or Datasphere federation vs. replication. The ADR captures options considered, the decision, and rationale.
Q: Is MDG required for Datasphere to work?
No. Datasphere integrates data from source systems regardless of master data quality. However, poor-quality master data in source systems is inherited by Datasphere models and surfaced in SAC dashboards (SAP Master Data Governance — Cloud Edition). MDG addresses the root cause; scope it when data quality is identified as the root cause of business pain, not as a general prerequisite.
Q: What is SAP Business Data Cloud and when should we recommend it?
SAP Business Data Cloud (BDC) is a single-contract SaaS bundle announced in early 2025 that includes SAP Datasphere, SAP Analytics Cloud, SAP HANA Cloud, BW modernization tooling, and SAP Databricks for AI/ML (SAP Business Data Cloud — Sapphire 2025 Innovation Guide). Recommend BDC for customers with no legacy BW to migrate incrementally, who want simplified commercial terms, or who anticipate AI/ML workloads alongside SAP analytics.
Q: When is the MDG → Datasphere → SAC sequence the right pattern?
This end-to-end sequence applies when: (1) poor master data quality is a primary cause of reporting inaccuracies (justifying MDG); (2) data from multiple systems must be integrated before reaching analysts (justifying Datasphere); and (3) business users need dashboards or planning on that integrated data (justifying SAC). Each layer must be independently justified — deploying all three when one or two would suffice adds cost without proportional benefit.
Summary
SAP BTP’s Data & Analytics domain is a layered architecture, not a menu of alternatives. SAP HANA Cloud provides the persistence layer; Datasphere provides governed integration and semantic modeling; SAC provides consumption and planning; and MDG provides master data governance as the quality foundation (SAP Datasphere product page; SAP Analytics Cloud product page). The integration sequence runs: MDG → (MDI distribution) → Datasphere → SAC, with S/4HANA Embedded Analytics as the right choice when reporting stays within the S/4HANA boundary.
Correct scoping requires answering three questions before selecting any tool: what is the measurable pain, who owns the data, and who holds the organizational mandate. Most project failures trace to seven patterns documented in §6. Addressing these at the requirements stage is the highest-leverage action a consultant can take on a Data & Analytics engagement.