Microsoft Fabric: De lessen & ervaringen uit 3 implementatieprojecten

Goede vraag, Pieter. Die vraag stel ik mezelf ook elke dag. Want ja, hoe kan het nou dat je van een stoffige alfaopleiding toch een beta-achtige baan uitvoert? Maar ik denk dat met name de raakvlakken liggen tussen de opleiding geschiedenis en het werk dat ik nu doe bij Always Be Learning, in het hele analyserende aspect dat erbij komt kijken. Bij de opleiding geschiedenis moest je veel informatie kunnen analyseren, distilleren en daar een mooi verhaal van kunnen maken. En dat pas je eigenlijk ook toe bij de verschillende opdrachten die we bij Always Be Learning doen.

Ja, hoe kan het lopen? Bij mij komt dat eigenlijk door mijn vader. Mijn vader was voor Feyenoord en die nam ons mee op de open dag naar de Kuip. Als je één keer in de Kuip komt, ben je verkocht. En toen, met mijn broer, ging het van kwaad tot erger. We begonnen met de seizoenkaart. Dat houden we nu al aardig wat jaren vol.

Het is nog niet helemaal zeker, maar de bal rolt nu naar Midden- en Zuid-Amerika. Dus langzaamaan krijgen we een beetje een plan.

Je moet Spaans leren.

Ja, sí, klaar.

Fabric is eigenlijk een heel allround dataplatform van Microsoft, waarin Microsoft tegenwoordig heel veel functionaliteiten heeft ondergebracht. We zijn ooit begonnen met Power BI, waarin al heel veel bedrijven dashboarding bouwen. Daarnaast had je Azure Synapse voor data engineering, voor het ontsluiten van data uit de bron. En tegenwoordig hebben ze dat ondergebracht in één groot platform, dat ze Fabric hebben genoemd.

Nou, het is een beetje een Zwitsers zakmes van de datawereld. Je hebt eigenlijk alles wat je nodig hebt op één plek. Of tenminste, zo verkopen ze het in ieder geval. En dat is grotendeels ook wel zo, denk ik.

Ja, dat noemen wij dan het ETL- of ELT-proces. Daar zitten veel stappen in, maar het belangrijkste is de data eruit halen, extract, de E. En dan heb je de T, transform, en de L, load. En voor al die stappen, en nog veel meer, hebben ze wat gevonden. Dat is eigenlijk de kern. Voor het eruit halen heb je nu Fabric Data Pipelines, dat vroeger Data Factory heette en technisch ook bijna hetzelfde is. Daarmee heb je heel veel connectors en kun je eigenlijk heel makkelijk pipelines maken om data mee op te halen en eventueel te transformeren. Er zit ook een mooie computekern in, Spark. Tegenwoordig kun je ook gewoon Python en wat andere dingen draaien, maar Spark is eigenlijk de kern waar het meest op draait. Daar kun je notebooks en code op draaien en al je transformaties mee doen. Het heeft OneLake, dat is eigenlijk de opslag waar alles in landt. Dat kan in verschillende vormen. Ik denk dat de kracht ervan is dat het eigenlijk een soort abstractieniveau is. Een soort grote black box waar je alles in kan stoppen en er weer uit kan halen wat je nodig hebt, zonder dat je je heel druk hoeft te maken over wat er allemaal gebeurt. En uiteraard, als sluitstuk, Power BI aan het uiteinde, waarmee je mooie rapportages aan eindklanten kan laten zien. En van al die stappen kun je ook net wat andere onderdelen gebruiken of dingen uitwisselen. Maar dat is eigenlijk de kern van waar de meeste mensen het voor zullen gebruiken.

Zeker. Zoals Sil zei, is het een veelzijdig platform waarop je eigenlijk een heleboel kan. Je hele end-to-end dataplatform kan je erin beheren, optuigen en ook opschalen. Het is ook heel flexibel. Maar zo kent het natuurlijk ook meerdere functionaliteiten. Zo kan je er bijvoorbeeld ook machine learning-methodes op toepassen. Dus je kan dat stukje data science ook betrekken bij Fabric en op je data loslaten. En ja, eigenlijk komt het hele spectrum van data analytics in zijn totale breedte weer terug, van engineering tot analyse.

Een stukje governance ook wel.

Nou, ze hebben een losse tool, Purview, die steeds meer integreert met Fabric zelf. Maar ze hebben tegenwoordig ook de OneLake Catalog, zoals dat heet. Daar proberen ze ook steeds meer functionaliteiten aan toe te voegen, zodat je een beetje kan inzien wat er allemaal aan data is. En volgens mij ook een stukje classificatie tegenwoordig. En streaming hebben we ook al genoemd. Streaming kan tegenwoordig ook best goed voor streaming data. Denk aan IoT, dus apparaten of sensoren die data streamen. Dat kun je ook mooi via Fabric doen.

