Technology / Azure
Microsoft’s data stack, arranged deliberately.
Azure’s data platform overlaps on purpose: Fabric, Synapse, Data Factory, Azure Databricks and Data Lake Storage each describe part of it. Quorlytic assigns one job to each service, keeps entitlement and business context attached to the data, and treats the hand-off into Power BI as an architecture decision rather than a reporting afterthought.
By QuorlyticUpdated
Several Azure services can each claim the same workload. Quorlytic decides which one owns storage, processing and serving in your estate, then designs the pipelines, permissions and semantic layer around that decision.
Architecture role
Where Azure fits.
Azure overlaps on purpose: Fabric, Synapse, Data Factory, Azure Databricks and ADLS each describe part of a data platform. The architecture decision is which service owns storage, processing and serving in your estate, and where the Power BI semantic layer begins.
Position in the end-to-end path
- 01Business sourcesSystems, files, events
- 02IngestData Factory, CDC and events
- 03AzureADLS storage, Fabric, Synapse or Databricks
- 04Semantic layerCertified models and measures
- 05Reporting & actionPower BI and operational workflows
Sources
- Business systems
- Files
- Events
- Ingest & integrateData Factory · CDC
Data platform — one owner per layer
- Storage
- ADLS Gen2
- OneLake
- Processing
- Fabric pipelines
- Synapse
- Azure Databricks
- Serving
- Fabric warehouse
- Synapse SQL
- Azure SQL
- EngineeringPipelines, models, releases
- GovernanceEntra ID · Purview · RBAC
- Power BI
- Excel
- Applications
Illustrative architecture. It shows a typical position for discussion, not a mandatory stack or a client implementation.
Fit and capability
When it is relevant, and what the work involves.
Relevant workloads
- Warehouse and lakehouse analytics
- Pipeline and integration
- Semantic models and reporting
- Machine learning
Engineering capabilities
- Service responsibility decision across Fabric, Synapse and Databricks
- Lake and entitlement design
- Capacity and cost plan per workload
- Power BI hand-off and refresh design
Integration points
What it connects to.
The platform is only as useful as the boundaries around it. These are the interfaces that usually need an explicit decision.
- 01Entra ID and entitlement
- 02Purview governance and lineage
- 03Data Factory and orchestration
- 04Power BI capacity
Delivery and operating considerations
What to decide before you commit.
Each consideration changes something concrete in the architecture, the operating model or the cost profile.
- 01
Decide between overlapping Azure services
Fabric, Synapse, Azure Databricks and plain Data Factory pipelines with Data Lake Storage all remain reasonable answers depending on the estate. Existing licensing, the consumption tool, whether Spark is needed, the governance requirement and the team’s operating skills decide between them. Choosing two services for one job is the expensive outcome, not choosing the less fashionable one.
- Existing licences and committed spend reviewed first
- One serving layer named before pipelines are built
- Spark requirement established rather than assumed
- 02
Design the lake before the pipelines
A lake is a set of conventions: raw retention, curated models, file format, partitioning and who may write where. Without them, every pipeline invents its own layout and downstream readers absorb the cost. Decide the zones, the format and the compaction approach first, and let the pipelines conform to them.
- Raw, curated and serving zones with owners
- File format and partitioning decided once
- Small-file and compaction behaviour planned
- 03
Keep entitlement and business context attached
Permissions and classification need to travel with the data. Entra ID identities, workspace and row-level security, sensitivity labels and catalogue lineage each answer part of the question of who may see what. A single shared credential in a pipeline removes the ability to answer it at all.
- A distinct identity per pipeline or domain
- Access tested with the roles real consumers hold
- Classification and lineage recorded where analysts can see it
- 04
Treat the Power BI hand-off as architecture
The semantic layer is where data definitions become business measures, so it belongs in the design rather than at the end. Agree the model grain, which datasets are certified, how refresh is triggered and what capacity the workload needs. Otherwise the reporting estate re-creates the definitions the platform was built to settle.
- Model grain and certified datasets agreed with the data model
- Refresh ownership and failure handling named
- Capacity cost considered alongside storage and compute
- 05
Know when Azure is the wrong fit
If the analytical centre of gravity sits on another cloud, or Power BI is not the consumption layer, Azure’s integration advantages shrink. Adding a platform also adds a second set of operating skills. Compare the whole path — ingestion, storage, processing, serving and reporting — before standardising on it.
- Consumption layer identified before the platform is chosen
- Existing platform cost and skills compared
- A representative workload used to justify the move
Typical delivery sequence
- 01Baseline & licence review
- 02Service boundaries & lake design
- 03Pipelines & access build
- 04Hand-off, capacity & operate
Decision table
When Azure fits, and when to compare.
| Dimension | Azure is a strong fit | Compare alternatives when |
|---|---|---|
| Existing estate | Microsoft 365, Entra ID and Azure already anchor the organisation. | Most workloads and skills sit in another cloud. |
| Platform | Fabric or Synapse over OneLake or ADLS for analytics, with Data Factory moving data. | The target is a lakehouse or warehouse the team already runs elsewhere. |
| Reporting | Power BI is the reporting layer and should read governed data directly. | Reporting is standardised on another BI tool. |
| Identity | Entra ID groups drive access across data, reports and applications. | Identity is managed outside Microsoft. |
| Operations | Someone chooses explicitly between Fabric, Synapse and Azure Databricks per workload. | Nobody owns that choice, so overlapping services get adopted at once. |
Separate restoring data from correcting a published action.
An Azure data publication can cross lake storage, a serving model and an operational consumer. Reverting a pipeline or restoring a table does not necessarily undo an action already taken from that publication. In this illustrative order-allocation scenario, a recovery record distinguishes the data that can be replaced from downstream work that needs an explicit compensating decision.
Scope and assumptions: This is an architecture assessment, not a production rollback procedure. The scenario assumes a permitted analytical recommendation path and supplies no executable changes. Microsoft's Compensating Transaction pattern explains application-specific compensation; it does not claim that Azure services automatically reverse business effects or that every action is reversible.
| Dimension | Publication state | Recovery boundary and evidence |
|---|---|---|
| Lake and serving versions | Record the dataset publication, semantic-model revision and recommendation batch seen by the consumer. Identify which stores can select a previous accepted version and which require reconstruction. | Keep the consumer-visible publication reference with the data versions. A successful pipeline rerun is not enough if the report or consumer still points at the rejected publication. |
| Action already accepted | Distinguish a recommendation not yet accepted by its owner from an allocation already accepted by an operational system. The first may be withdrawn; the second may have reserved stock, notified a customer or triggered another process. | Retain downstream acknowledgement and business identifiers. Restoring the earlier analytical table cannot establish that those separate effects have been reversed. |
| Concurrent valid changes | Include an authorised order change made after the rejected recommendation. A blanket restoration of old operational state could erase that valid update along with the unwanted effect. | Define a correction that accounts for current business state. Microsoft's pattern notes that compensation need not restore the exact original state and can require business-specific rules for concurrent work. |
| Compensation progress | If a correction spans several systems, record the completed step and the remaining work. Design repeatable compensation where possible so resuming after a failure does not apply the same business adjustment twice. | Keep a progress ledger and an explicit unresolved state. Compensation can itself fail or need manual resolution; an accepted correction in one system is not proof of consistency across the entire path. |
| Consumer resumption | Before the affected workflow resumes, reconcile the selected data publication, serving values and operational acknowledgements. Distinguish corrected recommendations from historical records retained for audit. | Record which effects were corrected, which were irreversible and which remain open. Define the usable consumer state instead of accepting a green infrastructure status as the complete business recovery criterion. |
At narrow widths, scroll the worksheet to read every column. With the table focused, use the arrow keys to scroll.
Worked decision: the analytical publication is restored, but an accepted allocation still refers to the rejected batch and a later customer order edit is valid. Preserve the later edit, apply the separately defined correction to the affected allocation and reconcile its acknowledgement before resuming that workflow. The example describes the required reasoning; it asserts no automated Azure compensation capability or completed operational exercise.
- Draw the boundary between data ownership and operational decision authority. A data platform operator may restore a dataset without having permission to cancel an order or contact a customer.
- Include downstream acknowledgements in the acceptance evidence. Monitoring only the lake or orchestration job misses the point where an analytical defect becomes an externally visible action.
For ongoing responsibilities and incident boundaries, connect the design to managed data and AI services.
Official references for this example:
Questions
Questions worth asking.
Should we use Fabric or Synapse?
It depends on the estate. Synapse suits teams already operating dedicated SQL or Spark pools with existing pipelines and governance. Fabric suits teams standardising on OneLake and Power BI with simpler governance needs. Licence position, workload shape, governance requirements and existing skills decide it — not a product comparison.
How should we split ownership between the data platform and Power BI?
The platform owns sources, storage, transformation and access; Power BI owns the semantic model and the measures people consume. Overlap creates two versions of the same metric. Agree the boundary explicitly, certify the datasets that cross it, and give each side a named owner.
Integration ecosystem
What sits around Azure.
Adjacent technologies grouped by the role they play next to this platform, and why that role usually needs an explicit decision.
Storage
- ADLS Gen2
- OneLake
- Delta
- Blob storage
Whether storage is addressed through Fabric or directly changes what the rest of the architecture can do with it.
Processing
- Data Factory
- Synapse
- Azure Databricks
- Fabric pipelines
Several services overlap deliberately, so naming which one owns each job is the central architecture decision.
Serving
- Synapse SQL
- Fabric warehouse
- Azure SQL
- Power BI datamarts
Concurrency profile and where the semantic layer begins usually decide this, not raw performance.
Identity and governance
- Entra ID
- Purview
- Private endpoints
- RBAC
Entra alignment is one of the strongest practical reasons Microsoft-centric estates consolidate here.
Consumption
- Power BI
- Fabric
- Excel
- Applications
Power BI integration is tight enough that the semantic layer boundary is an Azure architecture decision, not a downstream one.
Technology marks belong to their respective owners. No partnership, certification or endorsement is implied.
Migration and modernization
What moves, and what that asks of you.
Typical transitions. Azure migrations are usually as much about consolidating overlapping services as about moving data.
SQL Server estateAzure SQL, Synapse or Fabric
The path with the most familiar tooling and the most temptation to lift procedural logic unchanged, which is where these migrations usually go wrong.
SynapseFabric
A live question for many estates. It is worth deciding on measured workload evidence and on your team's operating model rather than on roadmap direction alone.
Scattered Data Factory pipelinesGoverned transformation
Moving logic out of pipeline activities into tested, version-controlled transformations is usually the highest-value change in an Azure estate.
Power BI-only reportingA platform behind it
When import models and gateways become the bottleneck, the answer is a platform layer rather than a larger capacity.
Performance and economics
What drives the bill.
Capacity-based pricing rewards steady utilisation and punishes spiky, unmanaged workloads.
Attributing and reducing Azure spend as an engagement, rather than a tuning exercise, is covered by data platform cost optimization.
- Capacity units
- Fabric and Power BI capacity is reserved rather than per-query, so the decision is sizing and who shares it.
- Dedicated versus serverless
- Synapse dedicated pools suit predictable load; serverless suits exploratory querying with unpredictable volume.
- Pipeline activity cost
- Data Factory bills per activity run, which makes fine-grained pipelines with many small activities surprisingly expensive.
- Storage
- ADLS tiering and retention are straightforward savings that are commonly left at defaults.
- Licensing alignment
- Existing enterprise agreements often dominate the comparison against other clouds, and belong in it explicitly.
Governance and security
What has to be designed first.
Overlapping services make explicit boundaries the main governance requirement.
- Service ownership
- Which service owns storage, processing and serving, written down. Without it, the same job appears in three places over two years.
- Catalogue and lineage
- Purview or an equivalent, so lineage crosses the services rather than stopping at each boundary.
- Entra and RBAC
- One access model spanning storage, compute and Power BI, rather than three that approximately agree.
- Network isolation
- Private endpoints and managed virtual networks are part of the data architecture where data is sensitive.
- Capacity governance
- Fabric and Power BI capacity is shared, so one team's refresh can affect another team's reports without a capacity policy.
Trade-offs
When it fits, and when it does not.
Where an Azure data platform fits, and where its overlap becomes a liability.
Where Azure tends to fit
- Microsoft-centric estates where Entra identity and existing agreements already apply
- Organisations where Power BI is the established consumption layer
- Workloads that benefit from tight integration between platform, semantic layer and reporting
- Teams that want one vendor relationship across cloud, platform and BI
Where another answer deserves consideration
- Snowflake or Databricks on AzureYou want a single platform with a clear boundary rather than choosing between overlapping first-party services.
- Deferring the Fabric decisionCurrent Synapse or Databricks workloads are stable. Migrating on roadmap direction rather than on a measured constraint is expensive.
- Another cloudThe estate is not Microsoft-centric. Much of Azure's practical advantage is identity and licensing alignment, which does not apply otherwise.
Related architectures
Patterns this platform appears in.
References
Primary sources for this platform.
Vendor documentation, linked for verification. It is not an endorsement, partnership or certification.
Next step
Review your Azure data architecture.
Bring the services you already run. On Azure the overlap between them is the decision to resolve.