Industry Analysis

Is Business Intelligence Splitting?

A thesis has been circulating for the last two years: that business intelligence is splitting in two. On one side, a governed platform layer — a semantic layer, a catalog, a lakehouse — that holds the trusted definition of every metric. On the other, a thin, increasingly disposable consumer layer where people, and now agents, ask questions. The counter-argument is just as loud: that Microsoft Fabric, Databricks, and SAP Business Data Cloud are doing the opposite — re-consolidating storage, semantics, governance, and consumption into a single estate. Both stories are supported by real product moves. Architecture and buying teams keep being asked to pick a side, and the honest answer is that both are happening at once, on different axes. This essay separates those axes, weighs the evidence, and works through what it means for anyone building on SAP Datasphere, SAP Analytics Cloud, and Joule.

The question behind the question

When someone asks whether BI is splitting, they are rarely asking an architecture question. They are asking a buying question. Should we standardize on one vendor's full stack, or assemble best-of-breed pieces around an open semantic layer? Will the dashboard tool we license this year still matter in three? If agents become the primary interface, what exactly are we paying a BI vendor for? These are reasonable anxieties, and the market has not made them easier to resolve, because the vendors are sending contradictory signals on purpose.

It helps to be precise about what "BI" even means here, because the word covers at least three distinct things that are moving in different directions. There is the storage and compute layer — where the data physically sits and where queries execute. There is the semantic layer — where a metric like "net revenue" is defined once, with its joins, filters, and business rules, so that everyone gets the same number. And there is the consumption layer — dashboards, notebooks, embedded charts, natural-language interfaces, and increasingly autonomous agents. The "split" thesis and the "re-consolidation" thesis are not really in conflict because they are usually talking about different layers. The split is happening in consumption. The consolidation is happening in storage and, more contestably, in semantics.

So rather than asking the binary question, I find it more useful to hold two propositions at the same time and test each against what vendors have actually shipped. Proposition one: the consumption tier is fragmenting and commoditizing, and value is migrating down into the semantic and platform layers. Proposition two: a small number of platform vendors are absorbing the entire vertical stack — storage, semantics, governance, and consumption — into one commercial and technical envelope. The interesting question is not which is true. It is where each is true, and what that means for the decisions you have to make this year.

The split thesis: BI separating into a governed platform layer and a thin consumer layer A vertical diagram. A wide consumer layer at the top holding dashboards, notebooks, embedded analytics and AI agents is shown as thin and interchangeable. Below it a thick governed platform layer holds the semantic layer, catalog, governance and lakehouse storage. An arrow indicates value migrating downward from consumption into the platform. The "Split" Thesis: Platform Below, Consumers Above Value migrates down; the interface tier thins and commoditizes CONSUMER LAYER — thin, plural, increasingly disposable Dashboards SAC, Power BI, Tableau Notebooks Python, SQL, BI-as-code Embedded In-app analytics AI agents Joule, Copilot, Spotter value & trust move down GOVERNED PLATFORM LAYER — where the value concentrates Semantic Layer Metric definitions, joins, business rules "Net revenue" defined once, served everywhere Catalog & Governance Lineage, access control, classification Audit, versioning, ownership Lakehouse / Warehouse Storage & Compute Open table formats (Delta, Iceberg) · elastic query engines The data stays put; consumers come and go above it

The split thesis in one picture: a thinning, plural consumer tier sitting on a thickening governed platform tier, with value and trust migrating downward.

The case that BI is splitting

The strongest version of the split thesis rests on a structural observation about where the difficult, durable work lives. Building a chart is no longer hard. Defining "net revenue" correctly — with the right currency conversion, the right treatment of returns and rebates, the right fiscal calendar, applied consistently to a dashboard, a planning model, an exported spreadsheet, and an AI agent's answer — is still hard, and it is the part that gets organizations into trouble when it is wrong. The split thesis says: pull that hard, shared work out of the dashboard and into a dedicated semantic layer, and the dashboard becomes a commodity skin over it.

Three product movements give this argument real weight rather than leaving it as theory.