Ja, dat is een goede vraag. Ik denk: als het continu streamt. En wat is dan continu? Ja, bij wijze van spreken elke seconde, of misschien zelfs elke milliseconde, iets in die richting. Dan kun je spreken over streaming. Maar dat is denk ik ook vaak de bron. Een temperatuursensor die continu temperatuur doorgeeft, dat is bijvoorbeeld echt een streamingbron. Of iets wat continu transacties doet.

Het moet ook event driven zijn. Dus een bron moet ook kunnen sturen. Maar het gaat vooral om realtime events die je continu opvangt.

Ja, en die ontbreekt vaak.

Ook niet superlang. Ik weet niet het exacte jaar, maar ik zit te denken ergens rond 2016 tot 2020. In die periode is Synapse denk ik op de markt gekomen. En daarvoor had je SSIS bijvoorbeeld, SQL Server Integration Services. Dat was vooral on-premise gericht, op eigen databases en het maken van packages. En je hoort het nog steeds: bedrijven gebruiken dat soms nog. Dat is geëvolueerd in Data Factory, dus die functionaliteit van data ophalen, verwerken en neerzetten zit in Data Factory. En ik denk dat rond die tijd ook Synapse is ontwikkeld, waar dan het stukje Spark vooral in zat. Dat maakt je ook een stuk flexibeler dan alleen maar bijvoorbeeld SQL op een database. Je hebt dan meerdere talen, en je kan je taken natuurlijk verspreiden. Dat is een beetje de kern van wat het doet: dat je een soort cluster hebt van workers en één driver die het werk verdelen, zodat je big data kan processen.

Ja, en het zijn ook grotendeels de tools die er al waren, maar samengevoegd, iets verbeterd, iets aangepast en in één jasje gestoken. Zo vertel ik het vaak.

Ik denk ook dat het gewoon een logische opbouw is in de ontwikkeling die Microsoft heeft gemaakt. Van eerst het on-premise stuk meer de cloudfilosofie volgen. Azure en de Data Lake waren daar het eerste stapje van, met de Azure-cloudomgeving. En nu is dat eigenlijk samengebracht in één nieuwe naam: Fabric.

Een beetje de multitool van de hele gereedschapskist, waarmee eigenlijk alles kan.

Maar we zien nog steeds heel veel bedrijven met on-premise SSIS. Daar wordt zeker nog veel in gewerkt, en het heeft op die plekken ook nog wel zijn waarde. Alleen je ziet dat er nu vergelijkbare tooling in Fabric is, waarin je vaak hetzelfde kan, maar ook nog meer, omdat daar veel op doorontwikkeld wordt.

Nou ja, als jij je dataplatform on-premise hebt staan, zullen je ETL-tools ook on-premise draaien. En als je veel in die on-premise bronnen werkt: soms kan het ook niet zo makkelijk naar de cloud. Je hebt tools die niet zo makkelijk naar de cloud te brengen zijn. Maar we zien toch wel veel bedrijven die die stap richting cloud maken, qua schaalbaarheid. Het is vaak zo: als je al wat hebt, stap je daar niet zo makkelijk van af.

Ja, en een niet-technische reden kan natuurlijk zijn dat je data hebt die je niet in de cloud wil hebben. Dat kan ook een afweging zijn. Dat je denkt: ik heb hele gevoelige data. Het is van Microsoft, waar gaat dat dan heen? Ja, het staat wel in een Nederlands datacenter, maar je weet niet helemaal zeker of het wel hier blijft, et cetera. Het kan een afweging zijn om juist te zeggen: ik ga het niet in de cloud doen. Met de ontwikkelingen rondom Amerikaanse bedrijven en de president op dit moment.

Nou, ik denk vooral Databricks. Dat is iets wat je heel veel hoort en ook veel in de markt ziet.

Ik denk dat Snowflake ook veel genoemd wordt als platform, als tegenhanger.

En Google, de Google-stack. Die hebben eigenlijk ook vergelijkbare tools, maar dan volledig op Google gebaseerd. Daar zitten volgens mij ook verschillende modules in, toch?

Zoals BigQuery en Google Cloud Platform.

Dus er zijn denk ik best wel wat alternatieven. Maar als je echt één op één gaat kijken, dan hoor je denk ik het meest Fabric, Databricks en Snowflake. Vooral Fabric en Databricks is echt een keuze die veel organisaties maken.

Ja, en ik denk op moduleniveau heb je wat meer alternatieven. Maar echt als geheel platform zijn dit wel de alternatieven.

