One Architecture Fits All — and This Time the Claim Holds

For fifteen years, the data industry has sold one architecture for everything. EDWs that would also do real-time. Hadoop estates that would also do BI. Cloud data warehouses that would also do machine learning. Every wave promised consolidation. Every wave produced another tool in the stack.

I have spent the last decade unpicking those estates. Manufacturing clients with a SQL Server warehouse for finance, a Synapse pool for operations, a Snowflake account because a procurement leader liked the demo, an S3 lake nobody could explain, and a Power BI Premium capacity refreshing the same numbers four times a day. FMCG distributors running three flavours of "single source of truth" — and the source none of them trust is the one their CEO actually reads.

So I have been deliberately slow to call any new platform "the one." When Microsoft launched Fabric in 2023, I treated it like every other consolidation claim: interesting, watch it, do not bet a client roadmap on it.

The historical version of the "one architecture" pitch was: pick one engine and ask it to do everything. The warehouse vendors said pick a warehouse. The Hadoop vendors said pick a lake. Each tried to bolt the other half on. Warehouses bolted on object storage. Lakes bolted on SQL. The bolts always showed.

What broke them was the storage layer. A warehouse had its own proprietary file format. A lake had open Parquet but no transactions. ML teams copied data into a third system because neither would serve them. Every workload demanded its own copy, its own latency profile, its own permissions model. By the time you had four copies of "customer master," you had four definitions of customer, four governance gaps, and four bills.

The lakehouse idea — open storage format, ACID transactions on the lake, multiple engines on the same files — was a paper concept in 2020. Databricks built one direction of it. Snowflake built another. Neither solved the unification problem for an enterprise that wanted BI, AI, real-time, and operational reporting under one set of permissions and one bill.

OneLake takes a position that is unusually disciplined for Microsoft. Every Fabric workload — Lakehouse, Warehouse, Eventhouse for streaming, Power BI semantic models — reads from and writes to the same OneLake storage, in the same open Delta Parquet format. Not a copy. The same files.

That sentence is the entire architectural argument. Three things follow from it that, taken together, change the maths.

Shortcuts make data movement optional. A OneLake shortcut is a symbolic link to data sitting in S3, ADLS Gen2, Dataverse, or another OneLake workspace. The data does not move. Authorisation is delegated through cloud connections. If the target is Delta Parquet, it appears as a queryable table immediately. For a manufacturing client whose plant data sits in an on-premises historian replicated to S3, this is the difference between a six-month migration project and a two-week shortcut configuration.

Direct Lake makes Power BI a first-class lake citizen. Until 2024, every Power BI report either imported data into a tabular model (stale within hours) or used DirectQuery (slow, expensive). Direct Lake reads Delta tables in OneLake straight into the Power BI engine — no import, no query translation. A semantic model now hits the same Delta files that a Spark notebook trained an ML model on yesterday, with no copy and no refresh job.

Mirroring closes the OLTP gap. The most honest critique of every lakehouse to date was that operational data — SAP, Oracle, SQL Server, Cosmos — lived elsewhere, and you needed pipelines to drag it in. Fabric mirroring now replicates SAP via SAP Datasphere, Oracle, Snowflake, Azure SQL Database, and Cosmos DB into OneLake as Delta tables, continuously, with no ETL code. SAP mirroring through Datasphere went generally available this year. For a manufacturing or FMCG estate sitting on SAP S/4 or ByD, that single capability removes the most expensive piece of the modern data stack.

The result is one logical store, in one open format, with engines for SQL, Spark, KQL streaming, and Power BI all addressing the same files. The architecture diagram for a Fabric estate that does BI, real-time IoT, and operational AI is not three boxes connected by pipelines. It is one box.

Take a mid-market FMCG distributor: two thousand SKUs, fifteen distribution centres across the GCC, SAP S/4 for finance and supply chain, Salesforce for field sales, a fleet of warehouse barcode terminals streaming pick events, and a board that wants daily margin visibility.

Historically this is a three-platform problem. A warehouse for finance reporting. A streaming platform — Kafka, Spark Streaming, something — for the warehouse events. A separate ML environment for demand forecasting. Three storage layers. Three permission models. Three teams.

Under Fabric, it is one platform with three workloads. The SAP data lands in OneLake through Datasphere mirroring as Delta tables, continuously updated. Finance and supply chain reports point at those tables through Direct Lake in Power BI. No nightly refresh. Numbers update minutes after the SAP transaction posts.

