Data Lineage 1 - Een valse belofte?
Data Lineage 1 - Een valse belofte?
Wat is data lineage en waarom is het zo moeilijk om data lineage van kop-tot-staart te bereiken? In deze blog vertellen we wat we zien in de praktijk aan de hand van twee schijnbaar simpele vragen. We tonen aan dat data lineage vooral een systeemprobleem is en niet eenvoudig op te lossen met een nieuwe tool.
|
Bij veel grote organisaties staat digitalisatie en de ambitie om data-gedreven te werken prominent in de strategie. Dit uit zich in BI-teams voor reporting en dashboarding, data science voor voorspellende analyses, data- en platform engineers voor de platformen, en business analisten die extra inzichten leveren. Er wordt hard gewerkt, maar het gemis van overzicht van het datalandschap bemoeilijkt het werk. Hierdoor is het lastig te zien wat wordt overgeslagen, wat dubbel wordt gedaan en wat prioriteit moet hebben. En alle initiatieven ten spijt is het nog steeds niet mogelijk voor een organisatie om twee simpele vragen te beantwoorden.
Twee simpele vragen
De twee ogenschijnlijk simpele vragen die in elke corporate organisatie kunnen worden gesteld zijn:
"Waar wordt mijn data gebruikt?" vraagt de HR Data Manager aan ICT.
"De SAP-tabel `MARD` gaat op de schop. Kunnen jullie zorgen dat alle data producten blijven draaien?" vraagt de Delivery Manager aan het data team.
Hoe simpel deze vragen ook lijken, het blijkt in de praktijk ontzettend lastig, tijdrovend en complex om ze te beantwoorden. De oorzaken? Drie in het kort:
Het data platform is grooooot. Een centraal dataplatform in een organisatie met 7.000 medewerkers bevat al snel tienduizenden tabellen, honderden verladingen per dag en ETL-jobs die met hun onderlinge afhankelijkheden allemaal 's ochtends gereed moeten zijn. Op zoek naar de impact van het wijzigen van de `MARD`-tabel? Speld in een hooiberg. En dan heb je het alleen nog over het dataplatform — de bronsystemen en rapportagetools tellen we even mee.
Figuur 1: visualisatie van de data-objecten die zijn gekoppeld aan de `MARD`-tabel uit SAP
Het landschap is onoverzichtelijk doordat het organisch is gegroeid. In het begin, één team, eerste data — nog onder controle. Snel daarna, door het succes, meerdere teams op hetzelfde platform. Architectuur en modelleringsvorm wijzigen mee. Wat logisch was met 2 teams, werkt niet meer met 20. Grip houden wordt lastig, en niemand heeft het overzicht meer in z'n hoofd.
Ontwarren is saai en levert niet direct business waarde. Waarom iets dat nu werkt (oké, wellicht te complex) ontwarren, opnieuw modelleren, testen, en dan pas een nieuwe dataset toevoegen? Als het ook in één keer kan, is dat leuker en levert het sneller business waarde op. Geen wonder dat de kluwen blijft groeien. Voor een data engineer blijft het lastig om te achterhalen welke data er onder een complex rapport hangt — laat staan bij een geheel systeem zoals SAP.
Het antwoord zou data lineage moeten zijn
Kunnen deze vragen wel beantwoord worden als data lineage is geïmplementeerd? Data lineage is een techniek waarbij je een data-object kunt volgen binnen je gehele landschap. Elk object wordt gecreëerd volgens een systematiek en het is inzichtelijk waar de data naartoe stroomt. We onderscheiden logische en fysieke dataobjecten:
Logische objecten: business concepten (zoals "klant", "medewerker") op modelniveau;
Fysieke objecten: tabellen, kolommen, rapporten in het platform.
Een logisch object kan door meerdere fysieke objecten worden geïmplementeerd — geen 1-op-1 met de techniek, maar wel traceerbaar als je de koppeling goed legt.
Hoe zou de vraag van de HR manager dan wel beantwoord kunnen worden? "Waar wordt mijn data gebruikt?". Idealiter zoekt de HR-data manager op de term "salaris" in de data catalogus en krijgt hij direct inzicht in de databases en rapportages die salarisgegevens gebruiken.
En hoe zou vraag twee beantwoord kunnen worden? "De SAP-tabel `MARD` gaat op de schop. Kunnen jullie zorgen dat alle dataproducten blijven draaien?". In dit geval zoekt de IT-architect de SAP-maatwerktabel op, klikt op de rechtermuisknop en selecteert "Show impacted data products". Hiermee krijgt hij direct een lijst van alle dataproducten die met deze tabel interacteren. Dit inzicht scheelt veel ongewenste verrassingen bij een migratie.
De praktijk van data lineage
Als data lineage eenvoudig te realiseren was, dan had elke organisatie dit wel op orde. Waar lopen organisaties dan vooral tegenaan? Dit is wat wij zien in de praktijk:
Geen catalogus — of te veel. Er is vrijwel nooit één plek, een “data catalogus”, waar alle relevante dataobjecten te vinden zijn. Of erger: er zijn er meer dan één, ieder met een deel van de dataset. Dan moet je zelf de puzzel leggen voordat je überhaupt lineage-vragen kunt stellen.
Data lineage-tools lossen de belofte niet in. Er zijn tools in te kopen, maar het is niet "plug and play" als je landschap niet precies volgens hun standaarden is ingericht. Ze zijn vaak niet volledig en niet betrouwbaar. Niet gebouwd voor grote hoeveelheden data — eerder voor een klein landschap in veel detail. En de visualisatie? Of te hoog-over (te weinig concreet voor specialisten) of te gedetailleerd (governance kan geen grip houden). Precies daar gaat het mis. Wat je nodig hebt is iets ertussenin: genoeg detail om impact te kunnen beoordelen, genoeg overzicht om het landschap te begrijpen.
Connectoren: jij past je aan, niet de tool. "Tientallen standaard connectoren, lineage uit bijvoorbeeld Snowflake, Matillion, Power BI direct beschikbaar" — zo klinkt de verkoop. De praktijk: welke objecten worden gebruikt, wordt wel duidelijk; hoe ze van A naar B stromen, niet. En daarom gaat het nou juist. Dan: "Om onze standaard te gebruiken, moet je wel aan deze richtlijnen voldoen. Die hanteren jullie niet — kunnen jullie even jullie ETL-flows ombouwen?" Dat zijn er honderden, weet je nog? 🤨 Vraag of de connector kan worden omgebouwd naar jullie implementatie? "Neen." Dus: of je past je hele landschap aan op de tool, of je zoekt een andere weg.
Data lineage wordt vaak verkocht als oplosbaar technisch probleem, maar het is in de praktijk een systeemprobleem. In onze volgende blog laten we zien hoe wij een dergelijk probleem hebben aangepakt en opgelost voor een grote organisatie.
Wat is data lineage en waarom is het zo moeilijk om data lineage van kop-tot-staart te bereiken? In deze blog vertellen we wat we zien in de praktijk aan de hand van twee schijnbaar simpele vragen. We tonen aan dat data lineage vooral een systeemprobleem is en niet eenvoudig op te lossen met een nieuwe tool.
|
Bij veel grote organisaties staat digitalisatie en de ambitie om data-gedreven te werken prominent in de strategie. Dit uit zich in BI-teams voor reporting en dashboarding, data science voor voorspellende analyses, data- en platform engineers voor de platformen, en business analisten die extra inzichten leveren. Er wordt hard gewerkt, maar het gemis van overzicht van het datalandschap bemoeilijkt het werk. Hierdoor is het lastig te zien wat wordt overgeslagen, wat dubbel wordt gedaan en wat prioriteit moet hebben. En alle initiatieven ten spijt is het nog steeds niet mogelijk voor een organisatie om twee simpele vragen te beantwoorden.
Twee simpele vragen
De twee ogenschijnlijk simpele vragen die in elke corporate organisatie kunnen worden gesteld zijn:
"Waar wordt mijn data gebruikt?" vraagt de HR Data Manager aan ICT.
"De SAP-tabel `MARD` gaat op de schop. Kunnen jullie zorgen dat alle data producten blijven draaien?" vraagt de Delivery Manager aan het data team.
Hoe simpel deze vragen ook lijken, het blijkt in de praktijk ontzettend lastig, tijdrovend en complex om ze te beantwoorden. De oorzaken? Drie in het kort:
Het data platform is grooooot. Een centraal dataplatform in een organisatie met 7.000 medewerkers bevat al snel tienduizenden tabellen, honderden verladingen per dag en ETL-jobs die met hun onderlinge afhankelijkheden allemaal 's ochtends gereed moeten zijn. Op zoek naar de impact van het wijzigen van de `MARD`-tabel? Speld in een hooiberg. En dan heb je het alleen nog over het dataplatform — de bronsystemen en rapportagetools tellen we even mee.
Figuur 1: visualisatie van de data-objecten die zijn gekoppeld aan de `MARD`-tabel uit SAP
Het landschap is onoverzichtelijk doordat het organisch is gegroeid. In het begin, één team, eerste data — nog onder controle. Snel daarna, door het succes, meerdere teams op hetzelfde platform. Architectuur en modelleringsvorm wijzigen mee. Wat logisch was met 2 teams, werkt niet meer met 20. Grip houden wordt lastig, en niemand heeft het overzicht meer in z'n hoofd.
Ontwarren is saai en levert niet direct business waarde. Waarom iets dat nu werkt (oké, wellicht te complex) ontwarren, opnieuw modelleren, testen, en dan pas een nieuwe dataset toevoegen? Als het ook in één keer kan, is dat leuker en levert het sneller business waarde op. Geen wonder dat de kluwen blijft groeien. Voor een data engineer blijft het lastig om te achterhalen welke data er onder een complex rapport hangt — laat staan bij een geheel systeem zoals SAP.
Het antwoord zou data lineage moeten zijn
Kunnen deze vragen wel beantwoord worden als data lineage is geïmplementeerd? Data lineage is een techniek waarbij je een data-object kunt volgen binnen je gehele landschap. Elk object wordt gecreëerd volgens een systematiek en het is inzichtelijk waar de data naartoe stroomt. We onderscheiden logische en fysieke dataobjecten:
Logische objecten: business concepten (zoals "klant", "medewerker") op modelniveau;
Fysieke objecten: tabellen, kolommen, rapporten in het platform.
Een logisch object kan door meerdere fysieke objecten worden geïmplementeerd — geen 1-op-1 met de techniek, maar wel traceerbaar als je de koppeling goed legt.
Hoe zou de vraag van de HR manager dan wel beantwoord kunnen worden? "Waar wordt mijn data gebruikt?". Idealiter zoekt de HR-data manager op de term "salaris" in de data catalogus en krijgt hij direct inzicht in de databases en rapportages die salarisgegevens gebruiken.
En hoe zou vraag twee beantwoord kunnen worden? "De SAP-tabel `MARD` gaat op de schop. Kunnen jullie zorgen dat alle dataproducten blijven draaien?". In dit geval zoekt de IT-architect de SAP-maatwerktabel op, klikt op de rechtermuisknop en selecteert "Show impacted data products". Hiermee krijgt hij direct een lijst van alle dataproducten die met deze tabel interacteren. Dit inzicht scheelt veel ongewenste verrassingen bij een migratie.
De praktijk van data lineage
Als data lineage eenvoudig te realiseren was, dan had elke organisatie dit wel op orde. Waar lopen organisaties dan vooral tegenaan? Dit is wat wij zien in de praktijk:
Geen catalogus — of te veel. Er is vrijwel nooit één plek, een “data catalogus”, waar alle relevante dataobjecten te vinden zijn. Of erger: er zijn er meer dan één, ieder met een deel van de dataset. Dan moet je zelf de puzzel leggen voordat je überhaupt lineage-vragen kunt stellen.
Data lineage-tools lossen de belofte niet in. Er zijn tools in te kopen, maar het is niet "plug and play" als je landschap niet precies volgens hun standaarden is ingericht. Ze zijn vaak niet volledig en niet betrouwbaar. Niet gebouwd voor grote hoeveelheden data — eerder voor een klein landschap in veel detail. En de visualisatie? Of te hoog-over (te weinig concreet voor specialisten) of te gedetailleerd (governance kan geen grip houden). Precies daar gaat het mis. Wat je nodig hebt is iets ertussenin: genoeg detail om impact te kunnen beoordelen, genoeg overzicht om het landschap te begrijpen.
Connectoren: jij past je aan, niet de tool. "Tientallen standaard connectoren, lineage uit bijvoorbeeld Snowflake, Matillion, Power BI direct beschikbaar" — zo klinkt de verkoop. De praktijk: welke objecten worden gebruikt, wordt wel duidelijk; hoe ze van A naar B stromen, niet. En daarom gaat het nou juist. Dan: "Om onze standaard te gebruiken, moet je wel aan deze richtlijnen voldoen. Die hanteren jullie niet — kunnen jullie even jullie ETL-flows ombouwen?" Dat zijn er honderden, weet je nog? 🤨 Vraag of de connector kan worden omgebouwd naar jullie implementatie? "Neen." Dus: of je past je hele landschap aan op de tool, of je zoekt een andere weg.
Data lineage wordt vaak verkocht als oplosbaar technisch probleem, maar het is in de praktijk een systeemprobleem. In onze volgende blog laten we zien hoe wij een dergelijk probleem hebben aangepakt en opgelost voor een grote organisatie.
Wat is data lineage en waarom is het zo moeilijk om data lineage van kop-tot-staart te bereiken? In deze blog vertellen we wat we zien in de praktijk aan de hand van twee schijnbaar simpele vragen. We tonen aan dat data lineage vooral een systeemprobleem is en niet eenvoudig op te lossen met een nieuwe tool.
|
Bij veel grote organisaties staat digitalisatie en de ambitie om data-gedreven te werken prominent in de strategie. Dit uit zich in BI-teams voor reporting en dashboarding, data science voor voorspellende analyses, data- en platform engineers voor de platformen, en business analisten die extra inzichten leveren. Er wordt hard gewerkt, maar het gemis van overzicht van het datalandschap bemoeilijkt het werk. Hierdoor is het lastig te zien wat wordt overgeslagen, wat dubbel wordt gedaan en wat prioriteit moet hebben. En alle initiatieven ten spijt is het nog steeds niet mogelijk voor een organisatie om twee simpele vragen te beantwoorden.
Twee simpele vragen
De twee ogenschijnlijk simpele vragen die in elke corporate organisatie kunnen worden gesteld zijn:
"Waar wordt mijn data gebruikt?" vraagt de HR Data Manager aan ICT.
"De SAP-tabel `MARD` gaat op de schop. Kunnen jullie zorgen dat alle data producten blijven draaien?" vraagt de Delivery Manager aan het data team.
Hoe simpel deze vragen ook lijken, het blijkt in de praktijk ontzettend lastig, tijdrovend en complex om ze te beantwoorden. De oorzaken? Drie in het kort:
Het data platform is grooooot. Een centraal dataplatform in een organisatie met 7.000 medewerkers bevat al snel tienduizenden tabellen, honderden verladingen per dag en ETL-jobs die met hun onderlinge afhankelijkheden allemaal 's ochtends gereed moeten zijn. Op zoek naar de impact van het wijzigen van de `MARD`-tabel? Speld in een hooiberg. En dan heb je het alleen nog over het dataplatform — de bronsystemen en rapportagetools tellen we even mee.
Figuur 1: visualisatie van de data-objecten die zijn gekoppeld aan de `MARD`-tabel uit SAP
Het landschap is onoverzichtelijk doordat het organisch is gegroeid. In het begin, één team, eerste data — nog onder controle. Snel daarna, door het succes, meerdere teams op hetzelfde platform. Architectuur en modelleringsvorm wijzigen mee. Wat logisch was met 2 teams, werkt niet meer met 20. Grip houden wordt lastig, en niemand heeft het overzicht meer in z'n hoofd.
Ontwarren is saai en levert niet direct business waarde. Waarom iets dat nu werkt (oké, wellicht te complex) ontwarren, opnieuw modelleren, testen, en dan pas een nieuwe dataset toevoegen? Als het ook in één keer kan, is dat leuker en levert het sneller business waarde op. Geen wonder dat de kluwen blijft groeien. Voor een data engineer blijft het lastig om te achterhalen welke data er onder een complex rapport hangt — laat staan bij een geheel systeem zoals SAP.
Het antwoord zou data lineage moeten zijn
Kunnen deze vragen wel beantwoord worden als data lineage is geïmplementeerd? Data lineage is een techniek waarbij je een data-object kunt volgen binnen je gehele landschap. Elk object wordt gecreëerd volgens een systematiek en het is inzichtelijk waar de data naartoe stroomt. We onderscheiden logische en fysieke dataobjecten:
Logische objecten: business concepten (zoals "klant", "medewerker") op modelniveau;
Fysieke objecten: tabellen, kolommen, rapporten in het platform.
Een logisch object kan door meerdere fysieke objecten worden geïmplementeerd — geen 1-op-1 met de techniek, maar wel traceerbaar als je de koppeling goed legt.
Hoe zou de vraag van de HR manager dan wel beantwoord kunnen worden? "Waar wordt mijn data gebruikt?". Idealiter zoekt de HR-data manager op de term "salaris" in de data catalogus en krijgt hij direct inzicht in de databases en rapportages die salarisgegevens gebruiken.
En hoe zou vraag twee beantwoord kunnen worden? "De SAP-tabel `MARD` gaat op de schop. Kunnen jullie zorgen dat alle dataproducten blijven draaien?". In dit geval zoekt de IT-architect de SAP-maatwerktabel op, klikt op de rechtermuisknop en selecteert "Show impacted data products". Hiermee krijgt hij direct een lijst van alle dataproducten die met deze tabel interacteren. Dit inzicht scheelt veel ongewenste verrassingen bij een migratie.
De praktijk van data lineage
Als data lineage eenvoudig te realiseren was, dan had elke organisatie dit wel op orde. Waar lopen organisaties dan vooral tegenaan? Dit is wat wij zien in de praktijk:
Geen catalogus — of te veel. Er is vrijwel nooit één plek, een “data catalogus”, waar alle relevante dataobjecten te vinden zijn. Of erger: er zijn er meer dan één, ieder met een deel van de dataset. Dan moet je zelf de puzzel leggen voordat je überhaupt lineage-vragen kunt stellen.
Data lineage-tools lossen de belofte niet in. Er zijn tools in te kopen, maar het is niet "plug and play" als je landschap niet precies volgens hun standaarden is ingericht. Ze zijn vaak niet volledig en niet betrouwbaar. Niet gebouwd voor grote hoeveelheden data — eerder voor een klein landschap in veel detail. En de visualisatie? Of te hoog-over (te weinig concreet voor specialisten) of te gedetailleerd (governance kan geen grip houden). Precies daar gaat het mis. Wat je nodig hebt is iets ertussenin: genoeg detail om impact te kunnen beoordelen, genoeg overzicht om het landschap te begrijpen.
Connectoren: jij past je aan, niet de tool. "Tientallen standaard connectoren, lineage uit bijvoorbeeld Snowflake, Matillion, Power BI direct beschikbaar" — zo klinkt de verkoop. De praktijk: welke objecten worden gebruikt, wordt wel duidelijk; hoe ze van A naar B stromen, niet. En daarom gaat het nou juist. Dan: "Om onze standaard te gebruiken, moet je wel aan deze richtlijnen voldoen. Die hanteren jullie niet — kunnen jullie even jullie ETL-flows ombouwen?" Dat zijn er honderden, weet je nog? 🤨 Vraag of de connector kan worden omgebouwd naar jullie implementatie? "Neen." Dus: of je past je hele landschap aan op de tool, of je zoekt een andere weg.
Data lineage wordt vaak verkocht als oplosbaar technisch probleem, maar het is in de praktijk een systeemprobleem. In onze volgende blog laten we zien hoe wij een dergelijk probleem hebben aangepakt en opgelost voor een grote organisatie.