In veel organisaties is metadata een bijproduct. Het ontstaat vanzelf als data ergens naartoe stroomt, maar niemand denkt bewust na over wat er vastgelegd moet worden, door wie, en hoe het beheerd wordt. Het gevolg is voorspelbaar: datasets zonder context, lineage die niet klopt en audits die uren handmatig speurwerk kosten.
Een conceptueel metadata-framework doorbreekt dat patroon. Niet doordat alles direct geautomatiseerd wordt, maar doordat eerst de juiste structuur wordt aangebracht en pas daarna de tooling wordt gekozen.
Wat is een conceptueel metadata-framework?
Een conceptueel metadata-framework definieert welke metadata er bestaat, hoe de verschillende soorten zich tot elkaar verhouden, en wie verantwoordelijk is voor het beheer ervan. Het is nadrukkelijk conceptueel. Het gaat dus niet over welke tool je gebruikt, maar over de onderliggende structuur.
In de praktijk onderscheid ik drie hoofdcategorieën:
- Technische metadata: structuur, formaten, locaties en interfaces. Deze metadata wordt grotendeels automatisch gegenereerd door platformen en pipelines.
- Business metadata: definities, eigenaarschap, classificatie en gebruiksdoeleinden. Hiervoor is actieve bijdrage van de business nodig.
- Operationele metadata: lineage, kwaliteitsscores, verwerkingstijden en run-historie. Deze informatie ontstaat in pipelines en governance-tooling.
De kunst zit in de verbinding tussen deze drie. Technische metadata zonder business context is waardeloos voor een analist. Business metadata zonder operationele koppeling is niet te verifiëren.
Het raamwerk in de praktijk
Bij een recente opdracht bij een financiële instelling was de opgave om ESG-dataproducten auditeerbaar te maken conform BCBS239. De vraag was niet welk governance-platform we zouden inzetten, maar eerst: wat moeten we eigenlijk vastleggen?
Het antwoord volgde uit het framework:
- Per dataset: eigenaar, classificatie (publiek / intern / vertrouwelijk / geheim), kwaliteitsnorm en retentiebeleid
- Per attribuut: definitie, herkomst, validatieregel en wijzigingshistorie
- Per pipeline-run: bronversie, transformatiestappen, kwaliteitsresultaat en tijdstempel
Pas nadat dit conceptueel helder was, werden de technische keuzes gemaakt: Databricks Unity Catalog voor technische en operationele metadata, aangevuld met een domeinmodel in de eigen datastore voor business metadata.
Governance als architectuurprincipe
Een metadata-framework werkt alleen als het niet als een laag bovenop de architectuur wordt toegevoegd, maar er deel van uitmaakt. Dat betekent:
- Datacontracten definiëren metadata-verplichtingen tussen producent en consument
- Medallion-architectuur als structuur om kwaliteit per laag expliciet te maken (bron → verrijkt → gecureerd)
- Lineage by design: elke transformatiestap legt automatisch de herkomst vast. Het is dus geen nagedachte.
Dit is wat DAMA bedoelt met governance by design: metadata-management is geen project dat je eenmalig uitvoert, maar een discipline die ingebakken zit in hoe data wordt aangemaakt, verwerkt en beschikbaar gesteld.
Conclusie
Een conceptueel metadata-framework is geen academische oefening. Het is het fundament voor betrouwbare lineage, zinvolle datakwaliteitsscores en serieuze compliancerapportages. Organisaties die deze stap overslaan en direct beginnen met toolselectie, bouwen governance op drijfzand.
De volgorde is altijd: eerst het concept, dan de architectuur, dan de implementatie.