When Does a Semantic Layer Make Sense?

The value of a semantic layer and assessing the need in your data infrastructure.

The Challenges With Technical Infrastructure in a Cost Conscious Market

Why is it that many technical concepts in the data space seem to cause more noise than clarity for a business? In 2025, trying to justify anything in data with long timelines or not being absolutely necessary is seen as a waste to executives.

For example, setting a timeline of 2-3 months to build a robust data mart for a company’s sales pipeline seems ludicrous to leadership. Hell, even taking 4 weeks to refine digital integrations and set up some basic dashboards for tracking a small software company’s digital customer journey is at risk of blowing the budget these days.

With the market as tight as it is (and trust me, running a consultancy full time I’m seeing this first hand), simplicity and consolidation with a company’s data infrastructure are top of mind.

I recently went through a sales experience that got my gears turning. We were in talks with a $50M ARR SaaS company that leverages Google Cloud Platform and the Looker BI suite. We had several discovery sessions; what we uncovered was this company’s inability to leverage their semantic layer (LookML) correctly to best communicate insights to the business.

This experience inspired a LinkedIn post (which then inspired this issue) shortly after it happened. See below.

I’ll get into more of the details of my experience in a bit. My goal with this issue is to go over the purpose of the semantic layer and a brief history and justify why it can be a major driver of efficiency, data governance, and self-service enablement for your company’s bottom line growth.

I’ll also go over when a semantic layer either does or does not make sense for a given company’s situation.

Purpose & A Brief History of the Semantic Layer

A semantic layer is a layer of code that defines metrics and fields aligned to how the business defines them. The purpose of a semantic layer is to enable a business user with common terminology and logic for the data they use to make decisions, while lightening the technical burden for them. In turn, the semantic layer makes a company’s data easier to explore, analyze, and query for the end user. It governs the fields, tables, and code logic used so end business users know they are leveraging the data in a company-wide agreed upon way.

A Great Metaphor

Let’s back away from the technical jargon for a second and use a metaphor. You can think of a data warehouse or data mart as an organized grocery store. The heavy lifting of boxes and neat placement of items is done in the data warehouse. However, when you’re at the store, sometimes you still need help finding things on the shelves. A detail-oriented store assistant can help you find the items you’re looking for. You can think of the semantic layer as a high quality store assistant. They make the user experience better and guarantee you’ll find what you’re looking for.

Now for a bit of history. Airbyte.com already did a fantastic job covering the history of the semantic layer. However, I’ll touch on it here concisely.

In 1991, SAP Business Objects (BO) patented the semantic layer. Since then, the semantic layer has been seen as part of OLAP Cubes (SSAS), Jinja templates using dbt, in BI tools themselves (Looker’s LookML), and Modern Semantic Layer tools like Cube.js.

Interestingly, Power BI and Tableau, even without a language like LookML, also technically have a semantic layer. You can define data model relationships and metric logics within the tool itself, but instead of being strictly code based it’s more GUI based.

All to say, the semantic layer is not a new concept. Next we’ll cover some of the challenges with the semantic layer before getting into its benefits.

The Challenges with the Semantic Layer - A Real Client Story

A Messy Looker Environment

Back to the story about my client, I figured it’d be an organic way to reveal some challenges with the semantic layer rather than just listing them out.

This mid-sized software company had a robust data team (a manager, analytics engineer, and analyst). However, we gathered that no analyst or engineer on their team was leveraging Looker’s semantic layer well. To be fair, this is a common complaint of Looker. Its LookML layer of code is so powerful, complex, and robust, it’s easy to overlook how to turn it into a profit center of insights and efficiency.

What does “leveraging it well” really mean? I’m going to try to stay tool agnostic here, but forgive me if I fall into “Looker speak”. At the end of the day, all data models should have been defined in LookML. For each business department and respective process, there is a place in Looker to build the respective LookML data model.

They had none of that. Furthermore, it was apparent that they didn’t do a good job managing their LookML views (you can think of a LookML view as a semantically defined table from the data warehouse). Dimensions and measures were poorly labeled with little or no descriptions. In turn, this added confusion to end users looking to explore data using Looker because they won’t know what fields are correct.

How To Translate the Semantic Layer for Execs

During discovery, I only interacted with the VP of Revenue Operations. A surprisingly technical sales exec, he had a good grasp on data pipeline and warehousing concepts, and was a Tableau user himself. However, the area he lacked education in was the semantic layer. In turn, this made communicating the solution difficult. We had a series of three discovery/proposal meetings. Since his data team was well equipped in data engineering and modeling, I baselined by asking where he thought they needed me.

The VP expressed that his data team lacked the data visualization and communication know-how to build reports that actually drive up sales. This fed directly into his discontent with their Looker BI ecosystem.

The business had a bad taste in their mouth for Looker’s self-service BI feature known as an Explore. Stakeholders felt restricted and confused with the fields available to use in these Looker Explores. This is a direct symptom of poorly built and maintained LookML models.

Due to the poorly labeled dimensions and measures, users weren’t certain of where to go or what data points to use for their exploration. Furthermore, many Looker Explores were either outdated or incorrectly defined data models which led to wrong numbers. This further reduced trust.

