Il data lineage è attualmente uno degli argomenti di maggiore interesse in materia di data governance.
Le tecnologie, le pratiche, gli approcci alla gestione delle relazioni source-target tra dati sono stati oggetto negli ultimi anni di un importante percorso di maturazione, soprattutto nel settore Finance che in Europa si è trovato per questioni regolamentari a dover considerare questi argomenti in modo sistematico. Le esperienze maturate in questo senso hanno in qualche modo cominciato a fare chiarezza su miti e realtà.
L’impostazione iniziale dei vendor di tecnologie è stata quella di un data lineage esclusivamente concentrato sul piano fisico, rilevabile automaticamente attraverso la retroingegnerizzazione, la ricostruzione delle relazioni di dipendenze e precedenze tra dati partendo dal software.
Questo approccio ha favorito nel mercato la percezione di una promessa da parte delle tecnologie di data management: quella di una ricostruzione del data lineage che non richieda l’impegno di risorse umane. Molte esperienze concrete maturate in questi anni ci hanno mostrato una serie di limiti in termini sia tecnologici, sia semantici.
Tecnici: non tutto il lineage è rilevabile analizzando i sistemi; inoltre spesso gli strumenti segnalano, oltre a percorsi rilevanti, anche molto rumore.
Semantici: il linguaggio con cui le relazioni sono espresse è quello utilizzato dai sistemi informativi, spesso incomprensibile ai referenti delle unità di business, che pure sono chiamati a partecipare attivamente al funzionamento di un sistema di data governance.
Questi vincoli di un approccio esclusivamente focalizzato sui sistemi informativi hanno orientato la maturazione delle pratiche di data governance verso modelli di data lineage più robusto e sostenibile.
Un primo importante passo è stato quello di riconoscere che si può parlare di lineage tra dati sui due piani di astrazione, quello di business e quello dei sistemi.
Un altro importante fattore evolutivo è consistito nel distinguere due distinte attività nella presa in carico del data lineage: la sua rilevazione e la sua rappresentazione.
Consideriamo ora in maggior dettaglio modalità e opzioni di rilevazione e rappresentazione del data lineage e indichiamo i fattori chiave di un approccio concreto e realmente orientato ad erogare servizi di data governance.
Rilevazione del data lineage
È un concetto comunemente accettato che un sistema di data governance debba considerare due distinti piani di astrazione:
- uno che identifica, classifica, qualifica e relaziona una serie di concetti di business o logici, i cui metadati sono comunemente gestiti in un business glossary;
- un altro che prende in carico metadati relativi alla rappresentazione e gestione fisica di questi concetti nei sistemi informatici, normalmente gestiti in un metadata repository.
Ciò premesso, riconosciamo tre distinte tipologie di data lineage:
Il lineage orizzontale di business si esprime esclusivamente sul piano di business, costituito in sintesi dalle modalità con cui i processi si scambiano le informazioni.
Analogamente il lineage orizzontale fisico si esprime sul piano tecnico dei sistemi informativi, in cui i dati, attraverso flussi informatici, fluiscono da una applicazione informatica ad un’altra.
Possiamo parlare infine di una terza tipologia di data lineage, denominato lineage verticale, che rappresenta un indispensabile ponte di connessione tra il piano di business e quello tecnico-informatico. Un campo di una tabella partecipa alla rappresentazione fisica di un dato definito nel piano di business, un processo è supportato da una applicazione informatica, e così via…
Questa tassonomia delle casistiche di lineage si sta via via consolidando rispetto alla proposta iniziale dei vendor di tecnologie informatiche che, come già accennato, consideravano rilevante il solo lineage fisico. Le motivazioni di questa evoluzione sono molte.
Una prima ragione è da ricercarsi nei limiti tuttora non superati della rilevazione automatica del lineage fisico. Le modalità più frequentemente adottate nel reperimento del lineage fisico sono tre:
- metadata driven – le comunicazioni di flussi informativi gestite da sistemi di ETL che operano attraverso specifici metadati possono essere rilevate attraverso l’analisi di questi metadati: il limite di questa modalità consiste nel fatto che questi sistemi sono tipicamente utilizzati per finalità particolari quali l’alimentazione di sistemi di datawarehouse o reporting; percorsi non coperti da questi strumenti non possono essere rilevati e quindi questi lineage non possono essere censiti; inoltre spesso le trasformazioni più complesse realizzate con questi strumenti non sono implementate attraverso la configurazione di metadati ma scrivendo codice, e in questo caso i metadati disponibili non sono sufficienti per documentarne il lineage;
- code driven – alcune soluzioni derivano i metadati necessari a rappresentare i percorsi di lineage ispezionando il codice; il limite di questa modalità sta nel fatto che spesso il codice, in funzione di una serie di condizioni, prevede percorsi differenti, che porterebbero a identificare numerosi mapping di lineage alternativi, alcuni dei quali potrebbero non essere quasi mai percorsi, generando un grande “rumore” rispetto all’identificazione del percorso più battuto;
- log/audit driven – altri strumenti di rilevazione ricostruiscono il lineage analizzando i log delle esecuzioni, ma ovviamente in questo caso il percorso di lineage rilevato sarà quello della specifica esecuzione; inoltre spesso i percorsi interessanti per le finalità di data governance attraversano più applicazioni, ciascuna delle quali potrebbe gestire la comunicazione con le altre con modalità differenti, che rendono complessa la ricostruzione dell’intero percorso di interesse.
Da queste considerazioni consegue che una completa e verosimile ricostruzione automatica del lineage fisico in un percorso articolato è un obiettivo difficilmente raggiungibile, non tanto per dei vincoli delle tecnologie di rilevazione, quanto per le modalità con cui le comunicazioni tra applicazioni sono state gestite, nella maggior parte dei casi in una logica che è tutt’altro che coerente con il principio di “data governance by design”. Lo sforzo richiesto per intervenire su quanto rilevato automaticamente, sfrondare l’inessenziale, tenere solo i passaggi di lineage rilevanti e qualificarli in termini di business è tale da rendere talvolta vano il ricorso a costosi tool di analisi.
Un’altra ragione dei limiti della rilevazione del lineage fisico sta proprio nelle finalità per cui il lineage è importante in particolare, ma non solo, nel settore Finance: queste finalità sono ad oggi ancora dettate da requisiti regolamentari; sulla base delle nostre esperienze l’attenzione degli organismi di vigilanza durante le attività ispettive si concentra non tanto sulla movimentazione dei file tra sistemi informatici, ma sulla movimentazione dei dati tra processi, dati che trovano poi evidenza nelle applicazioni che supportano questi processi. Questa che potrebbe sembrare una sfumatura attribuisce invece un grande valore alla determinazione e alla rappresentazione del lineage di business e di quello verticale, che sono la vera e soddisfacente risposta alle indagini del regolatore.
Ma il motivo non è solo questo e non si applica solo al mondo finance: basti pensare al compito dei data scientist che consiste, in termini generali, nell’intercettare e governare rischi ed opportunità per il business attraverso la i dati gestiti fisicamente nei sistemi informatici. Ancora una volta il lineage di business e quello verticale assumono un ruolo chiave nel sostenere il lavoro dei data scientist.
Rappresentazione del lineage
La rappresentazione delle tre tipologie di lineage sopra illustrate può seguire lo schema di riferimento illustrato in figura.
Lo schema è semplificato per una più rapida comprensione. Inoltre può essere integrato con altri metadati: ad esempio potremmo pensare ad una entità sul piano di business che rappresenta le regole di data quality da applicare ad un Business Term e un controllo automatico che implementa ed esegue quella regola lavorando sui flussi/campi che rappresentano i Business Term considerati dalla regola. Un sistema in grado di gestire un modello di questo tipo deve poter rappresentare le tre tipologie di lineage. Il livello di complessità che il tool di modellazione deve coprire aumenta quando nel tempo sorge la necessità di integrare il modello con nuovi metadati senza perdere le informazioni fin qui acquisite e gestendo le versioni e la storia del modello e dei dati in esso registrati in modo ingegnerizzato, ad esempio consentendo modifiche contemporanee e coordinate tra più utenti o team di lavoro sullo stesso modello.