L’esigenza di governo nella gestione dei dati
Abstract
Questo è il terzo articolo di una serie di blog post finalizzata a trasmettere i punti salienti della visione delle architetture IT enterprise e del Data Management che, come Quantyca, proponiamo ai nostri clienti.
Per chi non li avesse letti, consiglio di leggere gli articoli precedenti della serie, dai titoli:
- “I principi di un moderno Data Management”: descrive le sfide dell’IT nella nuova era di digitalizzazione e i driver che spingono verso la ricerca di un cambio di paradigma nella progettazione delle architetture dati
- “L’approccio data-centrico che cambia l’IT”: descrive i principi e i vantaggi di un orientamento di progettazione delle architetture IT che considera i dati come asset centrale e riusabile e le applicazioni come elementi effimeri che producono o consumano dati di interesse per l’intera azienda
Negli articoli successivi tratteremo diversi aspetti che riteniamo interessanti per costruire piattaforme dati in grado di rispondere alle esigenze pressanti di un business che sta diventando sempre più data-driven.
Questo l’elenco dei prossimi articoli:
- “L’adattabilità della piattaforma di integrazione in un modello Data Fabric”: descrive un nuovo modello di piattaforma architetturale intelligente e automatizzata
- “Il Domain Driven Design applicato ai dati per una maggiore agilità nella progettazione”: riporta i punti fondamentali del modello di sviluppo software Domain Driven Design, che ha influenzato la proposta di nuovi modelli organizzativi anche per il Data Management
- “Il Data Mesh e la spinta verso una gestione dati distribuita”: descrive le ragioni che hanno contribuito alla proposta del paradigma Data Mesh, in favore di una gestione dei dati decentralizzata e domain-oriented per ottenere scalabilità organizzativa
- “Il Data Mesh e il principio di consumo self-service dei dati come prodotti”: descrive la visione dei dati come prodotti, che formano una rete di domain-oriented Data Product e sono fruiti tramite una piattaforma self-service e un modello di governance federato;
- “La Data Strategy come motore dell’IT”: chiude la serie con un riassunto dei principi architetturali che riteniamo basilari per una strategia di Data Management efficace e una visione del ruolo dell’Enterprise Architect nel delineare l’evoluzione delle architetture dati
La Data Governance come strumento di controllo e insight sull’architettura IT
Considerare i dati come asset e metterli in condivisione a livello di intera organizzazione implica la necessità di mantenere il controllo del ciclo di vita di questi ultimi: tanto più l’architettura è distribuita e l’organizzazione aziendale è complessa, tanto più è marcata l’esigenza di governo dei dati.
Infatti, mentre l’utilizzo dei Data On The Inside si esaurisce all’interno dell’applicazione che li gestisce, l’esposizione nel data layer dell’architettura aziendale dei Data On The Outside presuppone che attori diversi potenzialmente interagiscano con i dati esposti, siano essi altre applicazioni, team verticali di differenti linee di business, gruppi di analisti e data scientist, società partner o altri: il data layer è normalmente un elemento architetturale condiviso e multi-tenant.
Inoltre è altamente probabile che le esigenze di integrazione e le caratteristiche dell’architettura comportino la replicazione di uno stesso dataset in diverse copie, distribuite su diversi sistemi, infrastrutture, componenti tecnologiche; spesso le data pipeline che implementano i flussi dati prevedono il coinvolgimento di più job, ciascuno dei quali opera un particolare step di trasformazione sul dataset.
Uno scenario architetturale del genere richiede pertanto di raccogliere una base ricca ed organica di metadati che permettano di mantenere il governo su diversi aspetti della gestione dei data asset; alcuni esempi di tipologie di metadati che è consigliabile raccogliere sono descritti nelle sezioni seguenti.
Business Glossary, Data Catalog e Data Classification
L’attività di modellazione semantica dei data asset dà l’opportunità di definire un glossario, detto Business Glossary, in cui censire le entità di business di interesse aziendale e gli attributi elementari che le costituiscono: si tratta di concetti logici, inquadrati nel modello concettuale del business e agnostici rispetto ai dettagli tecnici e alla rappresentazione fisica che viene invece implementata sui sistemi.
Per fare un esempio, consideriamo questa volta il dominio del Retail, in cui il concetto di Transazione di vendita è uno degli elementi chiave del modello di business. Nel glossario semantico sarà definita un’entità per la transazione di vendita, che riporterà una descrizione espressa nel linguaggio dei termini comunemente usato dal team business, eventuali sinonimi utilizzati per riferirsi allo stesso concetto (aliases), eventuali etichette (tag) utili per arricchire la classificazione semantica dell’entità e altri metadati di interesse.
Inoltre, nel glossario si andranno a definire gli attributi specifici associati all’entità, indicando per ciascuno di essi il tipo logico (booleano, numerico, stringa…), eventuali vincoli che il valore assunto deve osservare (esempio: valore non negativo), l’espressione di calcolo qualora l’attributo fosse una metrica complessa, così come eventuali pattern che il valore deve rispettare (esempio: un numero fisso di caratteri). Per una Transazione di vendita, alcuni attributi comunemente definiti sono la data della transazione, il punto vendita di interesse, il cliente acquirente, l’eventuale tessera fedeltà usata, l’importo pagato, l’importo degli sconti applicati.
I data asset vengono poi rappresentati a livello fisico in più copie sotto forma di tabelle o strutture dati di altro tipo all’interno dei sistemi che compongono l’architettura IT aziendale: dal momento che i sistemi coinvolti sono molteplici e basati su tecnologie differenti, è consigliabile estrarre da essi i metadati relativi agli schemi, alle strutture dati, ai campi specifici, ai vincoli fisici e raccoglierli in un catalogo centralizzato, detto Data Catalog. Il catalogo può essere arricchito riportando anche le informazioni sugli utenti che hanno accesso ai sistemi o a determinate strutture dati.
Per garantire un pieno controllo dei dati gestiti e condivisi nell’architettura è utile effettuare una mappatura tra i concetti di business definiti nel glossario semantico e le corrispondenti rappresentazioni fisiche nelle strutture dati, registrate nel catalogo dati: una simile mappatura costituisce il processo di Data Classification e può essere effettuata in modalità semiautomatica tramite un motore di valutazione di regole di classificazione e una successiva integrazione manuale.
Considerando il numero potenziale di repliche di uno stesso data asset tra i vari sistemi o su più strutture dati all’interno di uno stesso sistema, la mappatura tra il mondo concettuale e il mondo fisico permette di mantenere una tracciabilità dei punti di utilizzo dei dati e di facilitare la scoperta, l’esplorazione e l’accesso in modalità self-service ai data asset di valore aziendale. Inoltre, saper identificare tempestivamente tutte le strutture dati in cui è rappresentato un certo tipo di informazione, come ad esempio i Personally Identifiable Information (PII) dei clienti, consente di rispondere agilmente a esigenze di compliance dettate dalle normative legate alla Data Privacy, come eventuali requisiti di anonimizzazione o cancellazione su finestre temporali più vecchie di un certo numero di mesi.
Data Lineage
I metadati raccolti nel glossario dei concetti semantici, nel catalogo delle strutture dati e la mappatura tra il mondo fisico e il mondo logico forniscono una conoscenza sulla situazione dei dati at rest. Tuttavia, per rendere effettivamente accessibili i data asset ai vari consumatori vengono implementati diversi tipi di processi che hanno a che fare con i dati in motion, sia che si tratti di data pipeline che operano ETL/ELT in modalità batch, sia che si tratti di flussi in real time di stream processing, di integrazione tramite API piuttosto che di accesso tramite layer di virtualizzazione.
Pertanto, la raccolta di metadati utili a fornire insight per il governo dei dati dovrebbe coprire anche l’aspetto del Data Lineage, per permettere di tracciare il percorso end-to-end di un dataset, dal data provider, passando per i vari step di integrazione e trasformazione nel data layer, fino ai diversi data consumer, censendo tutte le applicazioni che sono coinvolte nella pipeline del flusso.
Il percorso tracciato può essere poi analizzato nel verso che va dalle sorgenti alle destinazioni (forward lineage) o in verso opposto (backward lineage). Il tracciamento del lineage dei dati è fondamentale per effettuare con efficacia delle analisi di impatto del cambiamento, nel momento in cui è necessario introdurre delle modifiche agli schemi e alle interfacce dei Data On The Outside, che necessitano di identificare tutte le componenti applicative eventualmente impattate da monitorare ed eventualmente modificare.
Per favorire la raccolta di metadati utili ai fini del lineage, può essere conveniente introdurre nello schema dei dati elaborati dalla pipeline alcuni campi tecnici come, per esempio, il timestamp di elaborazione di ogni step di trasformazione, o arricchire il singolo record con un identificativo univoco che permetta poi di fare delle analisi di correlazione tra più copie dello stesso record in diversi sistemi.
Data Quality
Un altro aspetto da non sottovalutare riguarda la qualità dei Data On The Outside che vengono pubblicati nel data layer e distribuiti ai diversi consumatori. Un dato fornisce valore nel momento in cui è consistente, coerente con il contesto semantico di appartenenza, integro e aggiornato di frequente. Al contrario, data set di scarsa qualità possono essere origine di impatti negativi sul business, come ad esempio previsioni di vendita errate, performance di raccomandazione e personalizzazione dell’esperienza utente modeste o, nel caso di consumatori operazionali, azioni errate che possono portare a perdite di revenue o di reputazione per l’azienda. Si pensi alle conseguenze di un calcolo errato dello stock dei prodotti per un business di e-commerce: i clienti rischierebbero di vedere i propri ordini cancellati per mancanza effettiva della merce in magazzino e questa situazione sgradevole potrebbe portare a perdere clienti a favore dei competitor.
Pertanto, all’interno dei processi di Data Governance è auspicabile definire dei controlli di Data Quality da effettuare in modo periodico e automatico sui dataset, sulla base dei quali prevedere delle azioni di alert o di rimedio automatico in caso di situazioni problematiche.
Esempi di controlli di qualità che è utile implementare sono i seguenti:
- controlli di integrità referenziale tra fatti e dimensioni di un data warehouse;
- controlli di quadratura tra una metrica calcolata e i dati di riferimento generati dalla sorgente;
- controlli sulla frequenza di ricezione degli aggiornamenti dei dati dalla sorgente;
- controlli di completezza di un master / reference data set;
- controlli di compliance di un attributo rispetto agli invarianti di calcolo, ai vincoli e ai pattern definiti a livello semantico nel glossario di business ( correttezza valori numerici, controllo su valori ammessi di campi categorici…).
Eseguire periodicamente i controlli di qualità permette di conservare i risultati in un database, abilitando la possibilità di effettuare analisi storiche tramite dashboard e di identificare trend positivi o negativi sulla qualità dei data asset condivisi, correlandoli con eventuali attività evolutive operate sulle pipeline dati.
Altri metadati
Un’area molto specifica è quella della Data Compliance e riguarda alcuni aspetti come il censimento del registro dei trattamenti sui dati, la definizione dei data subject e la notarizzazione dei consensi degli interessati all’utilizzo dei dati personali, che per alcune tipologie di dati sono richieste dalle normative sulla Data Privacy.
Inoltre, per ogni dataset pubblicato nel data layer, è utile tracciare informazioni riguardo la ownership del data asset, in termini di team o sotto-dominio di appartenenza e di applicazione provider, nonchè documentare all’interno di un data sharing agreement, per ciascun sistema consumatore che chiede la sottoscrizione al data set, le finalità specifiche e i vincoli con cui i dati vengono condivisi.
Knowledge graph
Per massimizzare la conoscenza estraibile dai metadati raccolti, è possibile organizzarli e tracciare le relazioni tra di essi in una rappresentazione a grafo, detta knowledge graph, che permette una navigazione a 360° e una visualizzazione efficace di tutti gli aspetti di gestione dei data asset. Questo è uno dei driver più rilevanti a favore dell’adozione a livello aziendale di un tool centralizzato di Data Governance in cui salvare in modo integrato i metadati raccolti e supportarne facilmente la consultazione e l’aggiornamento.
Blindata è una società che produce un’applicazione SaaS di Data Governance e Data Compliance. Un esempio della tipologia di visualizzazione dei metadati che si può ottenere sfruttando il knowledge graph è illustrato nella figura seguente (in cui viene mostrata la prospettiva del Data Lineage).
I metadati abilitano il modello Data Fabric
La possibilità di centralizzare in un unico strumento una base ricca e organica di metadati è il primo passo verso la creazione di un modello di piattaforma di integrazione intelligente, che mira ad una forte spinta verso l’automazione, detto Data Fabric, che discuteremo in dettaglio nel prossimo articolo.
