Voor de meeste organisaties is kopen de betere keuze, tenzij je een team hebt dat de catalog jarenlang wil onderhouden. Een eerste versie bouwen gaat snel: een lijst met tabellen, wat definities, een zoekveld. De echte kost komt daarna. Connectoren breken bij updates van je bronnen, metadata veroudert en iemand moet eigenaars blijven opvolgen. Bouwen loont alleen als je iets nodig hebt dat geen product biedt, en je dat werk structureel kan bemannen.
Waarom zelf bouwen goedkoper lijkt dan het is
De meeste teams vergelijken bouwen en kopen op de eerste maanden. Dat is de verkeerde periode. Bouwen is het makkelijke deel. De kost zit in alles wat daarna komt.
Een voorbeeld. Het BI-team bouwt een glossary in SharePoint, met een script dat elke nacht de Power BI-workspaces uitleest. Na een paar sprints staat het er. Iedereen is tevreden. Een half jaar later is er een nieuwe bron bij, verandert een API, en vertrekt de collega die het script schreef. Niemand durft er nog aan te komen. De definities kloppen niet meer, en de business stopt met kijken.
Dat is geen slecht team. Dat is het normale leven van intern gebouwde software die niemand als product beheert.
Wat een data catalog echt moet kunnen
Een lijst met tabellen is nog geen data catalog. Als je zelf bouwt, bouw je ook dit:
- Connectoren naar je bronnen: Power BI, je datawarehouse, je ERP. Elke bron heeft eigen API's die regelmatig wijzigen.
- Automatische scan en lineage, zodat je ziet welk rapport uit welke tabel komt, zonder dat iemand dat met de hand bijhoudt.
- Definities en eigenaars, met een manier om ze te laten goedkeuren en te herzien.
- Rechten en toegang, zodat mensen alleen zien wat ze mogen zien.
- Een zoekfunctie en een interface die een businessgebruiker zonder opleiding begrijpt.
- Zicht op datakwaliteit, zodat een lezer weet of het cijfer van vandaag te vertrouwen is.
Elk van die onderdelen is een project op zich. Samen zijn ze een product dat je moet blijven onderhouden.
Waar zit de kost na de lancering?
De kost van een catalog zit niet in de eerste versie. Ze zit in het werk dat elke maand terugkomt.
- Techniek. Bronnen veranderen, API's wijzigen, beveiligingsupdates moeten worden doorgevoerd. Wie bouwt, is ook verantwoordelijk voor upgrades.
- Inhoud. Definities verouderen, eigenaars wisselen van job, nieuwe rapporten komen erbij. Zonder vaste opvolging is een catalog na een jaar een archief.
- Adoptie. Gebruikers vragen nieuwe functies, en een interne tool concurreert met elke andere prioriteit van het team.
- Kennis. Vaak weten maar één of twee mensen hoe het precies werkt. Als zij vertrekken, vertrekt de catalog mee.
Een gekochte catalog neemt de techniek grotendeels van je over. De inhoud blijft altijd jouw werk. De vraag is dus ook: welk product maakt dat inhoudelijke werk het lichtst?
Bouwen, open source of kopen: hoe vergelijk je?
| Aanpak | Snel een eerste versie | Wie onderhoudt de techniek | Wie houdt de inhoud actueel | Past als |
|---|---|---|---|---|
| Zelf bouwen (wiki, SharePoint, eigen app) | Ja | Je eigen team, altijd | Je eigen team | De scope klein is en blijft |
| Open source catalog zelf hosten | Redelijk | Je eigen team: hosting, upgrades, connectoren | Je eigen team | Je een sterk data engineering team hebt dat dit wil beheren |
| Enterprise governance suite | Nee, vaak een lang traject | De leverancier | Data stewards en een governance team | Je een brede governance-organisatie hebt of opbouwt |
| Lichte catalog die in je rapporten zichtbaar is | Ja | De leverancier | De benoemde eigenaars, in hun eigen werk | De business vooral rapporten wil begrijpen en vertrouwen |
Wanneer zelf bouwen wel een goed idee is
Bouwen is niet altijd fout. Het kan de juiste keuze zijn als:
- je één of twee bronnen hebt en dat zo blijft;
- je data engineering team een catalog als product wil beheren, met tijd en budget voor onderhoud;
- je een heel specifieke vereiste hebt die geen product invult, en die vereiste belangrijker is dan al de rest.
Twijfel je, begin dan met de vraag wie de catalog over twee jaar beheert. Als je daar geen naam op kan zetten, is bouwen een risico.
Vijf vragen voor je beslist: Doel, Lezers, Bronnen, Onderhoud, Eigenaarschap
- Doel: welk probleem lost de catalog op, en hoe zie je dat het opgelost is?
- Lezers: zijn het data engineers, analisten of businessgebruikers die rapporten lezen?
- Bronnen: hoeveel systemen moet je koppelen, en hoe vaak veranderen ze?
- Onderhoud: wie houdt connectoren, upgrades en beveiliging bij, nu en over twee jaar?
- Eigenaarschap: wie houdt de definities actueel, en past dat in hun gewone werk?
Waar dScribe past
dScribe is een data catalog die je koopt in plaats van bouwt, gemaakt voor organisaties die vooral willen dat de business hun rapporten begrijpt. In Power BI toont de browserplugin de definities en eigenaars op de rapporten die je team al opent, en mislukte runs als alert. Datakwaliteitsproblemen zie je samen op één plek, in een marketplace in de dScribe-app. dScribe leest alleen metadata, je data zelf wordt niet verplaatst. Het crawlt de metadata van je systemen, ook oudere, en bouwt er een inventaris van, zodat je team geen eigen connectoren hoeft te onderhouden. Voor het inhoudelijke werk helpen slimme suggesties: ze helpen termen en KPI's te definiëren, koppelen ze aan de rapporten en datasets waarin ze lijken te worden gebruikt, vinden dubbels en helpen lineage op te bouwen. KPI's definiëren blijft deels handwerk, maar de suggesties maken het lichter.
In short
De vraag is niet of je een data catalog kan bouwen. Dat kan bijna elk BI-team. De vraag is of je hem wil onderhouden, elke maand, ook als de bouwer vertrekt. Vergelijk dus niet de eerste versie, maar het tweede jaar. Wie dan nog de techniek en de definities bijhoudt, bepaalt of je catalog leeft of een archief wordt.
Veelgestelde vragen
Wat kost het om zelf een data catalog te bouwen?
De bouw is zelden het grootste deel. Reken ook de mensen die de komende jaren connectoren, upgrades, beveiliging en gebruikersvragen opvolgen. Dat werk loopt door zolang de catalog bestaat.
Is een open source data catalog gratis?
De software wel, het gebruik niet. Je moet hem zelf hosten, upgraden, koppelen aan je bronnen en ondersteunen. Dat vraagt een team dat dit als vaste taak heeft.
Kunnen we niet gewoon Excel of SharePoint als data catalog gebruiken?
Voor een eerste lijst met definities wel. Het probleem is dat zo'n lijst los staat van je rapporten en bronnen, waardoor ze veroudert en weinig gelezen wordt. Zodra je automatische scans, lineage of zicht op datakwaliteit nodig hebt, bots je op de grenzen.
Wanneer is een data catalog kopen beter dan bouwen?
Als je meerdere bronnen hebt, als de business de catalog moet gebruiken, en als je geen team hebt dat hem als product wil onderhouden. Dat is in de meeste middelgrote en grote organisaties het geval.
Hoe begin je met een data catalog zonder groot traject?
Kies één domein en een handvol rapporten die veel gelezen worden. Spreek daar de definities en eigenaars af en maak ze zichtbaar waar mensen lezen. Breid pas uit als dat domein leeft.