Stefano Cazzella
Caccio's Blog Author

Last Tweet

Commenti

  • Azionifiat su Fiat Bravo Guerrilla Marketing
  • Amit su Business Intelligence Modeler (alpha version)
  • Stefano Cazzella su Dimensional Fact Model: dalla teoria alla pratica
  • Camillo su Dimensional Fact Model: dalla teoria alla pratica
  • Stefano Cazzella su Dimensional Fact Model

Tag Cloud

Archive for the ‘Metadata Management’ Category

Model Driven Business Intelligence

Pubblicato il 29/11/2013 da Stefano Cazzella in Business Intelligence,Metadata Management

Al ritorno da una due-giorni a Stoccarda, con ancora tanto entusiasmo e un po’ di stanchezza, pubblico le slide presentate mercoledì mattina all’Università dei Media (http://www.hdm-stuttgart.de) sul tema dell’approccio Model Driven alla Business Intelligence.

Le slide riassumono la “vision” che guida la realizzazione del tool di modellazione BI Modeler, ossia concepire i progetti di BI (al pari di quello che avviene per lo sviluppo software in contesti altamente industrializzati) come processi iterativi che portino alla realizzazione di due macro componenti: il progetto tecnico (Project Blueprint) e la sua realizzazione (Project Deliverables). Il progetto tecnico è costituito dall’insieme dei diversi modelli che descrivono i diversi aspetti e componenti del sistema di BI & Analytics di cui i deliverables sono un’istanza.

 

Meta Data Warehouse

Pubblicato il 30/10/2006 da Stefano Cazzella in Business Intelligence,Metadata Management

Dal 30 ottobre al 2 novembre si terrà a Londra la consueta Data Management and Information Quality Conference. La new entry dell’anno è una track dedicata ai temi di Data Warehousing e Business Intelligence. Scorrendo le presentazioni degli interventi di maggior rilievo in merito alla gestione dei metadati mi sono reso conto che il focus è tutto incentrato su come costruire, alimentare e gestire un un repository centralizzato dei metadati in cui vengano integrati i metadati prodotti durante il ciclo di sviluppo del sistema. Tale integrazione viene condotta tipicamente “a posteriori” ossia, nel migliore dei casi, al termine di ciascuna fase di un’iterazione progettuale.

Questo è il medesimo approccio che ho seguito nel disegnare la metodologia su cui si basa il sistema di gestione dei metadati realizzato nell’ambito del Data Warehouse della RGS. Tale sistema è costituito da prodotti commerciali e componenti software scritte ad-hoc al fine di ricostruire una “visione integrata, omogenea e strutturata” del sistema di data warehousing nel suo complesso. Tale esperienza è riassunta in un documento (in versione DRAFT) che ho preparato a valle del processo di certificazione del sistema di data warehousing condotto da Bill Inmon anche in seguito all’interesse e agli apprezzamenti che la componente di gestione dei metadati ha suscitato in tale sede.

Architettura a repository centralizzato Il mercato dei prodotti commerciali in ambito data warehouse è pressoché allineato nel seguire tale approccio generale che prevede la generazione dei metadati relativi alle diverse componenti in maniera pressoché indipendente e scorrelata. In particolare i diversi tool (case di modellazione dati, ETL, front-end, ecc.) utilizzati per la produzione delle diverse componenti del sistema (base dati, processi di alimentazione, reposrtistica, ecc.) hanno un proprio repository di metadati che descrive la componente prodotta; un sistema di gestione dei metadati interroga ciascun repository (attraverso delle API, tramite una sua rappresentazione in XML, ecc.) per estrarre una versione dei metadati da integrare nel proprio repository.

Un repository integrato dei metadati offre una serie di servizi ritenuti fondamentali sia per migliorare la qualità del servizio offerto agli utenti del sistema,sia per suportare la gestione del sistema stesso:

  • offrire all’utente indicazioni sul significato delle informazioni numeriche fornite attraverso la reposrtistica o gli ambienti di analisi multi-dimensionale (OLAP);
  • aiutare gli utenti a trovare le informazioni di cui hanno bisogno con sistemi di ricerca guidata;
  • suportare le attività di manutenzione attraverso le funzioni di cross-impact-analysis;
  • monitorare l’esito dei caricamenti e la crescita del sistema;
  • ecc.

Spesso però la qualità complessiva del sistema risulta scarsamente influenzata da una gestione dei metadati “a posteriori”; infatti l’integrazione “a posteriori” dei metadati può al limite evidenziare incongruenze fra il disegno delle diverse componenti, fra l’analisi e la progettazione delle stesse o fra la progettazione e lo sviluppo, ma non intervenendo attivamente nel processo produttivo, non migliora la qualità del prodotto.

Processo di integrazione “a priori”

Innovare il processo produttivo vuol dire innovare tanto le metodologie quanto gli strumenti di lavoro. Dal punto di vista metodologico il processo produttivo dovrebbe essere basato sul continuo riuso dei metadati: ogni attività dovrebbe arricchire i metadati del sistema integrando quanto già realizzato con nuove informazioni. Ad esempio la modellazione logica di un Data Mart dovrebbe partire dalla definizione del suo modello dimensionale arricchendolo con “i dettagli” utili alla sua implementazione in tecnologia ROLAP o MOLAP. Analogamente i metadati del medesimo modello dimensionale e della sua implementazione logico/fisica dovrebbero essere utilizzati nella definizione dello strato semantico attraverso cui gli utenti si interfacceranno e condurranno le proprie analisi OLAP.

Tale integrazione “a priori” dei metadati garantisce nel corso del processo produttivo una maggiore coerenza fra le componenti software realizzate. Inoltre, poiché il processo produttivo parte proprio dalla raccolta e formalizzazione dei requisiti e dall’analisi del patrimonio informativo e procede con l’integrazione dei metadati relativi agli aspetti progettuali e realizzativi del sistema, le probabilità che i requisiti utente siano sodisfatti aumentano. Si accorciano inoltre i ritardi nel rilevare problemi di incoerenza fra analisi e progettazione, progettazione e realizzazione o soddisfacibilità di requisiti.

Dal punto di vista degli stumenti software per la realizzazione di data warehouse, ad oggi non mi risulta che esista alcun tool in grado di seguire tutto il processo di analisi, progettazione e realizzazione di un sistema di Data Warehousing in modo integrato. Inoltre non sono molti i tool di front-end e back-end i cui repository di metadati siano aperti anche “in scrittura”, come avviene ad esempio per i cataloghi dei DBMS che vengono manipolati con linguaggi ormai standardizzati (DDL – Data Definition Language). Tuttavia il processo di integrazione dei diversi strumenti in suite tecnologiche può essere una spinta verso la realizzazione di un processo di questo tipo, purché l’integrazione non rimanga puramente commericale e ci sia una reale attenzione a coprire l’intero ciclo produttivo (mentre spesso fasi cruciali come l’analisi e la formalizzazione dei requisiti sono sottovalutate).

 

Glossari, metadati, wiki, …

Pubblicato il 25/02/2006 da Stefano Cazzella in Business Intelligence,Metadata Management,Web 2.0

Qualche giorno fa un mio amico e collega, sapendo del mio specifico interesse professionale per la gestione di metadati in progetti di Business Intelligence, mi ha segnalato l’intervento di Marianne Faro (European information manager della Nike) alla Gartner Business Intelligence Summit in cui veniva presentata la nuova strategia di Nike per la Business Inteligence. Nell’intervento vengono evidenziate, fra l’altro, le difficoltà che Nike ha incontrato nell’analisi integrata dei dati provenienti da diverse strutture aziendali distribuite geograficamente; in particolare

parte della difficoltà sta nel come parti differenti del business usavano i termini in modi diversi per i rispettivi report. Nike sta quindi creando un dizionario comune dei termini, per standardizzarli.

Il caso vuole che proprio in questi giorni stia lavorando alla creazione di un Glossario di Metadati per un sistema di supporto decisionale (DSS) di un importante istituzione pubblica il cui scopo è quello di fornire definizioni condivise per i principali termini di business in uso presso l’amministrazione. Il DSS in questione è basato su un Data Warehouse a due livelli con molteplici Data Mart costruiti iterativamente nell’arco di diversi anni. Il progetto ha coinvolto bacini d’utenza distinti con un lessico solo parizialmente comune: a volte i medesimi termini sono utilizzati con significati differenti cui possono corrispondono regole di business differenti.

La costruzione di un glossario comune pone ora il problema di condividere le definizioni fra i diversi utenti. Per supportare questo processo si sta valutando l’ipotesi di predisporre un wiki ad uso interno, inizializzato con le voci comuni e le definizioni più diffuse, lasciando ai diversi utenti il compito di dettagliarle e correggerle. Questa modalità “collaborativa” per il raffinamento dell’analisi attraverso un coinvolgimento diretto degli utneti consentirebbe (a patto di riuscire a coinvolgere realmente gli utenti nel processo di revisione e correzione) di giungere ad una definizione condivisa dei processi, dei concetti e delle relative regole di business.

Naturalmente le informazioni raccolte dovranno comunque essere formalizzate attraverso un proceso di analisi per essere “tradotte” in specifiche funzionali, tuttavia tale processo di formalizzazione risulterebbe assai agevolato dalla disponibilità di una descrizione organica e coerente della così detta “realtà di interesse”.

Relativamente al coinvolgimento diretto degli utenti nella definizione delle regole di alimentazione di un data warehouse, alcuni spunti di riflessione interessanti sono offerti dall'articolo di Mark Rittman in cui (in maniera un po’ avveniristica/semplicistica) si propone la definizione di un ambiente di front-end, destinato all’utnete finale, per la definizione delle procedure di aliemntazione.