The warehouse barcode events stream into Eventhouse — Fabric's KQL-native streaming database — through Eventstream. Pick velocity, exception rates, and SLA breaches are queryable in KQL in real time, and the same events land in Delta tables in OneLake for the data scientists to use tomorrow.

The forecasting model trains in a Fabric notebook against the same OneLake Delta tables — invoice history from SAP, order pacing from Salesforce, pick velocity from the warehouse stream. The output forecast writes back to OneLake as another Delta table. Power BI shows actual versus forecast in the same dashboard the CFO already reads.

One storage layer. One copy of every entity. One governance model. One bill. You can build that estate today. I have built fragments of it for live clients. The reason it works is not that any one of these capabilities is novel — the reason it works is the unification at the storage layer. Everything sees the same Delta files. Nothing moves. The argument about "whose numbers are right" stops, because everyone is reading the same table.

A practitioner article is only useful if it tells you where the new thing breaks. There are three places I would not yet bet on Fabric as the only architecture.

Heavy ML training still belongs elsewhere. Fabric's data science workload is competent for tabular ML, time-series forecasting, and most enterprise prediction problems. It is not the right tool for large-scale deep learning, foundation model fine-tuning, or anything that wants dedicated GPU clusters. If your roadmap includes computer vision on production-line cameras at scale, you will either run that on Azure ML or Databricks and write the inference outputs back to OneLake. That is fine — but it is a second platform, and the "one architecture" claim has to be read with that asterisk.

Sub-second operational systems are a separate concern. OneLake is an analytical store. It is not a system of record for the application that processes a transaction. Your SAP, your e-commerce platform, your warehouse management system — those continue to need their own operational databases. Fabric mirroring brings their data into the analytical layer continuously, but the operational write path stays where it is. Confusing those two is the most common conceptual error I see in early Fabric conversations.

Cost discipline is harder than the vendor pitch suggests. Fabric's F-SKU capacity model is conceptually elegant — one pool of compute units, all workloads share it — and operationally treacherous. The SKU jumps are large. A poorly written Spark notebook can eat capacity that should have served three Power BI workspaces. Below an F64, you do not get unlimited Power BI viewer access, which matters the moment you have more than a dozen report consumers. Implementations where capacity is treated as an afterthought run thirty to fifty percent over budget in the first year. This is not a reason to avoid the platform. It is a reason to put a Fabric administrator on the org chart before you put one terabyte in OneLake.

There is a fourth caveat worth stating. Fabric is Microsoft. If your data strategy is explicitly multi-cloud, Snowflake's cross-cloud sharing is still ahead. For most of my clients in Manufacturing, FMCG, and Logistics, this is not a meaningful constraint — they are already Microsoft estates, and OneLake's shortcut model lets them reach into S3 anyway.

One announcement from March 2026 deserves more attention than it received. Azure UAE North now supports the full Fabric stack, including Real-Time Intelligence, in-region. That removes the single biggest objection I had been hearing from GCC clients: data residency.

A Saudi manufacturer, a Dubai logistics operator, a regulated UAE entity can now run their entire analytical estate — including streaming, including AI — in-region, on a tenant they own, in an open Delta format they can leave with if they ever want to.

That changes the conversation from "can we use Fabric here" to "what do we move first." The combination of full Fabric in UAE North, SAP mirroring generally available, and Direct Lake out of preview means the three capabilities that historically stalled GCC Fabric deployments are all now in production. There is no sensible reason to be waiting.

If you are an Operations Director, IT Head, or CEO weighing a data platform decision in 2026, the question is no longer whether unified architectures are possible. They are. The question is whether the specific shape of your business — your ERP, your data residency requirements, your existing skills, your appetite for Microsoft dependency — makes Fabric the right unification.

Three quick filters from where I sit. If your estate is already SAP, Dynamics, or Microsoft-heavy, the integration economics now favour Fabric by a wide margin. The mirroring shortcuts alone are worth a serious evaluation.

If your data sits in S3 and you are happy there, OneLake shortcuts let you treat S3 as the back end and Fabric as the analytical surface. You do not have to migrate to unify.

If you have a serious deep-learning roadmap and a strong Databricks team, keep the Databricks. Use Fabric for the BI and operational reporting layer. Write outputs back to OneLake. The two play together through Delta — that is the whole point of an open format.

The thing the platform finally lets you stop doing is the most expensive thing your business has been paying for: arguing about whose numbers are correct, in meetings, instead of acting on them. One copy of the data, governed once, surfaced everywhere, is not a slogan any more. It is an architecture decision you can defend at a board level.

I would not have written this article in 2024. I would have hedged. The platform has caught up with the claim.