The taste was so bad for this VP, that his thought was to leave Looker alone entirely. I tried to explain the advantages of building in the semantic layer of Looker (LookML). I stated if we leverage LookML, we’d be able to set the foundation for the data model that aligns to the business in one place. Furthermore, this enhances data governance to build it all centrally in LookML. He just stared at me, puzzled.

The VP said, “My team is extremely capable in data warehousing and modeling. Every piece of business logic that we’ve defined thus far has been in our data warehouse models. I don’t want to have you go and build more code in Looker. It’d be too much to maintain.”

You have to respect this business exec’s awareness for code maintenance and general grasp of data engineering. His thought was that their data warehouse’s data marts would serve as the definitive location for their business logic across all data models, dimensions, and metrics.

Essentially, in an ideal world he wanted to just connect the data mart tables directly to either Google Sheets, Excel or Looker Studio and do exploratory analysis / self-service that way. This would bypass the semantic layer in LookML. However, I acknowledged his thought process and then pushed back a little.

In the first two discovery calls, I stumbled around using technical jargon. I also tried explaining to him what a semantic layer was respective of their data architecture diagram. News flash: this didn’t work.

Third time's a charm. Whenever a conversation gets too technical with a business stakeholder, use metaphors. From there, I kicked off the metaphor about the semantic layer as a store assistant at a grocery store that I mentioned in the beginning. One of my former employer’s engineering team had a motto - simplify, align, and win. Not only when you’re coding, but when communicating to execs this is everything. Metaphors do just that and it worked.

The Benefits of the Semantic Layer

Pulling from my client situation, they’d benefit from the semantic layer for two main reasons.

1. Serves as a centralized place for their business metrics and data model logics

   1. This sounds the data governance bell. Rather than having all their metrics in the data warehouse layer, the semantic layer cleanly labels and describes each metric with an agreed upon name and description. All end users are on the same page.

   2. Especially considering they use the Looker BI Suite, their LookML semantic layer will integrate across all their data exploration tooling in the Google Cloud BI suite.

2. Faster metric creation and ease of maintenance if the business has an evolving list of KPIs to track

   1. This client had an expanding list of metrics and KPIs. Bringing in a consultant to enable their Looker BI Suite unlocks a lot of possibilities for other metrics they hadn’t thought about until now.

   2. Rather than having to knock on a data engineer’s door to update a given metric in the data warehouse layer, an analyst can swiftly update the metric in LookML and publish it to the end user faster.

   
   

Does a Semantic Layer Make Sense For Your Company?

To be totally transparent, when I first started writing this article, my mission was to prove why the semantic layer is always necessary in a company’s data infrastructure. Since I am a Looker developer by trade, I am biased towards having a semantic layer in BI & analytics.

However, after attending one of Joe Reis’s Data Therapy sessions to rant about this very experience, I’ve gotten a new perspective from a data leader on that call (who I’ll keep anonymous). They surfaced a technique that qualifies if a client is in need of a semantic layer or should do without it.

1. Does this client have a large or small list of KPIs to manage?

2. Do they plan on constantly evolving their KPIs and metrics over time?

   
   

When It Makes Sense

If the answer to question 1 is large and 2 is yes, the value of the semantic layer is clearly there.

The benefits align with the benefits I saw for my client. Based on the discussion I had in this therapy session, having a large number of KPIs causes metric explosion in the data mart layer. If there are a large number of metrics, chances are there is constant evolution of them too. This can become exhausting to maintain in physical tables for a data engineering team.

In this scenario, the semantic layer lessens the burden of metric add-ons and changes by enabling analysts to add, update, and evolve a company’s list of KPIs/metrics easily. It gives them full control to tailor the logic and align labels/definitions where end users are consuming the data.

I’ve seen this value play out time and again in my 7 year data career. Anytime a metric needs changing in the data warehouse/mart layer, the analyst has to inconveniently bother a data engineer to update the metric and logic. The semantic layer allows an analyst to act swiftly for the business’s additional and changing needs, without disrupting the workflow of data engineers.

When It Doesn’t Make Sense

On the contrary, if you answered small to question 1 and 2 was no, a semantic layer may not be of value to your team. The increase in maintainability and speed a semantic layer brings may not be necessary for a company that only cares about 5-10 KPIs.

Furthermore, smaller data teams don’t usually have to worry about the divide between the data engineering and BI team. An analyst on a smaller team is probably doing a little bit of everything from data engineering to BI and analytics. Less hoops to jump through structurally could make a semantic layer not as useful, and more likely than not leads to more code overhead.

Conclusion

So there you have it, the semantic layer can be a supercharger for structured data teams that have an ever-expanding list of business KPIs and metrics to maintain. For smaller data teams with only a select few KPIs to report on, it may not make sense.

However, I’d wager to guess that the majority of SaaS companies have an expanding list of KPIs to track. Once a foundational data reporting practice is built, the sky becomes the limit. Stakeholders will surely be asking for more and more. I’m here to encourage you to invest in building a semantic layer if that’s the case. Furthermore, what software company isn’t trying to scale?

Invest the time in building a semantic layer now. Your stakeholders will be well equipped to explore their data accurately and consistently, driving up profit and saving everyone oodles of time.

If you’re interested in discussing a semantic layer or building one out and if it could drive profit and efficiency for your team, we’d be happy to help. Feel free to book your initial free consultation here.