Je hebt tooling die heel sterk is in bijvoorbeeld het ETL-stukje. En in dashboarding heb je natuurlijk ook alternatieven. Power BI is dan de variant van Microsoft, maar je hebt ook Tableau.

Dus daar heb je natuurlijk wel alternatieven, maar echt als platform denk ik dat Databricks daarnaast een van de veelgebruikte is.

Ja, want Databricks is onafhankelijk van de onderliggende infrastructuur. Je kan Databricks ook draaien op Google of op Amazon, en dus ook op Azure of Microsoft. Dat is onafhankelijk. Je kan het ook samen gebruiken natuurlijk. Je kan Databricks en Fabric naast elkaar zetten. Er zijn ook wel bedrijven die dat doen, maar je moet er wel een goede use case voor hebben. Ik weet niet of we daar nog op komen, de redenen waarom je nou een van de twee kiest.

Ik denk dat Databricks zich wat meer focust op het ETL-stukje en meer de data engineering-kant. Daar zal je als eindgebruiker niet zo veel van zien, van: oké, ik werk op een Databricks-platform. En ik denk dat daar ook het grote verschil zit: Fabric biedt ook meteen een rapportageproduct dat je neer kan zetten. Bij Databricks zal je altijd een ander rapportage- of dashboardingproduct nodig hebben om je eindgebruikers van de juiste rapportages te voorzien.

Ja, en ik denk dat Databricks gewoon wat verder is op het specifieke data engineering-stuk. We gaan het volgens mij ook nog hebben over best practices en dat soort dingen. Nou, dan heb je het over CI/CD, al dat soort aspecten. Daar is Databricks gewoon beter en verder in dan Microsoft Fabric op dit moment. Dus als je kijkt naar veelzijdigheid en gebruiksgemak, dan is Fabric heel snel the way to go. Maar als je wat geavanceerdere dingen wil doen, wat meer in controle wil zijn, en als je wat meer specialisten hebt, dan denk ik dat Databricks eerder een goede keuze is. Ik denk dat dat ook vaak de afweging is. En als je Microsoft al hebt, is Fabric natuurlijk ook snel een makkelijke keuze, omdat je het allemaal al kent, de look and feel.

Jazeker. De top die ik kan benoemen, als Fabric mijn naaste collega was, is dat het heel multifunctioneel is. Het is echt een verenigde software waarop heel veel samenkomt. Dat Zwitserse zakmes, zoals Auke net zei. Je hebt eigenlijk alles op één plek zitten. En ook het stukje gebruiksvriendelijkheid spreekt me erg aan bij Fabric. Het is een tooling waarop je heel snel je verschillende producten kan vinden, en ook op basis van bepaalde logica kan indelen. Je hebt bijvoorbeeld workspaces in Fabric, die je kan toewijden aan een bepaald aspect binnen je dataplatform. Dus specifiek een workspace toewijden aan engineering, en een andere weer aan je Power BI-dashboards. Dat is echt wel een top die ik zou kunnen benoemen van Fabric. En de tip: er werden net al governance-aspecten benoemd. Maar je hebt nu nog steeds dat je een losse resource van Microsoft moet afnemen, namelijk Purview, wil je het echt helemaal volledig inzichtelijk hebben. Maar wie weet dat die twee in de toekomst zullen versmelten. Want de gebruiksvriendelijkheid en de handige user interface zorgen er naar mijn mening ook voor dat het qua governance helemaal kan samenkomen. Dat je in een aparte module ook je governance kan terugvinden: je classificaties, je definities en je business glossary bijvoorbeeld.

Nou, mijn top is echt de veelzijdigheid van het platform. En ook dat het best wel laagdrempelig is om te leren. Je kan best snel starten met Fabric. Het is voor veel mensen goed te begrijpen en te volgen. Dus er kan goed mee samengewerkt worden, met die collega Fabric. En als tip zou ik eerder zeggen: het is soms een beetje een luie collega. Want als je in de Spark-sessies werkt als ontwikkelaar, moet je soms even wachten. Je geduld wordt op de proef gesteld. Maar daar leer je wel mee omgaan. En hij is een beetje onvoorspelbaar soms. Er zitten nog wel wat nieuwe dingen in, het platform ontwikkelt zich, dus die collega ook. En dat maakt het ook een beetje onvoorspelbaar: wat werkt al goed, wat is al af, wat is nog volop in ontwikkeling? En ook qua gebruik en kosten is het even leren: hoe werkt dit, is dit nou duur of goedkoop?

