July 03, 2026

Friday Fabric Facts #9: Your Lake Is Not a Product: Fabric Wants You to Think in Domains

The Executive Insight

Most teams still talk about “our Fabric environment” as if it were one big thing: one lake, one platform, one tenant they hope to keep under control.

Fabric itself doesn’t see it that way.

Look at the direction of the platform: domains, data mesh language, data products, federated governance. Microsoft is pushing you—gently but clearly—toward a different mental model:

The tenant is the infrastructure.
Domains are how the business shows up inside that infrastructure.
Data products are the units of value domains publish and consume.

Your lake is not a product. It’s the substrate. What Fabric really wants from you is: “Which domains own which parts of reality, and what products are they responsible for?”

The Quiet Anti-Pattern: One Giant “Enterprise” Workspace

In organizations just getting started, there’s a common survival tactic:

Create an “Enterprise Analytics” or “Central Data” workspace.
Put everything in it: lakehouses, warehouses, semantic models, reports.
Treat it as “the platform” and call it a day.

For a while, this feels neat and safe. There is:

One place to look.
One team “protecting” the data.
One set of people with permissions to change things.

But as Fabric adoption grows, cracks appear:

Sales wants to move faster and add their own metrics.
Operations starts building their own pipelines.
Finance wants stronger control over definitions and release cycles.
Different groups ask for different RLS rules, refresh timing, and compliance posture.

What started as a single “enterprise” container quietly turns back into the problem you thought Fabric would solve: central IT, surrounded by a ring of disconnected exports, copies, and side projects.

Domains exist so you don’t have to choose between “central everything” and “total chaos.”

What a Domain Actually Is (and Isn’t)

Microsoft’s definition is deliberately simple:

“A domain in Fabric is a logical grouping of workspaces, data, and items that share a common business context—such as Sales, Marketing, Finance, HR.”

But there are two details that matter if you read further:

Domains come with their own admins and contributors—people who can manage settings, associate workspaces, and override some tenant policies, within limits.
Domains are designed to support data mesh principles: decentralized ownership, localized governance, but with shared discoverability and standards.

A domain is not:

Just a category tag.
Just a prettier folder.
Just a “view” in the UI.

A domain is where ownership and responsibility live.

When you say “Finance domain,” you aren’t just saying “these things are about finance.” You’re saying:

These people own the finance view of reality.
They decide what counts as an official finance data product.
They are accountable for its quality, access, and evolution.

Fabric gives you technical knobs for this—domain admins, delegated settings, domain‑level governance—but the important part is the decision: who owns what slice of the truth?

Data Mesh, Without the Buzzword Bingo

Vendors have over‑marketed “data mesh” to the point of fatigue. But if you strip away the jargon, the core ideas still matter, especially on Fabric:

Domain-oriented ownership: Data should be managed by the teams that understand it, not only by a central platform group.
Data as a product: Each domain produces and maintains data assets that are usable, documented, trustworthy, and discoverable by others.
Self-serve platform: Central teams provide the tooling and guardrails; domains build products on top.
Federated governance: Security and compliance are consistent, but implemented close to where the data lives.

Fabric is one of the first mainstream platforms that bakes those assumptions into the core:

Domains as first‑class objects.
OneLake as a single underlying store, logically segmented but physically unified.
Workspaces as domain boundaries or sub‑domains.
Purview integration and delegated domain‑level governance.

You don’t have to hang a “data mesh” banner over your program. But if you ignore those patterns, you’re fighting the grain of the platform you bought.

A Real Pattern: When “Source-Aligned” Fights “Business-Aligned”

One of the more interesting domain debates I see is exactly the one Fabric’s own best‑practice content calls out:

“Do we organize domains by source systems or by business capabilities?”

Two archetypes:

Source-aligned domains: SAP, CRM, EHR, POS, etc.
Business-aligned domains: Sales, Finance, Supply Chain, Clinical, Marketing.

Source‑aligned often feels neat to IT:

Clear mapping to existing system ownership.
Easier to reuse governance, access rules, and SLAs from the source system.
You can keep your mental model: “This is the SAP domain; that’s the CRM domain.”