1. The semantic layer became a product category

For most of BI's history the semantic model lived inside the dashboard tool — BusinessObjects universes, Cognos frameworks, Power BI's tabular models, Looker's LookML. The defining shift of the last few years is that the semantic layer has been pulled out as a standalone, tool-agnostic product. dbt's Semantic Layer, powered by MetricFlow, lets you define metrics in version-controlled code and serve them to any downstream tool through an API; dbt Labs open-sourced MetricFlow under an Apache 2.0 license at its Coalesce 2025 conference in October 2025, an explicit bet that the semantic definition should be portable rather than locked to one vendor's renderer. AtScale open-sourced its Semantic Modeling Language (SML) in September 2024 as a YAML-based, multidimensional standard intended to be readable across platforms. Cube has been a headless, universal semantic layer since it was open-sourced in 2019; today the open-source Cube Core sits underneath Cube's commercial agentic BI platform and serves metrics chiefly through a Postgres-compatible SQL API, plus a REST API, so that BI tools, applications, and AI agents can all consume the same definitions. The common thread is the deliberate separation of "what a metric means" from "what draws the chart."

2. The data platforms grew their own metric layers

At the same time, the cloud data platforms decided that the semantic layer belonged next to the data rather than in the BI tool. Snowflake's Cortex Analyst translates natural-language questions into SQL against semantic models, and Snowflake promoted those models to semantic views — native, governed schema objects, generally available since June 2025, that standard SQL can query and that Cortex Agents and Snowflake Intelligence also draw on — a semantic layer that lives in the warehouse. Databricks added metric views to Unity Catalog so that a KPI is defined once in the catalog and consumed consistently across dashboards, Genie, and alerts; in April 2026 it made them generally available as part of Unity Catalog Business Semantics and began open-sourcing the core implementation in Apache Spark. Google opened up Looker's LookML semantic layer with BI connectors and an Open SQL Interface that exposes LookML models to any tool that speaks JDBC, and in April 2026 previewed a managed MCP server native to Looker so that agents can query it directly. Whether the semantic layer ends up in a neutral tool like dbt or Cube, or inside the platform like Snowflake and Databricks, the direction is the same: it is leaving the dashboard.

3. The interface tier is being commoditized by agents

The third force is the one executives feel most directly. Conversational and agentic interfaces are turning the dashboard from a destination into one option among several. Tableau renamed Einstein Copilot for Tableau to Tableau Agent and pairs it with Tableau Pulse, which proactively surfaces metric changes into Slack and email rather than waiting for someone to open a dashboard; at Tableau Conference in May 2026 it unveiled an agentic analytics platform spanning Tableau Cloud, Server, Desktop, and Next. Copilot in Power BI has been generally available since 2024, and Microsoft retires the older Q&A feature in December 2026 in its favor. ThoughtSpot first shipped its Spotter agent in November 2024 and in December 2025 surrounded it with a team of BI agents — SpotterModel, SpotterViz, and SpotterCode alongside Spotter 3. SAP's own answer is Joule and, rolling out in phases since October 2026, Joule Work, a single front door across SAP and non-SAP applications. When the question can be asked in plain language and answered by an agent grounded in a governed semantic layer, the specific dashboard tool matters less. That is the heart of the split: if the meaning lives below and the question is asked above, the middle — the proprietary visualization tool — is the part most exposed to commoditization.

🔻
The split thesis in one sentence: when metric definitions move into a shared semantic layer and questions are asked through interchangeable agents, the dashboard tool stops being where value lives — it becomes a rendering surface over a platform that holds the trust, the governance, and the meaning.

There is also a commercial logic that reinforces the split. "Headless" or "composable" BI — assembling a semantic layer, a query engine, and a lightweight front end from separate components — is attractive precisely because it resists lock-in. If the metric layer is portable, you can change the front end without re-implementing your business logic, and you can serve the same governed metrics to an embedded application, an internal dashboard, and an agent without maintaining three definitions. For organizations that have been burned by migrations, that portability is worth a great deal, and it is a genuine architectural argument for the layers separating.

