Skip to main content

Fabric Landing Zone Design Principles

The Microsoft Fabric landing zone conceptual architecture applies universally to any Fabric landing zone process or implementation. At the foundation of this architecture lies a set of core design principles that serve as a compass for decisions across critical technical domains.

These principles are intentionally aspirational to help guide organizations toward an optimum Fabric architecture that supports data democratization, governance, and innovation at scale.

Impact of Design Deviations​

There may be valid reasons to deviate from these principles. For example, compliance, performance, or integration requirements may dictate alternate approaches. However, it is crucial to understand the tradeoffs and long-term impacts of these deviations — particularly in terms of governance, manageability, and scalability.

Capacity Democratization​

Use Fabric Capacities as a unit of scale and management. Align Capacity allocation with business needs and prioritize workspace segmentation to support business domains and workload boundaries.

To enable scaling, define a logical structure of Workspaces and Domains. Fabric enables Dev/Test/Prod segmentation using separate Workspaces linked to the same or different Capacities.

Impact of deviation

  • Lack of workload isolation and governance boundaries
  • Difficulty in attributing costs and responsibilities per domain
  • Increased overhead for managing artifacts across shared workspaces

For more, see Workspace and Capacity Strategy.

Data Centralization vs. Departmental Demands​

Striking the right balance between centralized data management and the autonomy of individual departments is critical in Microsoft Fabric architectures. While a single, centralized Fabric capacity and workspace (hub-and-spoke model) offers clear advantages in terms of governance, cost attribution, and data discoverability, it can create challenges for departments with high independence or unique governance needs.

Key considerations

  • Centralized model: Promotes a unified data estate with consistent governance, streamlined ELT pipelines, and ready-to-use data for AI/ML scenarios. However, departments may compete for shared capacity resources, leading to "noisy neighbor" issues if consumption isn't well managed.
  • Departmental autonomy: Some organizations benefit from providing departments with dedicated workspaces and isolated capacities. This aligns with a data mesh approach but requires each department to take ownership of data stewardship, which can be difficult if the departments lack technical expertise or interest.
  • Hybrid approach: A hybrid architecture, where a central data engineering workspace (or shared "OneLake" hub) manages critical, organization-wide datasets, while departmental workspaces own their specific domain data, can help bridge the gap. Microsoft Fabric features like OneLake Shortcuts enable zero-copy sharing between workspaces.
  • Governance and lineage: Use Microsoft Purview and subscription-based policies to enforce data lineage and access control across both centralized and departmental workspaces.

Impact of deviation

  • Over-centralization can result in performance bottlenecks, overconsumption of capacity units (CUs), and loss of departmental agility.
  • Over-decentralization can recreate data silos, increase operational overhead, and complicate AI/ML initiatives.

For a detailed strategy on managing these tensions, see Workspace and Capacity Strategy.

Policy-Driven Governance​

Use Microsoft Purview, item-level permissions, and deployment pipelines to enforce governance guardrails across your Fabric estate. Policies ensure consistency while allowing teams to innovate within controlled environments.

Impact of deviation

  • Higher risk of non-compliant artifacts and shadow IT
  • Increased effort to manually validate and audit governance boundaries

For more, see Governance in Fabric.

Single Control and Management Plane​

Leverage Fabric’s unified control plane — via the Fabric Portal, Power BI Admin Portal, and API/CLI access — for all management tasks. Avoid layering custom abstractions or introducing conflicting tooling for core deployment and governance.

Impact of deviation

  • Increased complexity and reduced clarity in access and ownership
  • Potential conflicts in deployments and pipeline configurations

Use Fabric REST APIs and deployment pipelines for automation.

Application-Centric Service Model​

Design for applications, not infrastructure. Whether ingesting real-time data via Eventstreams, reporting via Power BI, or analyzing large datasets in Lakehouses, all artifacts should support business capabilities and product-centric thinking.

Impact of deviation

  • Fragmented deployment and ownership models
  • Difficulty in lifecycle management and governance alignment

See also Organize Fabric Artifacts.

Alignment with Fabric-Native Capabilities​

Use native Fabric capabilities (e.g., Lakehouse, Warehouse, Real-Time Hub, Power BI, Pipelines) wherever possible. Stay aligned with the Microsoft Fabric roadmap to ensure future-proofing and early access to enhancements.

Impact of deviation

  • Increased maintenance and integration effort with external tooling
  • Possible incompatibility with governance, monitoring, or automation features

See Stay current with Fabric.

Contributors