Datasphere is a component within BDC. SAP Business Data Cloud bundles four components — Datasphere (data management), SAP Analytics Cloud (BI and planning), SAP Databricks (AI/ML) and SAP Object Store (cost-efficient storage) — into a single subscription. BDC adds pre-built SAP data products and zero-copy data sharing (BDC Connect) on top of what Datasphere provides standalone. Going forward, SAP will not sell Datasphere and SAC separately; BDC is the unified offering. However, existing Datasphere investments carry forward into BDC — spaces can be cloned, models transfer, and user training is preserved. We design all Datasphere implementations BDC-forward so that the transition is licensing and data product activation, not a rebuild.

A space is an isolated container within Datasphere that has its own storage allocation, connections, security policies and set of data models. Spaces are how you organise data by domain, team or data layer — for example, a "Finance" space, a "Supply Chain" space, a "Raw Data" space and a "Semantic Models" space. The architecture decision is: how many spaces, how they relate and who owns each one. Get it wrong and you have permission confusion, cross-space dependency nightmares and storage that no one can account for. Our approach designs spaces around three principles: clear domain ownership (one team owns one space), explicit data flow direction (raw → transformed → semantic, not circular) and minimal cross-space sharing with governed handoff points. We formalise this in a space architecture document before connecting any source system.

Virtualise when: data is accessed infrequently, source system performance can handle the query load, data freshness is critical (always-current), and the source is HANA-based (best virtual performance). Replicate when: data is accessed frequently by many users, queries require complex joins across sources, historical snapshots are needed, or the source is non-HANA with limited query performance. The practical approach: start by virtualising everything, then selectively replicate assets where performance monitoring shows the virtual approach is too slow or where source-system load is unacceptable. Datasphere makes switching between virtual and replicated straightforward — it is not a permanent architectural decision. We monitor access patterns post-go-live and adjust the virtualisation/replication mix based on actual usage, not upfront assumptions.

Yes — open connectivity is a core Datasphere capability. Supported connections include: SAP HANA (cloud and on-premise), SAP S/4HANA and ECC (via ODP and CDS views), SAP BW/4HANA, Snowflake, Google BigQuery, Microsoft SQL Server, Amazon Redshift, Oracle, Teradata, Apache Kafka, MongoDB and generic ODBC/JDBC sources. Files (CSV, JSON, Excel) can be uploaded or accessed via cloud storage. Additionally, the Data Marketplace enables consumption of SAP and third-party data products without custom connector work. For organisations with a multi-platform data ecosystem, Datasphere's ability to federate across SAP and non-SAP sources with a single semantic layer is the primary architectural advantage — it eliminates the need to replicate everything into one system to achieve consistent analytics.

A focused first-phase implementation — space architecture, 2–3 source connections (typically S/4HANA and one non-SAP source), semantic model for a priority domain (Finance or Supply Chain) and SAC integration — runs 8–12 weeks. A broader multi-domain deployment covering 4–6 source systems, full semantic model across Finance, Supply Chain, Sales and HR, BW Bridge configuration and comprehensive governance setup typically runs 16–24 weeks. We always recommend starting with one domain: prove the value of federated, governed access with your finance team, then extend to other domains with the architecture already validated. The space architecture design phase (2–3 weeks) is non-negotiable and not compressible — it determines the success of everything that follows.