The case that BI is re-consolidating

Now the other side, which is equally well evidenced. The re-consolidation thesis says the industry's actual money and momentum are flowing toward a handful of platforms that absorb storage, semantics, governance, and consumption into a single estate — and that the "best-of-breed semantic layer plus interchangeable front end" picture, while elegant, is not how most large enterprises are actually buying.

One lake to hold it all

Microsoft Fabric is the clearest exhibit. Its foundation, OneLake, is positioned as "a unified data lake for your whole organization," included automatically in every Fabric tenant, with the OneLake catalog as the single place to discover, manage, and govern the data in it. Storage, engineering, the warehouse, Power BI, and Copilot are sold as one fabric — the name is not subtle. SAP and Microsoft announced at Microsoft Ignite in November 2025 that SAP Business Data Cloud would share data with Fabric and OneLake, with general availability planned for the third quarter of 2026; SAP's BDC FAQ lists the integration as a public preview, and as of November 2026 no general-availability announcement has followed. The pitch is the opposite of composability: do not assemble pieces, adopt the estate.

The lakehouse vendors moved up the stack

Databricks tells a parallel story under the banner of what it now calls the Databricks Data + AI Platform (formerly the Data Intelligence Platform). It did not stop at storage and compute. Unity Catalog now carries governance, lineage, and the metric views described above; AI/BI dashboards and Genie — since June 2026 a family of AI coworkers led by Genie One, generally available alongside Genie Agents and Genie Code — are first-party experiences built on that same catalog. The strategy is vertical integration: the same vendor that holds your Delta tables also holds your governance, your metrics, and your natural-language interface. That is consolidation, not separation — even though, confusingly, the same metric views are part of what makes Databricks a credible semantic-layer platform for the split thesis too.

SAP's unification play

SAP's Business Data Cloud (BDC) is the same move expressed in SAP's terms. BDC is not a new product so much as a commercial and architectural unification: it bundles SAP Analytics Cloud and SAP Datasphere with SAP HANA Cloud and master-data capabilities (SAP Master Data Governance and, since 2026, SAP Reltio), brings in Databricks and Snowflake as partnered engines (SAP Databricks and SAP Snowflake), and ties consumption together under capacity-unit pricing. In July 2026 SAP also completed its acquisition of Dremio, which it is making the basis of an open, Apache Iceberg-based lakehouse in BDC. SAP reinforced the unification commercially: since January 1, 2026, SAC and SAP Datasphere are no longer eligible services for new BTPEA, CPEA, or pay-as-you-go subscriptions, SAP's pricing pages route new licenses through BDC core capacity measured in capacity units, and existing agreements run to the end of their term. That is a deliberate decision to sell the platform rather than the parts. BDC Connect extends the estate outward with zero-copy sharing of data products with external platforms — Databricks reached general availability in October 2025, Snowflake on May 4, 2026, and Google BigQuery in July 2026, while Microsoft Fabric is in public preview and Amazon Athena is planned for the first half of 2027. The framing matters: rather than letting your data scatter across best-of-breed tools, SAP's answer is to make its governed estate the center of gravity and reach out to the others.

The re-consolidation counter-thesis: three platforms absorbing the full stack Three columns, one each for Microsoft Fabric and OneLake, the Databricks Data + AI Platform, and SAP Business Data Cloud. Each column shows the same four absorbed layers stacked vertically — consumption, semantics, governance and catalog, and storage and compute — illustrating that each vendor is integrating the whole stack rather than separating it. The "Re-consolidation" Counter-thesis Each platform absorbs the full vertical stack into one estate Microsoft Fabric OneLake foundation Power BI + Copilot consumption Power BI models semantics OneLake catalog governance & discovery OneLake unified data lake "adopt the estate" Databricks Data + AI Platform AI/BI + Genie consumption UC metric views semantics Unity Catalog governance & lineage Delta Lakehouse storage & compute vertical integration SAP Business Data Cloud capacity-unit estate SAC + Joule consumption Datasphere models semantics Catalog + Data Products governance HANA Cloud + Databricks storage & compute BDC Connect reaches out Same shape three times: one vendor holds consumption, semantics, governance and storage together.

