Most Microsoft Fabric projects don’t fail on technology. They fail on architecture — dozens of decisions about workspaces, capacity, security and data flow that get made ad-hoc, by whoever happens to be in the room that day. A Fabric architecture design system fixes that: every major decision is made deliberately, with your team, and written down before you build.
This is the framework we use at Gulf BI Analytics to design a Microsoft Fabric platform that is secure, cost-controlled and ready to scale — the same decision set whether you are a 20-person finance team or a group-wide data platform. New to the platform? Start with what Microsoft Fabric is, then come back here.
The Fabric architecture at a glance
Every well-designed Fabric platform follows the same shape: raw data flows left-to-right through medallion layers into a semantic model and reports, sitting on a foundation of platform, security and operations decisions.
1. Data strategy & sources
Before a single workspace exists, decide what the platform is for. Inventory every source — ERP, CRM, finance systems, spreadsheets, operational databases, APIs — and map each one to the business questions it answers. Then decide what actually needs to land in Fabric now versus later. The output is a one-page data strategy that every later decision points back to; without it, you end up ingesting everything and modelling nothing.
2. The medallion architecture: Bronze, Silver, Gold
The backbone of a Fabric lakehouse is the medallion pattern, with each layer as its own workspace (or schema) so you get clean security boundaries, independent refresh and clear end-to-end lineage:
- Bronze — raw. Data exactly as ingested, immutable. Your landing zone and audit trail; you can always rebuild everything downstream from here.
- Silver — cleaned & conformed. De-duplicated, data types fixed, business keys aligned across sources. This is where data becomes trustworthy.
- Gold — business-ready. Modelled facts and dimensions, aggregated and shaped for consumption. This is what your semantic models and reports read.
Decide lakehouse vs warehouse per layer: Spark-heavy or data-science transforms lean lakehouse; T-SQL and BI-centric workloads lean warehouse. OneLake means both read the same copy of the data — no duplication.
3. The semantic & reporting layer
Two more workspaces, kept deliberately separate from the data layers:
- Model workspace. Your Direct Lake semantic models — one version of the truth, with measures, hierarchies and row-level security. Direct Lake reads straight from Gold in OneLake, so there is no import refresh to manage for large models.
- Report workspace. The dashboards users actually open.
Separating model from report lets report developers work without touching the model, and lets you promote models and reports independently through your pipelines.
4. Platform setup: capacity, region & viewers
- Capacity. Start with a single F-SKU sized to your real workload and turn on surge protection so one runaway job can’t starve everything else. Scale up only when a workload earns it — and pause non-production capacity when it is idle.
- Region. Choose the capacity region closest to your users and that meets your data-residency rules — an important decision for UAE and GCC organisations.
- Free viewers. On Fabric capacity, free (non-Pro) users can view content in capacity-backed workspaces — a large licence saving when you need to reach a broad executive or operations audience.
5. Security & governance
- Entra security groups for every access boundary — never assign individual people to workspaces.
- Group-based row-level security defined once in the semantic model.
- Sensitivity labels (Microsoft Purview) that travel with the data, even into Excel and PowerPoint exports.
- Retention and audit — know who accessed what, and for how long data is kept.
- Workspace roles mapped to the medallion: engineers in Bronze/Silver, analysts in Gold/Model, viewers in Report. Least privilege by design.
6. Operations & monitoring
- Capacity Metrics app + alerts so you see throttling before your users do.
- Refresh and pipeline failure notifications routed to the team that owns them, not a shared inbox no one reads.
- Scheduled architecture reviews (we run them quarterly) as data volumes and usage grow.
- Cost monitoring — track capacity-unit consumption by workload so spend is a decision, not a surprise.
7. Source control & deployment
A platform that can’t be versioned can’t be trusted. Put your workspaces under Git integration (Azure DevOps or GitHub), use deployment pipelines for dev → test → prod promotion, and review changes before they reach production instead of clicking them live. This is also what makes a clean Power BI to Fabric migration repeatable.
How we run a Fabric Architecture Design engagement
Every decision above is made with your team and written down, so you leave with a documented architecture rather than a pile of workspaces. Our engagement follows six steps:
- Discover the decisions the platform must support.
- Design the story — the reports and questions it has to answer.
- Model the data — medallion layers and semantic models.
- Build, test and refine with your team.
- Automate & govern — security, pipelines and monitoring.
- Scale on Microsoft Fabric as adoption grows.
Frequently Asked Questions
What is a Microsoft Fabric architecture design system?
It is a structured way to make every major Fabric platform decision — medallion layers, workspaces, capacity, security, operations and DevOps — deliberately and document them before building, instead of letting them happen ad-hoc.
What is the medallion architecture in Microsoft Fabric?
Bronze (raw, as-ingested), Silver (cleaned and conformed) and Gold (business-ready) layers, usually built as separate workspaces in OneLake. It gives clean lineage, security boundaries, and the ability to rebuild everything downstream from the raw layer.
Should each medallion layer be a separate workspace?
Generally yes. Separate Bronze, Silver and Gold workspaces give clean security boundaries, independent refresh and clear lineage. Smaller platforms can start with schemas in one lakehouse and split into workspaces as they grow.
What is Direct Lake and why does it matter for architecture?
Direct Lake lets a Power BI semantic model read straight from Gold data in OneLake with no import refresh, giving large models fast performance without maintaining a separate copy of the data.
Do you design Fabric architectures for UAE companies?
Yes. Gulf BI Analytics runs Fabric Architecture Design engagements across the UAE and GCC, covering medallion design, semantic models, capacity, security, operations and Git/DevOps.
