Fabric in Production: Governance Patterns That Actually Hold

There's a moment in every Microsoft Fabric adoption that nobody puts in the business case. It's not the first workspace, or the first lakehouse, or the first report that makes an executive nod. It's the day you look up and realise you have forty workspaces, nobody can say who owns half of them, two teams have quietly built the same customer table three times, and last month's capacity bill arrived with a number attached that made someone in finance send a very direct email. That moment is not a Fabric failure. It's Fabric working exactly as designed — a platform that makes it gloriously easy to create things, and says nothing at all about whether you should. The governance is your job, and if you don't design it deliberately, the platform will happily let you build a swamp at speed.

I've now watched enough organisations cross that line to know which governance patterns hold under production load and which ones are comforting fictions that collapse the first time real teams and real money get involved. Here's the honest version.

Topology: domains over sprawl

The first thing that falls apart is workspace organisation, because the default — let every team make workspaces as they need them — is not organisation at all. It's entropy with a start button. The pattern that holds is to impose a domain topology early: group workspaces by business domain (finance, supply chain, customer), give each domain a clear owner, and treat the domain as the unit of governance rather than the individual workspace. Fabric's domain concept exists precisely for this, and the organisations that adopt it before they have fifty workspaces are the ones still sane at a hundred.

Within a domain, the medallion layering (bronze → silver → gold) still earns its keep, but the discipline that matters is separating where data is refined from where it's consumed. Analysts should build on governed gold, not go spelunking in bronze because it was easier. If your gold layer isn't good enough that people prefer it, they'll route around your governance, and no policy document will stop them.

Capacity: govern the CU or the CU governs you

The second thing that falls apart is cost, and it falls apart faster than anything else. Fabric's capacity model — everything drawing from a shared pool of Capacity Units — is elegant right up until a single badly-written notebook or an over-eager refresh schedule burns a day's compute in an afternoon and throttles everyone else's work. I've written before about treating cost as a first-class design constraint; in production that stops being advice and becomes survival.

The pattern that holds is active capacity governance, not passive billing:

• Separate capacities by domain or criticality, so one team's runaway job can't starve the finance close. Shared-everything is cheapest until it isn't.
• Watch the smoothing and bursting behaviour rather than trusting it. Fabric will absorb spikes by borrowing against future capacity; that's a feature until the borrowing becomes structural and you're permanently throttled.
• Attribute consumption to teams. If nobody knows whose workload cost what, nobody has any reason to fix the expensive one. Visibility is the whole of FinOps.
• Set the alert before the incident, not after. The email from finance should never be the monitoring system.

None of this is exotic. It's the same operational discipline any shared resource demands. What's specific to Fabric is how quiet the failure is — you don't get an outage, you get a slow degradation and a large invoice, which is harder to notice and harder to argue about.

Access and lineage: govern once, at the source

The third thing that falls apart is access, usually at the worst possible moment — a risk review, an audit, or the day someone realises a report exposed something it shouldn't. The pattern that holds is to govern data access at the data, not at the report. Row-level and object-level security enforced in the semantic model and the lakehouse survives; permissions bolted onto individual reports do not, because there's always one more report, one more export, one more copy.

This is also where Fabric's integration with Microsoft Purview stops being a slide and starts being load-bearing. Sensitivity labels that travel with the data, lineage you can actually query when someone asks "where did this number come from," a catalogue that makes the certified gold dataset discoverable so people stop rebuilding it — these are the difference between an estate you can defend and one you can only apologise for. With the EU AI Act's high-risk obligations now arriving as real deadlines, "we can show the lineage" has quietly become a production requirement, not a nice-to-have.

Deployment: stop editing production by hand

The least glamorous pattern is the one that prevents the most three-in-the-morning incidents: separate dev, test, and production workspaces, and move changes between them with deployment pipelines, not by editing the live thing and hoping. Every organisation knows this in the abstract and a surprising number still tweak production reports directly because it's faster. It is faster, right up until the tweak breaks the board pack an hour before the board meeting. Treat Fabric artefacts like the software they are: version them, promote them, and keep humans out of production except through the pipeline.

The pattern behind the patterns

If you reread the list, every pattern that holds has the same shape: govern deliberately and once, at the right layer, before the scale arrives — and every pattern that collapses has the shape of a shortcut taken under deadline that seemed harmless in isolation. That's not a coincidence, and it's the same lesson the first ninety days on Fabric teach anyone paying attention. The platform's greatest strength — how easy it makes creation — is precisely what generates the mess, because it removes every natural point of friction where governance used to happen by accident.

Here's the counter-view, because it's a fair one: you can over-govern, too. I've seen organisations so wrapped in approval gates and mandatory reviews that nobody can ship a report without a fortnight's ceremony, and that's its own kind of failure — the swamp's tidy, joyless cousin. The patterns above are meant to hold without strangling delivery: domains give ownership without central bottlenecks, capacity attribution creates accountability without approval queues, source-level security means people can build freely on data that's already safe. Good governance in Fabric feels less like a gate and more like guardrails — you go fast because the dangerous moves are quietly prevented, not because someone's checking your work.

Fabric in production is not hard because the technology is hard. It's hard because it asks you to make dozens of small governance decisions before you can feel their consequences, at exactly the moment when skipping them is easiest and most tempting. Make them anyway. The estate you can still run at a hundred workspaces is built by the person who governed the first ten as if the other ninety were already coming — because they were.