The counter-thesis: three platforms — Fabric, Databricks, and SAP BDC — each absorbing the same vertical stack rather than letting it separate into best-of-breed parts.

🧲
Why consolidation keeps winning the buying decision: integrated estates reduce the integration tax, give one throat to choke for governance and security, and amortize across a single commercial envelope. For a CIO answering to a board about data risk and AI readiness, "one governed platform" is an easier story to defend than "twelve best-of-breed components we wired together."

The semantic layer war is where the two theses collide

If you want to see the tension between splitting and consolidating play out in real time, watch the semantic layer. It is simultaneously the strongest evidence for the split — because it is being extracted into standalone products — and the prize each platform most wants to own, because whoever controls the metric definitions controls the trust. Both things are true, and the contradiction is the whole story.

The independents argue for neutrality. dbt's Semantic Layer and MetricFlow, AtScale's SML, and Cube all make the same wager: that your metric definitions are too important to lock inside any one vendor, and should sit in a portable layer that any tool or agent can call. Even that camp is consolidating: Fivetran completed its all-stock merger with dbt Labs on June 1, 2026, so the company behind the dbt Semantic Layer now also sells data ingestion. The platforms argue for proximity. Snowflake's semantic views and Cortex Analyst, Databricks' Unity Catalog metric views and Genie, and Google's Looker semantic layer with its Open SQL Interface all say the semantic layer should live next to the data and the governance, where it can be enforced rather than merely published. SAP makes the proximity argument inside its own world: Datasphere's analytic models are the semantic layer for the SAP estate, feeding SAC, planning, and Joule from one governed definition.

The semantic-layer landscape: neutral layers, platform-native layers, and an interoperability standard A landscape map with three zones. On the left, neutral standalone semantic layers: dbt Semantic Layer with MetricFlow, AtScale SML, and Cube. On the right, platform-native semantic layers: Snowflake semantic views with Cortex Analyst, Databricks Unity Catalog metric views, Looker's semantic layer, and SAP Datasphere models. Across the bottom, a wide band represents the Apache Ossie standard, formerly the Open Semantic Interchange, connecting both sides. The Semantic-Layer Landscape Neutral vs platform-native — bridged by an emerging interchange standard Neutral / Standalone "define once, serve any tool or agent" dbt Semantic Layer · MetricFlow metrics-as-code · open-sourced Apache 2.0 (2025) AtScale SML open-sourced YAML standard (Sept 2024) Cube open-source Cube Core · SQL & REST APIs Platform-native "define next to the data and the governance" Snowflake semantic views · Cortex Analyst native SQL object · NL-to-SQL Databricks Unity Catalog metric views GA Apr 2026 · feeds AI/BI & Genie Looker semantic layer · Open SQL Interface LookML over JDBC · managed MCP (preview) SAP Datasphere analytic models feeds SAC, planning & Joule Apache Ossie (formerly OSI) — vendor-neutral spec, launched Sept 2025 A shared format for metrics & dimensions, backed by 50+ organizations incl. Snowflake, Salesforce, Databricks, dbt Labs Apache 2.0; in the Apache Software Foundation Incubator since June 2026

The semantic layer is being fought over from both directions — and a vendor-neutral interchange standard has emerged to bridge them, which is itself evidence that no single owner has won.

The most interesting development cuts against simple narratives in both directions. In September 2025, a launch coalition of 17 companies convened by Snowflake — Salesforce (which owns Tableau), dbt Labs, Cube, Hex, Sigma, ThoughtSpot, Alation, Atlan, and Mistral AI among them — announced the Open Semantic Interchange (OSI), a vendor-neutral specification for how metrics, dimensions, and relationships are described so that they can be read consistently across tools and AI agents. The working group published the first version of the specification in an Apache 2.0-licensed repository in January 2026, by which time Databricks, AtScale, and Qlik had joined. On June 22, 2026, the project entered the Apache Software Foundation's Incubator under a new name, Apache Ossie, with the specification itself unchanged; by July the coalition had grown to more than 50 organizations, and reference converters already link it to dbt MetricFlow, Snowflake semantic models, and the Apache Polaris catalog. Ossie is fascinating precisely because it complicates both theses. It supports the split, by treating the semantic definition as a portable artifact independent of any renderer. But it also implies a kind of re-consolidation at the level of meaning — a single shared grammar for metrics, even if the products that store and serve them remain plural. The layer is separating from the tools, and at the same time converging on a common standard. That is not a contradiction the market has resolved; it is the live edge of it.

