Dataplatform laten bouwen

Een dataplatform is een centrale plek waar gegevens uit verschillende bronsystemen worden opgehaald, opgeschoond, gecombineerd en beschikbaar gemaakt voor rapportages, analyses en andere toepassingen. Het bronsysteem blijft leidend; het platform is een kopie die is ingericht om vragen te beantwoorden.

De signalen dat u er een nodig heeft, zijn meestal herkenbaar:

• twee afdelingen rapporteren een ander aantal voor hetzelfde begrip;
• rapportages worden gemaakt door exports uit meerdere systemen in een spreadsheet te combineren;
• zware rapportagequery's maken een bronsysteem traag voor de mensen die erin werken;
• niemand weet precies hoe een cijfer in het jaarverslag tot stand is gekomen.

Een dataplatform is niet nodig als u één bronsysteem heeft met goede ingebouwde rapportages, of als de vragen zo zelden voorkomen dat een handmatige export volstaat. Ligt het probleem vooral in één spreadsheet die is uitgegroeid tot bedrijfsapplicatie, dan past maatwerk software vaak beter. Bent u een mkb-bedrijf met vooral boekhouding, webwinkel en CRM als bron, dan is een compact data warehouse voor het mkb de kleinere variant. Twijfelt u, begin dan met één vraag en kijk of het antwoord de moeite waard is.

Een dataplatform hoeft geen groot project te zijn. Het bestaat uit vier lagen die u stap voor stap kunt opbouwen, te beginnen met één bron en één rapportage.

In de opzet die we voorstellen blijven de ruwe gegevens bewaard zoals ze binnenkwamen. Gaat er in een transformatie iets mis, dan rekent u opnieuw vanaf de ruwe laag in plaats van de bron opnieuw te bevragen. Dat maakt het platform ook controleerbaar: elke uitkomst is terug te leiden naar de oorspronkelijke records.

De keuze voor deze stack is een keuze voor overdraagbaarheid. PostgreSQL is een open source object-relationele database die al decennia wordt ontwikkeld en die vrijwel elke datatool kan lezen. Python is de gangbare taal voor het ophalen en bewerken van data. SQL kent bijna elke data-analist. Dat maakt het makkelijk om later eigen mensen of een andere partij op het platform te laten werken.

Met dbt worden transformaties geschreven als SQL-bestanden die in versiebeheer staan. Elke wijziging in een definitie is daardoor terug te vinden, met wie hem deed en waarom. Apache Airflow is een platform om workflows programmatisch in Python te definiëren, in te plannen en te bewaken, zodat zichtbaar is welke lading wanneer is gelukt.

Open source betekent niet dat er geen onderhoud is. Elke PostgreSQL-versie heeft een einddatum: volgens het versiebeleid van PostgreSQL is 12 november 2026 de laatste release van versie 14 (gelezen 11 oktober 2026). Een beheerafspraak voor een dataplatform bevat daarom een upgradeplan, niet alleen het oplossen van storingen. Heeft u locatiegegevens, dan voegt PostGIS ruimtelijke functies toe aan dezelfde database; zie GIS- en kaartoplossingen.

Een dataplatform is pas waardevol als mensen de cijfers vertrouwen. Dat vertrouwen komt niet van een mooi dashboard, maar van controles die automatisch draaien en van definities die zijn opgeschreven.

De documentatie van dbt omschrijft de basis van die controles zo:

Data tests are assertions you make about your models and other resources in your dbt project (for example, sources, seeds, and snapshots).

Bron: dbt Developer Hub, gelezen op 11 oktober 2026. Concreet betekent dat:

• Datatests bij elke lading. Bijvoorbeeld dat een kolom geen lege waarden of geen dubbele sleutels bevat. Faalt een test, dan wordt de rapportage niet stilzwijgend bijgewerkt.
• Eén definitie per begrip. Wat telt als een actieve klant, een afgehandelde melding of een bewoond adres? Die definitie staat één keer in het platform, met een beschrijving in gewone taal.
• Herkomst per cijfer. Van elk model is zichtbaar uit welke bronnen en tussenstappen het is opgebouwd.
• Bewaking van ladingen. Blijft een bron leeg of komen er ineens veel minder records binnen, dan krijgt de beheerder een melding.

Fouten in de bron lost het platform niet op. Het maakt ze wel zichtbaar, zodat de eigenaar van het bronsysteem ze kan herstellen. Dat is vaak een van de eerste opbrengsten.

