Architecture and landing zone
Workspace topology, domain boundaries, OneLake layout, naming and tagging standards, environment separation, and the decision record that explains why the boundaries fall where they do.
Microsoft Fabric
Microsoft Fabric implementation
Lakehouse architecture sized against measured consumption rather than headcount.
- A medallion lakehouse with explicit ownership and contracts between layers
- Capacity sized against measured consumption, with throttling understood before it happens
- Direct Lake models where they pay for themselves, import models where they do not
- A migration route from your current estate that does not require a big-bang cutover
Fabric is a genuine step forward and a genuine way to spend money quickly. The platform collapses storage, engineering, warehousing and reporting into one capacity-based bill, which is excellent when the architecture is deliberate and painful when teams lift and shift their existing mess into it.
We design Fabric estates that start from the workload: what has to land, how often, at what grain, and who reads the result. That produces a medallion layout with clear ownership at each layer, Direct Lake semantic models where they help and import models where they are simply better, and a capacity plan with headroom you can defend to a finance director.
We are equally willing to tell you not to adopt Fabric yet. If your volumes sit comfortably in an import model and your refresh window is fine, a capacity SKU is a cost without a benefit, and we will say so in writing.
What we deliver
What the work involves
Medallion lakehouse build
Bronze ingestion with full fidelity and replayability, silver conformance and deduplication with testable rules, gold dimensional models ready for analytics. Delta tables maintained properly: partitioning, OPTIMIZE and VACUUM on a schedule rather than when something breaks.
Ingestion and orchestration
Pipelines and Dataflows Gen2 for structured sources, notebooks where code is the honest answer, mirroring and shortcuts to avoid copying data that does not need copying, and orchestration with real failure handling and alerting.
Warehouse and SQL serving
Fabric Warehouse where T-SQL and multi-table transactions matter, lakehouse SQL endpoints where read-only serving is enough, and a clear rule for which one a new workload should use.
Direct Lake semantic models
Direct Lake models built with the fallback behaviour understood and measured, V-Order and framing considered, and an honest comparison against an import model on your own data instead of a vendor benchmark.
Capacity management and cost control
Capacity Metrics instrumentation, workload classification, background versus interactive consumption profiling, bursting and smoothing explained, and a sizing model that tells you what happens the day you double your users.
Method
How the engagement runs
Each stage names the artefact it produces, so progress can be checked without a status meeting.
Workload assessment
Every candidate workload catalogued with volume, latency requirement, concurrency and consumer type. This determines the architecture; fashion does not.
Workload catalogue and target-state architecture options
Landing zone and standards
Workspaces, domains, capacities, security groups, naming and deployment approach stood up before the first pipeline, so the estate does not need re-plumbing in month four.
Provisioned landing zone and written standards
Reference pipeline
One source taken end to end, from bronze through gold to a report, as the pattern everything else follows. Tested, documented, reviewed with your engineers.
Reference implementation plus pattern documentation
Scale-out
Remaining sources onboarded against the pattern, with capacity consumption watched as the estate grows rather than discovered at the first throttling event.
Production lakehouse and capacity report
Operate and optimise
Table maintenance, cost review, and a quarterly architecture check as Fabric itself changes, because it changes frequently.
Operations runbook and optimisation backlog
Deliverables
Deliverables
- Target-state architecture document with recorded trade-offs
- Provisioned workspaces, domains and capacity configuration
- Medallion lakehouse with documented layer contracts
- Orchestrated pipelines with retry, alerting and lineage
- Direct Lake or import semantic models, chosen on measured evidence
- Capacity sizing model and consumption dashboard
- Table maintenance schedule and operations runbook
- Migration plan from the existing estate with rollback points
Stack
Technologies
- Microsoft Fabric
- OneLake
- Fabric Data Factory
- Dataflows Gen2
- Fabric Warehouse
- Fabric Lakehouse
- Spark notebooks
- Delta Lake
- Direct Lake
- Fabric Capacity Metrics
- Microsoft Purview
Related work
Related engagements
Questions
Microsoft Fabric: common questions
Sometimes. Fabric earns its keep when you have several of: data volumes that strain import models, a real need for both SQL and notebook access to the same data, multiple teams needing governed self-service, or an existing Premium capacity you are already paying for. If one analyst maintains three import models that refresh in twenty minutes, a capacity is an expense without a return. We give that answer in writing when it is the right one.
By measuring. We profile each workload for compute shape, concurrency and peak hours, then map it to capacity units, then validate on a short-lived trial capacity with your real data. The output is a sizing model showing expected utilisation at launch, at double the users, and the specific point at which you would need the next SKU up.
Yes, and for most organisations that is the pragmatic path. Shortcuts and mirroring let Fabric read data in place, so you can serve analytics from Fabric without re-platforming your engineering layer on day one. We usually recommend a serving-layer-first adoption: Fabric for the gold layer and reporting, existing platform retained for heavy engineering, with later migration decided on evidence.
It lets a semantic model read Delta files in OneLake directly, with no import refresh and no DirectQuery round trip to a SQL engine. The catch is the conditions: unsupported constructs trigger fallback to DirectQuery, and performance then depends on the endpoint. We test Direct Lake against an import model on your data and pick on the numbers. In practice Direct Lake wins on large, frequently-landing tables, and import still wins on small models with heavy DAX.
Your team, with explicit layer ownership written down: who may write to silver, who approves a new gold table, who is on call when a pipeline fails. Fabric makes it easy for anyone with a workspace to create anything, which is exactly why ownership has to be defined on paper before the estate grows.
Related
Azure & SynapseAzure pipelines, warehousing and lakehouse engineering built to run unattended.Power BISemantic modelling, DAX and report delivery with one agreed definition per measure.GovernanceOwnership, cataloguing, classification and access evidence, implemented in the tools teams already use.
Sector context: Financial services, Manufacturing, Retail, Healthcare, Logistics.
Next step
Microsoft Fabric: what the next step looks like
A two to three week workload assessment with a written build-or-wait recommendation
Answered within one working day, by the engineer who would do the work