"Architecture is not drawing boxes and arrows. Architecture is making decisions under uncertainty and being able to justify every decision. This exercise teaches you how to think like an architect."
What You Will Produce
By the end of this guide, you will have produced:
- A written requirements analysis for a real enterprise scenario
- A component selection decision with justification
- A text-based architecture diagram of the complete platform
- An identified list of risks and governance considerations
No Azure subscription needed. No tools. Just structured thinking applied to a realistic problem.
The Scenario — Contoso Retail Group
Contoso Retail Group is a mid-sized retailer with:
- 300 stores across India, UAE, and Singapore
- Data sources: Point-of-sale transactions (SQL Server, on-premises per region), inventory system (REST API, updated hourly), customer loyalty app (Azure SQL Database, cloud), marketing campaign data (Excel files, uploaded monthly by marketing team)
- Current state: Finance team manually exports from each regional SQL Server monthly, consolidates in Excel, uploads to Power BI Desktop, publishes. 3-day lag on monthly reports. No real-time visibility.
- Requirements:
- Regional store managers need daily sales dashboards by 7am
- Finance needs consolidated P&L by next business day after month-end
- Marketing wants customer segmentation analysis (will involve ML later)
- IT has a Microsoft 365 E3 licence — no Azure subscription currently
- Data must remain within country borders (regulatory)
- Budget: Moderate. No dedicated data engineering team currently.
Step 1 — Analyse the Requirements
Before choosing any technology, classify each requirement:
Step 2 — Choose Your Components
Based on the requirements analysis, map each need to a Fabric component:
Step 3 — Draw the Architecture
CONTOSO RETAIL GROUP — MODERN DATA PLATFORM ARCHITECTURE
DATA SOURCES
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ POS SQL │ │ Inventory │ │ Loyalty App │ │ Marketing │
│ (On-prem, │ │ REST API │ │ Azure SQL │ │ Excel on │
│ per region) │ │ (Hourly) │ │ (Cloud) │ │ SharePoint │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │ │
↓ ↓ ↓ ↓
INGESTION LAYER
┌─────────────────────────────────────────────────────────────────┐
│ On-premises Dataflow Gen2 Data Pipeline Dataflow Gen2│
│ Gateway + (REST API) (Azure SQL) (SharePoint) │
│ Data Pipeline │
└────────────────────────────┬────────────────────────────────────┘
↓
STORAGE LAYER — ONELAKE (Fabric Lakehouse)
┌─────────────────────────────────────────────────────────────────┐
│ BRONZE (Raw) SILVER (Cleaned) GOLD (Business-ready) │
│ ───────────── ─────────────── ────────────────────── │
│ Raw POS data Deduplicated sales Daily_Sales_Summary │
│ Raw inventory Validated inventory Product_Performance │
│ Raw loyalty Merged customer Customer_Segments │
│ Raw Excel Standardised promos Regional_PnL │
│ │
│ All stored as Delta tables — ACID, versioned, auditable │
└────────────────────────────┬────────────────────────────────────┘
↓
SERVE LAYER
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ Power BI │ │ SQL Analytics │ │ Fabric Data │
│ Direct Lake │ │ Endpoint │ │ Science │
│ │ │ │ │ (Future) │
│ Store manager │ │ Finance team │ │ ML customer │
│ daily dashboard │ │ ad-hoc SQL │ │ segmentation │
│ 7am refresh │ │ P&L queries │ │ (Phase 2) │
└──────────────────┘ └──────────────────┘ └──────────────────┘
GOVERNANCE (Microsoft Purview — across all layers)
Data lineage | Sensitivity labels | Access control | Audit logs
REGION SEPARATION
India data → India Central workspace
UAE data → UAE North workspace
Singapore → Southeast Asia workspace
Consolidated reports → read cross-workspace via OneLake shortcuts
Step 4 — Identify Risks and Governance Considerations
Every architecture has risks. Identifying them before building is professionalism. Discovering them after is a crisis.
- Risk 1: On-premises connectivity — Data Gateway must be installed on a server near the regional SQL Servers. If gateway goes offline, ingestion stops. Mitigation: Install two gateways per region (high availability mode).
- Risk 2: Data quality from Excel uploads — Marketing team uploads Excel manually. Column names may change, sheets may be renamed. Mitigation: Dataflow Gen2 with schema validation + alert on failure.
- Risk 3: Fabric capacity limits — M365 E3 trial capacity is limited. Month-end processing may exceed limits. Mitigation: Monitor Fabric Capacity Metrics app. Scale capacity temporarily for month-end.
- Risk 4: Cross-region data governance — Three workspaces (India, UAE, Singapore) need consistent governance. Mitigation: Microsoft Purview tenant-wide policies applied before any data lands.
- Risk 5: Team skill gap — No data engineering team currently. Dataflow Gen2 is low-code but still requires training. Mitigation: Start with one data source as a pilot before full rollout.
🎯 Architecture Review Questions
Q1: Why was Dataflow Gen2 chosen for the REST API and Excel sources instead of Spark notebooks?
Show Answer
Because the requirement analysis identified a skills constraint — no data engineering team currently. Dataflow Gen2 is low-code and manageable by BI professionals without Spark experience. Spark notebooks would require Python/Scala knowledge the team doesn't have. Architecture decisions must account for team capability, not just technical optimal solutions.
Q2: Why are three separate Fabric workspaces used (India, UAE, Singapore) instead of one?
Show Answer
Because of the data residency requirement — regulatory rules require data to stay within country borders. Fabric workspace region determines where data physically resides in OneLake. One consolidated workspace would force data from all three countries to one region, violating compliance. Cross-workspace reporting is handled via OneLake shortcuts — which allow reading data cross-workspace without physically moving it.
Q3: Why is the ML/Data Science workload planned for Phase 2 rather than included now?
Show Answer
Two reasons. First, the data foundation must be reliable before ML is useful — ML on poor-quality data produces poor-quality predictions. The Bronze→Silver→Gold pipeline must be proven stable first. Second, the team skills constraint — adding ML in Phase 1 spreads the team too thin. Architecture phases work: get the data foundation right, then add intelligence on top.
Key Takeaways — Build Real Part 1
- Architecture starts with requirements analysis — classify each requirement by type (latency, compliance, skills, budget) before touching technology
- Medallion architecture (Bronze → Silver → Gold) is the standard pattern for Lakehouse organisation in Fabric
- Data residency is a governance decision that affects workspace structure — one workspace per country is sometimes required
- Choose components based on team skill level, not just technical capability — the best tool is the one the team can maintain
- Architecture phases work: data foundation first, intelligence layer second