Ja, ik zou echt met de tip willen beginnen. Want ik herken sowieso de punten die jullie noemen, ik zit zelf aan beide kanten. Maar wat ik echt als tip heb: kijk ook goed naar wat er open source gebeurt. Want ik zie dat er in de open source-wereld best wel veel dingen ontwikkeld worden voor Fabric, slash op Fabric, die megahandig zijn om te gebruiken. Alleen, omdat het een soort open source is, en soms wel gelieerd aan Microsoft: is het nou wel officieel of niet? Bijvoorbeeld CI/CD-dingen die wij gebruiken.

En dan bedoel je packages of libraries?

Packages, libraries, in Spark, dat soort dingen. En Semantic Link Labs, die kennen jullie denk ik ook wel. Die gasten maken echt supermooie spullen die heel handig zijn om te gebruiken. Dus het zou handig zijn als dat er bij wijze van spreken native allemaal in zou zitten, zodat je dat niet ook nog eens opnieuw hoeft te installeren.

Of dat er meer mee samengewerkt wordt. Dat zij ook op de hoogte zijn van nieuwe ontwikkelingen, dat iets niet zomaar wordt uitgezet. Want dan doen je packages ineens niet meer.

Precies, om die reden. Nou, dat is denk ik een tip. Al denk ik ook dat ze daar wel focus op hebben, maar goed, dat zou voor mij prettig zijn. En een top: wat vind ik echt een top? Ik denk het gebruiksgemak voor de vele doelgroepen. Het is heel makkelijk te gebruiken voor mensen die er eigenlijk niet zoveel verstand van hebben, mogelijk ook een gevaar, maar goed. Maar het is ook voor mensen die er wél verstand van hebben relatief makkelijk om snel mee te beginnen. En dan het stukje waar je echt het verschil gaat maken tussen een echte professional en, zou ik zeggen, een hobbyboer: daar loop je soms nog wel tegen grenzen aan. Maar je kan heel snel, zoals Sil zei, waarde gaan leveren. En dat is denk ik echt top aan het platform.

Het juiste moment is als er een behoefte is, een duidelijke behoefte. Ik denk dat dat heel belangrijk is. We hebben dat in de vorige podcast ook al besproken: er moet een duidelijke behoefte zijn gearticuleerd. Het hebben van data, of een platform om het hebben van een platform, is denk ik niet voldoende. Dus dat is eigenlijk het startpunt. Je moet iets willen met data en daar tooling voor nodig hebben. En dan ga je kijken: oké, wat heb ik dan nodig, et cetera.

En wie moet dat dan willen?

De klant, de eindgebruiker. Ja, en dat is ook een goede vraag. Is het bijvoorbeeld een IT-afdeling die vindt dat ze daar wat mee moeten? Of zijn er ook mensen in de business die zeggen: ik heb behoefte aan rapportages, of aan iets anders slims met data? Dus daar zit ook weer onderscheid in, denk ik.

Ja. En ik denk dat het ook belangrijk is dat je inderdaad die businessbehoefte hebt. En als je al rapportages hebt, vaak hebben bedrijven dat al, en dat begint een beetje te wringen, van: er zitten veel fouten in, of we houden het moeilijk overeind op het oude platform, dan kan je overwegen: zijn we niet toe aan een stapje groter, een stapje verder? Dan is een Fabric-platform wel heel aantrekkelijk om zo'n implementatie goed aan te pakken. Je hebt al wat lessons learned van wat je hebt, en die kan je mooi meenemen in zo'n traject. Ik denk dat dat een hele mooie start kan zijn.

Misschien nog aanvullend daarop, als voorbeeld: de eindeloze Excelletjes die op een gegeven moment maar blijven groeien. En op een gegeven moment ook gewoon niet meer kloppen met wat erin staat. Dat mensen door alle Excelletjes de data kwijt zijn, dat ze door de bomen het bos niet meer zien. Dan kan je je als organisatie afvragen: goh, we hebben zoveel applicaties lopen, er komen meer en meer vragen over data en het monitoren van bepaalde processen. Misschien is het een goede stap om over te stappen naar een platform, naar een hoger volwassenheidsniveau van omgaan met je data en processen.

Jazeker, beide kanten ken ik wel. Kijk, bij greenfield heb je vaak niks, dus kun je alles vanaf nul bedenken. Dat is heel veel werk, maar ook wel heel prettig. En als er al iets is, dan is heel vaak het gevaar: we gaan wat er is overzetten naar een nieuw platform, met alle rapportages, definities, et cetera. En mijn ervaring is dat je dan juist bedrogen uitkomt. Het is namelijk een moment om dat allemaal weer eens onder de loep te nemen. Want heel vaak klopt het eigenlijk helemaal niet meer met wat je nu wil. Dus ik denk eigenlijk dat je altijd bijna met een greenfield-mentaliteit moet beginnen, of je nou niks hebt of juist al heel veel. In ieder geval om goed te analyseren: alles wat ik nu wil meenemen, is dat ook allemaal wat ik nu nog nodig heb? Voldoet dat nog aan alle wensen en behoeftes? Bij greenfield kom je daar vanzelf op. Maar als je een bestaande omgeving hebt, wordt heel vaak gezegd: we gaan het as-is overzetten. Vooral omdat op een gegeven moment de tijd dringt. Terwijl je dan achteraf denkt: we hadden eigenlijk beter opnieuw kunnen beginnen. Of: we hadden dit toch beter anders kunnen doen.

