Managed Meta Data Environment (Parte Prima)

Praticamente tutte le grandi società e le agenzie governative hanno già realizzato, o stanno realizzando, oppure stanno pensando di realizzare un Managed Meta Data Environment (Mme), ovvero un ambiente di gestione dei meta-dati. Molte organizzazioni, tuttavia, continuano a compiere errori fondamentali. Un?impresa può realizzare molti repository, ovvero depositi di meta-dati, o “isole di meta-dati”, che non sono collegati tra loro, con un risultato che non produce molto valore aggiunto.

Risolviamo rapidamente un semplice quiz sui meta-dati: qual è la forma più comune di un’architettura di meta-dati? Verosimilmente, la maggior parte di voi risponderà “centralizzata” ma la vera risposta è ?una cattiva architettura?. La maggior parte delle architetture dei repository sono realizzate nel medesimo modo con il quale erano state costruite le architetture dei datawarehouse: ovvero un modo sbagliato. Il problema delle architetture dei datawarehouse si è manifestato in molte società comprese nella lista Global 2000, costrette a rifare le proprie applicazioni di datawarehouse, talvolta fino dalle fondamenta. Molti dei repository realizzati e ancora in uso debbono essere riprogettati e ricostruiti completamente.

Obiettivo di questo articolo è assicurarvi che la vostra architettura Mme sia costruita su fondamenta solide come una roccia, che forniscano alla vostra organizzazione vantaggi significativi rispetto ad altre architetture Mme poco efficaci. A tale scopo, presenterò un’architettura Mme completa, una visione generale, il dettaglio dei suoi sei componenti principali e i pilastri fondamentali dell’ambiente Mme.

Mme in breve

L’ambiente di gestione dei meta-dati è composto dai componenti architetturali, persone e processi necessari per accumulare, mantenere distribuire i meta-dati in maniera appropriata all’interno dell?intera impresa. L’ambiente Mme comprende, per i meta-dati, i concetti di repository, cataloghi, dizionari e ogni altro termine utilizzato con riferimento alla gestione sistematica dei meta-dati. Alcuni descrivono erroneamente un Mme come un datawarehouse per meta-dati. Nella realtà, un Mme è un sistema operativo e come tale possiede un’architettura molto diversa da quella di un datawarehouse.

Le società che stanno cercando di gestire realmente e in maniera efficiente i meta-dati secondo una prospettiva d’impresa, debbono disporre di un Mme completamente funzionale. È importante notare che un’impresa non deve cercare di mantenere tutti i propri meta-dati all’interno di un Mme, analogamente al principio che non tutti i dati posseduti debbano essere contenuti in un datawarehouse. Senza i componenti Mme, è molto difficile essere efficaci nella gestione dei meta-dati all’interno di una grande organizzazione. I sei componenti di un Mme sono:

• Livello delle fonti dei meta-dati
• Livello d’integrazione dei meta-dati
• Repository dei meta-dati
• Livello di gestione dei meta-dati
•  Depositi circoscritti (mart) di meta-dati
• Livello di consegna dei meta-dati

L’ambiente Mme può essere utilizzato nelle architetture centralizzate, decentralizzate oppure distribuite: l?architettura centralizzata offre un meta-modello unico, uniforme e consistente che rappresenta lo schema per definire e organizzare i diversi meta-dati memorizzati all’interno di un repository dei meta-dati globale. Questo consente un approccio consolidato per amministrare e condividere i meta-dati nell’ambito dell?impresa. L’architettura decentralizzata crea un meta-modello uniforme e consistente, che indica lo schema per definire e organizzare un sottoinsieme globale di meta-dati da memorizzare in un repository globale e negli elementi predeterminati di meta-dati condivisi che, a loro volta, appaiono nei repository di meta-dati locali. Tutti i meta-dati condivisi e riutilizzati nell’ambito dei diversi repository locali debbono prima transitare per il repository globale, ma la condivisione e l’accesso ai meta-dati locali risultano indipendenti dal repository globale. L’architettura distribuita comprende parecchi repository di meta-dati separati e autonomi, ognuno con un meta-modello diverso e adatto al proprio contenuto e organizzazione dei meta-dati, che prevede la responsabilità univoca per ogni repository della condivisione e amministrazione dei propri meta-dati. Il repository globale dei meta-dati non manterrà i meta-dati che appaiono nei repository locali, mentre avrà al suo interno, invece, i puntatori ai meta-dati nei repository locali, unitamente ai meta-dati che indicano come accedervi[1]. Presso la società EWSolutions, abbiamo realizzato un Mme che usa tutti questi tre approcci architetturali e alcune implementazioni utilizzano combinazioni di queste tecniche all’interno di un Mme.

Il livello delle fonti dei meta-dati

