Di Andrew Tan
Dashboard che mentono
Molte aziende spendono oltre sei cifre per strumenti di data lineage. Le loro demo sono impressionanti: visualizzazioni estese che mostrano ogni tabella, pipeline e dipendenza all'interno di un data warehouse. I colori indicano la freschezza. Le frecce mostrano il flusso di dati. Sembra la sala di controllo di una centrale nucleare.
Tutto questo è fantastico e appariscente, ma una delle domande senza risposta è cosa succede quando la tabella X ha dati errati.
Puoi cliccare sui diagrammi, zoomare e spostarti, individuare la tabella, ispezionare i consumatori a valle e le trasformazioni in cui è stata alimentata. E poi puoi dire che dodici dashboard usano 'indirizzo cliente'.
La vera domanda, però, è quali processi aziendali si interrompono. La spedizione si ferma? Le fatture vanno nel posto sbagliato? I report di conformità falliscono? Hai capito l'idea.
Il dashboard invece sa che i dati sono fluiti da A a B, ma non aveva idea di cosa B fosse effettivamente per.
Teatro del lineage
Questo è ciò che chiamo teatro del lineage: la pratica di costruire diagrammi di flusso di dati impressionanti che soddisfano liste di controllo di conformità e demo dei fornitori ma non aiutano realmente quando le cose si rompono.
I fornitori di strumenti hanno ottimizzato per la cosa sbagliata. Stanno vendendo visualizzazioni. Ciò di cui i team di dati hanno bisogno è contesto: la capacità di tracciare un problema di qualità dei dati al suo impatto aziendale in meno di 60 secondi.
Puoi vedere questo schema in molte aziende. Implementano strumenti di lineage con grande clamore. I diagrammi vengono messi in mostra sui televisori degli uffici (cool), e il team di governance dei dati scrive documentazione sulla documentazione. Poi, sei mesi dopo, un sistema a monte cambia un nome di colonna e il diagramma di lineage si illumina come un albero di Natale mentre l'effettivo impatto aziendale rimane un mistero.
Il team finisce per fare ciò che avrebbe fatto senza lo strumento: sfogliare Slack, controllare con gli stakeholder, tracciare manualmente quali report contano per quali decisioni.
Il divario del contesto aziendale
Ecco il problema fondamentale: il lineage tecnico e il lineage aziendale sono cose diverse, e la maggior parte degli strumenti fa solo il primo.
Il lineage tecnico risponde: Da dove provengono questi dati e dove vanno?
Il lineage aziendale risponde: Quali decisioni dipendono da questi dati e cosa succede se sono errati?
Il divario tra loro è dove accadono i disastri dei dati. Una pipeline può essere corretta al 100% da un punto di vista tecnico: tutti i lavori verdi, tutti i test superati: mentre produce un output catastroficamente errato per l'azienda.
Supponiamo che tu sia un'azienda fintech e il tuo modello di approvazione dei prestiti sia tecnicamente perfetto. Il lineage mostra dati puliti dall'applicazione attraverso l'ingegneria delle caratteristiche fino alla valutazione del modello. Ciò che il lineage non cattura è che un recente cambio di schema ha scambiato due campi con nomi simili, "reddito_annuale" e "reddito_mensile", in un modo che le regole di validazione della pipeline non hanno rilevato.
Il modello ora tratta il reddito mensile come reddito annuale. Le soglie di approvazione che avrebbero dovuto richiedere $60,000/anno si attivano su $5,000/mese. Il diagramma di lineage mostra frecce verdi. Il risultato aziendale è un mese di prestiti errati che richiedono sei mesi per essere risolti.
Come appare effettivamente un lineage utile
I team che gestiscono bene il lineage hanno una cosa in comune: lo trattano come un esercizio di mappatura aziendale, non come un compito di documentazione tecnica.
Devi adottare un approccio diverso: ogni data Asset nel tuo warehouse ha tre tag:
- Criticità: Viene utilizzato per report normativi, decisioni operative o solo analisi?
- Processi a valle: Quali funzioni aziendali dipendono da questo? (Non quali tabelle, ma quali funzioni: fatturazione, decisioni cliniche, conformità)
- Impatto dell'errore: Cosa succede se questi dati sono errati? (Ritardo, perdita finanziaria, problema normativo, sicurezza del paziente)
Lo strumento di lineage risultante è tecnicamente semplice: solo un tracker di dipendenze di base. Ma combinato con quei tre tag, dice esattamente ciò che devi sapere quando qualcosa si rompe.
Quando la tua tabella di elaborazione dei reclami ha un problema di qualità dei dati, non hai bisogno di tracciare attraverso quindici tabelle a valle. Guardi i tag, vedi "Criticità: Normativa, A valle: Deposito mensile CMS, Impatto dell'errore: $2M di penalità se in ritardo," e sai immediatamente di dover avvisare il CFO e avviare il processo di backup del deposito manuale.
L'intera risposta all'incidente richiede minuti. Nessuna navigazione nel diagramma richiesta.
Perché costruiamo la cosa sbagliata
Allora perché i team continuano a comprare strumenti di lineage ricchi di visualizzazioni che non risolvono il vero problema?
Parte di esso è teatro di approvvigionamento. La persona che acquista lo strumento spesso non è la persona che risolve l'incidente delle 2 del mattino. Stanno comprando qualcosa che sembra completo per l'audit di conformità o la presentazione al consiglio. I diagrammi belli spuntano le caselle. La mappatura del contesto aziendale richiede un lavoro organizzativo che non si fotografa bene.
Parte di esso è la natura di come questi strumenti vengono venduti. I fornitori fanno demo con ambienti di dati sintetici e puliti dove il lineage è ovvio. I veri ambienti di dati aziendali sono super disordinati: decenni di sistemi legacy, trasformazioni non documentate, conoscenze tribali mai scritte. Mappare il contesto aziendale richiede di parlare con le persone, non solo di scansionare il codice. Non si scala in modo pulito come la scoperta tecnica automatizzata.
E parte di esso è che il lineage tecnico è più facile da costruire. Puoi scansionare i log delle query, analizzare SQL, ispezionare DAG. Il contesto aziendale richiede interviste, documentazione, manutenzione continua mentre i processi cambiano. È un lavoro organizzativo mascherato da lavoro tecnico.
Come correggere il tuo lineage
Se sei già investito in uno strumento di lineage (e la maggior parte delle aziende lo è a questo punto), non hai bisogno di eliminarlo. Devi aggiungere contesto aziendale ad esso.
Inizia con la tua storia degli incidenti. Guarda gli ultimi cinque incidenti di qualità dei dati che hanno causato un reale impatto aziendale. Per ciascuno, identifica:
- Quali dati erano errati
- Quale processo aziendale si è rotto
- Chi doveva saperlo
- Quanto tempo ci è voluto per capirlo
Ora guarda il tuo strumento di lineage. Aiuta con qualcuna di queste domande? Se no, hai la tua roadmap di miglioramento.
Tagga manualmente gli Assets critici. Non cercare di taggare tutto. Inizia con i tuoi primi 20 data Assets per impatto aziendale. Per ciascuno, documenta: quali decisioni alimenta, chi possiede quelle decisioni e cosa succede se i dati sono errati.
Questo richiede tempo: forse 30 minuti per Asset; forse di più. Ma trasforma il tuo lineage da un bel diagramma in uno strumento operativo.
Costruisci avvisi consapevoli del business. La maggior parte degli avvisi di qualità dei dati sono tecnici. "Questo lavoro è fallito" o "questa colonna ha valori nulli." Aggiungi avvisi consapevoli del business: "Il riepilogo delle entrate giornaliere ha valori sospetti, che alimentano il dashboard del CEO alle 8 del mattino."
L'avviso dovrebbe includere non solo cosa è sbagliato, ma cosa dipende da esso e chi deve saperlo.
Pratica la risposta agli incidenti. Esegui un esercizio da tavolo. Simula un problema di qualità dei dati in un sistema critico a monte. Cronometra quanto tempo ci vuole per rispondere: quali decisioni aziendali sono influenzate, chi deve essere notificato e quali sono le opzioni di mitigazione.
Se ci vuole più di cinque minuti, il tuo lineage ha bisogno di più contesto aziendale.
Il prodotto che vorrei esistesse
Ho esaminato alcuni degli strumenti di lineage sul mercato. Sono tutte variazioni sullo stesso tema: scansiona la tua infrastruttura, costruisci un grafo, mostrati belle visualizzazioni.
Quello che voglio è diverso. Voglio uno strumento che inizi con i processi aziendali e lavori a ritroso. Mappa prima le decisioni, poi traccia i dati che le alimentano. Quando qualcosa si rompe, dimmi quali decisioni sono a rischio, non solo quali tabelle sono interessate.
Ma non hai bisogno di una nuova piattaforma per ottenere un lineage migliore. Devi smettere di trattare il lineage come un problema tecnico e iniziare a trattarlo come un problema organizzativo. Il diagramma non è il prodotto. Il contesto aziendale lo è.
Il test per il tuo strumento di lineage
Ecco un semplice test. Scegli un data Asset critico nel tuo sistema: qualcosa che sarebbe doloroso se fosse errato. Ora rispondi a queste domande senza guardare il codice:
- Quali decisioni aziendali dipendono da questi dati?
- Chi prende quelle decisioni e quando?
- Qual è il costo di essere errati?
- Chi deve essere informato se c'è un problema di qualità?
Se non puoi rispondere a queste domande in 60 secondi, il tuo strumento di lineage non sta facendo il suo lavoro: non importa quanto bello sia il diagramma.
L'obiettivo non è l'osservabilità perfetta. È un contesto utilizzabile. E questo è più difficile da costruire, ma infinitamente più prezioso.
Andrew Tan è un imprenditore seriale e fondatore di layline.io, costruendo infrastrutture di elaborazione dati aziendali che gestiscono carichi di lavoro sia batch che in tempo reale su larga scala.