C’è una regola che nel mondo dell’It è sovrana: “trash in, trash out”, che significa che se vogliamo avere dei buoni elaborati, vale a dire rispondenti alle nostre attese e utili per il business, dobbiamo prima essere sicuri della bontà dei dati da elaborare. Questa regola è tanto più rigorosa quanto più l’elaborazione è complessa e il punto d’arrivo si allontana da quello di partenza, e ciò spiega perché con la crescente complessità dei sistemi informatici la qualità dei dati abbia l’importanza che ha. Vogliamo quindi affrontare il tema parlando di un qualcosa che della data quality non soltanto è un presupposto fondamentale, ma ne supera i confini e le finalità, ossia della data discovery.
Data discovery è una locuzione che, come spiega Bloor Research in un’analisi dedicata, indica “la scoperta delle relazioni tra gli elementi costituenti i dati, indipendentemente da dove questi siano residenti”. L’ampiezza della definizione sottintende tre cose importanti: 1) la fonte dei dati può essere di ogni tipo, database relazionali, gerarchici, file XML, spreadsheet e quant’altro; 2) i dati da relazionare possono essere di fonti multiple ed eterogenee, ma anche di una fonte unica; 3) le relazioni possono essere di ogni tipo: semplici, complesse, dirette, indirette e anche ‘fuzzy’ (cioè non definibili da un algoritmo), così come possono riguardare più di due elementi.
C’è un’altra cosa da chiarire: ed è perché la data discovery preveda, come vedremo, processi e strumenti dedicati.
Dato che oggi la stragrande maggioranza dei dati è gestita da Dbms relazionali, verrebbe naturale chiedersi perché il modello del Dbms non basti a definire le relazioni tra i dati. Ciò non è possibile per più ragioni, delle quali la principale è che non esiste il Dbms perfetto, in grado di gestire tutte le relazioni tra i dati: a volte alcune relazioni sono trascurate per semplice errore, più spesso perché conviene eliminarle a vantaggio delle prestazioni. Un caso tipico è quello delle colonne ridondanti, cioè colonne aventi gli stessi dati replicate in diverse tabelle. In teoria andrebbero eliminate; in pratica duplicare i dati anziché stabilire collegamenti tra le tabelle rende una query più veloce. E questo all’interno di una stessa base dati. Se i data base sono diversi le relazioni sono praticamente perse: pochissime organizzazioni hanno costruito modelli capaci di legare Dbms diversi e non a caso uno degli obiettivi della data discovery è proprio trovare questi legami. Infine, come si è detto, la data discovery si applica anche a fonti che non hanno modelli relazionali. Il caso tipico è dato dagli spreadsheet: i dati che contengono non sono messi in relazione secondo uno schema definito, ma secondo regole diverse per ogni singolo foglio di ogni singolo utente. È anche per questo, osserva Bloor, che sono ignorati come fonte di dati, mentre invece, osserviamo noi, sarebbero una fonte di altissimo valore.
La comprensione delle relazioni tra i dati, e quindi l’uso degli strumenti di data discovery (che secondo Bloor incominciano a formare una classe di offerta a sé stante, differenziata sia dai tool di data profiling sia da quelli per la data quality), si rivela preziosa in molte situazioni e aree d’impiego. Ne elenchiamo solo alcune, tra le più significative.
Migrazione e Archiviazione dati. Che si tratti di passare da un vecchio Dbms a uno più moderno, o da un Erp ad un altro, è fondamentale mantenere intatte le relazioni tra i dati. Se questi rapporti sono esplicitamente definiti dal Dbms, questo non dovrebbe essere un serio problema, ma molto spesso sono le regole di business, cioè le applicazioni (specie se si tratta di vecchie applicazioni basate su Dbms non relazionali) a definire le relazioni tra i dati, cioè a dire quale dato debba far riferimento a quale altro. In questi casi il processo di migrazione necessita di una chiara individuazione e comprensione dei rapporti esistenti tra gli elementi dei dati e, ovviamente, della capacità di garantire che tali rapporti siano mantenuti nel nuovo ambiente applicativo o di data management.
I princìpi che guidano la migrazione dati si applicano anche all’archiviazione, con in più il problema che può essere necessario che i dati archiviati siano acceduti tramite le originali applicazioni business, cosa desiderabile negli archivi near-on-line.
Master Data Management. Una soluzione di MDM nasce, come intuibile, dal presupposto che vi siano diversi sistemi che fanno uso di una stessa serie di dati, come ad esempio l’anagrafica clienti. Per migliorare la qualità dei dati (anche al fine di ogni elaborazione successiva) diventa necessario condurre un’analisi di sovrapposizione (overlap analysis) per trovare le fonti che contengono una stessa informazione e scegliere quella che, per completezza, accuratezza e affidabilità, andrà a popolare l’ambiente di Master Data management. È un lavoro che, secondo Bloor, può non essere necessario se le fonti non sono più di due, ma che quando le fonti si moltiplicano richiede processi automatizzati per trovare i punti di sovrapposizione e tool analitici statistici per valutare, in caso di conflitto, quale fonte sia più attendibile e sicura. Gli stessi problemi si presentano quando, a seguito di fusioni e acquisizioni, si tratta di unire le basi dati delle precedenti società per creare una fonte dati unica.
Data warehousing e Business Intelligence. Molte delle problematiche riguardanti il Master Data Management si applicano anche ai progetti di Data warehousing, specie se l’approccio è quello di un singolo Enterprise DW anziché di più Data mart dipartimentali. Gli strumenti di ETL disponibili normalmente includono funzioni per mappare le relazioni tra i dati e garantire che queste siano mantenute. Può però sorgere un ulteriore problema quando gli attributi relativi a dati la cui relazione è rilevante sono replicati in diversi Data mart (o Data warehouse) e devono quindi essere conformi. In questo caso bisogna prima stabilire quali attributi conformare, e quindi controllare che tale conformità sia mantenuta, dato che un’eventuale difformità impedisce di mantenere un rapporto di relazione.
Questo problema è, come ovvio, fondamentale per i sistemi di Business intelligence, il cui fine è appunto l’analisi delle relazioni tra i dati: se queste si sono perse, nessuna soluzione di intelligence o di performance management potrà funzionare.
Data modelling e sviluppo applicativo. Che siano usati per progettare un database partendo da zero o attraverso un processo di reverse engineering, gli strumenti di data modelling in realtà lavorano sui metadati piuttosto che sui dati. Ciò comporta dei limiti e il confronto con le analisi combinate su dati e metadati offerte dai tool di data discovery serve ai progettisti per avere una visione globale del problema. L’uso di questi strumenti non si limita però alla modellazione dei data base. Individuare le relazioni tra i dati è un aiuto concreto per chiunque sviluppi un’applicazione che si appoggia a una base dati preesistente e ne debba, o ne voglia, riutilizzare le strutture dati.
In conclusione, secondo Bloor i convenzionali strumenti di data profiling sono ottimi se si tratta di lavorare su una sola fonte di dati, ma l’utilità di strumenti specificamente indirizzati alle relazioni intercorrenti tra dati appartenenti a fonti diverse è chiaramente emergente. Questo porterà, come si è detto, a connotare la data discovery come un’offerta a sé stante piuttosto che come un ramo del profiling, tanto più che esistono prodotti dotati di funzioni di scoperta non rivolti alla profilazione ma alla data quality e al Master Data Management.
Nell’ambito delle iniziative per la qualità dei dati quelle di Master Data Management sono oggi oggetto di grande attenzione. Forrester ha condotto un’indagine dalla quale emergono però aspetti per molti versi contraddittori di tale interesse. Infatti, se da un lato ben il 49% delle realtà indagate (che comprendono imprese sia di grandi sia di minori dimensioni) risulti impegnata, nell’agosto 2009, nell’implementare o nel potenziare delle soluzioni di MDM, con una crescita del 9% rispetto all’anno precedente, queste si dimostrano ancora per certi versi immature e incontrano forti resistenze da parte dei responsabili della gestione dati. Tanto da consigliarne un’adozione prudente, secondo un processo per gradi e scaglionato nel tempo.
Queste considerazioni partono dall’elaborazione, di Forrester, di un “MDM Maturity Model” che considera cinque livelli di sviluppo.
Il più basso (livello 1) riguarda la semplice integrazione dei dati, con modesta attenzione alla loro qualità, e sfrutta strumenti di ETL e di EAI (enterprise application integration) realizzati ad hoc o reperiti sul mercato. Un approccio di base alla qualità dei dati compare al livello 2, rivolto ad applicazioni o funzioni particolari (Crm, Data warehouse, BI/Bpm), con strumenti di profilazione dati. Il concetto di dato “master”, al quale fanno riferimento tutti i dati relativi a un silos applicativo, viene definito solo al livello 3, così come i relativi strumenti software, mentre l’estensione di questo stesso concetto e dei relativi strumenti a un intero dominio informativo (tipo: tutti i dati per la produzione, le vendite e così via) porta al livello 4. L’ulteriore estensione dei master data a più domìni aziendali, che realizza una struttura di MDM a livello enterprise, costituisce infine il livello 5, un livello di maturità che, tra l’altro, presuppone un’architettura It orientata ai servizi (Soa) per poter essere implementato e soprattutto utilmente sfruttato per fornire dati e informazioni affidabili e contestualizzate a chiunque vi sia interessato.
Ora, lo stato dell’arte, allo scorso agosto, del MDM nelle imprese appare alquanto basso. Nel 36% dei casi è limitato a un silos applicativo (livello 3) e nel 37% è di fatto assente (livello 2), in aziende impegnate nella deduplicazione dei dati e nella riconciliazione di dati conflittuali all’interno di ambienti definiti. Solo il 17% ha realizzato soluzioni classificabili ai livelli 4 e 5 del modello descritto (vedi figura).
Questa situazione è dovuta, secondo Forrester, più a problemi di tipo organizzativo che tecnologico, e un segnale in tal senso è dato dal fatto che la maggioranza (il 54%) dei progetti di MDM è guidata dai Cio o dai responsabili It. Al contrario, data la rilevanza della qualità dei dati nell’efficienza operativa del’impresa, dovrebbero essere i responsabili del business (ovviamente in partnership con l’It) a promuoverne l’adozione. Invece, anche in quel 37% di casi fortunati in cui ciò si è verificato, i manager coinvolti sono risultati di livello BU o dipartimentale, il che porta ovviamente a limitarne l’impiego a particolari silos applicativi o domìni aziendali.
Insomma: se da un lato, nonostante le barriere tecnologiche ed economiche siano ben percepite, quasi nessuno vede nel master data management degli elementi negativi, dall’altra parte manca ancora, soprattutto ai “piani alti” una piena percezione del valore delle iniziative MDM ai fini della competitività di impresa.