Where does this leave SAP? Datasphere is firmly on the platform-native side: its analytic models are designed to be the governed semantic layer for the SAP estate, and SAP's strategic value proposition is that this layer is enriched by the business semantics already present in S/4HANA — entities, hierarchies, and master data that a generic warehouse does not have for free. The open question I watch closely is interoperability. Ossie's ecosystem page lists nearly 80 organizations, Microsoft, Databricks, Oracle, and Salesforce among them; SAP itself is not listed, although Dremio, which SAP acquired in July 2026, is (checked in November 2026). As Ossie matures, the pressure on every platform vendor, SAP included, to speak a common semantic dialect will grow, because customers will not want to re-author "net revenue" three times for three tools. SAP's instinct is integration within its own estate — in 2026 it put the SAP Knowledge Graph at the core of its SAP Business AI Platform — while the market's drift is toward portable meaning across estates. How SAP reconciles those is, in my view, one of the more consequential roadmap questions of the next two years.

Agentic and embedded analytics: the interface dissolves into the workflow

Both theses agree on one thing: the standalone dashboard is losing its monopoly on consumption. They disagree on what replaces it. The split camp expects a plurality of interchangeable agents calling a shared semantic layer. The consolidation camp expects each platform's own agent, grounded in that platform's own catalog. The evidence so far supports a messier middle, where agents are proliferating but are only as trustworthy as the semantic layer beneath them.

Consider the trajectory. ThoughtSpot moved from a single Spotter agent in late 2024 to a coordinated team of BI agents announced in December 2025, and since July 2025 its generally available Agentic MCP Server has let other AI clients call Spotter's skills through the Model Context Protocol. Tableau's analytics is now framed as agents — Tableau Agent for conversational analysis and Tableau Pulse for proactive metric monitoring — pushed into the flow of work in Slack, email, Microsoft Teams, and Google Workspace rather than confined to a dashboard, with Tableau MCP servers generally available since May 2026. Copilot in Power BI now works in reports, as a standalone experience, and in the mobile apps. SAP's Joule spans SAP Business AI, and SAP's Autonomous Suite — more than 50 domain-specific Joule Assistants orchestrating more than 200 specialized agents, by SAP's May 2026 count — has been rolling out in phases since October 2026. The common pattern is that analytics is dissolving into the applications and conversations where work already happens — embedded, proactive, conversational — rather than living in a separate BI destination people remember to visit.

This is where the semantic layer stops being an abstraction and becomes a safety requirement. An agent that generates SQL or picks a metric is only as reliable as the definitions it is grounded in. Ungoverned, it will confidently return a "revenue" number assembled from the wrong table. Grounded in a governed semantic layer — Snowflake's semantic views, Databricks' metric views, Datasphere's analytic models — it inherits the joins, filters, and access controls that make the answer trustworthy and auditable. This is the deepest reason the value is migrating down the stack: in an agentic world, the semantic layer is not a convenience, it is the control point that decides whether an autonomous answer can be trusted. Whether that layer is neutral or platform-native, the organizations that invest in it will get usable agents, and the ones that skip it will get plausible-sounding fabrications at machine speed.

🧭
Practitioner's note: do not evaluate an analytics agent on its demo. Evaluate it on what it is grounded in. The right questions are: which semantic layer does it read? Are access controls enforced at that layer or bolted on after? Can it explain which definition produced a number, and trace it to source? An agent without a governed semantic layer behind it is a liability dressed as a feature.