Voor overheden en publieke organisaties is een dataplatform vaak ook de bron voor open data. Dan is het verstandig om publicatie mee te nemen in het ontwerp, in plaats van er later een losse export voor te bouwen.

Daarvoor zijn twee dingen nodig. Ten eerste metadata volgens DCAT-AP-NL, het Nederlandse profiel voor het beschrijven van datasets en datacatalogi. Geonovum heeft versie 3.0 vastgesteld op 26 mei 2025. Ten tweede een catalogus of portaal waar de datasets te vinden zijn. CKAN is daarvoor een veelgebruikt open source datamanagementsysteem voor dataportalen.

In het platform houdt dat in dat elke publiceerbare dataset een eigen, gecontroleerde publicatielaag krijgt, zonder velden die niet openbaar mogen. De metadata worden uit het platform zelf gegenereerd, zodat beschrijving en inhoud niet uit elkaar lopen. Wie een volledig open dataportaal zoekt, vindt dat bij het open data platform. Hoe een gemeente het publiceren organiseert, staat in de kennisbank onder open data publiceren als gemeente.

Een dataplatform brengt gegevens samen die eerder gescheiden waren. Dat vergroot de waarde, maar ook het risico. Wie toegang heeft tot het platform, kan combinaties maken die in de bronsystemen niet mogelijk waren.

Daarom richten we het platform in volgens een paar uitgangspunten:

• alleen de velden ophalen die voor een afgesproken doel nodig zijn, en dat doel per bron vastleggen;
• direct identificerende gegevens zo vroeg mogelijk vervangen door een pseudoniem, zodat analisten er niet mee werken;
• toegang per laag en per dataset regelen, met aparte rollen voor beheer, analyse en raadplegen;
• bewaartermijnen technisch afdwingen, zodat oude gegevens ook echt verdwijnen;
• vastleggen wie welke query's draait op gevoelige tabellen.

Of voor uw platform een gegevensbeschermingseffectbeoordeling nodig is, bepaalt u met uw privacyfunctionaris. Wij leveren de technische beschrijving die daarvoor nodig is: welke gegevens, welke koppelingen, wie toegang heeft en hoe lang alles wordt bewaard. Die beschrijving groeit mee met elke nieuwe bron.

We bouwen een platform op vanuit één vraag, zodat er na de eerste stap al iets bruikbaars staat.

1. Eén vraag en de bronnen erachter. Welke rapportage kost nu het meeste handwerk, uit welke systemen komt die, en wie is per bron eigenaar?
2. Ruwe laag. De gegevens uit die bronnen worden ongewijzigd en met tijdstempel opgehaald, zodat elke latere stap herhaalbaar is.
3. Definities en modellen. De begrippen uit de vraag worden één keer vastgelegd als SQL-model, met datatests en een beschrijving in gewone taal.
4. Eerste ontsluiting. Eén rapportage of export op de modellen, naast de oude handmatige versie, tot de cijfers aantoonbaar overeenkomen.
5. Uitbreiden en overdragen. Volgende bronnen en vragen, plus beheerdocumentatie, upgradeplan en toegangsrollen.

Pas na stap 1 is een realistische planning te geven, omdat de toegang tot bronnen en de kwaliteit van de data het tempo bepalen.

Een dataplatform raakt aan veel systemen en afdelingen. De techniek is zelden het knelpunt; afspraken over eigenaarschap zijn dat wel.

• Per bronsysteem een eigenaar die toegang regelt en vragen over de betekenis van velden beantwoordt.
• Bij voorkeur leestoegang via een kopie of replica, zodat het platform de productieomgeving niet belast.
• Iemand die beslist over definities als afdelingen het oneens zijn.
• Een eerste concrete vraag om mee te beginnen, liefst een rapportage die nu veel handwerk kost.
• Een keuze voor de plek waar het platform draait; de afwegingen staan bij cloud- en data-infrastructuur.

Tekin Uslu, oprichter van TechinFlow, werkt volgens eigen opgave sinds 2006 aan geo-informatie, data engineering en IT-architectuur. Meer over zijn achtergrond staat op de pagina van Tekin Uslu. Begin bij voorkeur klein: één bron, één vraag en een rapportage die nu veel handwerk kost. Wilt u zo'n eerste stap bespreken, neem dan contact op.