Dal data observability al data quality e oltre: cosa cambia nella gestione della qualità dei dati la cui complessità cresce in modo esponenziale con evidenti ricadute.

Nei decenni scorsi la gestione dei dati è stata gestita con un approccio reattivo: test manuali, controlli schedulati, validazioni a valle della pipeline. Il modello funzionava quando i dati risiedevano in database centralizzati e i processi ETL erano relativamente semplici e controllabili. Oggi non più.

Come spiega Mirko Gubian, Global Demand Senior Manager & Partner di Axiante, il panorama è cambiato radicalmente. Già nel 2023 l’indagine “State of Data Quality“, realizzata da Wakefield Research, confermava che erano aumentati sia gli incidenti legati alla qualità dei dati che i tempi medi della loro risoluzione, il cosiddetto Mean Time to Recovery (MTTR).

Il gap temporale tra l’insorgenza del problema e la sua scoperta è il vero tallone d’Achille. Le pipeline moderne elaborano dati in tempo reale o near-real-time, ma i controlli di qualità rimangono spesso schedulati una volta al giorno o alla settimana. A ciò si aggiunge il limite dei test manuali: a parte assorbire tempo prezioso, coprono soprattutto scenari noti, lasciando vulnerabili le organizzazioni rispetto ad anomalie impreviste.

Il risultato? Il Data Downtime cresce e per le organizzazioni, per cui ormai l’accuratezza e la velocità nella presa di decisione sono strategiche, questo è un grande problema.

Monitoraggio continuo

Questo handicap rende necessario adottare la cosiddetta Data Observability, una pratica di monitoraggio, gestione e manutenzione continua dei dati che tocca, in modo automatico e costante cinque aspetti principali:

– aggiornamenti secondo la frequenza attesa (Freshness)

– monitoraggio dei range normali attesi: se una tabella riceve solitamente 10.000 righe al giorno ma improvvisamente ne arrivano solo 100 o ben 50.000, ciò può indicare problemi nei sistemi upstream o duplicazioni di dati (Volume)

– coerenza strutturale dei dati rispetto alle aspettative per monitorare problemi di compatibilità o errori nelle trasformazioni (Structure)

– tracciamento del percorso completo dei dati attraverso i vari sistemi e trasformazioni (Lineage)

– verificare se i valori nei dati seguono i pattern statistici attesi (Distribution).

Cambio di prospettiva

Un cambio di prospettiva di cui molte organizzazioni stanno comprendendo la necessità. Si stima che già nel 2026 il 50% delle aziende che detengono architetture di dati distribuite, adotteranno strumenti di Data Observability.
La crescita di queste soluzioni è sostenuta dai benefici di questa pratica, per cominciare sul fronte della velocità nel Mean Time to Recovery (MTTR) che in alcuni casi può passare da ore a minuti, con un impatto diretto sulla continuità operativa e sulla reputazione.

Fiducia nei dati

La fiducia nei dati è un ulteriore vantaggio, anche se più difficile da quantificare. Non ultimo, il risparmio di costi. A prima vista, aggiungere un layer di Data Observability è una spesa aggiuntiva, ma prevenire è più economico che curare. Un incidente di dati costa molto di più – in termini di blocco dell’operatività, fiducia e rework – di quanto serve per implementare un monitoraggio proattivo.

Le sfide

Implementare la Data Observability non è semplice. Le sfide sono significative e quindi vanno tenute in attenta considerazione. La prima riguarda la complessità tecnologica all’interno delle aziende. La proliferazione e frammentazione di tecnologie, repository, etc. richiedono una scelta accurata del tool da adottare e un’integrazione molto attenta nell’infrastruttura esistente.
A questo si aggiunge il rischio di generare troppi alert, rendendo difficile distinguere problemi reali da falsi positivi e quindi congestionando e non aiutando il team data/IT, ma superabile partendo con ambiti limitati e affinando progressivamente le soglie.
Tuttavia ancora più insidiosa è la sfida culturale, che richiede un cambio di mentalità da un approccio reattivo a uno proattivo: non basta acquistare una soluzione di Data Observability, servono nuove competenze che combinino Data Engineering a una comprensione del business; e ciò richiede investimenti in formazione fino a nuove assunzioni. Aspetti che possono condizionare negativamente un’evoluzione invece sempre più strategica.