Business‑aligned matches how decisions are actually made:

Finance doesn’t care which system a number came from; they care if it’s the finance truth.
Supply chain leaders think in terms of “inventory,” “lead time,” “service level,” not “which database this field lives in.”
AI agents and Copilot need conceptual entities like “Customer,” “Order,” “Claim,” not “Table X in Source Y.”

Fabric’s own guidance leans toward business‑aligned domains, precisely because the platform is trying to bridge data and decision‑makers, not just replicate system silos.

What I see working in practice is often a hybrid:

Business‑aligned top‑level domains (Finance, Sales, Operations…).
Source‑aligned subdomains or workspaces within them when that helps with lineage and responsibility.

The key is not which taxonomy you pick. It’s whether every domain has a clear purpose, clear owners, and clear products.

Data Products: The Unit of Trust Between Domains

Once you accept that domains are where ownership lives, the next question is: what exactly are they owning?

This is where data product thinking becomes useful.

Thoughtworks, Microsoft, and several Fabric communities all converge on similar principles:

A data product isn’t:

Just a table.
Just a lakehouse.
Just a report.

It’s a bundle with:

A clear purpose (“forecast‑ready demand signal for the next 90 days”).
A defined schema and contract—including what’s stable and what can change.
An owner and SLOs (freshness, availability).
Documentation and discoverability in the catalog.
Access controls that match its sensitivity.

Fabric gives you the pieces to express that:

A lakehouse or warehouse as the physical store.
A semantic model to define how business sees it.
Reports, SQL endpoints, or APIs as “outports” for consumption.
Domains and Purview to register, label, and govern it.

When you start asking, domain by domain, “What are our actual data products?” the platform starts to make more sense:

The Finance domain might own “Financial Statements,” “Margin Bridge,” and “Working Capital KPIs” as products.
Sales might own “Pipeline Health,” “Customer 360,” “Revenue by Segment.”
Operations might own “Inventory Position,” “Service Level Performance,” “OTIF Metrics.”

Now Fabric isn’t just “a lake and some workspaces.” It’s a marketplace of products with clear labels and vendors.

Hope for Lean Teams: Start with One Domain, One Product

All of this can sound like theory if you’re a lean SMB team with a handful of people and no appetite for giant operating model projects.

The good news: you don’t need a full data mesh to benefit from domain and product thinking.

You can start extremely small:

Pick one domain that already behaves like a team: maybe Finance, maybe Operations.
Within that domain, pick one data product that is already de facto critical (e.g., margin dashboard, demand plan, cash forecast).
Make that product intentional in Fabric:

What usually happens next:

People from other areas start asking, “Can we get a product like that for our domain?”
The conversation shifts from “What report do you want?” to “What product do you need, and who should own it?”
The first domain becomes a pattern you can copy, not a one‑off hero effort.

You’re not “rolling out a data mesh.” You’re doing something more grounded: teaching the organization that data isn’t a project—it's a portfolio of products with owners.

Fabric’s domains and OneLake hub then become tools to scale that mindset, not buzzwords to decorate a slide.

Where I Fit In (For Partners and Leaders)

Most Fabric conversations still start with:

“Should we use lakehouse or warehouse?”
“How do we organize workspaces?”
“How do we turn on Copilot safely?”

Those are important, but they’re all downstream of one more fundamental question:

“What are our domains, and what data products are they responsible for?”

I work with:

Partners who need a coherent data product and domain story when they pitch Fabric—not just a feature tour.
CIOs, CDOs, and CTOs who are tired of rebuilding platforms every few years because no one ever fixed the ownership model.
Business leaders in F&B, healthcare, and energy who know their competitive edge is locked up in domain knowledge, but don’t yet have a structure to turn that into durable data products.

My role is to help you design:

A domain map that reflects how your business actually thinks and operates.
A data product portfolio that turns Fabric from “shared infrastructure” into “shared value.”
A set of lightweight conventions (naming, ownership, contracts) that your teams can actually live with—not just nod at in a workshop.

If you’re investing in Fabric and you suspect the real bottleneck isn’t the tech but the lack of a domain and product frame, that’s where it makes sense to talk.