Ja, het gaat erom dat je je fundamenten goed hebt. Met een greenfield stel je die fundamentele vragen standaard, want dan ga je een nieuw plan maken. En eigenlijk moet je ze dan herevalueren: zijn dit de fundamenten waarop ik wil bouwen? Is dit goed of moet dit beter? Misschien was het ooit goed toen we het opzetten, maar is het nu echt toe aan een upgrade. Dus daarin moet je heel goed kijken: kan dit zomaar mee over? Is dit wat we in stand willen houden, of moet het anders? Het klinkt vaak heel mooi, dan zeggen ze: ah, we doen lift and shift en je bent in de cloud. Dat is altijd een beetje de salestaal, maar zo simpel is het vaak niet. En dan ga je ook voorbij aan die fundamenten die je wil leggen.

Ja, zeker. Ik denk dat je altijd moet beginnen met een goed plan. En dat zit in verschillende lagen. Eén is: wat is mijn dataplatform en waarvoor is het eigenlijk? En waar wil ik op bouwen? Dus een stukje definities die je wil borgen, rondom berekeningen die je maakt, rondom data die je vastlegt, en ook rondom de bronnen die je wil opslaan en ontsluiten. Ik denk dat dat de eerste laag is die je echt fundamenteel goed wil hebben: hoe ga ik om met die data? Hoe ga ik dat opslaan, en hoe ga ik dat goed verzamelen en continu weer aanvullen? Dat is eigenlijk je fundamentele laag voor je dataplatform. En daarop kan ik dan heel veel producten ontsluiten rondom data.

Ja, waar ik vaak mee start als ik op een opdracht begin met de implementatie van bijvoorbeeld een Fabric, is even de status quo opmaken van: goh, hoe gebeurt het nu? Wat is een beetje de werkmethodiek en de werkwijze van de verschillende medewerkers die met data werken, of in ieder geval baat hebben bij zo'n oplossing, zo'n platform? En dan ook een beetje mikken op een soort target state: waar willen we naartoe bewegen? Het hoeft niet meteen de stip op de horizon te zijn, maar gewoon een eerste fase van: goh, we willen al de data vanuit deze en deze applicaties kunnen samenvoegen, want dan hebben we meer context en kunnen we er meer uit halen. Dus dat je een soort oplossing of doel formuleert waar je naartoe probeert te streven. Misschien nog een ander punt dat bij deze collega's ook vaak aan bod komt, is natuurlijk requirements ophalen. Dat is een heel belangrijk aspect. Er zijn veel mensen in de business die niet echt een beeld hebben bij data, maar wel behoeftes hebben. Nou, haal die behoeftes op, vertaal die naar een bepaalde technologische oplossing of naar een dataconcept. En het is nog mooier als je dat dan weer goed kan uitleggen aan de business, zodat zij ook begrijpen: aha, dit ga jij doen, of dit is wat het platform doet.

En ik denk ook: verschillende dataproducten benoemen. Waar wil je data voor gebruiken? Is het dashboarding en rapportage? Is het misschien meer de machine learning- of AI-toepassing? Het is belangrijk om te weten waarvoor je data gebruikt, en ook dat daar businessbehoefte aan zit. En ik denk ook: hoe moet mijn datateam eruitzien? Dat je daar een beeld bij hebt, dat je weet wat je centraal doet en wat je decentraal doet. Want misschien heb je al hele goede mensen in je business die heel veel met data kunnen, die je toegang wil geven tot een stukje. Maar daar moet je wel bij nadenken, bij de architectuur die je neerzet: oké, ik kan ook qua rollen en rechten dat goed borgen, dat de juiste mensen toegang hebben tot de juiste data. Ik denk dat je daar een plan voor nodig hebt.

