I termini Business Glossary, Data Catalog e Data Dictionary sono spesso utilizzati parlando di Data Governance, ma qual è la loro differenza?

A cura di Laura Bacci, Principal Consultant di Kirey Group

I termini Business Glossary, Data Catalog e Data Dictionary sono spesso utilizzati parlando di Data Governance, ma non sempre le loro definizioni sono standardizzate in modo che siano chiare ed evidenti le loro differenze, evitando sovrapposizioni e conflitti di competenze.

Tab 1 – I tre strumenti della Data Governance

Tutti e tre, come elencati in Tab. 1, sono strumenti che raccolgono metadati utili a contestualizzare i dati, seppure con caratteristiche diverse: alcuni infatti sono metadati orientati al business (Business Glossary) altri sono metadati di natura tecnica (Data Catalog e Data Dictionary).
Parte della confusione è facilmente comprensibile, considerando come la governance dei dati si evolve in genere all'interno di un'organizzazione. Ad esempio, è abbastanza tipico iniziare con la creazione di un Data Catalog e successivamente costruire un programma di governance a partire da quello; oppure, per un'iniziativa di qualità dei dati, partire definendo per primo il Data Dictionary.
Questo tipo di approccio è potenzialmente efficace per dare risultati immediati, ma deve essere successivamente “aggiustato”, corretto, in modo da catturare pienamente il valore addizionale che si ottiene, per un programma di governance dei dati, dall’implemen­tazione comune di tutti e tre gli strumenti.

Business Glossary, che cos'è?

Un Glossario deve essere focalizzato sui termini utilizzati all’interno dell’organizzazione per riferirsi al business condotto dall’organizzazione stessa, deve essere facilmente comprensibile a tutti i livelli e deve definire ciò che ogni termine significa in ottica di business. Cosa si intende per Cliente? Per Codice Fiscale? Per Riserva? Per Premio? Per Conto Corrente?

Il Glossario nasce proprio per rispondere a questo tipo di quesiti. Come risulta evidente un Glossario è tipico di una specifica azienda anche se, per favorire l’in­teroperabilità, dovrebbe essere costruito in modo da avere buona parte dei termini comuni alle aziende che operano nello stesso settore.

Vantaggi di un Business Glossary completo

Disporre di tale glossario porta il chiaro vantaggio di poter condividere, internamente all’organizzazione, un vocabolario di termini comuni, con tutte le ricadute positive che ciò comporta sulle attività operative, sia funzionali che tecniche, nonché sui progetti eseguiti.

Responsabilità e proprietà

Il campo di applicazione di un Glossario dovrebbe collocarsi a livello dell’azienda nel suo insieme. Solamente nei casi in cui le diverse divisioni che compongono l’azienda si occupino di affari significativamente diversi, e dunque debbano adottare una terminologia a sua volta significativamente diversa, il Glossario potrebbe collocarsi a livello divisionale. A causa della sua portata e delle competenze richieste per la sua redazione, la responsabilità del Glossario non dovrebbe essere delegata alla componente di Information Technology dell’azienda. Il Glossario è proprietà dell'Azienda o, per meglio dire, della componente funzionale dell’Azienda, piuttosto che della sua componente tecnologica informatica.

Il Data Dictionary

Un Dizionario, d’altra parte, deve essere incentrato sulle descrizioni e i dettagli relativi alla struttura fisica dei dati. Ogni flusso dati (file o tabella di database) utilizzato all’interno dell’organizzazione dovrebbe essere registrato all’interno del Dizionario. Quest’ultimo deve includere dettagli sui dati quali il tipo, la lunghezza ammissibile, il nome tecnico, le trasformazioni (il lineage^[1] ) e ogni altro dettaglio tecnico rilevante. Questi dettagli altro non sono che i metadati, principalmente tecnici, di cui parlavamo all’inizio, e consentono agli architetti di dati, e agli ingegneri dei dati di comprendere come associare e interrogare i dati per la progettazione dei sistemi informativi e la produzione della reportistica utilizzata dalla componente funzionale dell’azienda.

Seppure i Dizionari siano spesso disponibili a livello delle singole risorse (file o database) che provvedono a censire, risulta evidente che sarebbe oltremodo utile concentrare tali informazioni in un Repository centralizzato a livello aziendale o almeno dipartimentale. Data la necessità di competenze tecniche e di metadati, la responsabilità della proprietà di un Data Dictionary spesso risiede nel dipartimento IT.

Data Catalog