Il livello delle fonti dei meta-dati è il primo componente dell’architettura di un Mme. Il compito di tale livello e di estrarre i meta-dati dalle loro fonti e di inviarli al livello di integrazione dei meta-dati, oppure direttamente all’interno del repository dei meta-dati stessi.

L’accesso ad alcuni meta-dati da parte dell’Mme avverrà mediante l’uso di puntatori (distribuiti) che presenteranno i meta-dati all’utente finale nel momento in cui verrà richiesto. I puntatori sono gestiti dal livello delle fonti dei meta-dati e sono memorizzati all’interno del repository dei meta-dati.

In termini generali, è più conveniente inviare i meta-dati estratti alla medesima locazione hardware del repository dei meta-dati dal quale provengono. Spesso, i progettisti dell’architettura dei meta-dati inseriscono, non correttamente, i processi di integrazione dei meta-dati nella medesima piattaforma dalla quale provengono i meta-dati stessi (a differenza della scelta dei record, che è accettabile). Questa commistione del livello delle fonti con il livello di integrazione dei meta-dati è un errore comune che causa una quantità di problemi.

Nel momento in cui vengano modificate e aggiunte (come accade inevitabilmente) le fonti dei meta-dati, il processo d’integrazione di questi ultimi subisce un impatto negativo. Quando il livello delle fonti viene separato dal livello di integrazione dei meta-dati, solamente il primo viene impattato da questo tipo di cambiamento. Mantenendo tutti i meta-dati sulla medesima piattaforma, l’architetto dei meta-dati può adattare il processo d’integrazione molto più facilmente.

Mantenendo poi il livello di estrazione separato dal livello delle fonti, si fornisce un back up ordinato e un punto di ripartenza efficace. Gli errori di caricamento dei meta-dati avvengono tipicamente all’interno del livello di trasformazione dei meta-dati. In mancanza di un livello di estrazione, se avviene un errore l’architetto dovrebbe tornare indietro alla fonte dei meta-dati e leggerli nuovamente. Questo causerebbe numerosi problemi. Se la fonte dei meta-dati ha subito un aggiornamento, può perdere il sincronismo con alcune altre fonti di meta-dati con le quali risulti integrata. Inoltre, la fonte di meta-dati può essere correntemente in uso e questo processo può impattare sulle performance della fonte dei meta-dati. La regola aurea dell’estrazione di meta-dati è:

Mai avere processi multipli che estraggono il medesimo meta-dato dalla stessa fonte di meta-dati

