Om de ETL-pipelines zo flexibel mogelijk op te zetten is het van belang dat de generieke code (logica) van de organisatie-specifieke metadata (configuratie) wordt gescheiden. Ofwel, de ETL moet metadata-gedreven zijn. De metadata bestaat uit specificaties van de op te halen data. Dat kunnen bijvoorbeeld de url, filename, path, type, tabelnamen, kolomnamen, etc. zijn. Deze metadata staat dus nooit hard-coded in de ETL-scripts/pipelines.

Deze metadata moet ergens staan en bijgewerkt kunnen worden. Voor de Ingest-stappen (van bron t/m de psa-laag) staat de metadata in YAML configuratie bestanden. Voor de laadstap naar het GGM (en later ook Datamart) staat de metadata in SQLmesh modellen. Uit zowel de yaml's als de SQLmesh modellen kan de metadata opgehaald worden en m.b.v. een data catalog geanalyseerd worden. Er zijn verschillende tools beschikbaar om deze metadata vervolgens te managen en bijv. de lineage in kaart te brengen.

De pipelines draaien al "metadata-driven" d.m.v. de yaml's. Voor extra functionaliteit moet nog een tool geselecteerd worden, opties zijn:
- OpenMetadata
- DataHub
- Atlas
- Amundsen

Het voordeel van de specifieke tools is dat daarin vaak ook andere nuttige functionaliteit zit zoals data lineage, catalogus, data kwaliteit, etc. Het nadeel is dat dit een éxtra tool is (die we voor de PoC niet nodig hebben). Voor nu kunnen we beginnen met config files in YAML (goed leesbaar, wijd verspreid gebruik).

Resources voor wanneer we wél naar de tools gaan kijken:
https://dataworkers.io/resources/data-catalog-complete-guide/
https://www.pistack.xyz/posts/2026-05-17-self-hosted-data-mesh-platforms-openmetadata-atlas-datahub-guide/
https://dataworkers.io/resources/openmetadata/
https://atlan.com/openmetadata-vs-openlineage/