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’ Tag

Dimensional Fact Model: dalla teoria alla pratica

Pubblicato il 28/01/2010 da Stefano Cazzella in Business Intelligence

Dopo aver introdotto il formalismo Dimensional Fact Model (DFM) come strumento di definizione dei requisiti per la realizzazione di applicazioni analitiche e aver proposto una serie di regole che guidino il disegno di un modello dati relazionale in grado di soddisfare tali requisiti, è giunto il momento di vedere come sia possibile mettere in pratica tutto ciò seguendo un modello di sviluppo di tipo Model Driven.

(continua…)

 

Parlando di data quality a colazione con Business Objects e il prof. Pasini (SDA Bocconi)

Pubblicato il 12/07/2007 da Stefano Cazzella in Business Intelligence

Ieri Business Objects ha organizzato un interessante evento/colazione sui temi del data quality in un lussuoso hotel al centro di Roma. La qualità dei dati è uno degli aspetti fondamentali nell’ambito dei sistemi di supporto decisionale: se le decisioni vengono prese in funzione delle informazioni disponibili, queste devono essere attendibili affinché le decisioni possano essere efficaci (o, in altre parole, la qualità delle decisioni dipendere anche dalla qualità dei dati su cui queste si basano).

(continua…)

 

Business Objects Complete Works

Pubblicato il 29/11/2006 da Stefano Cazzella in Business Intelligence,Web 2.0

The Complete Works

Ieri pomeriggio Business Objects, nell’ambito della campagna The Complete Works, ha presentato a Roma la propria collezione completa di prodotti ampliatasi notevolmente negli ultimi anni in seguito a diverse acquisizioni. La suite è stata riorganizzata in tre linee di prodotto:

  • TRUST – racchiude i prodotti EIM (Enterprise Information Management) dedicati al data cleansing (FirstLogic), al ETL (Acta), al EII (Medience) e alla gestione dei metadati (sviluppato da BO stessa)
  • SIMPLICITY – racchiude il risultato dell’integrazione fra i prodotti e l’esperienza di BO e Crystal per la Business Intelligence (Query&Reporting, OLAP, BSC, Dashboards, ecc)
  • ALIGNMENT – racchiude i prodotti EPM (Enterprise Performance Management) che integrano quanto sviluppato da SRC Software (anch’essa acquisita) per definire e condividere le strategie aziendali e monitorare l’esecuzione dei relativi piani operativi

La metafora scelta da BO per la campagna promozionale della propria suite è quella musicale: ogni strumento (linea/prodotto) ha un suo valore intrinseco ma i risultati migliori si ottengono quando suonano tutti assieme. Il tema musicale ha accompagnato l’evento: un trio jazz (vedi foto) ha inframmezzato le diverse presentazioni e ha poi accompagnato il classico buffet conclusivo.

L’evento era strutturato in tre interventi principali:

  • nel primo Keith Gile (Chief Strategy Officer Senior Analyst, Business Objects) ha tracciato uno scenario del settore della Business Intelligence del prossimo futuro sia in termini di mercato che di tecnologie (per ulteriori dettagli vi rimando ad un post dedicato in cui intendo approfondire gli argomenti trattati da Gile);
  • nel secondo è stato presentato da ANAS (Maurizio Biccellari – Resp. Area Contabilità e Controllo di Gestione SI di ANAS) uno studio di caso incentrato sull’utilizzo della tecnologia Xcelsius per la realizzazione di un cruscotto direzionale per monitorare lo stato di avanzamento delle diverse commesse stradali e autostradali gestite da ANAS;
  • nel terzo Maurizio D’Ascenzo (Product Marketing Manager, Business Objects) ha fatto una veloce carrellata sulle funzionalità offerte dai prodotti presenti nelle diverse linee.

Business Intelligence 2.0

Proprio dal terzo intervento sono venuti alcuni interessanti spunti sulla convergenza e l’adozione di tecnologie e filosofie del Web 2.0 nel settore della Business Intelligence. La rivoluzione che Business Objects sta perseguendo nell’innovazione della propria offerta interessa diversi ambiti:

  • User Revolution
    • Facilità d’uso degli strumenti di fruizione dell’Informazione; i modelli di riferimento dal punto di vista dell'interface design sono, guarda caso, Google ed Apple che hanno fatto della semplicità e dell’efficacia dell’interfaccia utente uno dei loro temi distintivi. Dal punto di vista tecnologico la scelta è caduta su Flash (vedi Xcelsius) piuttosto che su AJAX
    • Raggiungere anche quegli utenti che attualmente non usano strumenti BI ma che sono coinvolti a vario titolo nel processo decisionale di un impresa (middle management e impiegati); in questo caso la soluzione tecnologica individuata è in una maggiore integrazione con Excell e tutta la suite Office;
  • Platform Revolution
    • Offrire servizi di BI su web in modalità software-as-service in modo da sgravare le imprese (specie le PMI) dai costi di gestione di una piattaforma HW/SW; attualmente crystalreports.com offre un servizio su web per gli utenti di Crystal Reports XI che consente la distribuzione/condivisione di report realizzati con Crystal Reports
  • Network Revolution
    • Introduzione delle principali tecnologie di inter-networking come Web Services e RSS feed per integrare gli strumenti di BI nelle architetture SOA
  • Community Revolution
    • Integrare strumenti di collaborazione come forum di discussione contestuali ai report pubblicati che consentano, agli utenti abilitati a consultare un report, di discuterne i contenuti fra loro in modo che commenti e spiegazioni offerte da un utente vadano a beneficio di tutti; in questo modo spiegazioni e richieste di modifica, abitualmente scambiate via email, vengono tracciate ordinatamente e restano disponibili nel tempo a corredo del report stesso
 

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.