Medallion architecture (also called the Bronze-Silver-Gold architecture) is a data lake design pattern, popularised by Databricks and widely adopted across Microsoft Fabric and Azure data lake implementations, that organises data lake content into three progressively refined quality layers. Bronze is the raw layer — data landed exactly as received from source systems, with no transformation: Oracle EBS GL extracts as raw CSV files, ZATCA XML invoice responses as received, Oracle FCCS export files in their native format. Bronze data is immutable — it is never modified after landing, providing the audit record of what was received from the source. Silver is the conformed layer — cleansed, standardised, deduplicated, and lightly transformed data in a consistent schema, stored in open columnar format (Delta Lake or Parquet), with source system fields renamed to business-friendly names and data types standardised. Gold is the consumption layer — business-ready dimensional models, aggregations, and metrics structured for BI tool consumption in star schema format, with DAX-ready table designs and the specific grain and history required by the reporting use case.
Medallion Architecture Layers
| Layer | Content | Transformation | Consumers |
|---|---|---|---|
| Bronze | Raw source files and streams — unmodified, timestamped, with load metadata | None — raw as received | Data engineers for investigation; auditors for source data evidence; re-processing on schema changes |
| Silver | Cleansed, typed, conformed tables — one row per business event | Type casting, null handling, deduplication, renaming, light business logic | Data engineers for transformation; data scientists; dbt models that produce Gold |
| Gold | Star schema fact and dimension tables; KPI aggregation tables | Full business logic — account mapping, currency translation, period labelling, metric calculation | Power BI semantic models; Oracle Analytics Cloud; Reporting layer direct SQL |
Medallion Architecture in Microsoft Fabric
Microsoft Fabric’s Lakehouse architecture is a natural implementation platform for Medallion architecture — with OneLake providing the unified storage for all three layers and Fabric’s Lakehouse, Warehouse, and Notebook workloads providing the processing tools for each layer’s transformation. In a Fabric-based GCC finance data lake: Bronze is implemented as a Fabric Lakehouse receiving raw files from Fabric Pipelines (which ingest from Oracle EBS via the on-premise Integration Runtime); Silver is implemented as a second Lakehouse where Spark notebooks (or dbt via Fabric’s dbt integration) clean and standardise the Bronze data; Gold is implemented as a Fabric Warehouse (T-SQL accessible, auto-scaling) containing the star schema tables that Power BI semantic models connect to. This architecture aligns with Microsoft’s recommended Fabric data platform pattern and provides the lineage traceability — from raw Bronze Oracle EBS extract to Gold fact table to Power BI measure — that finance audit requires.
GCC Finance Medallion Architecture Considerations
Two GCC-specific considerations shape the Medallion architecture for finance data platforms. First, ZATCA archive data: ZATCA requires ten-year retention of e-invoice records in a tamper-evident format. The Bronze layer — storing the raw ZATCA XML clearance responses exactly as received — provides the immutable, timestamped archive that satisfies this retention requirement, as long as the Bronze layer’s storage includes access controls (preventing modification), encryption (protecting confidentiality), and lifecycle management (ensuring files are not accidentally deleted within the retention period). Second, EGP devaluation impact on historical analysis: Egyptian entities in GCC holding groups have experienced significant EGP devaluation since 2022. The Silver layer’s currency standardisation logic — converting historical EGP amounts to group reporting currency (SAR or USD) — must preserve both the original EGP amount and the applied exchange rate as separate columns, enabling historical analysis to be reproduced with the original rates and recalculated with alternative rates for sensitivity analysis.
What Goes Wrong in Practice
The most common Medallion architecture implementation failure is a Bronze layer that is not truly immutable — where transformation jobs overwrite Bronze files rather than landing new Bronze files and producing Silver output separately. When a data quality issue is discovered in a Silver transformation, the ability to re-process from Bronze depends on Bronze being the unmodified original. A Bronze layer that has been modified by transformation jobs has no reliable re-processing baseline; the recovery requires re-extraction from the source system — which may no longer have the original data if the source is a transactional system that purges historical records.
How Loop Wise Solutions Implements Medallion Architecture
We implement Medallion architecture with Bronze immutability as a technical constraint — configuring storage access policies that prevent any process from modifying or deleting Bronze files, with only append operations permitted. Bronze files are stored with the source system name and extraction timestamp as part of the file path, providing a complete history of what was received and when from each source system.