The economics: FinOps quietly favors consolidation

Architecture arguments are often settled by the invoice. One reason the re-consolidation thesis has commercial wind behind it is that fragmented, consumption-priced platforms are hard to forecast, and finance teams have noticed. When compute is metered per query and a dozen tools and now a fleet of agents all hammer the same warehouse, costs become volatile and difficult to attribute. The discipline of FinOps — bringing engineering, finance, and the business together to manage variable cloud spend — has become a standing concern in the data platform conversation precisely because of this.

The pricing models tell the story. Microsoft's Power BI is licensed per user — Pro at fourteen dollars per user per month and Premium Per User at twenty-four dollars per user per month, paid yearly, since April 1, 2025 — while Fabric capacity is purchased as a reserved or pay-as-you-go pool, with an F64 capacity, for example, listed at about $8,410 per month pay-as-you-go and about $5,003 per month on a one-year reservation in Microsoft's Central US pricing. SAP's move to capacity-unit pricing under BDC, and its decision to route new SAC and Datasphere licenses through BDC core capacity from January 2026, is the same instinct: convert a sprawl of per-item charges into one capacity pool that can be planned and governed centrally. Consolidation is partly an architecture story, but it is also a procurement story — one bill, one capacity model, one place to apply FinOps discipline, is genuinely easier to manage than many.

This does not settle the debate, because composability has its own economic logic: a portable semantic layer lets you put cheap, even free, front ends in front of expensive governed data, and avoid paying premium per-seat prices for users who only consume. But it does explain why the people who control budgets often lean toward the integrated estate even when the architects in the room prefer best-of-breed. The split is intellectually attractive; consolidation is frequently easier to defend in a budget review. Any honest assessment has to weigh both.

Best-of-breed versus consolidation: a decision lens, not a dogma

After all of this, the practical question for most teams is not "which thesis is correct" but "for this decision, in this organization, which way should we lean." I do not believe there is a universal answer, and I am suspicious of anyone who offers one. What helps is a small set of factors that tend to indicate whether composing best-of-breed pieces or consolidating onto a platform will serve a given organization better.

Lean toward consolidation when your data already lives substantially in one vendor's gravity well, when your governance and compliance obligations make "one auditable estate" worth a premium, when your team is small relative to the integration burden, and when predictable, plannable cost matters more than squeezing out the last efficiency. Lean toward composable, best-of-breed when avoiding lock-in is a first-order strategic concern, when you have genuinely heterogeneous data that no single platform can claim, when you have the engineering maturity to own the integration, and when a portable semantic layer would let you serve many surfaces — embedded apps, internal dashboards, agents — from one definition without re-implementing it.

A decision lens for choosing between composable best-of-breed and platform consolidation A two-column comparison. The left column lists conditions that favor platform consolidation: data concentrated in one ecosystem, heavy compliance needs, a small team relative to integration burden, and a need for predictable cost. The right column lists conditions that favor composable best-of-breed: lock-in avoidance as a priority, genuinely heterogeneous data, high engineering maturity, and many consumption surfaces to serve from one semantic definition. A central band reminds the reader that the semantic layer is the hinge either way. A Decision Lens: Compose or Consolidate? Lean by your conditions, not by the loudest narrative Lean to Consolidate Data already in one ecosystem most sources sit in one vendor's gravity well Heavy compliance & audit needs "one auditable estate" is worth a premium Small team vs integration burden fewer moving parts to operate and secure Predictable cost matters most one capacity pool, easier FinOps discipline Lean to Compose Lock-in avoidance is strategic portability ranks above integration ease Genuinely heterogeneous data no single platform can honestly claim it all High engineering maturity you can own the integration responsibly Many surfaces, one definition apps, dashboards & agents from one layer Either way, the hinge is the same: invest in a governed semantic layer first. It is what makes the front end interchangeable and the agents trustworthy.

A decision lens rather than a verdict: the conditions that should tip a given choice toward consolidation or composition — with the semantic layer as the constant.