Ik denk dat het stukje mensen echt ook heel belangrijk is, wat jullie eigenlijk al direct en indirect zeggen. Het is een technologische oplossing, zeker, maar het is ook een heel stuk mensen. En ik denk ook dat het sentiment van die mensen belangrijk is in zo'n proces, om daar feeling bij te krijgen. We hebben het de vorige keer ook gehad over silo's, nou, dat soort dingen moet je allemaal meenemen in een plan. Want het kan zijn dat iedereen staat te springen en dat je juichend wordt ontvangen. Maar het kan ook zo zijn dat jij ergens wordt ingehuurd en dat mensen denken: wat kom jij aan mijn data zitten, en wat kom jij me vertellen wat ik hier moet doen, ik weet het eigenlijk wel beter. Dus ik denk dat dat ook een belangrijk aspect is dat je naast je technische plan en de requirements echt mee moet nemen, zodat je een volledig beeld krijgt van wat er allemaal moet gaan gebeuren. En dat is dus niet alleen technologisch.

Heel veel praten. Een goede podcast maken, een interne podcast voor de organisatie. Nee, ik denk dat het "what's in it for me" wel een bekende is, dat dat heel duidelijk moet zijn voor mensen, en dat dat ook vaak vergeten wordt. Dus dat uitleggen, dat is al stap één. En ook mensen meenemen in het proces en in wat je nou precies doet, om die black box iets kleiner te maken. Dat is denk ik ook heel belangrijk. Omdat het anders voor heel veel mensen een te grote stap is die ze niet begrijpen, en vaak ook niet willen begrijpen. Want ze zijn helemaal niet geïnteresseerd in de techniek erachter. Ze hebben een bepaalde behoefte en hopen dat die opgelost wordt. En als je daar goed op kan inspelen, dan kom je wel verder. Alleen, dat is wel lastig te duiden: wat doe je dan precies?

Ja, en wat ik altijd een handig hulpmiddel vind, is het gewoon visueel maken. Vaak ben je aan het praten, maar woorden zeggen niks. Als je met een plaatje komt waarin je het visueel kan specificeren en laten zien van: goh, dit doet het eigenlijk, dan hebben meer mensen er een beeld bij. Aha, oké, dit is het algehele doel. En dan heb je ook de mogelijkheid tot gelaagdheid: zo is het op hoofdlijnen, maar je kan altijd dieper in detail treden en uitleggen wat bijvoorbeeld een Fabric-item of -functionaliteit precies doet en teweegbrengt. Dus visueel maken is voor mij ook iets wat vaak helpt bij dit soort zaken.

Ja, en daarin ook een beetje begrijpen en begrepen worden. Dus één: uitleggen wat de mogelijkheden zijn en wat je in vorm ook echt concreet maken. Maar ook vooral begrijpen wat diegene nou nodig heeft. Wat heeft hij nodig qua dashboarding? Is hij tevreden met wat hij nu heeft? Is hij misschien bang om iets kwijt te raken? Dat zie je ook vaak, dat mensen vooral angst hebben van: ja, ik kan nu allemaal dit, en jullie gaan het uitzetten, want we gaan naar iets nieuws, en dan kan ik dat straks allemaal niet meer. Daar moet je goed mee omgaan, dat dat ook wordt meegenomen in de behoefte.

Wat wel belangrijk is, wat wij vaak doen, is ook mensen verantwoordelijk maken binnen een team of afdeling voor een stukje. Dus we hebben dan data stewards en data-eigenaren benoemd. Dat is vaak de manager of een vooruitgeschoven key user, een wat meer ervaren persoon binnen een team.

Ja, bijvoorbeeld vanuit HR of Finance. Dat zijn eigenlijk de mensen waar wij veel mee kunnen sparren. Die begrijpen echt wat dat team doet en welke processen daar worden uitgevoerd. Het is belangrijk dat je die op tijd meeneemt, want dat worden eigenlijk jouw sponsors binnen jouw team en jouw domein. En daarmee kan je ook veel schakelen: oké, we willen nu dit proces aanpakken, hoe werkt dit, wie is de specialist? Maar ook: wat als we hierin iets gaan veranderen of aanpassen? Die weten de valkuilen en de risico's. Dus ik denk dat dat een hele belangrijke is in zo'n traject.

Ja, je kan die vraag eigenlijk tweeledig stellen. Je kan het schematisch laten zien: hoe vloeit je data door je platform heen? Dus echt van databron tot en met je gouden laag in je medallion. Maar je kan het ook zo laten zien dat er uiteindelijk een vraag komt van: oké, maar ik wil het toch weer terugzien in een tabelletje of een taartdiagram of in een bepaald dashboard. En daarin kun je het dan ook visueel maken, met eerst een schets die je uitwerkt in Power BI. Ik gebruik het met name echt voor dat hele schematische van wat er met je data gebeurt, vanaf de bronkant helemaal tot de halte voor je Power BI-dashboard. Wat je dan eigenlijk hebt staan en wat je uiteindelijk uit je data kan halen.

