Modern data engineering architecture on Azure, 2026

Sources, ingestion, bronze, silver, gold, semantic model, consumers. The layered lakehouse that modern Azure data engineering is built on, layer by layer.

A modern data engineering architecture on Azure in 2026 is a layered lakehouse: source systems feed an ingestion layer, which lands raw data in a bronze layer, which is cleaned into silver, which is modelled into gold, which is described by a semantic model, which serves reports, applications and AI agents. Governance, security and monitoring run across every layer rather than sitting at the end. On Azure today the natural home for that architecture is Microsoft Fabric, with OneLake as the storage and Delta Parquet as the format, although the same shape works on Databricks or Synapse. This post walks through each layer, what goes in it, which Azure and Fabric components do the work, and the mistakes that turn a tidy diagram into a slow, untrusted platform.

Sources

Everything starts with the systems that run the business: an ERP such as Business Central, Dynamics 365 or SAP, a CRM, an e-commerce platform, a warehouse or production system, HR and payroll, and the spreadsheets that hold budgets and targets. The architecture decision here is not technical. It is the list of which systems are in scope, who owns each one, and what the business means by a customer, an order and a cost centre across them. Teams that skip that conversation build the lower layers twice.

Ingestion

Ingestion moves data from sources into the lake with as little transformation as possible. In Fabric there are four mechanisms and the right one depends on the source. Mirroring replicates operational databases such as Azure SQL, Cosmos DB, Snowflake, Oracle and SAP into OneLake continuously with no pipeline to maintain. Shortcuts expose data already in Azure Data Lake Storage, Amazon S3 or Google Cloud Storage in place without copying it. Pipelines, the Fabric version of Azure Data Factory, handle scheduled extraction from APIs, files and on-premises databases through the on-premises data gateway. Dataflows Gen2 cover the long tail of small sources where Power Query is the quickest route. Our decision guide sets out the rule for choosing, and the principle is to prefer mirroring and shortcuts, because the best pipeline is the one you do not have to run.

Bronze: raw, complete, untouched

Bronze holds data exactly as it arrived, in Delta tables, with the load date and source recorded on every row. Nothing is cleaned, nothing is deleted, and history accumulates. The point of bronze is replay: when a silver rule turns out to be wrong, or a new question needs a column nobody extracted, you rebuild from bronze rather than going back to the source system. Bronze is cheap to keep. OneLake storage in UK South lists at under two pence per gigabyte per month, so the economic case for keeping everything is easy.

Silver: cleaned, conformed, trusted

Silver is where data becomes reliable. Types are fixed, duplicates removed, keys standardised, codes decoded, and the same customer or product from different systems matched to one conformed record. Silver also holds the data quality checks: row counts reconciled to source, freshness measured, and nulls and outliers flagged. Most of the engineering effort in a lakehouse lives here, and most of it should be in notebooks or dataflows that are version controlled, tested and run by pipelines rather than by hand. Testing a data pipeline describes the checks that belong in this layer.

Gold: modelled for the business

Gold is the star schema: fact tables for sales, invoices, stock movements and journal entries, surrounded by dimension tables for date, customer, product, department and company. Measures such as gross margin, days sales outstanding and utilisation are defined once here, in the business's own terms. Gold is deliberately smaller and simpler than silver, because it is the layer people and tools read. In Fabric it is either a lakehouse with a SQL endpoint or a Fabric warehouse; lakehouse SQL endpoint or Fabric warehouse explains the choice, and medallion architecture in practice covers the build in detail.

Semantic model: the meaning layer

Above gold sits the Power BI semantic model, reading the Delta tables directly through Direct Lake so there is no import refresh to schedule. The semantic model holds the measures, hierarchies, row-level security and descriptions that make the data understandable to a person asking a question in Power BI or an agent asking one through Fabric IQ. It is also the layer Copilot and data agents reason over, which is why the names and descriptions in it matter more in 2026 than they did in 2020. Data model or ontology? explores how far that layer should go.

Consumers

The consumers are Power BI reports and apps, Excel connected to the semantic model, embedded analytics in portals and operational applications, write-back and planning tools, and increasingly AI agents that answer questions, raise alerts through Activator or take actions. Nothing in this layer should calculate a business number; if a report defines margin differently from the semantic model, the architecture has failed at the previous layer.

Across every layer: governance, security and monitoring

Governance is not a layer at the end. Microsoft Purview catalogues and classifies data across the lakehouse, OneLake security applies row and column rules at the storage layer so they hold in every engine, Fabric policies set tenant and capacity rules, and workspace monitoring and the capacity metrics app show what ran, what failed and what consumed the capacity. Fabric governance in 2026 covers the controls and the pipeline ran is not the same as the data is right covers the monitoring.

The three mistakes that break the pattern

The first is skipping bronze to save storage, which costs pennies and removes the ability to replay. The second is letting reports read silver, which means every report re-implements the business rules and no two agree. The third is building gold before anyone has agreed the definitions, which produces a technically correct model of numbers finance will not sign off. The cure for all three is the same: a short Establish phase that agrees sources, definitions and the layer rules before the first pipeline is built, which is how our data platform and warehouse engagements start.

What does a modern data engineering architecture on Azure look like in 2026? The layered lakehouse, explained