De stille storing die meer kost dan de daadwerkelijke uitval.
Op een dinsdagochtend opent het financiële team van een middelgroot SaaS-bedrijf een dashboard dat klaar is voor de directie en merkt dat er iets niet klopt. De omzet uit de EMEA-regio ontbreekt volledig. Het cijfer is niet per se fout, maar het is er gewoon niet.
Het kost het datateam zes uur om het probleem te achterhalen: een stille schemawijziging in een Salesforce-export had drie dagen geleden een kolom hernoemd. Het dbt-model had de rijen verwijderd. De Power BI verversing was succesvol verlopen. Er was nergens in de pipeline een waarschuwing geactiveerd.
Dit is wat data-incidenten onderscheidt van applicatie-incidenten. Een webapplicatie die uitvalt, maakt veel lawaai. Een data pipeline die vastloopt, blijft stil – totdat iemand bij de financiële afdeling, marketing of de directie een beslissing neemt op basis van onjuiste cijfers.
Volgens Wakefield Research besteden data-engineers gemiddeld 40% van hun tijd aan het oplossen van problemen met de datakwaliteit, en een gemiddelde organisatie ervaart 70 data-incidenten per jaar per 1.000 tabellen. (Monte Carlo, 2024)
Er bestaat een data-observability tool die die verhouding kan omdraaien.
Wat een data-observability tool daadwerkelijk doet
Een data-observability tool bewaakt continu de gezondheid van je data en de pipelines die deze produceren. Het verzamelt metadata, voert geautomatiseerde controles uit, detecteert afwijkingen en traceert problemen tot hun oorzaak in elk systeem in de keten.
Het onderscheid dat je goed moet onthouden:
| Type tool | Wat het bewaakt | Wat het beantwoordt |
|---|---|---|
| Pipeline-orchestrator (Airflow, ADF) | Taakuitvoeringen en -planningen | Is de taak uitgevoerd? |
| Datakwaliteitstool (Great Expectations, dbt tests) | Regels op een specifieke tabel | Voldoet deze kolom aan mijn regel? |
| Data-observability tool | De data zelf, van begin tot eind | Gebeurt er ergens iets vreemds? |
Een pipeline-orchestrator vertelt je dat een taak is geslaagd. Een data kwaliteitstool vertelt je dat een regel is voldaan. Een data-observability tool vertelt je dat het dashboard dat je CFO op het punt staat te openen, cijfers bevat die niet overeenkomen met de werkelijkheid van gisteren — zelfs als er nooit een regel voor is geschreven.
Het laatste onderdeel maakt deze categorie interessant. De beste tools voor data-observability detecteren problemen waar je zelf niet aan had gedacht.
De vijf vaardigheden die er echt toe doen
Leveranciers zijn dol op checklists met functionaliteiten. De meeste komen neer op vijf mogelijkheden. Als een tool er twee of meer mist, is het eigenlijk geen tool voor data-observability, maar een dashboard.
1. Actualiteitsmonitoring Komt de meest recente tijdstempel in je data overeen met wat je voor dit uur, deze dag of deze week zou verwachten? Een model dat elke ochtend om 6 uur zou moeten worden vernieuwd, maar vier dagen geleden stilletjes is gestopt, is de meest voorkomende stille fout in dataverwerking.
2. Detectie van volumeafwijkingen Als de pipeline van gisteren 1,2 miljoen rijen produceerde en die van vandaag 80, is er iets misgegaan in de upstream-processen. Volume is een belangrijke indicator voor vrijwel elk type pipeline probleem, en een goede tool signaleert dalingen zonder dat je een drempelwaarde per tabel hoeft te definiëren.
3. Tracking van schemawijzigingen Upstream-bronnen veranderen. Kolommen worden hernoemd, verwijderd of opnieuw getypeerd zonder waarschuwing. Een schema-bewuste tool detecteert deze wijzigingen op het moment dat ze plaatsvinden, niet drie sprints later wanneer een downstream-rapport lege resultaten begint te retourneren.
4. Distributie- en waardecontroles** Vallen de spreidingen van je numerieke kolommen binnen de historische normen? Zijn de categorische waarden die je verwacht nog steeds aanwezig? Dit is waar statistische anomalie detectie zijn nut bewijst: het opsporen van problemen waarbij de data technisch gezien wel aanwezig is, maar onjuist.
5. End-to-end lineage Wanneer er iets misgaat, is de vraag nooit "wat is er mis?", maar "wat gebeurt er stroomafwaarts en wie moet dat weten?". Een tool zonder lineage dwingt je team om die vraag handmatig te beantwoorden voor elk incident, en dat is precies wanneer ze de minste tijd hebben.
Een onderzoek van Gartner uit 2024 schatte dat slechte datakwaliteit organisaties gemiddeld $ 12,9 miljoen per jaar kost, waarbij een groot deel van dat verlies toe te schrijven is aan vertraagde detectie in plaats van aan de onderliggende fout. (Gartner, via TechTarget)
Let op wat er níét op deze lijst staat: mooie dashboards, door AI gegenereerde incidentoverzichten en implementatiehandleidingen van 200 pagina's. Nuttig, soms. Doorslaggevend, nooit.
Tool vs platform vs framework: stop met alles 'observability' te noemen.
De categorie heeft een naamgevingsprobleem. Drie termen worden door elkaar gebruikt, terwijl dat niet de bedoeling is.
| Term | Wat het betekent | Voorbeelden |
|---|---|---|
| Dataobservability framework | Een filosofie of methodologie | De 'vijf pijlers'-aanpak, populair gemaakt door Barr Moses (Monte Carlo) |
| Dataobservability tool | Een specifiek product dat één of meer aspecten van de datakwaliteit monitort | Soda, Elementary, Bigeye, MetricSign |
| Dataobservability platform | Een geïntegreerde suite — observability tool + data lineage + catalogisering + governance | Monte Carlo, Acceldata, Datafold |
Een tool is iets dat je in een middag kunt installeren en waar je binnen een week al profijt van hebt. Een platform is iets dat je aanschaft, integreert en over een periode van maanden uitrolt naar verschillende teams. Beide hebben hun nut. De fout is om een platform te kopen terwijl je een tool nodig had — of erger nog, een framework presentatie te kopen terwijl je software nodig had.
"De grootste bron van verspilling in data-observability-projecten is overmatige aanschaf. Teams kiezen een platform omdat het alle functies heeft, maar gebruiken er vervolgens maar 15% van." — geparafraseerd uit een paneldiscussie van dbt Coalesce uit 2024 over het ontwerp van monitoring stacks.
Tekenen dat je er een nodig hebt (en tekenen dat je er nog geen nodig hebt)
Niet elk team heeft een speciale tool voor data-observability nodig. Laten we eens snel kijken.
Je hebt er waarschijnlijk een nodig als:
- Meer dan één business team slechte data heeft opgemerkt vóór je data team, in het afgelopen kwartaal
- Je data engineers meer dan twee dagen per maand besteden aan het debuggen van stille fouten
- Je meer dan 50 productietabellen, -modellen of -rapporten hebt
- Je met meer dan twee tools werkt (bijv. ADF + Databricks + Power BI) en cross-stack lineage nodig hebt
- Compliance of audit vereist dat je SLO's voor datakwaliteit kunt aantonen
Je hebt er waarschijnlijk nog geen nodig als:
- Je stack bestaat uit één tool met ingebouwde monitoring (bijv. alleen Snowflake met native alerts)
- Je minder dan 10 productiedatasets hebt
- Dataproblemen zeldzaam zijn en een enkel Slack-kanaal ze snel aan het licht brengt
- Je team uit minder dan drie personen bestaat en de on-call-last beheersbaar is
In die tweede categorie leveren dbt-tests plus een paar goed geplaatste pipeline-alerts je 80% van de waarde op tegen 0% van de kosten. Het juiste moment om te upgraden is wanneer je je huidige systeem ontgroeid bent, niet eerder.
Wat moet je evalueren voordat je een beslissing neemt?
Als je hebt besloten dat je een tool voor data-observability nodig hebt, is de evaluatie belangrijker dan de shortlist. We hebben teams de verkeerde tool zien kiezen omdat ze de verkeerde criteria hanteerden.
Tijd tot eerste waarde. Hoe lang duurt het van aanmelding tot een nuttige melding? Als het antwoord "weken integratiewerk" is, is die tool niet geschikt voor een klein datateam.
Dekking van jouw specifieke stack. Een tool die alleen Snowflake monitort, is niet nuttig als je problemen zich voordoen in Power BI verversingen of ADF-pipelines. Evalueer de lijst met connectors aan de hand van je daadwerkelijke stack, niet aan de hand van een generiek diagram van een moderne datastack.
Kwaliteit van meldingen, niet kwantiteit. Demonstreer elke tool door bewust een echte fout te introduceren (een kolom verwijderen, een verversing vertragen, extreem afwijkende gegevens verzenden) en kijk wat er gebeurt. Nutteloze meldingen leren je team om echte meldingen te negeren.
Geschikt prijsmodel. Prijsstelling per tabel benadeelt stacks met veel kleine tabellen. Prijsstelling op basis van verbruik benadeelt pieken in het gebruik. Prijsstelling per gebruiker benadeelt teams met veel incidentele gebruikers. Stem het model af op je specifieke situatie.
Eigendom van de metadata. Sommige tools slaan al je metadata op in hun cloud. Sommige draaien als een sidecar in je eigen omgeving. Sommige publiceren resultaten naar je datawarehouse. Het juiste antwoord hangt af van je beveiligingsstrategie, maar het is een vraag die veel teams vergeten te stellen.
Een rapport van IDC schat dat data-engineers tot 30% van hun tijd besteden aan incident triage en oorzaakanalyse, een tijdsbesteding die lineair toeneemt met de complexiteit van de stack, tenzij tools de belasting absorberen. (IDC InfoBrief, 2023)
Veelgemaakte fouten bij de adoptie van een kind
De meeste teams die een tool voor data-observability implementeren, melden na zes maanden wisselende resultaten. Het patroon van fouten is consistent.
Fout 1: Het beschouwen als een vervanging voor tests. Observatie detecteert wat je niet hebt getest. Het vervangt niet de tests die je had moeten schrijven. De twee werken samen.
Fout 2: Alles tegelijk implementeren. Een tool die op dag één 2.000 tabellen monitort, genereert op dag twee 2.000 overbodige alerts. Begin met de 20 datasets die de meest bekeken dashboards aansturen. Breid van daaruit uit.
Fout 3: Het runbook negeren. Een alert zonder eigenaar, zonder ernst niveau en zonder eerste actie is slechts een melding. De tool lost het incident responsproces niet op – dat doet je proces.
Fout 4: De zakelijke context vergeten. Technische monitoring vertelt je dat de pipeline is vastgelopen. De zakelijke context vertelt je dat het aan het einde van de maand is vastgelopen en dat de CFO over drie uur een vergadering met investeerders heeft. De beste tools stellen je in staat om datasets te taggen met die context en waarschuwingen dienovereenkomstig door te sturen.
Fout 5: Het rendement op investering (ROI) niet meten. Houd vanaf de start drie cijfers bij: de median tijd tot detectie, de median tijd tot oplossing en het aantal incidenten dat een zakelijke gebruiker bereikt. Als deze cijfers binnen 90 dagen niet veranderen, verdient de tool zijn geld niet terug – of je hebt hem niet goed geïmplementeerd.
Waar MetricSign past
We hebben MetricSign ontwikkeld omdat de markt voor data-observability tools er overwegend van uitgaat dat je werkt met de moderne datastack — Snowflake, dbt Cloud, Looker. Als je in werkelijkheid Microsoft gebruikt (Power BI, ADF, Fabric, Databricks), dan is het grootste deel van de markt niet compatibel.
MetricSign is een data-observability tool die zich richt op de Microsoft datastack. Het maakt verbinding met Power BI, ADF, Databricks, dbt (Cloud en Core), Fabric en Snowflake — en monitort alle vijf de hierboven genoemde mogelijkheden binnen die stack, inclusief data lineage tussen verschillende tools.
We zijn een tool, geen platform. Je kunt het binnen 15 minuten koppelen en dezelfde dag nog je eerste melding ontvangen. Dat is bewust zo — de meeste teams hebben een tool nodig die één specifiek probleem goed oplost, geen implementatie die een jaar duurt.