Hoe richt je Microsoft Fabric in
De inrichtingsbeslissingen die je in de eerste maand neemt en jaren met je meedraagt: tenant, capaciteiten, workspaces, domeinen en governance.
25 april 2026
Stap 1: Tenant-instellingen en vangrails
Loop vóór de eerste workspace de tenant-instellingen door: wie mag Fabric-items maken, wat mag naar buiten (export, delen met externe gebruikers), en welke preview-features zet je bewust uit. Een open tenant "om te beginnen" wordt binnen maanden onbeheersbaar.
Beslissing: vrijheid per persona. Data engineers krijgen meer ruimte dan casual gebruikers, regel dat met security groups, niet met individuele uitzonderingen.
En beslis Private Link vroeg: het is een tenant-brede instelling die bij inschakeling bepaalde features tijdelijk kan raken, en terugdraaien is ingrijpend. Test het in een aparte tenant voordat je het aanzet.
Stap 2: Capaciteitsstrategie
Bepaal hoeveel capaciteiten je nodig hebt en waarvoor. Eén grote capaciteit is efficiënt maar maakt iedereen buurman van elkaar; gescheiden capaciteiten voor ontwikkeling en productie voorkomen dat een experiment je maandrapportage platlegt.
Beslissing: minimaal een scheiding tussen productie en niet-productie. Richt vanaf dag één capacity monitoring in, throttling ontdek je anders pas als gebruikers klagen. En weet dat de home region van de capacity je data residency bepaalt: wie EU-residency belooft, legt die keuze hier vast.
Stap 3: Workspace-topologie
Kies een indelingsprincipe en houd je eraan. Per datadomein (verkoop, logistiek, finance) met gescheiden workspaces per omgeving (dev, test, prod) is voor de meeste organisaties het houdbaarst. Vermijd indeling per team of per persoon, organisaties reorganiseren, domeinen blijven.
Beslissing: naamgevingsconventie vóór de eerste workspace, niet erna. Hernoemen kan, maar alle verwijzingen opruimen is vervelend werk.
Stap 4: OneLake en domeinen
Richt domeinen in die je datalandschap weerspiegelen en wijs domein-eigenaren aan. Gebruik shortcuts om bestaande data (ADLS, S3, Dataverse) te ontsluiten zonder kopiëren, elke kopie die je voorkomt, is governance die je niet hoeft in te halen.
Stap 5: Deployment en versiebeheer
Koppel workspaces aan Git en richt deployment pipelines in van dev naar test naar prod. Doe dit bij het eerste echte project, niet "later", achteraf toevoegen betekent handmatig migreren van alles wat er inmiddels staat.
Stap 6: Monitoring en kosten
Richt de Capacity Metrics-app in, stel alerts in op langdurig hoge belasting en maak iemand eigenaar van het capaciteitsbudget. Bespreek maandelijks welke workloads de capaciteit verbruiken; de grootste verbruikers zijn zelden de belangrijkste workloads.
De volgorde doet ertoe
Vangrails, capaciteit en topologie eerst; content daarna. Elke week eerder "gewoon beginnen" koop je terug met maanden opruimen, dat is de minst leuke vorm van datamigratie die er bestaat.