Spend ten minutes near Microsoft’s data and AI stack and you will collect a pile of words that seem designed to make architecture meetings longer: Fabric. OneLake. Lakehouse. Data lake. Delta Lake. Warehouse. Data agents. Copilot.
Then somebody says “we should probably put all our data in the lake”, everyone nods, and the meeting moves on. It is the boardroom version of agreeing the conditions look great from the car park.
None of these things are really about storing data for its own sake. They are about getting business data into one place where it can be governed, analysed and eventually made useful to AI. For a company running Microsoft Dynamics 365 Business Central that distinction matters, because Business Central holds the transactions and almost never holds everything you need to answer the question you actually care about.
Your data is scattered all over the mountain
Most businesses do not have a data problem. They have a data fragmentation problem, which is a different animal wearing the same jacket.
Business Central probably holds customers, vendors, items, sales orders, purchase orders, inventory, the general ledger, projects and service records. That is a lot. It is also not all of it. Somewhere else you have CRM, e-commerce, payroll, shipping, manufacturing data, contracts, emails, web analytics, support tickets, and the spreadsheet on somebody’s desktop that finance quietly depends on.
The information exists. It is just parked in nine different lots, and none of the shuttles connect.
Now ask a genuinely useful question: which customers are most likely to cut their spend next quarter? Business Central knows what they bought. CRM knows which deals are open. Support knows which of them are furious. E-commerce knows what they have been browsing and not buying.
Every one of those is a piece of the answer. Sitting in separate systems, they are four people describing different parts of the same slope over a bad radio. This is the entire reason modern data architecture exists.
A data lake, and how it becomes a swamp
Start with the simplest one. A data lake is a large store where you can drop data in many shapes: structured tables, semi-structured JSON, CSVs, Parquet, logs, images, documents, machine output. A relational database wants everything to arrive in uniform. A lake does not care.
That flexibility is the point, and it is also the trap. Left ungoverned, a data lake becomes what the industry calls a data swamp: a place where the data technically exists but nobody can tell you what it means, whether it is current, who owns it, or whether it can be trusted.
What a lakehouse actually adds
A lakehouse takes the flexibility of a lake and bolts on the things a warehouse was always good at: structure, consistency, reliable analytics. Not a compromise so much as a pair of skis that will hold an edge and still float.
In Microsoft Fabric, a lakehouse stores its data in OneLake and handles both files and structured tables. Those tables use Delta Lake format, which is what gives you transactional consistency instead of a directory full of files and a lot of hope. You can work with the same lakehouse through Spark or through SQL.
This does not mean warehouses are finished. It means you have another shape available when your data will not sit still long enough to be modelled up front.
OneLake is not a lakehouse
This is where the naming starts making people reconsider their career, so read this bit twice.
OneLake is the single unified data lake for your whole organisation. A lakehouse is one of the things that lives in it.
Every Fabric tenant gets exactly one OneLake, automatically. You cannot delete it and you cannot have two, which is deliberate — the whole idea is that departments stop building their own private lakes nobody else can find. It is built on Azure Data Lake Storage and keeps tables in open Delta Parquet or Iceberg format, so other tools can read them without a migration project.
Inside that one lake you have workspaces, and inside workspaces you have the actual items: lakehouses, warehouses, eventhouses, KQL databases. One mountain, many runs, one trail map.
Where Fabric sits in all this
If OneLake is the ground, Fabric is the resort built on it. It brings Data Factory, data engineering, data science, warehousing, real-time intelligence, Power BI and the AI and Copilot experiences into one place, all working against that shared foundation.
The argument for it is not that any single piece is revolutionary. It is that you stop building one platform for ingestion, a second for engineering, a third for analytics and a fourth for AI, then spending a year teaching them to talk. Fewer lifts, same mountain.
Why any of this matters to AI
AI needs data. Not just any data — relevant, reachable, understandable, governed data.
Ask a model “why did our gross margin drop this quarter?” and it has no idea about your sales, costs, inventory, discounts, purchasing, customer mix or product mix. If those live in five systems, you have two options: hand-feed it context forever, or build somewhere it can go and look.
That is the actual difference between asking a general-purpose chatbot a question and running an enterprise AI system. One is a conversation. The other has a governed place to retrieve from.
Bronze, silver, gold
Here comes another term that sounds worse than it is: medallion architecture. It is three stages, and you already understand all of them.
Bronze — raw
Data exactly as it arrived. Business Central exports, CRM records, CSVs, API responses, logs. Resist the urge to tidy it. This is your untouched snow, and you will want it later when somebody asks what really happened.
Silver — cleaned
Standardised customer IDs, sane dates, normalised product codes, duplicates gone, business rules applied consistently. The groomer has been through.
Gold — business-ready
The layer analysts, Power BI and AI should actually consume. Rather than handing a model seventeen tables and three CSVs with a cheerful “good luck”, you hand it something like Customer Profitability, with defined metrics and stated relationships.
Here is why the gold layer is not optional if AI is involved. If two systems identify the same customer differently, the AI cannot reliably tell they are the same customer. If inventory is stale, it will recommend from stale inventory. If margin is defined three ways, it will pick one and never mention it. Garbage in, garbage out — except AI makes the garbage articulate, confident and beautifully formatted.
RAG, in one paragraph
Retrieval-Augmented Generation is the acronym you will hear next, and the idea is almost disappointingly simple: instead of making the model answer from whatever it absorbed in training, you let it go and fetch your information first, then answer. Question in, relevant company data retrieved, answer generated from that. It is the difference between asking a local and asking somebody who once read about the area.
Which is exactly why your data architecture matters. RAG needs somewhere trustworthy to retrieve from. If that somewhere is a swamp, RAG will confidently retrieve swamp.
Fabric data agents
A Fabric data agent lets people ask questions of governed organisational data in plain English — “what were our top five customers by revenue last quarter?” — without knowing how a single table is structured. It translates the question into SQL, DAX or KQL depending on where it is pointed, then runs it. They are generally available, not preview.
Two details worth knowing before anyone gets excited. An agent can draw on up to five data sources in combination — lakehouses, warehouses, Power BI semantic models, KQL databases and more — and it is read-only. It cannot write, update or delete. That constraint is a feature, and it is the same principle as designing an integration layer where read and write are separate decisions.
It also runs on paid Fabric capacity, which is the point at which this stops being an architecture conversation and starts being a budget one.
Business Central is one piece, not the whole picture
Back to that question about which customers are about to spend less. Business Central gives you purchase history, customer records, product mix and order frequency. CRM adds opportunities, interactions and account activity. Support adds complaints and satisfaction. E-commerce adds browsing, searches and online orders.
An AI system reasoning across all four is genuinely useful. Getting the data into a shape where that reasoning is reliable is the entire job, and it is a data engineering job, not an AI one. Fabric does not remove the need for good data engineering. It raises the return on it — and it will not paper over the technical debt already sitting in your ERP either.
Do you actually need any of this?
Here is where the consulting advice gets less thrilling than the keynote.
No. Plenty of Business Central companies should not go anywhere near Fabric.
One ERP, straightforward reporting, modest data volumes, few integrations, no real AI programme — adding Fabric buys you complexity and a capacity bill. Business Central plus Power BI plus Power Automate is not settling. For a lot of companies it is simply the correct architecture, and the discipline to stop there is worth more than the platform.
Fabric earns its place when the picture genuinely gets bigger: multiple enterprise sources, serious history, complex analytics, several business units, data science, machine learning, real-time reporting, actual governance obligations, or an AI programme that needs to reason across systems. The more fragmented you are, the more a unified foundation pays for itself.
Do not start here
This is the most important line in the article, so it gets its own run.
Do not start with “we need Fabric”. Start with which business questions can we not answer today? Then: what data would answer them? Then: where does that data live? Then: how should it be governed? Then, and only then: what architecture exposes it to analytics and AI?
By the time you reach that last question you will know whether Fabric belongs in the answer, and you will be able to say why in one sentence. The technology follows the problem. Every expensive data platform failure in history went the other way.
The real advantage
The future of enterprise AI is not a chatbot bolted to Business Central. It is a system that can reason across your ERP, your CRM, your inventory, your customers, your vendors, your documents, your financial history and your operational systems at once.
Getting there requires something considerably less exciting than any of the product names in this article: good data architecture. The companies that win at this will not be the ones who bought the most platform. They will be the ones who knew which question they were trying to answer, and built only what that question needed.
