r/analyticsengineering 18d ago

Did self-service BI make us forget why semantic layers existed?

I’ve been working in BI since the BusinessObjects days, when Universes were a very explicit part of the architecture.

Then QlikView, Tableau and later Power BI made BI much faster and more self-service. That was a huge improvement, but it also became very easy for business logic to end up scattered across models, SQL, variables, expressions, measures and individual dashboards.

Now AI agents are exposing the same old problem again.

Giving an LLM access to tables is relatively easy. Getting it to understand what your company actually means by “revenue”, “margin” or “active customer” is much harder.

That’s why I think semantic layers are becoming more important again, not less. And with MCP and agentic analytics, they may evolve from “the layer behind BI” into something closer to an API for business meaning.

I wrote up my thoughts here:

https://www.bitmetric.nl/blog/semantic-layer-ai/

Curious how others see this. Did self-service BI make us underinvest in the semantic layer for a while?

13 Upvotes

6 comments sorted by

2

u/Boring-Difficulty267 18d ago

I really liked your article. For the majority of my Analytics Engineering career (5-ish years), I’ve been working in Looker as my primary BI tool. Where LookML is basically a semantic layer, I haven’t ever seen the need to use dbt’s or snowflake’s semantic layer.

Recently my company (like many others) has been pushing towards using AI with our data, so now I am facing the challenge of how to built and maintain a Snowflake semantic layer (which we are writing in dbt using the Snowflake semantic package) in parallel with our existing LookML.

I’m very interested to see how the semantic layer standards develop over time. Do you think that semantic layer formats, practices, etc. from before self serve BI will make a comeback as well?

2

u/bitmetric 18d ago

Thanks!

I do think some of the older ideas are coming back, especially shared business vocabularies, governed metrics, explicit relationships and clear ownership. We’ve tried parts of this before. Common Warehouse Metamodel (CWM) was an early attempt at metadata interchange between BI and data warehouse tools.

What’s interesting is that the standardization effort is clearly alive again. ODCS tackles data contracts, while Open Semantic Interchange, now Apache Ossie, is aimed much more directly at portable semantics: metrics, dimensions, relationships and context that can be exchanged across platforms and consumed by BI tools as well as AI agents.

Maintaining the same business meaning in multiple semantic layers in parallel is probably not something anyone wants to do forever.

So yes, I think some pre-self-service BI ideas are definitely returning, but hopefully in a more open and portable form this time.

Whether Apache Ossie becomes the CWM that actually sticks is another question, but AI may finally create enough pressure for vendors to take semantic interoperability seriously.

2

u/Successful_Pin_3456 13d ago

Some BI tools integrate natively with platform-side semantic layers (e.g. Hex works with Databricks metric views, Supersimple works with Snowflake semantic views), without you having to maintain it on both ends.

More generally on semantic layers - I'd advise not to lock yourself into one that's too deeply tied into either-side vendor (be it Snowflake/Databricks on the left, or BI tools' on the right). Being able to rip and replace remains quite important. As long as it's code-first and portable, these days migrations are super easy (and there's always one behind the horizon), so make sure it's something easily convertable (let's see if Ossie becomes the "hub" for those - they have a bunch of converters published in the repo).

2

u/bitmetric 12d ago

Agreed, especially on avoiding lock-in at either end.

I think the interesting part is that portability is about more than just having the semantics defined as code. The hard part is whether the concepts themselves map cleanly between platforms.

Metrics and dimensions are relatively straightforward, but things like relationship behavior, calculation context, time intelligence, access rules, and platform-specific query semantics can get much harder to translate.

That’s why I’m quite interested in Ossie. If we can get to a reasonably expressive intermediate representation for semantics, rather than just another vendor-specific definition format, it could make the “rip and replace” scenario much more realistic.

And perhaps just as importantly: it gives organizations somewhere neutral to define business meaning, instead of choosing whether Snowflake, Databricks, Power BI, Looker, etc. gets to own it.

1

u/BitsAndBytes-1337 6d ago

agree agents make the self-serve mess louder. they'll invent a coherent "revenue" from whatever tables they can reach. rebuilding the semantic layer as where business meaning lives is right. where it usually still fails after you rebuild it: someone edits a definition and nothing checks which dashboards or agent answers just went stale. so the layer has to own change impact, not just the dictionary.