Vorige week gaf ik met veel enthousiasme een introductie over data-architecturen aan nieuwe collega’s. We bespraken de historie van architecturen, de plek van een Data Architectuur binnen een Enterprise Architectuur en hoe zo’n architectuur het werk van Data Engineers, Data Analisten en Data Scientists beïnvloedt. Data Architectuur wordt vaak gezien als een IT-feestje, maar een goede architectuur wordt altijd gedreven door heldere businessdoelen. Zonder die doelen is een data platform als een Ferrari bij een off-road rally: technisch en esthetisch indrukwekkend, maar totaal ongeschikt voor het terrein waarin het moet presteren. Zo verliest een architectuur zonder richting snel zijn waarde en wordt data engineering meer een technologisch experiment dan een strategisch fundament.

Elk relatief groot bedrijf bestaat uit verschillende afdelingen, elk met zijn eigen vraagstukken. Op datagebied is dat niet anders: marketing wil weten hoe campagnes performen, operations wil de huidige voorraad kunnen inzien, finance bewaakt de cashflow en productontwikkeling volgt klantgedrag.

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.