Wat is Microsoft Fabric?
Microsoft Fabric is een geïntegreerd analyseplatform waarin diensten voor gegevensinname, data engineering, datawarehousing, realtime analyse en business intelligence samenkomen. Een organisatie kan in één omgeving ruwe gegevens ontvangen, transformeren, modelleren en ontsluiten voor rapportages. Fabric is daarmee geen vervanging van één specifieke Excel-werkmap of Power BI-visualisatie, maar een mogelijke architectuur voor de volledige route van brongegevens naar betrouwbare informatie. De praktische waarde ligt vooral in de gezamenlijke opslag via OneLake, de integratie tussen workloads en de mogelijkheid om beheerafspraken centraal te organiseren.
Het platform is relevant wanneer gegevens verspreid zijn over boekhoudsystemen, CRM, ERP, operationele databases en losse exportbestanden. Zonder gezamenlijke structuur ontstaan meerdere definities van omzet, klant of voorraad. Fabric lost dit niet automatisch op: definities, eigenaarschap en gegevenskwaliteit moeten nog steeds worden ontworpen. Wel biedt het onderdelen waarmee één organisatie die afspraken technisch kan uitvoeren en beheren. De juiste uitgangsvraag is daarom niet welke Fabric-functies beschikbaar zijn, maar welk bedrijfsprobleem een geïntegreerde gegevensarchitectuur moet oplossen.
De belangrijkste onderdelen en hun onderlinge samenhang
OneLake vormt de geïntegreerde opslaglaag. Een lakehouse combineert bestandsopslag met tabellen die onder meer via Spark en een SQL-analyse-eindpunt benaderd kunnen worden. Een warehouse is in het bijzonder geschikt voor SQL-georiënteerde analyseprocessen en gestructureerde bedrijfsrapportage. Data Factory omvat onder meer pipelines en dataflows om bronnen te ontsluiten en bewerkingen te organiseren. Data engineering richt zich op verwerking met notebooks en andere ontwikkelmiddelen. Power BI gebruikt semantische modellen en rapporten om gegevens voor besluitvorming toegankelijk te maken.
Deze onderdelen zijn geen verplichte reeks die altijd volledig geïmplementeerd moet worden. Een team kan een eenvoudige datastroom opzetten die slechts een paar bronnen en een semantisch model gebruikt. In een grotere organisatie komen daar testomgevingen, historisering, beveiliging per gegevensdomein, deployment en capaciteitsbeheer bij. De architectuur hoort mee te groeien met de werkelijke eisen. Een groot technisch ontwerp zonder expliciete informatiebehoefte veroorzaakt vooral kosten, afhankelijkheden en beheerlast.
Eén doorlopend praktijkvoorbeeld: orders uit ERP en CRM
Stel dat een groothandel omzet per klantsegment wil rapporteren. Orders staan in ERP, klantkenmerken in CRM en budgetten in een periodiek Excel-bestand. De financiële afdeling gebruikt de factuurdatum als uitgangspunt, terwijl sales rekent met de besteldatum. Een dashboard dat deze verschillen negeert, kan technisch goed verversen en toch inhoudelijk tegenstrijdige bedragen tonen. Daarom worden eerst de definities vastgesteld: gaat omzet over gefactureerde bedragen, exclusief btw, na creditnota’s, en voor welke periode?
In de innamefase wordt per bron bepaald hoe gegevens worden opgehaald, hoe vaak vernieuwing nodig is en welke bron eigenaar blijft. Een pipeline kan de orders op een afgesproken moment laden; klantkenmerken komen via een aparte verbinding binnen. Daarbij hoort logging: hoeveel records zijn ontvangen, zijn sleutels uniek, hoe worden ontbrekende klantnummers behandeld en wat gebeurt er bij een onbeschikbare bron? Een pipeline die technisch slaagt maar de helft van de orders mist, is geen succesvolle verwerking.
De ruwe gegevens komen bijvoorbeeld terecht in de Bronze-laag van een lakehouse. Daar blijft voldoende informatie beschikbaar om een fout te reconstrueren. In Silver worden dubbele regels, inconsistenties en datatypen aangepakt. In Gold worden de tabellen geschikt gemaakt voor bedrijfsanalyse: een datumdimensie, klantdimensie en feitentabel met orderregels of factuurregels. Een semantisch model legt vervolgens relaties, berekeningen en definities vast; Power BI presenteert de uitkomsten aan gebruikers. De labels Bronze, Silver en Gold zijn architectuurafspraken, geen garantie dat data in Gold werkelijk betrouwbaar is.
Lakehouse en warehouse: hoe wordt gekozen?
Een lakehouse ligt voor de hand wanneer datasets verschillende vormen hebben, wanneer Spark-transformaties een belangrijke rol spelen of wanneer bestanden en tabellen gezamenlijk beheerd worden. Een warehouse sluit vaak beter aan bij teams die vooral T-SQL, relationele structuren en gecontroleerde SQL-processen gebruiken. Fabric ondersteunt combinaties: de keuze hoeft niet voor het hele bedrijf hetzelfde te zijn. Het is belangrijk om per workload de vereiste functies, transacties, beheerervaring, toegangspatronen en prestaties te beoordelen.
Ook de aanwezigheid van een SQL-eindpunt bij een lakehouse betekent niet dat elke SQL-operatie hetzelfde werkt als in een warehouse. Functionaliteit en schrijfmogelijkheden verschillen per onderdeel. Daarom hoort een testscenario te bestaan uit de eigen query’s, verwachte datavolumes en gewenste onderhoudsprocessen. De benaming van een dienst is geen voldoende selectiecriterium; de werkelijke verwerking bepaalt de geschiktheid.
Medallion-architectuur zonder onnodige complexiteit
Een gelaagde inrichting maakt technische bewerkingen en zakelijke definities beter controleerbaar. Bronze bevat bij voorkeur de herkenbare brongegevens plus informatie over herkomst en laadtijdstip. Silver normaliseert datatypen, herstelt of markeert datakwaliteitsproblemen en maakt bronstructuren consistenter. Gold bevat herbruikbare modellen voor analyse. In de praktijk zijn ook andere architecturen mogelijk. Het doel van lagen is niet een verplicht aantal kopieën, maar duidelijke verantwoordelijkheden tussen brondata, bewerking en gebruik.
Voor iedere laag worden acceptatiecontroles ontworpen. Bij Bronze gaat het bijvoorbeeld om tijdige binnenkomst en volledigheid. Bij Silver kunnen dubbele sleutels, lege waarden en referentiële fouten worden gemeten. Bij Gold is het van belang dat bedrijfsdefinities aantoonbaar overeenkomen met afgestemde broncijfers. Een goed ingestelde waarschuwing bij onverwachte aantallen kan meer waarde opleveren dan een uitgebreid dashboard dat fouten pas aan het eind van de maand zichtbaar maakt.
OneLake en shortcuts: gegevens delen zonder alles opnieuw te laden
OneLake maakt gedeelde analytische opslag binnen Fabric mogelijk. Met shortcuts kan in ondersteunde scenario’s worden verwezen naar gegevens op een andere locatie, zonder eerst overal een afzonderlijke volledige gegevenskopie te maken. Dat kan dubbele opslag en ingewikkelde synchronisatie verminderen. Een shortcut is echter geen vrijbrief om eigenaarschap of beveiliging over te slaan: beschikbaarheid, bevoegdheden, verwerkingskosten en afhankelijkheid van de externe bron blijven relevant.
Voor een organisatie die meerdere afdelingen heeft, kan een centraal beheerd gegevensproduct beschikbaar worden gesteld aan verschillende teams. De afdeling Finance beheert bijvoorbeeld een vastgestelde factuurtabel, terwijl commerciële teams die informatie combineren met klantsegmenten. Voordat zo’n verbinding operationeel wordt, moeten de gebruikte identiteiten, bronrechten en afspraken over wijzigingen worden gecontroleerd. Een technisch toegankelijke tabel is niet automatisch een gegevensbron die voor ieder doel rechtmatig gebruikt mag worden.
Semantische modellen en Power BI
Een semantisch model vertaalt fysieke tabellen naar een begrijpelijke informatieomgeving met relaties, measures, opmaak en eventueel beveiligingsregels. Daarmee hoeft niet ieder rapport opnieuw omzet, marge of actieve klanten te definiëren. Het model vormt een belangrijk kwaliteitscontract tussen datateams en informatiegebruikers. Ook wanneer Fabric wordt ingezet, blijft kennis van Power BI-datamodellering en DAX van waarde.
Bij nieuwe modellen hoort een controle op de relatie tussen feiten en dimensies, correcte datumniveaus en de gekozen opslagmodus. Import, DirectQuery en Direct Lake hebben verschillende voor- en nadelen. Direct Lake kan voor geschikte Delta-tabellen interessant zijn, maar de ondersteuning en voorwaarden hangen af van de gebruikte Fabric-architectuur en capaciteit. Prestatie- en beveiligingstests met echte gebruikersrollen blijven noodzakelijk.
Beveiliging, compliance en verantwoordelijkheden
Fabric kent meerdere lagen van autorisatie en governance, waaronder omgevingsrollen, itemrechten en gegevensgerichte beveiligingsmogelijkheden. Het ontbreken van één centraal overzicht van wie gegevens mag zien, is een groter risico dan een onduidelijke rapportkleur. Maak daarom onderscheid tussen de eigenaar van een bron, de beheerder van het platform, de ontwikkelaar van de pipeline en de gebruiker van een rapport. Beheerrechten zijn niet hetzelfde als inhoudelijke bevoegdheid om vertrouwelijke informatie te delen.
Voor persoonsgegevens en bedrijfsgevoelige informatie horen classificatie, bewaartermijnen, toegangscontroles en auditmogelijkheden in het ontwerp. Test ook daadwerkelijk met een account dat de laagste beoogde rechten heeft; een rapport dat voor de ontwikkelaar correct werkt, bewijst niets over de rechten van eindgebruikers. Registreer welke dataset geautoriseerd is, welke uitzonderingen bestaan en welke persoon beslist wanneer een nieuwe gegevensbron toegevoegd wordt.
Kosten en capaciteit onder controle houden
Fabric werkt met capaciteit en verbruik door verschillende workloads. De maandkosten volgen niet alleen uit het aantal gebruikers, maar ook uit de gekozen capaciteit, duur van processen, achtergrondverwerking, opslagpatronen en gebruikspieken. Een onnodig frequente dataload of een inefficiënt notebook kan daardoor dezelfde zakelijke informatie duurder maken. Begin met een proef in beperkte omvang en meet hoe pipelines, notebooks en rapportinteracties de capaciteit gebruiken.
Maak expliciet onderscheid tussen ontwikkelwerk, geplande verwerking en pieken bij interactief rapportgebruik. Stel voor kritieke data een passend vernieuwingstijdstip vast: actuele voorraad kan andere eisen hebben dan een afgesloten financiële maand. Controleer daarnaast de product- en licentievoorwaarden voordat toezeggingen over toegang tot gedeelde Power BI-rapporten worden gedaan. Microsoft past licentie- en capaciteitsvoorwaarden in de loop der tijd aan; actuele contractdocumentatie is daarbij leidend.
Een beheersbaar invoeringsplan in zes stappen
Eerst wordt één informatieprobleem gekozen en een meetbare nulwaarde vastgelegd. Vervolgens worden definities en broneigenaren vastgesteld, inclusief het onderscheid tussen operationele gegevens en geautoriseerde rapportagecijfers. In stap drie wordt een minimaal end-to-end datapad gerealiseerd, bijvoorbeeld van ERP via een pipeline naar een gecontroleerde tabel en één Power BI-rapport. In stap vier worden foutscenario’s getest: dubbele ordernummers, ontbrekende CRM-sleutels, vertraagde bronlevering en mislukte vernieuwingsstappen.
Daarna volgt controle door zowel een technisch beheerder als een inhoudelijke eigenaar. De technische toets kijkt naar herstartbaarheid, logging, prestatie en autorisatie; de inhoudelijke toets naar juistheid van omzet, aantallen en periodefiltering. Pas in de laatste stap wordt besloten welke onderdelen worden gestandaardiseerd, welke teams volgen en hoe releases beheerd worden. Op die manier ontstaat een herhaalbare gegevensketen in plaats van een demonstratie die slechts onder ideale omstandigheden werkt.
Wanneer is Fabric niet de beste keuze?
Niet ieder bedrijf heeft meteen een geïntegreerd analyseplatform nodig. Wanneer er slechts één kleine databron is en de benodigde analyses eenvoudig zijn, kan een bestaande Power BI-oplossing of een zorgvuldig ingericht Excel-proces passend blijven. Fabric heeft vooral meerwaarde wanneer uiteenlopende databronnen, verwerkingsbehoeften, rollen en governance-eisen samenkomen. Een investering verdient onderbouwing met onderhoudskosten, gewenste betrouwbaarheid, verwacht gebruik en de beschikbaarheid van medewerkers die het platform kunnen beheren.
Ook een migratie van bestaande Power BI-oplossingen hoeft niet alles tegelijk te vervangen. Inventariseer eerst datasets, refreshschema’s, gateway-afhankelijkheden en bestaande DAX-measures. Houd goed werkende semantische modellen in stand zolang er geen concrete reden is om ze anders te organiseren. Een gefaseerde migratie beperkt de kans dat businessgebruikers tijdelijk andere cijfers krijgen zonder dat zij weten waarom.
AI en Copilot bij Fabric-analyses
AI-assistenten kunnen helpen om technische documentatie te structureren, SQL of gegevensbewerkingen voor te bereiden en vragen over rapportdefinities begrijpelijk te formuleren. Daarbij blijft controle van gegenereerde query’s, datatoegang en bedrijfsdefinities noodzakelijk. De aanwezigheid van Copilot-functionaliteit is afhankelijk van de dienst, tenantinstellingen, licenties en op dat moment ondersteunde mogelijkheden. Een geautomatiseerd voorstel voor een berekening mag niet ongemerkt de formeel vastgestelde KPI-definitie vervangen.
Een opleiding in Power BI, data-analyse of Fabric moet aansluiten op de gebruikte architectuur en het ervaringsniveau van het team. Waar de organisatie AI inzet voor modellering of analyse, kunnen aanvullende AI- en Copilot-vaardigheden relevant zijn, maar de primaire leerbehoefte van dit onderwerp ligt bij data-architectuur, verwerking en governance.
Conclusie
Microsoft Fabric kan organisaties helpen om versnipperde analyses te verbinden in één beheersbare gegevensketen. Het succes hangt af van een duidelijk gedefinieerd informatieprobleem, betrouwbare bronnen, een passende keuze tussen lakehouse en warehouse, eigenaarschap en aantoonbare kwaliteitscontroles. Een kleine end-to-end proef met echte bedrijfsgegevens geeft een betere basis voor besluitvorming dan een generieke demonstratie van alle beschikbare functies.
Verdieping en training
Voor dit onderwerp kan een passende opleiding of een maatwerktraject worden gekozen op basis van de gebruikte Fabric-onderdelen en verantwoordelijkheden. Training over Microsoft Fabric bespreken →
Bronnen voor verdere verdieping
Microsoft Learn: OneLake, lakehouse-overzicht, data-engineering en Direct Lake. Controleer in de officiële documentatie altijd de actuele beschikbaarheid, beperkingen en licentievoorwaarden.