Modern Data Platform — Architecture Decisions Map

The architectural decisions a CDO and Head of Data actually litigate — platform selection (Fabric vs Databricks vs Snowflake), foundations, federation, and platform-team operations.

BusinessCapabilityTechnology
Compass
  • Businesspersona, use case, outcome
  • Capabilitywhat the org needs to do
  • Technologythe technology choices
Guided journey · Step 1 of 4

Platform Selection Strategy

Decide platform selection — Fabric anchor, Databricks lakehouse, Snowflake warehouse, or coexistence pattern. Workload fit, not vendor preference.

~ 6 weeks

Search any SKU, capability, risk, or source on this map.

Filter by type

Narrative intro

Every modern data platform conversation begins as a platform-selection debate — Fabric, Databricks, Snowflake, or a coexistence pattern. The architectural answer is rarely binary. This map names the four architectural decision points (platform selection, foundations, federation, operations) and the SKUs that anchor each, so the trade-offs are visible rather than implicit.

Key takeaways

  • Platform selection is workload-fit — coexistence is a legitimate answer
  • Storage substrate decisions outlast compute decisions — ADLS / OneLake / Iceberg matter most
  • Catalogue federation via Purview is the cross-platform governance plane
  • Platform-as-product is what makes the architecture trustworthy operationally

Programme shape

Estimated duration
16–32 weeks
Estimated FTE
1 FTE platform architect + part-time governance, engineering, and BI partners
Spend tier
major
Risk level
elevated

Platform selection has multi-year implications. The decision is not binary — Fabric and Databricks frequently coexist; Snowflake often serves a specific workload class.

Back to all maps