This is a conversation I find myself having frequently with technology groups — especially with the rise of AI‑enabled interactions that can generate data products from conversational prompts, and with organizations adopting modern analytics for the first time.
Sometimes the conversation starts with a question.
“Why build complicated data models when tools can just generate the data products dynamically?”
Then occasionally it's just delivered as a fact.
“We don’t need all those complicated layers anymore…”
My response is usually fairly direct.
“With a bit of discipline, it doesn’t need to be complicated at all — and when it’s done properly, it actually makes the entire platform far simpler to manage.
Modern data platforms are evolving quickly, especially with the rise of AI‑driven analytics and conversational data access. As tools become more capable of generating queries and automatically assembling analyses, many organizations are questioning whether traditional structured data architectures are still necessary.
At first glance, removing layers from the architecture can look like simplification. But in practice, the opposite often happens.
Two‑layer architectures rarely fail immediately. They fail gradually over time.
The irony is that architectures trying to remove structure often end up creating far more complexity, just hidden in different places. In an AI‑driven analytics world, this matters even more.
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, creating analyses, and even assembling data products from natural language interactions, but they still depend on something fundamental.
They depend on well‑structured, well‑defined, quality‑controlled data.
If the underlying data structures are inconsistent, loosely defined, or dependent on transformation logic scattered across dashboards and semantic layers, AI doesn’t magically solve the problem; it simply produces incorrect answers faster.
In other words, removing structure from your data architecture doesn’t eliminate complexity; it just pushes it into the least governed part of the stack.
A common pattern emerging in modern two‑layer data architecture designs looks something like this:
A pattern I increasingly see looks something like this:
| Raw Data Layer | Presentation Layer |
|---|---|
|
Data is ingested from operational systems and stored in a warehouse largely as it arrives. |
Business logic, joins, and calculations are implemented in the presentation layer. |
|
Tables typically resemble the structure of the source systems. |
Often implemented inside BI tools, semantic models, notebooks, or AI‑generated queries. |
|
Only minimal cleaning or normalization is applied. |
Each consumer assembles the data they need at query time. |
The pitch for this architecture is always the same:
And for a while, that’s actually true.
When you have a handful of dashboards and a small analytics team, restructuring data at the presentation layer can work surprisingly well.
The problem is that this architecture doesn’t break immediately. It breaks slowly.
The first problem that appears is a combination of logic duplication and semantic drift.
Each dashboard or analysis begins implementing its own joins, filters, and calculations. What started as a single metric definition becomes slightly different in multiple reports.
Revenue might be calculated one way in the finance dashboard and slightly differently in the sales pipeline model.
At first, these differences are small and easy to ignore. But over time, they accumulate into something more fundamental: the same metric name begins to represent slightly different logic, intent, and business meaning depending on where it is used.
In other words, the organization ends up with multiple interpretations of the same concept masquerading behind the same name.
Over time, organizations start asking questions like:
The second problem is that not all analytics can rely on simple live queries.
Many business questions require clean, complete, and consistent datasets that represent a specific interpretation of the business. Producing these datasets often requires more than just joins and filters, it may involve record matching, survivorship logic, deduplication, or selecting fields based on the data's live content.
When this logic exists only inside ad‑hoc data pipelines, queries, notebooks, or dashboards, every consumer ends up recreating their own version of how the dataset should be assembled. Over time, this leads to datasets that look similar but are built using slightly different rules.
The third problem is performance and operational complexity.
Transformations that should be executed once upstream are now executed repeatedly at query time. As usage grows, the system becomes harder to optimize and more expensive to run.
Ironically, the architecture designed to simplify the data stack often ends up creating complexity in the very place where governance is hardest to enforce.
And when AI systems become the primary mechanism for dynamically assembling data, trust, reliability, and repeatability quickly become major concerns.
Even as some modern data platform vendors suggest these layers are no longer necessary, their continued success in enterprise data platforms comes from their simplicity. They have four layers precisely because there are four things most organizations must ensure in large‑scale data environments: usability, scalability, reliability, and sustainability. Each layer focuses on doing one thing well.
A typical implementation looks like this:
|
Raw Data Layer (aka Bronze) |
Transformation Layer (aka Silver) |
Consolidation Later (aka Gold) |
Presentation Layer (aka Platinum) |
|
Capture raw data exactly as it arrives from operational systems. |
Standardize and validate data from a single source against the target logical data model. |
Match, merge, and reconcile data across multiple sources to create unified entities. | Deliver curated datasets designed for analytics, reporting, and AI consumption. |
|
Focus on preservation rather than transformation. |
Ensure fields, structures, and reference values conform to the designed model. |
Apply matching logic, survivorship rules, and cross‑source reconciliation. | Provide business‑ready datasets for specific use cases. |
|
Minimal structural changes so the original state can always be reconstructed. |
Apply transformations such as type standardization, structural alignment, and validation against model constraints. | Link records and create unified entities such as Entity, Product, Transaction, Portfolio Company, or Financial Performance across systems. | Deliver datasets such as Customer Lifetime Value, Revenue Forecasts, KPI models, or Portfolio Company performance. |
|
Provides the audit trail and lineage foundation for the platform. |
Produces structurally consistent datasets ready to be matched and merged with other sources. | Produces unified cross‑system entities that represent the organization’s integrated view of the business. | Consumers interact with trusted, curated data products rather than raw tables and ad hoc transformations. |
Bonus. Wondering how to design your logical models for your gold layer - read our article on Subject-based Data Modelling.
As organizations adopt AI analytics and AI‑driven data platforms, the quality and structure of underlying data architectures become even more critical.
AI systems are excellent at generating queries and building analyses from conversational interactions. But they still rely on something critical. They rely on deterministic, well‑defined data structures.
If the underlying data models are inconsistent or loosely defined, AI systems don’t magically resolve that ambiguity. They amplify it. Which is why the principle becomes increasingly important:
The more deterministic and well‑defined your data is, the more reliable your AI outcomes will be.
Two‑layer architectures promise simplicity. In reality, they achieve that simplicity by pushing complexity into the presentation layer — where governance, reuse, and consistency are hardest to maintain.
The four‑layer medallion architecture does the opposite. It introduces structure earlier in the data lifecycle, making downstream analytics simpler and more reliable.
For small teams or early experimentation, the two‑layer approach can work. However, for organizations that want analytics to become a core operational capability, structured data architecture becomes unavoidable.
The “Dashboard Data Warehouse”
In organizations where the primary outcome is business-facing analytics dashboards and scorecards, the "two-layer" approach can even result 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 itself.
No formal modeling. No structured layers. Just connect the tool and start building. Again, for a while, it works.
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 been accidentally rebuilt multiple times within your BI tool.
For small teams or early experimentation, this can work. However, for organizations that want analytics to become a core operational capability, structured data architecture becomes unavoidable.
If the answer to any of the following questions is YES, we would almost always recommend moving forward with a four‑layer architecture. (You already know the answer) Don’t shortcut it. Don’t defer it for later. Just start right.
Will more than one team or application system 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 business groups create operational, risk or client credibility problems?
When done right, medallion architectures are not complex. They exist because they are explicitly designed to perform the four things that are ultimately required in all large data‑driven environments:
The strength of the medallion architecture is that each layer focuses primarily on one of these responsibilities.
By doing only one primary job at each stage, the overall system becomes easier to understand and maintain, and far more reliable at scale.
The tools we use to interact with data are evolving rapidly. AI‑driven analytics, conversational queries, and automatically generated data products are becoming part of everyday workflows.
But one principle hasn’t changed. Good analytics still depends on well‑designed data.
And once discipline is done, the medallion architecture doesn’t make things more complicated. It actually makes the entire system far simpler to manage.
To find out more about our practical, data‑management‑first approach to improving business outcomes through better data use, use the contact form below.