Notice the band across the bottom of that lens. Whichever way you lean, the same investment pays off: a governed semantic layer. If you consolidate, it is the part of the platform you must take most seriously, because it is what lets you swap or add consumption surfaces without re-litigating every metric. If you compose, it is the spine that holds the assembly together and keeps the pieces honest. The semantic layer is the one decision that survives a change of mind about everything else, which is exactly why it is worth getting right before anyone argues about tools.

What this means for SAP Datasphere, SAC, and Joule

For organizations whose center of gravity is SAP, these two forces resolve into a fairly clear set of implications — provided you read SAP's recent moves as the consolidation play they plainly are, while staying honest about the splitting pressures that will not respect any vendor's boundaries.

SAP Business Data Cloud positioning: a consolidated SAP estate that reaches out to external platforms A hub-and-spoke diagram. At the center, SAP Business Data Cloud holds three stacked layers: a consumption layer with SAC, planning and Joule; a semantic layer of Datasphere analytic models enriched by S/4HANA business semantics; and a foundation layer of HANA Cloud, master data and partnered Databricks and Snowflake engines. Around the center, BDC Connect spokes reach out with zero-copy sharing to Databricks, Snowflake and Google BigQuery, each generally available, while a separate note marks the Microsoft Fabric and OneLake integration, in public preview. SAP BDC Positioning: Consolidate the Center, Reach the Edges One governed SAP estate, with BDC Connect sharing data with external platforms Databricks GA Oct 2025 Snowflake GA May 4, 2026 Google BigQuery GA July 2026 BDC Connect · zero-copy SAP Business Data Cloud — one capacity-unit estate Consumption — SAC · Planning · Joule (NL front door) interchangeable surfaces over the governed layer below Semantic — Datasphere analytic models enriched by S/4HANA business semantics — the SAP differentiator Foundation — HANA Cloud · Master Data · Databricks & Snowflake (partnered) storage, compute and the data-science engine Catalog, data products, lineage and access control wrap all three layers. Microsoft Fabric / OneLake — public preview (Nov 2026)

SAP's positioning in one frame: consolidate the SAP estate around a Datasphere semantic layer, and use BDC Connect to share data products — rather than copy them — with Databricks, Snowflake, BigQuery, and, in public preview, Microsoft Fabric.

Datasphere is SAP's semantic layer — treat it as one, not as a warehouse

The most consequential mental shift is to stop thinking of Datasphere as "SAP's cloud data warehouse" and start treating its analytic models as the governed semantic layer for the SAP estate. In the architecture that BDC implies, every consumption surface — SAC stories, planning, Joule — should query Datasphere's models rather than reaching into raw tables. SAP's genuine differentiation here is not generic warehousing, where it competes with everyone; it is that this semantic layer can carry the business semantics already present in S/4HANA, the entities and hierarchies and master data that a neutral lakehouse does not get for free. If you are building on SAP and you let modeling logic sprawl back into individual stories, you are forfeiting the one advantage the platform gives you.

SAC is a consumption surface among several — and that is fine

The splitting pressure says the dashboard tool is becoming interchangeable, and SAP's own strategy partly concedes this by routing consumption through Joule and by making BDC, not SAC, the unit of sale. The healthy interpretation is not that SAC is diminished but that its job is clarified: it is the native SAP surface for exploration, storytelling, and — crucially — planning, which remains a genuinely differentiated capability that pure BI tools do not have. SAC does not need to be the only place SAP data is consumed; through BDC Connect and the broader estate, the same governed semantics can surface in other tools. Treating SAC as "the SAP-native consumption surface, especially for planning" rather than "the one dashboard to rule them all" matches where the market is going.

Joule is the agentic front door — its trustworthiness is a Datasphere problem

