
From the founder: This article is part of a LinkedIn series by Nabil Jallouli, Rollstack’s co-founder and CEO, on the future of BI and data teams. Read the original article on LinkedIn.
BI as we knew it is dead.
LLMs aren’t just adding a chat interface to BI. They’re redesigning the entire data stack.
BI and analytics have always had three main objectives:
- Define the standard for how metrics are viewed across an organization.
- Inform leadership, teams, and other stakeholders about the health and state of the business.
- Make it easy for the organization to make good and fast decisions.
Over the next few posts, I’ll share my perspective on the changes we’re seeing in the market across all three objectives, which players are best positioned to leverage technology to address these organizational needs, and which new players will emerge along the way.
Let’s start with the first objective:
1. Defining the standard for metrics
LLMs are making it cheaper and faster to write code and query data. As technical execution becomes more accessible, trusted business context becomes more valuable.
Because code generation is one of LLMs’ strongest use cases, data engineers—and increasingly analysts—can now build strong data foundations and data marts faster than ever.
The difficult work remains in building a correct and trusted data foundation: choosing the correct grain, joins, business logic, tests, and definitions.
The roles of data engineers and analysts are increasingly blurring. This trend began with dbt making production-grade data transformation more accessible to SQL-fluent analysts and business domain experts.
The role that will become increasingly important is that of the analytics engineer as a business-context architect.
They will spend less time producing SQL and more time translating business requirements into well-defined fact tables, dimension tables, and data marts, while defining their grain, ownership, tests, and semantics.
The real battle we are witnessing right now is over the semantic layer. These players are all trying to make themselves the one-stop shop for semantics:
- Traditional BI tools: Tableau , Power BI , Looker , etc.
- Data warehouses: Databricks , and Snowflake
- Transformation tools: dbt Labs
- Independent semantic-layer platforms: Cube, etc.
Reducing switching costs between BI tools is one reason for organizations to centralize this layer. But the larger reason is consistency: definitions need to remain the same across systems, dashboards, spreadsheets, applications, and now AI agents.
It is still unclear who will ultimately own this layer.
I personally believe data platforms such as Snowflake and Databricks are best positioned to house it because the data and compute already live there.
However, this transition will take time.
At large organizations, it will be messy. In the meantime, semantics will continue to be distributed across multiple platforms.
At fast-moving, midsized organizations, we are already seeing teams move their semantics out of the BI tool and into the data platform.
Open Semantic Interchange (OSI), now The Apache Software Foundation Ossie, is a great initiative for enabling a unified semantic model across platforms.
It will not decide what revenue or open pipeline should mean. But once an organization has agreed on those definitions, Ossie can help make them portable and consistent across the platforms and agents consuming them.
If widely adopted, it could create a common foundation that allows new analytics platforms and AI agents to be deployed much more quickly, without reconstructing an organization’s semantics from scratch.
This also means that data warehouses will continue moving up the stack—from their traditional role in data storage and querying into a more prominent position in analytics itself.
This helps explain why Snowflake is investing in Semantic Views and Databricks in Metric Views within Unity Catalog, bringing both platforms into territory historically owned by traditional BI tools.
It also means that traditional BI tools are on increasingly thin and fragile ground, especially when considering their architecture and slowness to deploy. Many of the features they carry made sense 10 years ago but may no longer be needed in today’s world. Adding a chat interface to a legacy platform may also not be the right solution.
Sometimes building for the new world is what it takes.
Connects to the tools you already use
All integrations