Do You Really Need Domains in Microsoft Fabric? An Architect’s Perspective

Yooo, what's up. Let's talk about domains in Fabric, but not from a feature perspective, but more from a enterprise architecture perspective. Today, I'm seeing these two extremes. We have people enabling domains all over the place, but maybe not understanding why. On the other hand, we have people ignoring domains completely. Both approaches might be wrong. First of all, let's clear something up. Domains inside of Microsoft Fabric. They're not a compute boundary or a security boundary or a network boundary. They are, however, a business aligned governance construct, and they will help you organize your workspaces, your data assets, your ownership structures, and link them towards your business capabilities like sales, finance, HR, marketing, and so on. And now you're probably like, but wait, Marthe, what about the governance stuff that you've been talking about, like applying a default sensitivity label to one domain? Or you could also decide that all the workspaces connected to that domain will be connected to one capacity. Yes, that's true. You could definitely do these things with domains, but if you think that domains are gonna solve your security setup or your access control setup, they're just not. For that you have to also think about the workspace level. Okay. So here is where most people miss the mark on the domain discussion. You're not designing domains for today, you are actually designing domains for the point in time when you are hitting hundreds of workspaces. When you need to move towards decentralized development, then you want to enable self-service at scale or when you want to move towards federated ownership, then domains are gonna make a lot of sense. So when you are reaching that point of maturity without domains, discoverability will be very noisy and challenging to find stuff. Ownership will become unclear. You might see that duplication is increasing, and then you have a governance that becomes reactive to the challenges that you already have. And I've seen this happen. Flat structures, they don't fail immediately. They fail when you start scaling. So now you think well done, Marthe. Great selling points for domain. You love everything governance, so of course you're gonna talk a lot about domains. Yes, I know, I know, I know. But let me say something that might surprise you. If you have 30, 40 workspaces only, you have a centralized BI team, no formal ownership model and no stewardship layer, and also speed is more important to you than structure inside of Fabric. Then domains could be more a pain than enabling you in your architectural journey, because now you would need, uh, domain definitions. You need to know what a domain is inside of your organization to set it up. You need to have domain owners, you need governance alignment. All of that also requires a lot of change management. Of course, you could always introduce domains at a later point, but this is a big but. Retrofitting governance that can be quite painful. So keep that in mind. All in all, I think the question is not a technical one, if you should use domains or not. It's organizational. So yes, I think domains make a lot of sense if you're working with enterprise at scale. I don't think domains are gonna make life better for you if you're still looking at Fabric from a pilot face, and you should really consider architecting for where you're going. Not for where you're at right now. Okay. Let me know what you think. Definitely maybe a bit of a different video from my end. If you liked it, hit the like button on this video and let me know in the comments below what your thoughts on domains are. If you haven't already, make sure to subscribe and as always, from Adam, Patrick and this gal right here. Thank you so much for watching and we will see you guys in the next video. Bye.