Joule is SAP's answer to the agentic consumption shift, with Joule Work as the front door across SAP and non-SAP applications, rolling out in phases since October 2026. Everything in the agentic section applies to it directly: Joule will be exactly as trustworthy as the semantic layer it is grounded in. That makes the quality, completeness, and governance of your Datasphere models not a back-office concern but the thing that determines whether business users can trust what Joule tells them. SAP's TechEd 2026 roadmap widens that grounding — customer-specific SAP Knowledge Graph context for Joule and BDC data products inside Joule Studio are both planned for general availability in Q1 2027 — which makes model and data-product quality matter more, not less. Organizations that invest in clean, governed analytic models will get a useful Joule; those that point it at ungoverned data will get confident, plausible, and wrong answers. The agentic front door does not reduce the importance of the semantic layer — it raises the stakes on it.

The open question: portability across estates

The honest tension for SAP-centric architectures is the same one the whole industry faces, sharpened. SAP's strategy is integration within its estate; the market's drift, embodied by Apache Ossie (the former Open Semantic Interchange), is toward portable meaning across estates. Most large enterprises will not be all-SAP, and they will increasingly resent re-authoring the same metric for SAP, for Fabric, and for Databricks. The strategic question to put to SAP — and to your own architecture — is how the governed semantics in Datasphere will interoperate with the rest of the data estate as common standards mature. BDC Connect already answers part of this on the data-access axis, with bidirectional, zero-copy sharing with Databricks, Snowflake, and BigQuery, and the Dremio acquisition brings Apache Iceberg and a catalog built on Apache Polaris into SAP's own stack — Polaris integration being one of the proposals on Ossie's roadmap. The semantic axis is the one still being written.

🟢
For SAP-centric teams, the through-line: consolidate onto BDC where it serves you — the integrated estate, the capacity model, the S/4HANA-aware semantics — but treat Datasphere's analytic models as a first-class, portable-in-spirit semantic layer rather than a private warehouse. That posture lets you benefit from consolidation today without being stranded if the splitting forces, and the interchange standards, win the longer game.

So — is business intelligence splitting?

Yes, and no, and the "and no" is the part most commentary gets wrong. Consumption is genuinely splitting and commoditizing: the dashboard is losing its monopoly to notebooks, embedded analytics, and a growing fleet of agents, and value is migrating down into the layers that hold meaning and trust. At the same time, storage and platform are genuinely re-consolidating: Microsoft Fabric, Databricks, and SAP Business Data Cloud are each absorbing the vertical stack into one estate, and the buying behavior of large enterprises, reinforced by FinOps pressure, keeps rewarding that. These are not competing predictions about the same thing. They are accurate descriptions of different layers moving in opposite directions at the same moment.

The semantic layer is where the two forces meet, and its trajectory is the most telling signal of all. It is being extracted into neutral products and simultaneously pulled into every platform's core — and then, with Apache Ossie, beginning to converge on a shared grammar that, under Apache governance, belongs to no single vendor. The layer is separating from the tools and unifying around a standard at the same time. If you want one prediction to organize around, it is this: the semantic layer is becoming the center of gravity of the entire stack, and the contest of the next few years is less about who owns the dashboard than about who owns — or whether anyone owns — the definition of a metric.

For practitioners, that resolves into advice that is almost boringly stable across both theses. Invest first in a governed semantic layer; for SAP estates, that means taking Datasphere's analytic models seriously as the semantic spine, not as a warehouse. Treat the consumption tier — SAC, Joule, and whatever agents follow — as important but interchangeable surfaces over that spine. Choose consolidation or composition by your own conditions rather than by the loudest narrative, knowing the semantic layer is the decision that survives either way. The question "is BI splitting?" is the wrong one to optimize for. The question that actually pays off is "where does the meaning live, and how well is it governed?" Get that right and you are resilient whichever way the rest of the market breaks.

Sources and further reading

Attribution and sources: This essay is independent editorial analysis. SAP capabilities, release timing, and packaging reflect SAP's public communications and the author's advisory experience as of November 2026; non-SAP product claims are drawn from the vendors' own announcements and documentation as cited above. Roadmap dates and capability scopes are subject to change and should be verified against official vendor communications before high-stakes decisions. This content is not official SAP, Microsoft, Databricks, Snowflake, Google, Salesforce, Fivetran, dbt Labs, AtScale, Cube, ThoughtSpot, or Apache Software Foundation documentation.