Il Catalogo infine funge da registro per individuare la localizzazione dei dati: anch’esso deve essere visto come un asset a livello aziendale, asset che costituisce la fonte di riferimento unica per la localizzazione di qualsiasi set di dati, asset necessario per tutte le possibili esigenze interne all’organizzazione, sia tecnico-operative, a livello di Information Technology, che di interrogazione funzionale per attività di Data Science o di Business Analytics. Proprio come per il Glossario, se una divisione dell’impresa svolge un business significativamente differente dalle altre, potrebbe essere ragionevole che il Catalogo sia sviluppato a livello di divisione piuttosto che dell’intera azienda.

Poiché la compilazione del Catalogo richiede la conoscenza della localizzazione di tutte le risorse dati presenti in azienda e poiché la maggior parte di tali dati sono a gestione IT, di solito la responsabilità del Catalogo è demandata all’Information Technology. Ciò non toglie che nel Catalogo debbano essere elencati anche quei dati prodotti e gestiti dalle componenti funzionali dell’azienda e che, di conseguenza, la compilazione debba essere frutto di un’attività congiunta che vede il coinvolgimento di entrambe le componenti tecniche e funzionali dell’organizzazione.

Alcuni esempi

Per fare Data Governance nel migliore dei modi possibili tutti e tre gli strumenti descritti sopra dovrebbero essere implementati, poiché costituiscono la base su cui si fonda la Data Governance: come posso pensare di governare i dati se non so quali sono, dove sono e che cosa significano per il mio business?

Tab 2 –Esempi di contenuto per i tre strumenti di Data Governance

Inoltre, i tre strumenti dovrebbero “parlarsi” tra di loro: se nel Catalogo ho censito la localizzazione di tutte le risorse informative e nel Dizionario ho censito tutti i metadati relativi sempre alle stesse risorse informative, per ricavare pieno vantaggio da entrambi dovrò ben collegare le due informazioni! Ma non solo, dovrò anche collegare le definizioni dei termini di business inseriti nel Glossario alle risorse registrate nel Catalogo in modo da chiudere completamente il cerchio e sapere esattamente per ogni termine di business dove si trovano le risorse informative che lo realizzano e quali metadati sono caratteristici di tali dati.

Un approccio efficace ed efficiente

Il massimo dell’efficacia e dell’efficienza si avrebbe facendo convergere tutte le informazioni del Glossario, del Dizionario e del Catalogo in un unico repository centralizzato dei metadati di Data Governance dove si aggiungono anche tutti i metadati relativi alle entità caratteristiche dei processi di Data Quality, descritti in seguito, come regole di controllo, esiti e segnalazioni. In questo modo la gestione dei metadati diventa il nodo centrale da cui si sviluppa la governance dei dati. Questa, per lo meno, è la teoria.

Nella pratica del mondo reale però l’approccio è spesso parziale, non completamente organizzato, ottimizzato per una parte e magari carente per un’altra, in funzione della capacità visionaria o meno di una parte del management oppure più semplicemente per problemi di costi. Per questo motivo è irrealistico immaginarsi un approccio alla Data Governance che preveda, partendo da zero, di avviare un progetto globale per censire l’intero patrimonio informativo aziendale sotto tutte le sue sfaccettature.

Il miglior approccio è di tipo Agile (mutuando il termine dal Project Management^[2]): lasciare che si sviluppino inizialmente iniziative locali, dipartimentali, dove si utilizzano anche strumenti diversi, per convergere alla fine verso una visione centralizzata, avendo, nel frattempo, selezionato gli strumenti informatici che meglio rispondono ai requisiti e che più successo hanno avuto nei progetti locali. L’approccio deve essere incrementale, inserendo nella Governance prima quegli ambiti informativi che per varie motivazioni, di mercato, di impatto su più aree aziendali, di rilevanza normativa, ecc., sono ritenuti prioritari, per aggiungere poi progressivamente tutti gli altri ritenuti rilevanti ai fini della governance complessiva.

Note

[1] Si definisce con lineage la relazione source-target esistente tra i dati che subiscono delle trasformazioni.

[2] Le metodologie “agili” sono nate originalmente nell’ambito dei progetti di sviluppo del software e si riferiscono a quelle pratiche di sviluppo leggere e flessibili, che prevedono team di sviluppo piccoli, lo sviluppo iterativo e incrementale, la pianificazione adattiva, e il coinvolgimento diretto e continuo del cliente nel processo di sviluppo.