La Data Observability è l’evoluzione necessaria per gestire la complessità delle moderne architetture dati aziendali.
Indice degli argomenti
Il costo nascosto della scarsa qualità dei dati
Non è raro che i responsabili aziendali si trovino ad analizzare dashboard i cui dati, già a una prima verifica, non corrispondono alla realtà e ciò a seguito di anomalie tecniche verificatesi giorni prima.
Situazioni che non solo hanno ricadute economiche – secondo una ricerca Gartner, la scarsa qualità dei dati costa alle organizzazioni una media di 12,9 milioni di dollari all’anno – ma intaccano anche la fiducia stessa nei dati e la credibilità dei team data e IT.
Il problema non è la mancanza di controlli. Anzi, molte aziende hanno investito anche molto in strumenti di Data Quality tradizionali. Il punto è che questi strumenti non sono più sufficienti alla luce della complessità delle architetture dati moderne.
Quando gli strumenti tradizionali non bastano più
Per decenni, la qualità dei dati è stata gestita con un approccio reattivo: test manuali, controlli schedulati, validazioni a valle della pipeline. Un modello che funzionava quando i dati risiedevano in database centralizzati e i processi ETL erano relativamente semplici e controllabili.
Ma il panorama è cambiato radicalmente. Le moderne architetture distribuite come i Data Lake o i Data Lake House, hanno introdotto una complessità esponenziale con evidenti ricadute. 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 – ovvero il tempo in cui i dati sono inaccurati, incompleti o non disponibili – cresce. E per le organizzazioni, per cui ormai l’accuratezza e la velocità nella presa di decisione sono strategiche, questo è un grande problema.
Le cinque dimensioni della data observability
Questo handicap rende necessario adottare la cosiddetta Data Observability, una pratica di monitoraggio, gestione e manutenzione continua dei dati che tocca – grazie a vere e proprie piattaforme di Data Observability o sistemi di Data Quality evoluti integrati nei Data Stack – in modo automatico e costante cinque aspetti principali:
- Freshness: viene controllato se i dati vengono aggiornati secondo la frequenza attesa. Ad esempio, se una tabella dovrebbe ricevere nuovi dati ogni ora ma l’ultimo aggiornamento risale a tre ore prima, questo segnala anomalie, per esempio nelle pipeline di ingestion;
- Volume: si monitora se la quantità di record processati rientra nei range normali attesi. Ad esempio, se una tabella riceve solitamente 10.000 righe al giorno ma improvvisamente ne arrivano solo 100 o 50.000, ciò può indicare problemi nei sistemi upstream o duplicazioni di dati;
- Structure: in questo caso il monitoraggio si concentra sulla coerenza strutturale dei dati rispetto alle aspettative. Ad esempio, se un campo viene eliminato, rinominato o il suo tipo di dato viene modificato, questo segnala una devianza che può derivare da problemi di compatibilità o errori nelle trasformazioni;
- Lineage: viene tracciato il percorso completo dei dati attraverso i vari sistemi e trasformazioni. Questa visibilità sulle correlazioni può indicare quali asset downstream saranno compromessi da un problema, facilitando l’analisi d’impatto e la risoluzione prioritaria degli incidenti;
- Distribution: in questo caso si verifica se i valori nei dati seguono i pattern statistici attesi. Ad esempio, se il 95% degli ordini ha valori tra 50-200€ ma compaiono improvvisamente molti ordini da 0€, questo segnala anomalie. Queste deviazioni possono indicare problemi nelle integrazioni tra sistemi o dati corrotti che necessitano investigazione.
Dal controllo reattivo al monitoraggio proattivo in tempo reale
Rispetto alla Data Quality tradizionale, nella Data Observability non si conferma quindi se i dati rispettano certe regole, ma si analizza e valuta la salute dell’intero ecosistema dati in tempo reale.
Un cambio di prospettiva di cui molte organizzazioni stanno comprendendo la necessità tanto che Gartner stima che già nel 2026 il 50% delle aziende che detengono architetture di dati distribuite, adotteranno strumenti di Data Observability.
Vantaggi misurabili: velocità, fiducia e risparmio economico
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.
La fiducia nei dati è un ulteriore vantaggio, anche se più difficile da quantificare. Non da 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.
Un esempio? Recentemente un incidente dati ha causato la cancellazione di oltre 2.000 voli nel Regno Unito e Irlanda, con perdite stimate in oltre 126 milioni di dollari per le compagnie aeree. Questo non è un caso isolato, è la punta dell’iceberg di un problema sistemico che le soluzioni di Data Observability sono progettate a prevenire.
Ostacoli tecnologici e culturali nell’implementazione
Ovviamente, 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.