Ik denk meerdere rollen. Sowieso heb je je datateam. Daar heb je vaak de data engineer die meer de technische stukken doet. Je hebt de data- en business-analisten die meer aan de businesskant en de frontend staan. En ik denk dat je altijd wel een architect nodig hebt die helpt met het ontwerpen van je platform. Vaak zie je dat de engineers technisch wel losgaan op de taken die er liggen, maar dan het geheel van het platform een beetje verliezen. Het is goed om ook te bouwen aan een werkend eindproduct. En dan kan de architect daar focus aan geven: jongens, we moeten dit onderdeel goed afmaken, hier moet de kwaliteit top zijn, want dat zijn de basiselementen van je platform. Dus ik denk aan de datateamkant: architect, engineer, analist.

Ja, precies. En dan, misschien niet aan de datakant, bijvoorbeeld een IT-officer die helpt met de nodige rechten en permissies die je nodig hebt om een applicatie in te duiken. Maar ook een functioneel beheerder. Dat is ook vaak iemand met wie ik mee heb gespard, om even scherp te halen: oké, als je dit invoert in een applicatie, hoe komt het dan precies weer terug op je platform? Dus dat zijn ook wel twee niet-datamensen met wie ik vaak te maken heb.

Ja, en de sponsor daarbovenop natuurlijk. Dus degene die op hoog genoeg niveau achter het initiatief staat. Want dat zie je toch wel vaak: als er één of meerdere sponsors zijn, dat kan een team zijn, bijvoorbeeld een raad van bestuur, maar het kan ook een directeur of een manager zijn. Als die erachter staat en op sommige momenten iedereen dezelfde kant op kan krijgen, dan zie je dat dat een heel flink stuk kan helpen. Dus dat is denk ik ook een belangrijke rol in dit proces.

Jazeker. De gouden tip voor de manager is denk ik: bepaal enerzijds wat je centraal wil doen en wat je decentraal wil doen. En daar bedoel ik mee: welk deel van een dataplatform wil je met jouw datateam doen, en wat moeten andere mensen kunnen doen? Waar zitten de eindgebruikers? Die zitten vaak in de domeinen, bij bijvoorbeeld een Finance, HR of de business. Maar ook: hoe ver moeten die zelf rapporten kunnen bouwen? Maak daar een goede rollenscheiding in. En begin met een plan qua architectuur. Wij zien vaak de data engineering als het ETL-stuk, trek die lagen ook los van elkaar. Dus scheid de engineering-laag van de analistenlaag. Want dan krijg je echt een heel goed gescheiden platform, en komen de modules die in het Fabric-platform zitten, maar ook in een dataplatform op zich, het best tot hun recht. Dus ik denk dat dat voor de manager wel de tip is.

Bij mij is het misschien nog een beetje hoog over. De tip is eigenlijk: wat wil je nou precies uit je data halen? Dus weer heel concreet die behoefte. Misschien dat de manager gewoon zegt: goh, ik heb dit Excel-lijstje en ik wil eigenlijk een hele mooie taartdiagram. Nou, dan importeer je hem gewoon in Power BI Desktop en je maakt die taartdiagram. Check, gedaan, daar had ik het voor nodig. Maar als iemand echt zegt: ja, we hebben nu zoveel applicaties en we willen die data toch met elkaar combineren en integreren, dan ga je wel meer nadenken van: oké, dan is het toch een grotere behoefte, een wens naar een functionerend platform. Zeker als we ook zeggen: goh, we willen dat het automatisch gaat, dat het ook integreert met andere Microsoft-middelen die je gebruikt. Dus eigenlijk weer heel concreet en heel basic naar die behoeftes toe gaan.

Nou, het wordt een beetje een herhaling misschien, maar ook echt: als manager, vergeet de mensenkant niet. Dus even los van wat de behoeftes van mensen zijn, die zijn er denk ik namelijk altijd wel, zijn ook de sentimenten heel belangrijk bij dit soort dingen. Want sommige mensen hebben echt het gevoel dat hun werk verdwijnt, of dat ze de controle verliezen. En dat kan heel vervelend worden in zo'n proces. Voor het proces zelf, maar ook voor de mensen zelf. Dus om dat niet te vergeten, ook bij voorbaat al, is denk ik de tip: sta daar gewoon bij stil en denk na over wat de impact kan zijn voor de individuen in dit proces.

