This is often a conversation we find ourselves having with technology or data engineering teams at organizations that are struggling to achieve the outcomes they expect from AI, or whose data is not sufficiently reliable for key decision-making. With the rise of AI‑enabled interactions that automatically create data products on the fly from conversational prompts, many organizations are starting down this route and then wonder why the projects just keep iterating.
The conversation often starts something like this:
“Why build complicated data models when tools can just generate the data products dynamically?”
Sometimes, it even morphs into:
“We don’t need all those complicated layers anymore…”
But no matter where conversations start, they eventually turn to the most fundamental point, which ultimately determines the final level of success.
The more deterministic and well‑defined your data is, the more reliable your AI outcomes will be.
AI tools are incredibly good at generating queries, building analyses, and even assembling data products from natural language interactions. But they still depend on something fundamental. They depend on well‑structured, well‑defined data.
In practice, it typically looks like this:
| Raw Data Layer | Presentation Layer |
|---|---|
| Source system data is ingested largely as‑is into the warehouse with minimal normalization or integration. |
Business logic, joins, aggregations, and metric definitions are implemented inside as views, semantic layers, notebooks, or AI‑generated queries. |
At first, this seems to work. Teams can create and deploy views on top of the data. Consumption applications can start accessing the transformed and merged data they could not before, and dashboards can iterate quickly. However, over time, the presentation layer quietly becomes responsible for:
Which means the presentation layer slowly becomes the actual data warehouse, just without the governance or structure.
In organizations where the primary outcome is business-facing analytics dashboards and scorecards, this often results in what we have come to call the "magical one-layer architecture"!
A BI tool is directly connected to each raw data source, and teams immediately start building dashboards. Business logic, calculations, and transformations all iterate within the dashboard.
No formal modeling. No structured layers. Just connect the tool and start building.
Again, for a while, it works! However, dozens of dashboards later, you have hundreds of slightly different measures, transformation logic scattered across multiple reports, and nobody is entirely sure why the numbers don’t quite match anymore.
The architecture hasn’t disappeared. It has simply been rebuilt by accident multiple times inside your BI tool!
A typical implementation looks like this:
|
Raw Data Layer (aka Bronze) |
Transformation Layer (aka Silver) | Consolidation Later (aka Gold) | Presentation Layer (aka Platinum) |
|
Raw capture of source data with full lineage and minimal transformation. |
Data from each source is standardized to the target object models and data standards. Also, optionally quality checked per source. | Data is matched (entity recognition) and merged from across the different standardized source datasets to create the final target data objects/ |
Curated data products designed to answer specific individual business value add functions or answer targeted business questions often recombing data across multiple logical data objects. |
Each layer performs a clear role in preparing data for the next stage.
The key advantage is that integration and business logic are defined once and implemented within a specific point in the architecture. This keeps analytics environments consistent, scalable, and easier to manage as they grow.
Bonus. Wondering how to design your logical models for gold? Try reading our view on Subject-based Data Modelling.
The tools we use to interact with data are evolving rapidly. Conversational analytics, AI‑generated queries, and automated data products are becoming normal.
But they rely on something critical. They rely on deterministic data structures.
If the underlying models are inconsistent or loosely defined, AI doesn’t resolve the ambiguity. It amplifies it. Which is why the principle i mentioned above becomes increasingly important:
The more deterministic and well‑defined your data is, the more reliable your AI outcomes will be.
If the answer to ANY of the following questions is YES, we would always recommend that you move forward with a four‑layer architecture. Don’t shortcut it. Don’t defer it for later. Just start right.
Will more than one team rely on the same data or metrics?
Do you expect the analytics environment to grow significantly over time?
Are the numbers going to be used to make financial, operational, or strategic decisions?
Will different teams build their own dashboards, or will they consume the same data for different functions?
Do you have multiple data sources that must be combined to form a complete record or universe?
Do you have risk, finance, or regulatory functions that need to roll up data across different business lines?
Do different business units currently define similar data differently?
Are you planning to introduce AI‑driven analytics or conversational data tools?
Do you expect to integrate external data providers or third‑party datasets? Would inconsistent numbers between dashboards create operational or credibility problems?
If you’re designing a new data platform — or trying to untangle an existing warehouse that has gradually accumulated complexity — the architectural decisions you make early will determine how well your environment scales and the reliability of your data-driven business decisions.
Medallion architectures don't have to be complicated, and they work! Our practical “data management first” approach focuses on defining the meaning, structure, and relationships of data before focusing on downstream consumption. When done right, this enables warehouse automation, simplifies reporting, and ensures governance. All of which in turn accelerate the delivery of trusted data, reliable analytics, improved AI outcomes, and improved risk management.
To find out more about our practical data‑management‑first approach for improving business outcomes with better data use the contact form below.