There are two broad implementation approaches: built-in semantic layers inside BI tools, or a separate semantic layer as an independent system.

The right choice depends on your organization’s priorities and constraints.

Quick win: built-in semantic layers

Many BI tools provide semantic layers.

• Pros: proven technology, mature features, lower effort, tight integration into BI workflows
• Cons: tool lock-in, limited reuse across BI tools and data science, harder to standardize across an ecosystem

Long-term solution: separate semantic layer

A separate layer provides more flexibility and reuse.

• Pros: reuse across BI tools, experimentation, and machine learning, more control, less vendor lock-in
• Cons: higher effort and risk, more integration work, stronger governance required

Options for a separate semantic layer

Catalogs with computation and serving, dedicated semantic tools (Cube, dbt-related tooling, AtScale), data cloud capabilities, or a custom build.

Concrete examples (so it’s not abstract)

• Cube / semantic API layer: define a curated set of metrics and dimensions once, then serve them consistently into multiple BI tools and apps through an API.

• Custom semantic store (3-layer pattern): maintain a metadata table that separates base metrics (from curated data), derived metrics (built on base), and KPIs (composed on top), including definitions, ownership, and lineage.

  

• Catalog + computation/serving: extend a catalog so users can discover a metric and compute it reliably (instead of treating the catalog as documentation only).

• Data cloud semantic features: use cloud-native semantic capabilities when you are highly standardized on one cloud, but treat it as a deliberate trade-off because it can increase lock-in.

Decision prompts (to avoid tool-first decisions)