In tali situazioni, la tempestività e, conseguentemente, l’accuratezza del meta-dato può risultare compromessa. Per esempio, supponete di aver costruito un processo di estrazione dei meta-dati (Processo #1) che legga i nomi degli attributi fisici da un tabella di strumenti di modellazione, per caricare un’entità voluta nella tabella dei meta-modelli che, a sua volta, contiene i nomi degli attributi fisici. Avete poi costruito anche un secondo processo (Processo #2) per leggere e caricare i valori del dominio degli attributi. È possibile che la tabella degli attributi all’interno dello strumento di modellazione sia stata modificata tra l’applicazione del Processo #1 e del Processo #2. Questa situazione provocherà una perdita di sincronismo dei meta-dati.

Questa situazione può causare anche un ritardo non necessario nel caricamento dei meta-dati, con fonti di meta-dati che hanno finestre limitate di disponibilità/elaborazioni batch. Per esempio, se stavate leggendo i log dei database a partire dal vostro sistema di pianificazione delle risorse dell’impresa (Erp), non potrete far girare processi di estrazione multipli su questi log poiché verosimilmente questi avranno un numero limitato di finestre batch disponibili. Dato che una situazione di questo tipo non si verifica spesso, non vi è ragione per creare perturbazioni non necessarie all’interno della vostra architettura di meta-dati.

Il numero e la varietà delle fonti di meta-dati varierà fortemente in base alle richieste al vostro Mme da parte degli utenti. Anche se esistono fonti di meta-dati utilizzate contemporaneamente da molte imprese, non ho mai visto due repository di meta-dati che abbiano esattamente le medesime fonti di meta-dati (avete mai visto due datawarehouse con le stesse fonti di informazione?) ma, in termini generali, le più comuni fonti di meta-dati sono le seguenti:

• Strumenti software

•  Utenti finali

•  Documenti e fogli elettronici

• Messaggi e transazioni

• Applicazioni

•  Siti Web e commercio elettronico

•  Terze parti

Strumenti software

Un gran numero di meta-dati di valore è contenuto all’interno di diversi strumenti software. Non dovete dimenticare che molti di questi strumenti dispongono di propri repository di meta-dati, progettati per consentire funzionalità specifiche e tipicamente non sono progettati per consentire l’accesso da parte degli utenti di meta-dati, oppure risultano integrati in altre fonti di meta-dati. In questo caso, avrete bisogno di attivare processi specifici per entrare in questi repository riservati ed estrarne i meta-dati.

Tra gli strumenti in questione, i database relazionali e gli strumenti di modellazione sono le fonti più comuni di meta-dati nell’ambito del livello delle fonti di meta-dati. L’Mme normalmente legge le tabelle del database di sistema per estrarre i meta-dati in termini di nomi di liste fisiche, nomi di attributi logici, nomi di tabelle fisiche, nomi di entità logiche, modalità di relazione, indicizzazione, cattura dei dati modificati e modalità di accesso ai dati stessi.

Utenti finali

Gli utenti finali costituiscono una delle fonti più importanti per i meta-dati da inserire in un Mme. Questi utenti sono di due tipi: business e tecnici.

Spesso, i meta-dati di business per una grande impresa sono conservati nella coscienza collettiva dei suoi dipendenti, ovvero nella loro “conoscenza tribale”. Come risultato, l’input dei meta-dati di business nel repository risulta vitale per gli utenti dell’impresa. La necessità di avere utenti attivi e coinvolti si lega all’argomento della gestione dei dati[2].

Anche gli utenti tecnici hanno bisogno di un accesso diretto al repository dei meta-dati per l’input dei propri meta-dati tecnici. Poiché gran parte dei meta-dati tecnici sono memorizzati all’interno di vari strumenti software, per gli utenti tecnici l’attività di input non è così rigorosa come quella degli utenti di business.

Le interfacce per entrambe queste categorie di utenti debbono essere abilitate al Web. Il Web fornisce un’interfaccia facile da usare e intuitiva, familiare a tutti i tipi di utenti. L’aspetto critico è dato dal collegamento diretto dell’interfaccia ai meta-dati contenuti nel repository. A tale proposito, suggerisco caldamente l’uso di accorgimenti come i box di inserimento e le liste di prelevamento, funzioni con le quali gli utenti hanno familiarità. Inoltre, dovete sempre tenere conto dell’integrità dei riferimenti e collegamenti forniti dal software del database.

Documenti e fogli elettronici

Una grande quantità di meta-dati è contenuta nei documenti dell’impresa (Microsoft Word) e nei fogli elettronici (Excel). Le caratteristiche del vostro Mme saranno grandemente condizionate dal grado di dettaglio di cui avete bisogno nel trasferire i dati dai documenti o nel creare dei puntatori di riferimento. Talvolta, questi documenti e fogli elettronici sono localizzati in un’area centrale di una rete, oppure nel computer di un dipendente. In molte organizzazioni, quindi, documenti e fogli elettronici tendono a essere altamente volatili e privi di regole di standardizzazione e di presentazione. Come risultato, normalmente costituiscono una delle fonti di meta-dati meno affidabili e più problematiche, nell’ambito di un Mme. Talvolta, i meta dati di business contenuti in queste fonti possono essere trovati nelle note o nei campi di commento associati a un documento o a una cella (nel caso di foglio elettronico). I meta dati tecnici, come calcoli, dipendenze o valori di controllo sono contenuti all’interno dei data store proprietari delle applicazioni (Microsoft Excel oppure Lotus 1-2-3).

Per le imprese che hanno implementato un sistema di gestione dei documenti, è importante estrarre i meta dati da queste fonti e trasferirli nel repository Mme. Normalmente, quando una società realizza un sistema di gestione dei documenti o della conoscenza, acquista anche un prodotto software per aiutare nella gestione dei meta-dati su documenti, immagini, file audio, file geospaziali (topografici) e fogli elettronici. È importante avere un livello delle fonti di meta dati che li possa leggere all’interno degli strumenti di gestione documentale, per poi estrarli e trasferirli all’interno del repository Mme. Questo compito è molto difficile perché la maggior parte dei fornitori di sistemi per la gestione dei documenti non comprendono che si tratta di veri repository di meta dati e che, come tali, debbono essere accessibili. Questi strumenti spesso utilizzano software proprietario per il database con lo scopo di proteggerlo dalla concorrenza, così come risulta molto poco visibile la struttura interna del loro database, con l’effetto che la struttura dei meta dati non è rappresentata nel meta-modello ma, invece, è rappresentata come codifica di programma. Come risultato, può risultare difficile costruire processi che estraggano i meta dati da queste fonti.

Messaggeria e transazioni

Molte imprese e agenzie governative utilizzano una qualche forma di messaggeria e di transazioni, sia con tecniche Eai (Enterprise application integration) sia con linguaggio Xml (talvolta le applicazioni Eai utilizzano Xml), per trasferire dati da un sistema a un altro. L’uso di Eai e Xml è molto diffuso, poiché le imprese si trovano a combattere con l’alto costo di mantenimento degli attuali approcci all’integrazione dei dati da punto a punto. Il problema dell’integrazione punto a punto è che l’ambiente dell’It diviene così complesso che è impossibile gestirlo in maniera efficace ed efficiente, specialmente se non si dispone di un Mme a livello dell’impresa. Un paradigma della messaggeria Eai dovrebbe aiutare le imprese a districarsi dagli attuali approcci all’integrazione dei dati punto a punto.

Mentre la maggior delle organizzazioni non sono molto avanti nell’uso e applicazione di Eai e Xml, questi tipi di processi possono essere utilizzati per reperire meta-dati di grande valore: regole di business, statistiche sulla qualità dei dati, allineamento dei dati, processi di razionalizzazione dei dati e così via. Poiché gli strumenti Eai sono progettati per gestire il bus della messaggeria, non i meta-dati che vi transitano, è importante portare questi ultimi nell’Mme, estraendoli dagli strumenti Eai, per consentirne l?accesso globale, la gestione storica, la pubblicazione e la distribuzione. Senza un buon Mme diviene molto difficoltoso mantenere questo tipo di applicazioni. Le grandi organizzazioni governative e le grandi imprese stanno utilizzando i rispettivi Mme per affrontare questa sfida.

Applicazioni

All’interno del largo spettro di applicazioni usate all’interno dell’impresa, alcune saranno state realizzate internamente dal dipartimento It (per esempio, datawarehouse, contabilità generale, paghe e stipendi, gestione della catena logistica e via dicendo), altre saranno basate su package (per esempio, PeopleSoft, SAP, Siebel) e altre, infine, possono essere gestite in outsourcing oppure utilizzano il modello di un provider di servizi Asp (Application service provider). Questa proliferazione di applicazioni può essere abbastanza voluminosa. Per esempio, conosciamo diverse grandi società e agenzie governative il cui numero di applicazioni si conta a migliaia.

Ciascuna di queste applicazioni contiene meta-dati di valore che debbono essere estratti e trasferiti nelle applicazioni Mme. Considerando che le applicazioni siano costruite su di una delle più diffuse piattaforme di database relazionale (ovvero IBM, Oracle, Microsoft, Sybase, Teradata), il livello delle fonti di meta-dati potrà leggere le tabelle di sistema e i log di questi database. Esistono anche un numero considerevole di meta-dati memorizzati all’interno delle varie applicazioni. Le regole dell’impresa e i valori di verifica sono contenuti all’interno della codifica applicativa o nelle tabelle di controllo. In tali situazioni, è necessario costruire un processo per acquisire i meta-dati.

Siti Web e e-commerce

Una delle fonti di meta-dati meno utilizzate sono i siti Web dell’impresa. Molte società dimenticano l’ammontare dei meta-dati di valore contenuti (e, secondo noi, da custodire meglio altrove) nel linguaggio ipertestuale (Html) nei siti Web. Per esempio, gli analisti del settore della sanità hanno bisogno di conoscere le informazioni più recenti circa i test sui pazienti di una nuova medicina. Questa ricerca è tipicamente effettuata da un medico che opera in un ospedale. Normalmente, il dottore registra i suoi dati sul sito Web o sul portale dell’ospedale, per cui è importante catturare i meta-dati esistenti in questi siti Web, così come sono importanti le modalità e i tempi di aggiornamento dei dati e così via.

Il medesimo ragionamento si applica anche al commercio elettronico. Quando un cliente ordina un prodotto tramite il Web, vengono generati una serie di meta-dati di valore che possono essere trasferiti e utilizzati in un Mme.

Terze parti

Per molte società, una forte interazione con le terze parti costituisce un processo di business standard. Alcuni tipi di imprese nei settori bancario, della difesa e delle agenzie collegate, della sanità, delle finanze e in alcuni tipi di produzione debbono necessariamente interagire con i rispettivi partner, fornitori, venditori, clienti, governo o agenzie di regolamentazione (come la Food & Drug Administration e il Census Bureau, negli Stati Uniti) su base giornaliera. Per ogni interazione sistematica, queste fonti esterne di dati generano meta dati[3] che debbono essere estratti e trasportati nell’Mme.

[1] Per una disamina più dettagliata di questo approccio, vedi il Capitolo 7 di “Building and Managing the Meta Data Repository” (David Marco, Wiley 2000)

[2] Per una discussione dettagliata sulla Gestione dei Dati, vedi la quarta parte delle serie di David Marco, apparsa in DM Review December, 2002 – March 2003

[3] Vedi il Capitolo 2 di “Building and Managing the Meta Data Repository” (David Marco, Wiley 2000), per una discussione più dettagliata sulle fonti esterne di meta-dati