Veel organisaties worden zich bewust van een harde realiteit: technologie is slechts één hoofdstuk in het dataverhaal. Daar gaat het niet alleen over technische specificaties, maar ook over de manier waarop data-architectuur functioneert in een permanent evoluerend bedrijf. Als teams in silo's blijven werken, lukt het zelfs met de meest geavanceerde tools niet om waarde te creëren .
Om te onderzoeken hoe technologie en organisatie elkaar versterken, gingen we in gesprek met Maarten Lauwaert, Business Unit Leader voor Management Information & Systems, en Evert Augustyns, Data & Analytics Project Manager. Voor hen is een technisch perfecte architectuur nutteloos als die teams niet stimuleert om verder te kijken dan de grenzen van hun eigen afdeling. Zoals Augustyns opmerkt, verdwijnt zonder een gezamenlijke aanpak de belofte van een uniforme datalaag. Wat overblijft, zijn niet met elkaar verbonden eilandjes.
Het belang van data-architectuur
Evert Augustyns: ‘Lakehouse is in de eerste plaats een technologie, maar je bedrijf zo organiseren dat het silodenken verdwijnt, is minstens even belangrijk. Je kunt de technologie hebben, zelfs 101 Lakehouses, maar als elk team zijn eigen eiland bouwt, ontstaat geen uniforme datalaag. Dan eindig je met een Lakehouse voor Finance, een lakehouse voor HR, een lakehouse voor Supply Chain, enzovoort.’
Het creëren van een robuuste lakehouse architectuur helpt om deze silo’s te doorbreken en maakt het mogelijk om een centrale, consistente bron van waarheid te hebben. De echte uitdaging ligt dus in het creëren van een data architectuur die een datagedreven Finance-departement ondersteunt én een organisatiecultuur die die silo’s actief afbouwt.
Tien à twintig jaar geleden werd al volop gesproken over big data: bedrijven verzamelden massaal gegevens, maar benutten die onvoldoende. Vandaag is de context anders: nieuwe datatypes, nieuwe tools en een veel breder publiek dat met data wil werken, zorgen ervoor dat de klassieke, sterk gecentraliseerde aanpak niet langer volstaat.
Maarten Lauwaert nuanceert dat de kern van het probleem doorheen de jaren vrij constant is gebleven. “Toen werkten bedrijven met datawarehouses; nu praten we over lakehouse architectuur. Het gaat niet enkel om technologie, maar vooral om hoe de organisatie met data omgaat.”
De nood vandaag is groter omdat niet alleen IT-teams met data werken, maar ook business-profielen, analisten en domeinspecialisten. Dat lukt enkel wanneer de data architectuur uitnodigt tot samenwerking en toegankelijkheid. Waar oudere technologie die flexibiliteit niet bood, maakt lakehouse architectuur dat wél mogelijk.
Moderne data engineering-praktijken zorgen ervoor dat datapijplijnen betrouwbaar en schaalbaar zijn, terwijl sterke data management-processen consistentie, kwaliteit en goede governance over alle lagen garanderen. Deze combinatie stelt organisaties in staat om bestaande silo’s te doorbreken en optimaal gebruik te maken van de Lakehouse-architectuur. Volgens Lauwaert is dit een echte game-changer: “Met de juiste vaardigheden kan een organisatie groeien in het gebruik van data en bestaande silo’s doorbreken.”
Volgens Lauwaert is dat een echte gamechanger: “Met de juiste data engineering skills," zo zegt hij, "kan een organisatie groeien in datagebruik en de bestaande silo’s doorbreken.”
Lakehouse is in de eerste plaats een technologie, maar je organisatie zo organiseren dat het silodenken verdwijnt, is minstens even belangrijk
Waarom Lakehouse-technologie de sleutel is tot het doorbreken van datasilo’s
Evert Augustyns: "Microsoft hanteert verschillende maturiteitsniveaus. Veel organisaties zitten nog in de fase waarin elk departement zich alleen op zijn eigen rapportage richt. Teams kijken in vele gevallen niet bij de buren. Finance exporteert bijvoorbeeld financiële data uit SAP, F&O of NetSuite en maakt daar zijn eigen rapporten mee.
"Er zijn ook bedrijven die het proces al gestructureerd en geautomatiseerd hebben, waarbij de data typisch in een SQL-datawarehouse terechtkomt. Maar veel organisaties werken nog altijd met exceldumps die vervolgens in Power BI worden ingeladen.
Dat maakt het moeilijk om te evolueren naar datagedreven finance waarbij beslissingen steunen op gedeelde, consistente data in plaats van op geïsoleerde rapporten per departement.
"Het voordeel van een lakehouse en van Microsoft Fabric in het bijzonder is dat de technische kennis die nodig is om data geautomatiseerd te ontsluiten en gestructureerd op te slaan, veel beperkter is. Daardoor wordt het veel eenvoudiger om data breder toegankelijk te maken en af te stappen van rapportage in data silo's."
Maarten Lauwaert: "De schaal die Microsoft gebruikt om het maturiteitsniveau van organisaties te bepalen, vind ik heel handig. Op het eerste niveau draait alles rond het centreren van data. Je zorgt ervoor dat er binnen de organisatie een team is dat alle data samenbrengt op één plek, in een centrale technologie. Vroeger was dat meestal een datawarehouse. Vandaag kan dat ook een lakehouse zijn.
"Van daaruit maak je rapporten die vooral terugkijken, ze zijn backward-looking. Op het volgende niveau probeer je met die data ook voorspellende inzichten te ontwikkelen via finance data analytics, daarbij vertrekkende van een predictieve analytics-strategie, of zelfs ai in je financiële rapportage. Maar dat kan pas als je die eerste stap hebt gezet. Zonder die centrale structuur lukt dat niet. Pas als je die basis hebt, kun je echt vooruitkijken op basis van de data die in dat datawarehouse of lakehouse zitten.
"Daar ontstaat ook ruimte voor AI in financiële rapportage: niet alleen rapporteren wat er gebeurd is, maar met behulp van algoritmes automatisch afwijkingen detecteren, voorspellingen maken en financiële inzichten proactief onder de aandacht brengen"
Het voordeel van een lakehouse en van Microsoft Fabric is dat de technische kennis die nodig is om data entries te automatiseren en gestructureerd op te slaan, veel beperkter is
De impact van Lakehouse-technologie op diverse datatypes
Evert Augustyns: "Lakehouse en big data zijn er deels gekomen om ook semi-gestructureerde en ongestructureerde data te kunnen analyseren. Eerlijk gezegd zijn we in onze projecten nog geen echt ongestructureerde data tegengekomen. Bij één klant kwam het wel ter sprake omdat ze telefoongesprekken wilden analyseren, maar dat project is uiteindelijk niet van de grond gekomen.
"Semi-gestructureerde data zien we daarentegen vaker. Steeds meer systemen worden via API’s ontsloten, en daarbij krijg je data in formaten zoals JSON of XML, die niet passen in klassieke tabellen.
"Het Lakehouse-concept helpt die verschillende datatypes samen te brengen in één omgeving, met een transactielaag bovenop het data lake. Daardoor kun je data beheren en analyseren met de performantie van een datawarehouse, maar met de flexibiliteit van een lake.
Maarten Lauwaert: ‘Semigestructureerd betekent dat er structuur aanwezig is, maar die structuur is niet voor elke record dezelfde. Normaal heeft een tabel tien kolommen. In dit soort data heeft de eerste regel in de file bijvoorbeeld tien kolommen, de tweede vijf, en de derde vijftien. Er zit dus structuur in, maar die is niet generiek voor alle data.’
Waarom klassieke SQL-structuren tekortschieten
Evert Augustyns: ‘Die JSON-bestanden werken eigenlijk niet meer met vaste kolommen. Dat zijn areas of velden die op verschillende niveaus kunnen voorkomen. In de eerste record staat bijvoorbeeld eerst de voornaam, “Arno”, en daarna de familienaam, “Muylaert”. In de tweede record kan dat net omgekeerd staan.
"Als je bij personeelsdata ook nog informatie over kinderen wilt toevoegen, blijft dat veld bij veel jonge medewerkers leeg, maar bij anderen opent zich in de file een tweede niveau met gegevens over hun kinderen. Omdat dat niveau niet bij iedereen voorkomt, is het moeilijk om alles in één tabel te gieten.’
"Daarom is een solide datamanagement cruciaal: je hebt een architectuur nodig die verschillende datatypes kan beheren zonder dat deze verloren gaan of verkeerd gemappet worden. Velden zoals 'voornaam' of 'familienaam' komen dan niet alleen voor op het niveau van het personeelslid, maar ook daaronder, bij de kinderen. Als je die gegevens in een traditionele SQL-tabel probeert te persen, gaat het mis, omdat je niet twee keer ‘achternaam’ in dezelfde tabel kunt hebben.
'De technologie van het data lake is juist ontwikkeld om dat soort transformaties mogelijk te maken en flexibel met zulke semi-gestructureerde data om te gaan."
Door datasilo's krijg je geen volledig beeld, werk je met verschillende versies van de waarheid en verlies je tijd aan het samenbrengen van data
Lakehouse voor leken verklaard
Veel bedrijven werken vandaag nog met een klassiek Data Warehouse. “Dat is op zich geen probleem,” zegt Maarten Lauwaert. “Maar conceptueel zit een lakehouse anders in elkaar, ook al vertrekken beide van hetzelfde idee: data uit verschillende systemen samenbrengen op één plek. Zo creëer je een uniforme databron voor iedereen die met die 'siloed data' aan de slag wil.”
Met ‘siloed data’ bedoelt hij informatie die opgesloten zit in aparte systemen of afdelingen die niet goed met elkaar communiceren. “Daardoor krijg je geen volledig beeld, werk je met verschillende versies van de waarheid en verlies je tijd aan het samenbrengen van data,” legt hij uit.
Het traditionele datawarehouse probeerde deze silo's te doorbreken, maar stootte op zijn grenzen. “Met de opkomst van big data kwamen semi-gestructureerde en ongestructureerde data in beeld. Die kon je niet langer goed opslaan in een traditioneel datawarehouse”, zegt Lauwaert. Het data lake bood een oplossing door ruwe data op te slaan, ongeacht de structuur. Maar het had één groot nadeel: “In het begin presteerde het niet erg goed. Je kon geen efficiënte queries of analyses uitvoeren.
Daarom is het lakehouse ontstaan: het combineert de flexibiliteit van een Data Lake met de performantie van een Data Warehouse. Deze performantie ontstaat doordat er bovenop het Data Lake een metadata- en transactielaag komt, zoals Delta Lake of Apache Iceberg, wat ACID-transacties en efficiënte query’s mogelijk maakt.
Een doordachte data strategy kan hierbij helpen om te bepalen welke datalagen relevant zijn voor wie, en hoe predictive analytics in finance optimaal ingezet kan worden.
Medallion is geen methodologie maar een ontwerpprincipe voor het structureren van data binnen een data lakehouse architecture
Hoe de Medallion-architectuur Lakehouse-modellen versterkt
Architecturaal wordt die aanpak vaak ondersteund door Medallion, met de bekende Bronze-, Silver- en Gold-lagen. “Een aparte methodologie is dat niet,” zegt Maarten Lauwaert. “Het is een ontwerpprincipe voor de manier waarop je data binnen een data lakehouse architecture structureert en kwaliteitsvol opbouwt.”
Voorbeelden van Lakehouse-technologie zijn Microsoft Fabric en Databricks. “Een datalake is eigenlijk een vergaarbak,” zegt Lauwaert. “In een lakehouse zit daarboven een engine (notebooks of Spark-engines) die ervoor zorgt dat je die data performant kunt gebruiken.”
Evert Augustyns verduidelijkt de Medallion-lagen: Bronze voor ruwe data, bij voorbeeld uit SAP; Silver voor gedeeltelijk gestructureerde data, Gold voor geaggregeerde en opgeschoonde data.
Dit laatste niveau is cruciaal voor de bruikbaarheid. “Daar bepaal je bijvoorbeeld welke tien van de dertig kostenplaatsvelden je nog nodig hebt voor rapportage. Soms blijven er maar tien over. Voor selfservice-rapportage is dat handig, omdat de laag overzichtelijk is. Maar ook voor mensen die diepere analyses uitvoeren, bij voorbeeld met finance data analytics, is de Gold-laag de aangewezen plek, omdat de gegevens daar al aanzienlijk zijn opgeschoond.”
Deze aanpak ondersteunt een data-analytics-strategie en kan zelfs dienen als basis voor het ontwikkelen van een strategie voor data-analyse.
Een andere gebruikerssegmentatie
Evert Augustyns benadrukt dat de verschillende Medallion-lagen niet alleen een technische rol spelen, maar ook bepalen welk type gebruiker ermee aan de slag gaat. “Afhankelijk van het niveau van analyse dat je wil doen en van je eigen skillset, ga je naar de Silver- of de Gold-laag,” zegt hij. “Eigenlijk was dat vroeger niet zo anders. Het concept leek er sterk op, alleen werd die Silver-laag niet expliciet benoemd.”
In klassieke Data Warehouse-architecturen had je vaak een staging layer, waar ruwe data werd binnengebracht. “Dat noemen we vandaag de Bronze-laag. Het is in essentie dezelfde stap, maar met een andere naam, en waar we nu de Gold-laag hebben, sprak men vroeger over dimensie- en facttabellen die werden klaargezet voor de kubus of voor visualisaties. Maar dat stuk ertussen, die Silver-laag, is conceptueel het meest interessante.”
Volgens Augustyns is die Silver-laag niet exclusief aan een Lakehouse gebonden. “Je zou dat perfect ook kunnen bouwen in SQL, in een klassiek Data Warehouse,” zegt hij. “Voor mij staat de Lakehouse-architectuur gelijk aan de Medallion-architectuur. Of je dat nu op een Data Lake of op een Data Warehouse toepast, maakt eigenlijk niet uit, al zie je dat iedereen die vandaag met Lakehouse start, automatisch die aanpak volgt.”
De Medallion-architectuur verandert niet alleen de manier waarop data wordt opgebouwd, maar ook hoe eindgebruikers ermee werken. “Door die laag ertussen te plaatsen, geef je eindgebruikers een extra dataset waarmee ze zelf kunnen experimenteren,” zegt hij. Daardoor ontstaan ook nieuwe gebruikerssegmenten. Wie met de Silver-laag wil werken, heeft meer technische kennis nodig. Vroeger bestond eigenlijk alleen de opgeschoonde data uit de eindlaag.
Die verandering heeft impact op hoe teams samenwerken. Vroeger moest IT inspringen als iemand nog een detail, een extra variabele of een bijkomend veld nodig had. “Die moest dan in de staginglaag gaan programmeren,” zegt Augustyns. “Als die data er überhaupt al instond. Vandaag evolueren organisaties naar een model waar gebruikers veel autonomer kunnen werken.”
Meer autonomie met Lakehouse
Met de komst van het Lakehouse verandert dat. “Vandaag evolueer je naar een situatie waarbij mensen die goed zijn met data zélf aan de slag kunnen,” legt hij uit. “Ze starten vanuit de gevalideerde data in de Gold-laag, maar merken soms dat een extra attribuut niet in Gold staat, terwijl het wel aanwezig is in Silver. Dan kunnen ze rechtstreeks connecteren met die Silver-laag en zelf experimenteren. Dat kon vroeger gewoon niet.”
De Silver-laag stelt gebruikers in staat zelfstandig te experimenteren met data, wat essentieel is voor een geavanceerde analytics en predictieve analytics strategie.
Door robuuste data engineering en voldoende data engineering skills kunnen finance-teams bijvoorbeeld voorspellende analytics inzetten in finance zonder afhankelijk te zijn van IT, wat een stap is richting data gedreven finance.
Toegang tot de verschillende lagen wordt eenvoudig georganiseerd via folders of workspaces. Hierdoor blijven analyses en extra data zoals Excel-bestanden onderdeel van dezelfde centrale omgeving en leiden ze niet tot nieuwe datasilo's.
Die Silver-laag speelt een cruciale rol voor wie experimenteert met data. “Het is een laag met opgekuiste, maar nog niet volledig beperkende data,” legt hij uit. “Voor machine learning of andere predictieve modellen gebruik je die laag veel meer dan de Gold-laag. In Gold zit al heel veel structuur en filtering. Voor predictive analytics wil je juist breed kijken wat relevant kan zijn.”
Belangrijk is dat dit niet leidt tot nieuwe datasilo’s. “We willen vermijden dat de mensen van predictive op één dataset werken, terwijl de Gold-rapportering op een andere dataset draait,” zegt Augustyns. “Dit moet één keten blijven, binnen dezelfde technologie. Alles start in de grote ‘rommelbak’ die het Data Lake is, en beweegt dan naar de lagen die passen bij het gebruik: Silver voor experimenten, Gold voor rapportering.”
Die aanpak is volgens hem een grote kans voor organisaties. “Je kunt zelfs een ‘speeltuinlaag’ creëren voor goede analisten, bovenop de Silver-laag,” zegt hij. “Daar kunnen ze data linken, extra Excelbestanden toevoegen, experimenteren maar wel binnen de centrale omgeving. Het belandt niet meer op individuele laptops. Het blijft onderdeel van het geheel, zichtbaar, monitoreerbaar en beheersbaar.”
Dat vraagt wel doordachte keuzes. “Als je als bedrijf goed nadenkt over hoe je je Lakehouse en je architectuur inricht, en je mensen meeneemt in dat verhaal, dan kun je veel meer waarde uit je data halen dan vandaag,” aldus Augustyns.
Datamaturiteit evalueren over diverse domeinen
Maar technologie alleen volstaat niet. “Wat is het maturiteitsniveau van een organisatie die een Lakehouse heeft? Dat hangt volledig af van wat ermee gedaan wordt,” zegt hij. “Alleen technologie installeren brengt je niet automatisch op een hoger maturiteitsniveau. Je moet het gebruiken, en je organisatie moet het kunnen dragen.”
Daarbij verwijst hij naar bekende maturiteitsmodellen. “Vanaf niveau twee verdwijnen de silo’s stilaan en ontstaat er vaak een centraal analytics-team,” legt Augustyns uit. “Zo’n overkoepelend orgaan zorgt voor coördinatie en bewaakt de kwaliteit en consistentie van die grote bak aan data.”
Een evaluatie van maturiteit gebeurt volgens hem op meerdere domeinen: analysetechnieken, mensen, cultuur en governance. “Je kunt bijvoorbeeld al een central analytical department hebben, maar nog laag scoren op organisatie omdat de mensen nog niet mee zijn,” besluit hij. “Maturiteit is dus nooit puur technologisch. Het is een combinatie van structuur, vaardigheden en hoe je als organisatie met data werkt.”
