Metadata voor observability en governance: verder dan information_schema
Een aantal weken geleden, wijdden we een blog aan het gebruik van metadata voor het slimmer ontwikkelen en onderhouden van dataplatforms. Metadata wordt helaas nog vaak gezien als het saaie bijproduct van data: een paar kolomnamen, datatypes en misschien een timestamp, maar in moderne dataplatformen is dat nog maar het topje van de ijsberg. Metadata kan, mits goed benut, een krachtig fundament vormen voor zowel observability als governance. Het kan helpen bij het opsporen van problemen, het begrijpen van datastromen, het garanderen van compliance en zelfs het optimaliseren van prestaties.

Data migraties zijn voor veel organisaties een uitdaging: je stapt over van een oud systeem naar een nieuw, je moderniseert je datawarehouse of je integreert een nieuw platform na een fusie. Ondanks dat het technisch ‘slechts’ het verplaatsen van data lijkt, komt er meer bij kijken om een goede datamigratie uit te voeren. Hoe weet je zeker dat de data na migratie nog klopt? Dat er niets verloren is gegaan, of erger nog: dat je geen subtiele fouten hebt geïntroduceerd die maanden later pas boven water komen?
In deze blog staan we stil bij test- en validatiestrategieën bij data migraties. We bespreken waarom het testen van een datamigratie fundamenteel anders is dan het testen van een standaard applicatie, welke technieken je kunt gebruiken om betrouwbaarheid te garanderen, en hoe je omgaat met de praktische uitdagingen die je onderweg tegenkomt.

In veel MKB-organisaties is het verzamelen en rapporteren van data nog steeds een tijdrovende en foutgevoelige klus. Excel-bestanden circuleren overal, gegevens worden handmatig gecorrigeerd in verschillende systemen en rapportages worden met de hand bijgewerkt. Het gevolg is dat managers en analisten vaak worstelen met verouderde inzichten, inconsistente cijfers en een gebrek aan overzicht. Hierdoor duurt het langer voordat er goede beslissingen genomen kunnen worden en het vertrouwen in de data neemt af.

Een bekend probleem is dat data uit verschillende systemen, zoals een boekhoudpakket, CRM of HR-software, niet automatisch met elkaar verbonden zijn. Dit leidt tot dubbel werk, handmatige controles en fouten bij het overzetten van data. Denk bijvoorbeeld aan het handmatig aanpassen van uitzonderingen in BTW-tarieven of het dubbel moeten invoeren van klantgegevens. Deze werkwijze kost veel tijd en brengt risico’s met zich mee.

Hopelijk weet iedereen die met databases werkt van het bestaan van standaard metagegevens waarmee er gemakkelijk inzicht verkregen kan worden over de structuur, data en opzet van de database. Ook voor dataplatforms zijn deze objecten enorm waardevol. Toch wordt het potentieel van metagegevens nog vaak onderschat, terwijl vrijwel elke (moderne) relationele database, van PostgreSQL tot Snowflake, een krachtig en vaak onderbenut startpunt biedt in de vorm van information_schema.

In deze blog duiken we dieper in hoe metagegevens via information_schema je dataplatform slimmer, transparanter en beheersbaarder maken. Voor zowel data engineers die pipelines bouwen, als analisten die vertrouwen op stabiele datasets, bieden deze metagegevens enorme voordelen. Van automatisch documenteren tot het voorkomen van incidenten: wie information_schema goed gebruikt, bouwt een robuuster platform.

Sinds het begin van het gebruik van Business Intelligence hebben organisaties vertrouwd op periodieke dataverwerking, de zogenaamde ’batch jobs’ die elke nacht draaien. Sindsdien is de behoefte aan snelheid, flexibiliteit en realtime inzichten enorm toegenomen. Die behoefte zorgt dan ook voor een fundamentele verschuiving in hoe we data-architecturen ontwerpen: weg van batch processen, op weg naar een event-driven benadering.

Maar wat betekent dat eigenlijk: ’event-driven’? En waarom zou je hier als data engineer, analist, data scientist of business gebruiker wakker van moeten liggen? In deze blog duiken we in de wereld van event-driven data-architecturen, hun voordelen, uitdagingen, en de tools die deze transitie mogelijk maken.

In een data gedreven organisatie vliegen de samenwerkingstermen je om de oren: DevOps, DataOps, MLOps. Deze drie termen, die inderdaad erg hetzelfde klinken (en door sommige organisaties ingevuld worden door een beheerder in een ontwikkelteam te zetten), verschillen in de praktijk aanzienlijk in toepassing, focus en doel. Voor wie dagelijks werkt met data of systemen die op data drijven, is het essentieel om deze termen niet alleen te kennen, maar ook te begrijpen wat ze betekenen en hoe ze zich tot elkaar verhouden. Daar nemen we jullie in deze blog dan ook in mee.

Datamigraties lijken op het eerste gezicht slechts een technische randvoorwaarde, maar zijn in werkelijkheid een strategisch en risicovol proces. Uiteraard willen bedrijven de data die ze al hebben weer terugzien in de nieuwe applicatie. Het klinkt misschien als een simpele verhuizing, maar bij een datamigratie komt een hoop kijken. Je hebt immers niet alleen te maken met de twee systemen waar de data uitkomt, maar ook met de kritische processen die erop draaien. Denk aan orderverwerking, voorraadbeheer of klantcommunicatie.

Een slechte aanpak kan zorgen voor kostbare downtime, verstoringen in processen of zelfs verlies van klantvertrouwen. Organisaties staan vaak voor de keuze tussen twee migratiestrategieën: de ‘big bang’-aanpak of een gefaseerde overgang.
Welke kies je en waarom? We nemen je mee in de afwegingen.