Analytics Legends The knowledge platform for SAP Analytics
Guide

SAP BDC architecture, component by component

As of 2026-08-14

SAP BDC architecture is five components, and one of them is why the other four behave as a stack rather than a bundle. Datasphere supplies the semantics, a Databricks-managed lakehouse supplies open-format storage, Joule is the consumption surface, the Knowledge Graph links business entities across the estate, and the Catalog carries semantic types, lineage, data products and access rules across both storage sides. Remove the Catalog and BDC really is four separately governed products on one invoice — which is why every decision below routes back to it.

The five components, and which is load-bearing

Datasphere does what it always did — analytic models, hierarchies, currency conversion, push-down against HANA Cloud — with one change: it resolves its catalogue from BDC scope rather than a standalone tenant. The managed lakehouse provides Delta-format storage governed through Unity Catalog, reachable from Spark, MLflow or DBSQL. Joule consumes analytic models for business context and writes back through guarded actions. The Knowledge Graph links Customer, Material, Order and other core entities so Joule and Datasphere query an entity graph rather than each rebuilding one.

The Catalog turns those four into an architecture: the unified metadata layer carrying semantic types, lineage, data products and access rules across both storage planes, so a rule written once applies to what Joule surfaces and to what a Spark notebook reads.

This is also the common design failure. Teams defer the Catalog and the Knowledge Graph as configuration for later, reproducing pre-BDC fragmentation inside a BDC contract with the platform cost on top.

How the tiers stack

Read vertically, this is three tiers, not a flat set of products. At the bottom, lake storage spanning SAP application data, SAP Business Warehouse data and non-SAP third-party data — the last is explicit, and scoping semantic work around SAP sources alone leaves an agent blind to a real share of the estate.

In the middle, the semantic and governance layer SAP frames as six capabilities: semantics, knowledge graph, AI domain models, analytics and simulations, data products, and discovery and activation, with cost and lifecycle management, data governance, and security and trust wrapped around all six. The framing is generational: a warehouse coupled compute and storage, a lakehouse separated them, this layer adds the typed governed substrate an agent needs before it is trusted with a decision.

At the top sit the agents and packaged applications that consume it. Inside the compute tier, three runtimes sit side by side rather than ranked — HANA Cloud for in-memory sub-second analytics, Databricks for large-scale engineering and governed machine learning, Snowflake for elastic warehousing and cross-cloud sharing. Each carries its own monitoring, cost management and skills requirement.

Hot and cold: where a query should land

HANA Cloud on the Datasphere side is the hot tier: sub-second responses for interactive consumption and anything a user waits on. The managed Delta layer is the cold tier: historical depth, high-volume scans, and the feature engineering that precedes model training.

Cross-domain joins belong in Datasphere analytic models, because that is where semantic types, currency conversion and access rules live — a join performed elsewhere re-derives all three. Machine-learning feature engineering belongs in Databricks notebooks, where the tooling and the scale are.

Getting the partition wrong is not a performance problem first; it is a cost problem. A dashboard pointed at the cold tier will work, slowly, and keep consuming lakehouse compute on every refresh.

Where non-SAP data enters

BDC Connect supports four patterns, not one connector. Delta Sharing inbound subscribes to tables published by an external organisation and surfaces them as catalogue objects. Iceberg federation reads Apache Iceberg tables from object storage against any Iceberg catalogue implementation, so an existing lake becomes consumable without lift-and-shift. Snowflake federation pushes SQL down live, with compute cost landing on the Snowflake side. The fourth federates a Databricks workspace the customer runs on their own cloud account.

What makes this architectural rather than convenient is that federated objects are first-class catalogue citizens: access rules, lineage and data-product structure apply as they do to native objects, and the access rule fires at query-rewrite time.

The latency is not free, and the figure belongs in a design review: Iceberg federation through an external catalogue such as AWS Glue adds roughly 100 to 300 milliseconds of metadata lookup on top of the data scan. Invisible on a warm demo table; not at production concurrency.

Decision table: federate or replicate

Exploratory access, low query frequency, or a governance need to make a source visible in the catalogue. Federate — an agent occasionally grounding against a partner share does not justify a migration.

Anything latency-sensitive that a user waits on, such as an operational dashboard expected under two seconds. Replicate. Federation binds your query time to the source system's performance, and a cold-partition scan adds seconds, not milliseconds.

High-volume fact data, or many concurrent business-intelligence users on the same objects. Replicate the facts, federate the dimensions and slow-changing reference data; the practical threshold in the corpus sits around 100 gigabytes of fact data or roughly fifty concurrent users.

A source whose compute you do not control or do not want to pay for on every query. Replicate and price the storage — federation quietly moves cost onto the source platform's invoice, where the capacity-unit conversation never sees it.

One governance plane, or none

The architectural claim is that access control is defined once at catalogue level and reaches every consumer — SAC, Joule, a Spark notebook, a federated table. That claim is only as strong as its weakest entry point, and there are two known side doors.

The first is the federated source. Applying rules inside BDC while leaving the source system's own controls untouched means a user blocked in the catalogue can still query the Snowflake warehouse or the Iceberg lake with their own credentials.

The second is the agent. Once Joule agents consume the semantic layer, the consumption layer stops being a reporting artefact and becomes a policy object: naming, row-level security and currency logic have to be agent-safe, not merely correct for a human reading a chart. Wiring the semantic catalogue separately for agents and humans is the standard opening mistake, and hard to unwind once both are populated.

Which is why the first design question is not which components to switch on, but whether the customer has an agreed data ownership model at all. The Catalog enforces rules; it does not invent them.

What we cannot assert

We publish no architecture reference sized for a specific customer: SAP publishes no capacity guidance per component, so how the 128-unit tenant floor divides across the six competing workloads is a sizing exercise, not a documented split.

Frequently asked

What are the components of SAP BDC architecture?

Five: SAP Datasphere as the semantic layer, a Databricks-managed lakehouse as open-format storage, Joule as the AI consumption surface, the SAP Knowledge Graph as the entity layer, and the Catalog as the shared metadata and access-control plane spanning both storage sides. The Catalog is the integrative piece.

Is BDC a replacement for SAP Datasphere?

No — BDC contains Datasphere. Inside BDC, Datasphere behaves as before except that it resolves its catalogue from BDC scope rather than a standalone tenant. The real decision is not which product to buy but whether you buy the wiring between components or build it yourself.

Do I have to move Snowflake or Iceberg data into BDC?

No. BDC Connect federates external sources through four patterns — Delta Sharing inbound, Iceberg federation, Snowflake federation, and federation to an externally hosted Databricks workspace — and federated objects become first-class catalogue citizens. Replicate only where latency or query frequency makes federation expensive.

How many compute runtimes does the architecture have?

Three, positioned side by side rather than ranked: HANA Cloud for in-memory sub-second analytics, Databricks for Spark-scale engineering and machine learning, and Snowflake for elastic warehousing and cross-cloud sharing. Each adds its own monitoring, cost management and skills requirement.

What this page is built on

Read next