There is a silent architectural crisis happening in modern data stacks. It’s not about storage costs or query speed—it’s about where the truth lives.
For the past decade, the default advice has been to "model your data in the BI tool." You ingest raw tables into Power BI, Tableau, or Looker, and then spend months writing complex logic to define what "Net Revenue" or "Active User" actually means.
This seems efficient at first. But it creates a dangerous dependency: your business logic becomes trapped in a proprietary language (DAX, VizQL, LookML) that no other system can read.
The Lock-in Reality Check
If you decided to switch BI tools tomorrow, could you migrate your metric definitions in a day? Or would you have to rewrite thousands of lines of proprietary code from scratch? If the answer is "rewrite," you are locked in.
The Problem: Logic Silos in a Multi-Consumer World
In the old world, the BI dashboard was the only consumer of data. It made sense to put the logic there.
But today, your data has many consumers:
- AI Agents: LLMs need context to answer questions like "Why did churn spike?"
- Operational Apps: Your CRM needs to show "Customer Health Score" to sales reps.
- Marketing Automation: Email tools need "Lifetime Value" segments.
If your definition of "Churn" is written in DAX inside a Power BI report, none of these other tools can see it. You are forced to duplicate that logic in SQL for the CRM, in Python for the data science team, and in Javascript for the product app.
This is the definition of Metric Divergence.
The Solution: The Headless Semantic Layer
The architectural fix is to decouple metrics definitions from visualization. This is known as the "Headless BI" or "Universal Semantic Layer" approach.
In this model, you define your metrics once—usually in SQL or a YAML-based modeling language—upstream of the BI tool.
Proprietary Approach
- • Logic lives in .pbix or .twb files
- • Only accessible via the BI interface
- • Migration requires full rewrite
- • AI agents cannot parse the logic
Headless Approach
- • Logic lives in Git (SQL/YAML)
- • Accessible via API / JDBC / SQL
- • BI tool becomes just a "viewer"
- • AI & Apps consume the same metric
Why This Matters for Procurement
When evaluating BI software, do not just ask "Can it make pretty charts?" Ask: "Does it force me to write logic that I can't take with me?"
Vendors love proprietary semantic layers because they are the ultimate retention mechanism. Once you have 500 measures defined in their language, you are never leaving.
Strategic Recommendation: Prioritize tools that can query an external semantic layer (like Cube, dbt Semantic Layer, or Malloy) or those that use standard SQL for definitions. If you must use a tool with a heavy proprietary layer, strictly limit its use to visualization-only logic (e.g., color formatting), not business logic (e.g., profit calculations).