Analytics & BI Tools · Chapter 18 of 18
What actually interoperates
Every vendor claims to integrate with everything. Here is what the connections really are, and the one gap that undermines the whole story.
The previous chapter on the semantic layer described the architecture. This one is about whether the pieces actually fit together, because ‘supported’ covers two completely different experiences and the difference decides whether your governance project works.
Three mechanisms, and why they are not equivalent
Emulating the old analysis-server protocol. Several independent semantic layers present themselves as though they were a Microsoft analysis server, speaking DAX and MDX. This is the highest-fidelity option for that ecosystem because it reuses a mature protocol that already carries hierarchies, drill paths and pivot semantics — which is why an Excel PivotTable works against them natively. Its limit is obvious: it only helps in the Microsoft-shaped half of the world.
Exposing SQL or JDBC. Universal, and this is what most modern semantic layers do — some by speaking a database wire protocol directly. Every client that can query a database can query the layer.
But it is lossy in a specific way that matters: the BI tool usually receives a flat result set rather than a browsable model. There is no hierarchy to expand, no drill-through, no folder structure of measures to explore. An analyst can run a query someone wrote; they cannot wander around the model the way they can with a native one. That is a large difference in day-to-day use and it is invisible in a feature matrix.
Bespoke native connectors. The highest fidelity and the smallest coverage. One prominent semantic layer names about a dozen tools with first-class integration; everything else falls back to the generic path. Each connector is a separate engineering commitment by both parties, and either party can deprecate it.
The gap that undermines the whole story
The largest BI tool does not natively consume the largest warehouse's semantic views.
Both vendors have shipped a semantic layer. Both are excellent. They do not speak to each other at the semantic level, and joint customers ask for it constantly — there is a small industry of intermediate-layer products whose entire value proposition is bridging that specific gap.
Why it matters beyond the inconvenience: it means the promise — define the metric once, and every tool agrees — is currently unachievable for a very common pair of technologies. If your estate is that pair, you are choosing which side owns the definition, not avoiding the choice.
And the honest advice that follows: pick the semantic layer that matches where your consumption happens, not where your data happens. The definition has to live somewhere the people asking questions can reach without a translation layer.
The current state, layer by layer
| Semantic layer | Consumed natively by | Mechanism |
|---|---|---|
| The BI-native model | Its own tool, Excel, and any DAX/MDX client — the widest client surface in the market | A published analysis-server endpoint, read and write |
| A modelling-language layer (code-first, Git-versioned) | Its own tool natively; others through its API, awkwardly | Product API. Deliberately opinionated, which is the point and the friction |
| A transformation-project semantic layer | About a dozen named tools with first-class support; everything else generically | JDBC over a columnar wire protocol, plus GraphQL and a Python client |
| A standalone universal layer | Nearly everything | Analysis-server emulation and SQL — which is why these products exist at all |
| Warehouse-native semantic views | A growing set of cloud-native BI tools, and the warehouse's own assistant | A SQL function. Broad in principle, and the biggest single tool is missing |
What to ask before you commit
The question is never “does it integrate?” — every vendor says yes, and every vendor is telling the truth by their own definition. The useful questions are narrower:
- Can an analyst browse the model? Expand a hierarchy, see the available measures grouped sensibly, discover what exists without being told. Or does the connector return one flat table?
- Does drill-through work? Clicking a total and seeing what makes it up is the single most-used interaction in BI, and it is frequently the first thing lost in a generic connection.
- Can they build an ad-hoc view, or does every new question require someone to write a query? This determines whether you have self-service or a report factory.
- Does row-level security propagate? If the semantic layer enforces permissions and the BI tool connects with a service account, you have a single identity reaching everything — which is a security finding, not an integration detail.
- And who maintains the connector? A first-party integration and a community-maintained driver have very different lifespans.
Then test the exact pairing, with a real analyst doing real work, before committing. Not a demo with prepared data — an analyst answering a question they actually have. Half an hour of that tells you more than any amount of documentation, and being the person who insists on it is what experience sounds like in a procurement meeting.
Where this is going
Two developments are worth watching, and they point in the same direction.
The first is storing semantic definitions as ordinary database tables rather than in a proprietary format or a bespoke API — metrics, lineage and documentation readable by anything that reads SQL, with the database's existing security applying. The bet is that ‘readable by anything’ beats building N×M connectors, and it is the first serious attempt at a universal answer.
The second is that AI agents are becoming a first-class consumer, and they change the requirement. A human analyst can work around a lossy connection — they know the business and they can tell when a number looks wrong. An agent generating SQL against raw tables will invent joins, choose the wrong grain, and produce confidently wrong answers that nobody can check.
So the pressure for genuinely good semantic interoperability is coming from the AI side rather than from the BI side, and that is probably what finally resolves it. The honest framing to carry into an interview: the semantic layer stopped being a tidiness project the moment something started querying it that cannot tell when it is wrong.
Check yourself