Nou, ik denk... wij zijn bij een klant bezig met bouwen in dit platform, en ik heb nu een heel mooi platform neergezet. Maar dan heb je altijd wel wat uitdagingen. Eentje daarvan is bijvoorbeeld, ik noemde al dat Fabric best wel in ontwikkeling is, dat af en toe een module net even niet werkt. Of dat er even onderhoud wordt gepleegd, dat iemand van Microsoft een knopje heeft ingedrukt. En daar heb je dan best wel even last van. Of dat dingen nog in ontwikkeling zijn. Het volwassenheidsniveau neemt wel toe, maar het is nog niet helemaal af. Dat is wel een van de uitdagingen.

Ja, ik heb wel het gevoel dat ze dat agile ontwikkelen.

Ja, waar ik een beetje tegenaan liep, of wat eens een keer niet helemaal soepel ging, was toch uiteindelijk de business helemaal mee zien te krijgen met wat je precies aan het doen bent als consultant die hen komt helpen met een bepaalde behoefte of vraag. Bij mij specifiek was het dat ik ongeveer wist: ah oké, we gaan die kant op. En dan heb je in je hoofd: oké, Fabric vertaalt zich naar dit en dit en dit. En dan begin je met bouwen. Maar dan vergeet je toch ook nog om hen in de loop te houden over wat je precies aan het doen bent. En dan komen ze achteraf van: goh, we zijn twee weken verder en ik heb je uren geaccordeerd, maar wat heb je eigenlijk gedaan? En ja, dus je kan eigenlijk niet genoeg delen en op de hoogte houden. Het is voor sommigen toch een beetje een black box: wat heb je nou concreet opgeleverd? Maar ze daarin goed meenemen, en ook duidelijk maken: goh, er komt nu even, in deze twee weken, niet meteen iets eruit. Maar weet dat we nu bezig zijn met de fundering, als het ware. En als die staat, dan gaan we door naar de volgende stap.

Nou, die uitdagingen heb ik ook gehad. Ik zit even te denken wat leuke best practices zijn om te delen. Ik denk dat je niet moet vergeten dat, omdat het heel gebruiksvriendelijk is, je heel snel kan starten. Waarmee je dus heel gauw voorbij gaat aan juist die best practices. Dus ik denk dat dat beseffen eigenlijk al een soort best practice is. Want je kan, als je start en je hebt een creditcard en je vraagt een capacity aan, in principe met een beetje kennis in een dag dingen hebben. Alleen, waar gaat nou het hele werk in zitten? Dat is juist dingen goed modelleren. Zoals Sil zei, workspaces op een bepaalde manier scheiden, CI/CD inrichten, met versiebeheer werken, al dat soort dingen zijn best practices waar je heel snel overheen stapt, omdat je zo snel dingen kan doen. En ik denk dat dat een hele goede is: sta daarbij stil. Want je hoeft ook echt niet voor elke casus volledig versiebeheer en al dat soort dingen te hebben. Maar besef dat er heel veel dingen zijn, neem dat mee in je plan, en zorg dat er een plan is. Dan kan je voor jouw casus heel snel een goede uitgangspositie creëren.

En ik denk ook: daag je technische mensen uit om dat te bedenken. Hoe willen wij versiebeheer doen? Hoe doen anderen dat? Veel daarover lezen en een standpunt innemen van: wij willen het zo aanpakken. Ik denk dat heel veel technische mensen dat ook wel graag willen, netjes een test-, ontwikkel- en acceptatieomgeving hebben. Maar ga het dan ook gewoon doen. En dan kom je eigenlijk wel verder, en dan zie je ook wat je nodig hebt.

Ja, en ik denk dat het belangrijk is om een werkwijze te kiezen. Wij werken vaak agile, met Scrum. Elke twee weken iets opleveren en terugpresenteren naar de business en de klant. Maar je hoeft niet agile te werken, kies wel een methodiek van wat je wil doen.

Nou, ik denk wat ook mooi is, wat jij ook zei: dat je best wel een schaalbaar platform kan bouwen. Je hoeft niet meteen met een volledig platform te beginnen. Je kan best in stapjes daarop bouwen, ook qua kosten en qua grootte. Dus ik denk dat dat heel mooi is, dat je ook een beetje een proof of concept kan doen. En ik denk dat dat ook heel erg kan bijdragen aan adoptie en aan het vormgeven van je project. En ja, eigenlijk al doende leren van: hoe gaan we dit nou doen?

Ja, het is eigenlijk volledig op maat te maken op basis van de business en de organisatie. Dus je kan heel klein beginnen en langzaamaan opbouwen.

Soms is dat juist dé manier om vertrouwen te wekken. Dat je zegt: we doen het linksom en rechtsom, en aan het eind moet er hetzelfde uitkomen. En als mensen dat zien, krijgen ze juist heel snel vertrouwen. Oh, als we het zo doen, dan komt er ook hetzelfde cijfertje uit. Dus dan kan dat juist heel erg helpen.