Il Dimensional Fact Model viene spesso presentato come un modello concettuale per la definizione di sistemi di data warehousing: durante la fase di analisi può essere efficacemente utilizzato per formalizzare i requisiti informativi che il sistema dovrà soddisfare, mentre nella fase di progettazione costituisce il principale input per il disegno del modello logico su cui si basa l’applicazione di Business Intelligence.

Lo stesso modello concettuale può essere implementato con diverse tecnologie: ROLAP, MOLAP, HOLAP, ecc. Anche nell’ambito di una medesima tecnologia non esiste una modalità unica di traduzione di un modello dimensionale in modello logico e spesso le scelte di disegno sono guidate da altri requisiti funzionali e non funzionali.

Di seguito vediamo un esempio di come sia possibile implementare, in ambiente relazionale, il modello dimensionale di analisi delle vendite già descritto.

Il modello logico di riferimento scelto è il classico star-schema: ogni schema di fatto viene implementato da una tabella dei fatti (fact table) in cui vengono rappresentate tutte le misure; alla fact table sono collegate tante tabelle dimensionali denormalizzate (dimension table) quante sono le gerarchie presenti nello schema di fatto.

Ogni dimension table rappresenta tutti i livelli di aggregazione della gerarchia; ogni livello è costituito dall’attributo dimensionale che lo identifica e da tutti gli attributi non dimensionali ad esso collegati. Generalmente ad ogni attributo corrisponde un campo della tabella.

Alle tabelle vengono inoltre aggiunti i campi tecnici quali chiavi surrogate, campi di audit (data di creazione, date di validità del record, ecc.) che non hanno una diretta corrispondenza con gli attributi e le misure del modello.

E’ buona regola definire i vincoli di chiave primaria su tutte le tabelle. Per le tabelle dimensionali la chiave naturale della tabella è costituita dal campo relativo alla dimensione della gerarchia e questa può essere utilizzata come primary key della tabella. Nel caso in cui sia stata inserita nella tabella una chiave surrogata, sarà questa a costituire la primary key; a seconda delle esigenze può essere comunque utile definire anche un vincolo di unicità sulla chiave naturale. Per le fact table generalmente la primary key è costituita dall’insieme dei campi (foreign key) che referenziano le dimensioni dello schema di fatto.

Per quanto riguarda i vincoli di integrità referenziale fra la fact table e le dimension table, pur essendo questi parte integrante del modello logico, la loro implementazione fisica può essere subordinata a considerazioni di natura prestazionale, fermo restando che l’integrità referenziale deve essere comunque garantita dal database e/o dalle procedure di alimentazione.

La gerarchia Territorio viene implementata da un’unica tabella relazionale denormalizzata: ogni attributo (dimensionale e non) da origine ad un campo della tabella; inoltre è stato aggiunto il campo ID che svolge il ruolo di chiave surrogata. La chiave primaria (PK) della tabella è quindi costituita dal campo ID, mentre sul campo NEGOZIO, che implementa la dimensione della gerarchia e rappresenta quindi una chiave naturale (AK), viene imposto un ulteriore vincolo di unicità (UNIQUE).

Una possibile valorizzazione della tabella DIM_TERRITORIO è esemplificata nella tabella seguente.

Dall’esempio risultano evidenti le dipendenze fra i campi PROVINCIA, REGIONE e STATO che danno origine alle ridondanze tipiche delle strutture dati denormalizzate. Tali dipendenze presenti nel modello DFM non sono invece rappresentate nel modello relazionale.

La tabella che implementa la gerarchia Tempo è composta da 4 campi: uno per ogni attributo; in questo caso il campo GIORNO (di tipo data), in qualità di chiave naturale, costituisce la chiave primaria della tabella.

Anche in questo caso sarebbe possibile affiancare alla chiave naturale della tabella una chiave surrogata come è stato fatto per la tabella DIM_TERRITORIO.

Vediamo ora un esempio di Slowly Changin Dimenson di tipo 2. Supponiamo che lo stesso prodotto possa essere fornito in momenti diversi da fornitori diversi. In questo caso la relazione uno-a-molti definita al livello concettuale fra gli attributi dimensionali Fornitore e Prodotto è verificata solo per determinati intervalli temporali (eventualmente collassati al livello di singolo giorno).

Il DFM non prevede uno specifico formalismo grafico per identificare le dipendenze funzionali dinamiche (cioè che evolvono nel tempo), tuttavia questo è un requisito che è fondamentale tracciare (es. con note o vincoli fuori schema) in quanto condiziona sia il modello logico/fisico implementante che le sue modalità di alimentazione.

Poiché nulla è immutabile nel tempo, in fase di definizione dei requisiti è importante selezionare quali siano gli elementi dinamici nelle gerarchie per cui sia di interesse tracciarne l’evoluzione nel tempo e quali siano i requisiti relativi all’analisi dinamica di tali gerarchie.

Nel nostro caso siamo interessati a poter analizzare le vendite di ciascun prodotto, confrontando le quotazioni del prezzo di acquisto e vendita al variare del fornitore nel tempo. Per tale tipo di analisi è necessario prevedere una tabella che consenta di rappresentare la dinamicità del legame fra prodotto e fornitore, senza rinunciare alla struttura denormalizzata che caratterizza uno star-schema; la soluzione scelta è quella denominata Slowly Changing Dimension di tipo 2 che prevede l’uso di una chiave surrogata (ID) e di una coppia di campi di tipo data (DATA_INIZIO_VALIDITA e DATA_FINE_VALIDITA) che identifichi l’intervallo di validità di ciascuna relazione.

Questo pattern implementativo prevede che uno stesso prodotto sia presente più volte in tabella, purché i periodi temporali definiti dalle due date di inizio e fine validità per ciascuna occorrenza non siano sovrapposti. In ciascuna occorrenza il medesimo prodotto può essere associato a un fornitore diverso; in un determinato istante temporale il prodotto viene fornito da uno e un solo fornitore.

In questo caso non è possibile definire una chiave naturale della tabella che garantisca tale condizione, tuttavia la coppia PRODOTTO e DATA_INIZIO_VALIDITA può essere usata per definire un vincolo UNIQUE in modo da garantire un ordinamento totale fra le diverse versioni del medesimo prodotto.

Una possibile valorizzazione della tabella DIM_PRODOTTO è esemplificata nella tabella seguente.

Il “Prodotto X” viene correntemente fornito dal “Fornitore A” a partire dal 10/2/2008: la data 31/12/9999 utilizzata come data di fine validità identifica la versione corrente delle informazioni relative al prodotto in questione.

Il “Prodotto Y” invece è stato fornito dal “Fornitore A” nel periodo compreso fra 1/1/2008 e il 31/12/2008; a partire dal 1/1/2009 viene invece fornito dal “Fornitore B”. Tale situazione è rappresentata dai due record identificati con ID 2 e 3.

La fact table che implementa lo schema di fatto relativo all’analisi delle vendite su riportato è costituita da due insiemi di campi: quelli relativi alle misure contenute nello schema di fatto e quelli che implementano le foreign key verso le tre dimension table; ciascuna foreign key referenzierà la primary key della rispettiva dimensione.

In particolare ID_TERRITORIO referenzia il campo ID della DIM_TERRITORIO, ID_TEMPO referenzia il campo GIORNO della DIM_TEMPO, e ID_PRODOTTO referenzia il campo ID della DIM_PRODOTTO. Le tre foreign key costituiscono congiuntamente la primary key della FACT_VENDITE.

Una possibile valorizzazione della tabella FACT_VENDITE è esemplificata nella tabella seguente.

Il negozio “Roma Uno” (ID_TERRITORIO = 1) ha effettuato due vendite del “Prodotto Y”: in data 30/11/2008 ha venduto una quantità 10 di tale prodotto che era stata acquistata dal “Fornitore A” (ID_PRODOTTO = 2), mentre in data 10/1/2009 ha venduto una quantità pari a 15 dello stesso prodotto rifornito questa volta da “Fornitore B” (ID_PRODOTTO = 3).

Complessivamente la quantità venduta di “Prodotto Y” è pari a 25 (10+15) mentre l’importo totale relativo ai prodotti acquistati dal “Fornitore A” (ID_PRODOTTO = 1 e ID_PRODOTTO = 2) è pari a 130 (60 + 70).

Ogni progetto avrebbe bisogno di una fase di inizializzazione in cui pianificare le risorse necessarie, selezionare le tecnologie e le metodologie, ecc.; fra queste scelte riveste un ruolo non secondario anche il modello di sviluppo da adottare.

L’esperienza personale e le letture (frutto dell’esperienza altrui) possono aiutare ad impostare correttamente tale aspetto cruciale di ogni progetto.

Circa tre anni fa, con altri due amici, abbiamo dato vita ad un progetto in pieno stile web 2.0: un aggregatore semantico di flussi informativi (feed RSS e non solo) con un sistema di ranking basato essenzialmente sulla taggatura dei contenuti.

Fra le nottate, i sabati e le domeniche passate a scrivere codice, gli interminabili brainstorming fra pizze e birre, gli scazzi e i momenti di esaltazione, quella esperienza è stata caratterizzata da una straordinaria intensità umana e professionale che ha travalicato anche i confini del progetto stesso.

L’architettura del sistema prevedeva tre diverse componenti inter-operanti. Sul piano tecnologico è stato facile individuare come soluzione ottimale per disaccoppiare le componenti realizzate da ciascuno, la definizione delle interfacce di comunicazione fra i tre sotto-sistemi; mentre una delle principali difficoltà affrontate è consistita nella condivisione di un modello di sviluppo e di organizzazione del ciclo di vita del progetto.

Le esigenze di sperimentazione legate all’elevato livello di innovazione caratteristico del progetto suggerivano un approccio di tipo agile che consentisse una continua verifica delle scelte adottate; d’altro canto l’inevitabile a-sincronicità con cui venivano portati avanti gli sviluppi richiedeva la definizione di un disegno progettuale comune (per quanto soggetto a radicali e frequenti cambiamenti) che fosse da guida nella realizzazione delle singole parti e garantisse l’unità di intenti. Come nelle migliori tradizioni della filosofia orientale, il caos creativo e l’ordine produttivo hanno continuato a fronteggiarsi e (s)bilanciarsi per tutto l’arco del progetto.

Il quesito, sopravvissuto al progetto, è se tali esigenze siano intrinsecamente inconciliabili o se esistano strumenti e modelli produttivi in grado di garantire la velocità di esecuzione e la frequente rimodulazione di un disegno progettuale definito.

Non credo esista una risposta universale a tale quesito, tuttavia è possibile identificare alcune classi di soluzione.

Le risposte “classiche” della software engineering si chiamano modello iterativo/prototipale e sviluppo basato su componenti. Tali approcci però si prestano bene a risolvere istanze specifiche di problemi già noti con soluzioni che sono in gran parte preconfezionate (sia nelle componenti di interfaccia che negli algoritmi adottati). Per quanto riguarda la velocità realizzativa, questa dipende molto dalla disponibilità e dalla qualità dei componenti riusabili; mentre per quanto riguarda la flessibilità nella rimodulazione del disegno progettuale, questa dipende molto dalle tecnologie scelte (dal loro uso corretto) e dall’IDE utilizzato per assemblare i componenti. Il risultato di tale modello produttivo finisce per assomigliare molto alla realizzazione di un prototipo (che diventa definitivo nella sua seconda o terza versione, ma non necessariamente esaustivo nei suoi requisiti iniziali) incentrato sui componenti che è stato possibile assemblare.

Un approccio alternativo che offre maggiore flessibilità è quello del Model Driven Engineering (o sue varianti come il Model Driven Architecture di OMG) in cui al centro del processo realizzativo viene posto il disegno progettuale (modello) del sistema definito in funzione del requisito di business espresso. Il sistema viene realizzato attraverso l’adozione di una serie di scelte implementative applicate alle diverse componenti del modello disegnato: tale processo realizzativo può essere concepito come una catena di trasformazioni del modello iniziale che integrano e raffinano il requisito di business fino a realizzare il sistema software (Business Driven Development). La velocità esecutiva consiste nella generazione automatica o semi-automatica dell’implementazione del modello, mentre la flessibilità è data dalla facilità di manipolazione del modello del sistema rispetto alla sua implementazione (che viene adeguata in maniera automatica o semi-automatica) in modo da assecondare agevolmente le rimodulazioni dei requisiti.

Una delle tecniche più semplici per implementare tale processo di trasformazione consiste nell’utilizzo di template di codice applicati ai metadati che descrivono formalmente il modello del sistema. Molti case UML (ex. StarUML, Enterprise Architect, ecc.) consentono di definire tali template all’interno del prodotto, così come di estendere il proprio metamodello per integrare le informazioni necessarie alla generazione automatica del codice.

L’automazione del processo di trasformazione del modello, oltre a ridurre drasticamente i tempi di codifica lasciando più spazio alla modellazione del sistema e all’individuazione delle soluzioni implementative più adatte, garantisce l’apllicazione coerente delle medesime soluzioni implementative nell’arco dell’intero progetto. A parità di funzionalità implementate il carico di lavoro (così come le professionalità richieste) si sposta nelle fasi alte del ciclo di sviluppo (analisi e progettazione); le track di sviluppo si scaricano delle attività di codifica più ripetitiva (applicazione stereotipata di patttern) a favore dello studio di soluzioni tecnologiche adeguate e dell’implementazione degli algoritmi e delle componenti per cui non è possibile o conveniente prevedere una generazione automatica del codice.

L’applicazione di tale modello produttivo risulta di grande utilità anche nell’ambito della realizzazione, in tempi ristretti, di prototipi funzionanti, nel momento in cui si dispone già di template e strumenti di analisi e progettazione collaudati. Con un ambiente di dimostrazione preconfigurato e gli strumenti adeguati si può condurre in pochi giorni (o ore) un intera iterazione progettuale dalla formulazione di un semplice requisito alla realizzazione di un sistema che ne implementi le principali funzionalità. Attività dimostrative di questo tipo possono essere condotte anche da un’unica figura professionale in grado di modellare un requisito e seguire le fasi di auto-generazione del sistema che lo implementa.

Fra i vari formalismi messi a punto dal mondo accademico per la definizione di modelli multi dimensionali, il Dimensional Fact Model (DFM) è fra quelli che più di altri negli ultimi anni è riuscito a valicare i confini universitari e ad essere conosciuto ed utilizzato in diverse realtà industriali e della pubblica amministrazione.

Personalmente sono circa sei anni (da quando ho curato la realizzazione di un CASE specifico per il disegno di modelli multi-dimensionali) che ho adottato il Dimensional Fact Model (DFM) come formalismo per la rappresentazione dei requisiti utente nell’ambito di progetti di Data Warehousing/Business Intelligence. In questo periodo mi è capitato spesso (specie in occasione dello start-up di un nuovo progetto) di dover riassumere “in pillole” gli elementi fondamentali del formalismo e come la sua adozione faciliti la definizione di un requisito di analisi univocamente interpretabile nel corso di tutto il ciclo di vita del progetto; mi fa piacere quindi dedicare alcuni post a questi argomenti.

Prima di introdurre i costrutti fondamentali del DFM è utile riassumere brevemente quelli che sono gli elementi principali della modellazione multi-dimensionale rappresentati dal formalismo.

Un modello dati multi-dimensionale è costituito da un insieme di grandezze numeriche (dette genericamente misure) il cui valore varia in funzione di alcuni parametri, definiti su domini discreti (o categorici). Tali domini (detti dimensioni di analisi) costituiscono lo spazio multi dimensionale in cui viene condotta l’analisi degli eventi (o fatti di interesse) descritti quantitativamente dalle misure.

Tale modello viene spesso esemplificato come un cubo i cui spigoli rappresentano le dimensioni di analisi; il cubo è suddiviso in tanti “cubetti”, ciascuno dei quali è identificato da una terna di coordinate; ogni cubetto contiene idealmente i valori assunti dalle misure per quella data terna. Tale elemento atomico (rispetto allo spazio dimensionale) viene comunemente denominato “fatto” in quanto rappresenta l’accadimento di un evento di interesse per il dominio di business.

L’esempio più classico di questo modello dimensionale è costituito dal “cubo delle vendite” che rappresenta lo spazio di analisi per le vendite di una catena di negozi; tipicamente le dimensioni di analisi sono:

• il giorno in cui è stata effettuata la vendita
• il negozio in cui è avvenuta la vendita
• il prodotto venduto

mentre le misure che descrivono quantitativamente il fatto “vendita” sono:

• la quantità di prodotto venduta
• il prezzo di vendita
• il prezzo di acquisto del prodotto venduto

Modelli dimensionali più complessi possono prevedere un numero maggiore di dimensioni di analisi; in questi casi si parla spesso di ipercubo.

Gli elementi di una dimensione possono essere raggruppati gerarchicamente in vari livelli fino a comporre un albero: ogni livello rappresenta un raggruppamento uniforme degli elementi della dimensione rispetto ad una loro caratteristica: la radice dell’albero rappresenta l’intera dimensione, mentre le foglie rappresentano i suoi singoli elementi. I gruppi che costituiscono un livello di aggregazione (ossia gli elementi del livello) sono legati agli elementi del livello inferiore da relazioni di tipo uno-a-molti: ogni gruppo di un livello (a meno delle foglie dell’albero) include uno o più gruppi del suo sotto livello.

Tale relazione costituisce una dipendenza funzionale fra un livello di aggregazione e quello superiore (che risulta dipendente dal primo); il legame funzionale deriva dalla corrispondenza esistente fra ogni gruppo di elementi di un livello di aggregazione e il gruppo (univocamente identificato) di elementi di livello superiore che lo include. La dimensione di analisi è l’unico livello di aggregazione indipendente di una gerarchia.

Il carattere di uniformità dei gruppi di elementi che costituisce un livello gerarchico di aggregazione conferisce un’identità propria al livello stesso. Il medesimo criterio di omogeneità da esso rappresentato può essere riapplicato anche ad elementi di altre dimensioni di analisi; viceversa gli elementi di una stessa dimensione possono essere raggruppati secondo criteri differenti così da generare alberature alternative.

Per riprendere l’esempio del cubo delle vendite, i negozi della dimensione Negozio possono essere raggruppati gerarchicamente in funzione della loro dislocazione sul territorio nazionale: il primo livello di aggregazione è rappresentato dalla provincia in cui il negozio risiede, quello successivo dalla regione e in fine dallo stato nazionale che rappresenta la radice dell’albero. Gli elementi del livello Provincia sono Roma, Milano e Brescia che rappresentano rispettivamente i tre insiemi di negozi Roma = {Negozio 1, Negozio 2} , Milano = {Negozio 3} e Brescia = {Negozio 4}.

Le misure associate agli elementi della dimensione possono essere aggregate (es. sommate) ai diversi livelli della struttura gerarchica: la radice dell’albero rappresenta il livello di aggregazione massimo, mentre alle foglie è associato il valore elementare della misura (rispetto a quella data dimensione di analisi).

L’uso incrociato delle diverse gerarchie di analisi consente, ad esempio, di calcolare la quantità venduta di un particolare prodotto (o dell’insieme di prodotti di un particolare fornitore) in un determinato giorno dell’anno (o in una settimana, mese, ecc.) da un determinato negozio (o da tutti quelli presenti nella provincia di Roma o nel Lazio).

Il DFM è un linguaggio di modellazione per rappresentare modelli multi-dimensionali in una forma sintetica e facilmente leggibile (grazie anche alla sua rappresentazione grafica coincisa); come ogni linguaggio formale ha i suoi costrutti e le sue regole che ne garantiscono l’univocità interpretativa.

L’elemento principale del formalismo è lo Schema di Fatto che raccoglie, in un unico diagramma, le misure che descrivono quantitativamente un fatto, le dimensioni che ne costituiscono lo spazio multi dimensionale di analisi e le gerarchie di aggregazione definite per ciascuna dimensione.

La figura seguente riporta lo schema di fatto (commentato) relativo al cubo delle vendite descritto precedentemente.

Il fatto viene rappresentato da un’area rettangolare suddivisa in due parti: in alto la denominazione del fatto (che da il nome allo schema nel suo complesso) e sotto l’elenco delle sue misure.

Al fatto sono legate direttamente le dimensioni di analisi rappresentate da un cerchio affiancato dal nome della dimensione. Nell’esempio citato queste sono Negozio, Giorno e Prodotto.

I livelli di aggregazione che costituiscono la gerarchia di ciascuna dimensione sono chiamati attributi dimensionali della gerarchia; la loro rappresentazione è analoga a quella di una dimensione (che è a tutti gli effetti un attributo dimensionale della gerarchia). La gerarchia Territorio comprende gli attributi dimensionali: Negozio (la dimensione), Provincia, Regione e Stato.

Le relazioni che legano gli attributi dimensionali sono rappresentate da un segmento che unisce i due cerchi; il verso della relazione di dipendenza si deduce dalla posizione della dimensione nella gerarchia, quando ciò non è possibile o al fine di aumentare la leggibilità dello schema il verso viene esplicitato con una freccia. L’insieme delle relazioni di dipendenza costituisce un grafo diretto aciclico la cui sorgente è la dimensione di analisi. Nello schema di fatto vengono rappresentate solo le dipendenze non ridondanti.

La gerarchia Tempo presenta il classico schema a diamante in cui i giorni dell’anno possono essere raggruppati sia in mesi che in settimane. Dato un giorno dell’anno, sia il mese che la settimana cui il giorno appartiene risultano univocamente identificati, mentre fra settimane e mesi non esiste un’analoga dipendenza funzionale in quanto diverse settimane dell’anno si trovano a cavallo di due mesi. Per questo motivo esistono due percorsi di aggregazione indipendenti per l’attributo Giorno che passano per Mese e Settimana; data la settimana di un anno o un suo mese, l’anno cui questi appartengono è univocamente (e indipendentemente) identificato e pertanto i due percorsi indipendenti si ricongiungono sull’attributo Anno. Per facilitare la lettura degli schemi, quando un attributo dipende da due differenti attributi è bene indicare il verso della dipendenza in maniera esplicita.

Agli attributi dimensionali è possibile collegare anche attributi di dettaglio (detti non dimensionali) che non rappresentano un ulteriore livello di aggregazione, ma solo delle informazioni di corredo riferite all’attributo cui sono collegate. La loro rappresentazione è data semplicemente dal nome dell’attributo corredato da un tratto di sottolineatura come nel caso dell’Indirizzo di un Negozio raffigurato nello schema di esempio.

Roma, 24 Gennaio 2009 - La facoltà di Ingegneria di Roma Tre ha ospitato la terza edizione romana del Java Day.

Anche quest’anno si è confermato il grande successo di pubblico che ha caratterizzato la passata edizione.

Nel video ho raccolto alcuni passi dei tre talk che ho seguito con maggior attenzione:

• Java SE 6 Update 10 & JavaFX: la piattaforma Java per le RIA sulle novità introdotte con l’ultima release del JRE in merito alla realizzazione di Rich Internet Applications. Particolarmente interessante la maggior integrazione fra applet e browser (fra cui il pieno accesso alla struttura DOM della pagina sia in “lettura” che in “scrittura”) e con JavaScript (lo standard de fact nella realizzazione di web apps).
• Android: lo sbarco di Google nel pianeta Mobile Internet: uno dei talk più attesi (e più affollati) non ha deluso le aspettative, combinando tanto codice con un’analisi acuta delle potenzialità e delle prospettive di mercato per il sistema targato Google.
• Una carriera nell’Open Source: unico talk (credo) senza una riga di codice … ma probabilmente il più affascinante, come spesso succede quando ci si concentra sul rapporto fra tecnologia e modelli di organizzazione sociale.

Ieri si è tenuto a Roma l’evento Cognos Performance 2008 organizzato con la collaborazione di alcuni partner fra cui Sopra Group. Lavorando ormai da diversi mesi su progetti incentrati sulla suite Cognos BI 8.3, sono stato sopratutto attirato dalla presentazione delle nuove features della release successiva. Nondimeno ha apprezzato il tentativo di organizzare le sessioni iniziali con un modello comunicativo diretto e informale.

Per motivi di policy aziendali non mi è stato concesso di pubblicare le clip video prese durante l’evento. Peccato, perché sono convinto che sarebbero state sicuramente più efficaci delle mie parole. Trovo tale limitazione assai singolare in un momento storico in cui l’attenzione del marketing è rivolta al mondo dei blog e del web 2.0 più che ai canali tradizionali (anche i siti istituzionali sono ritenuti meno utili e credibili dei blog indipendenti) e in cui le aziende cercano di promuovere un’immagine moderna, aperta e trasparente di se stesse (specie quelle che cavalcano le innovazioni del web 2.0).

Ad ogni modo, alcune delle novità introdotte con la suite Cognos BI 8.4 sono degne di nota e meritano una veloce carrellata:

• Go Dashboard! - con questa nuovo strumento è possibile creare cruscotti interattivi basati su componenti Flash, in grado di aggiornarsi dinamicamente in funzione dei controlli applicati senza ricaricare l’intera pagina e facilmente componibili mediante drag-and-drop. Con Go Dashboard!, Cognos tenta di colmare, almeno in parte, il gap creatosi con l’introduzione di Crystal Xcelsius nell’offerta di SAP Business Objects. A favore di Cognos gioca la perfetta integrazione dello strumento nella suite: infatti, grazie alla reingegnerizzazione della versione 8 secondo gli standard SOA, oggi è più semplice per Cognos integrare l’offerta con nuove componenti che sfruttino lo strato architetturale sottostante.
• Go Search! - l’introduzione di un motore di ricerca che lavori sui nomi degli oggetti contenuti nei report (e non solo su nome e descrizione) è una delle novità più interessanti. In questo modo gli utenti del sistema possono individuare, fra tutta la reportistica pubblicata, quella che contiene un certo insieme di informazioni di interesse. Lo stesso insieme di oggetti di business viene ricercato anche all’interno di uno o più package per includere, fra i risultati della ricerca, anche un set di report elementari appositamente costruiti con tali oggetti.
• Go Mobile! - potenziata l’interfaccia di distribuzione delle informazioni verso le principali piattaforme Mobile (Blackberry, Symbian e Windows Mobile) che è in grado di sfruttare le informazioni di geo-referenziazione dei dispositivi provvisti di GPS per fornire dati contestuali alla propria posizione geografica.

Fra le altre novità introdotte ci sono due nuovi tipi di grafici (Marimekko Chart e Step Chart), la possibilità di commentare i report e condividere i commenti con altri utenti (funzionalità orientata alla collaboration già presente in Business Objects dalla seconda release di XI) e l’integrazione con IBM Infosphere per la gestione di glossari (con cui definire la semantica degli oggetti di business che compongono i modelli di analisi) e la conduzione di analisi di data lineage all’interno della suite Cognos.

Dopo il successo dello scorso anno, il Java User Group di Roma, sta organizzando la terza edizione del Java Day nella Capitale, l’evento OPEN dedicato al mondo Java in cui sale in cattedra chi si confronta tutti i giorni con pregi e difetti di questa tecnologia.

L’evento si terrà il 24 Gennaio 2009 presso le aule dell’Università di Roma Tre e sarà, come sempre, aperto a tutti. Tra i temi affrontati non potranno mancare:

• Java Mobile: Android & J2ME
• Java Enterprise: JavaFX, SOA, JBI, ESB, JAXB, Metro, OpenSSO, ecc.
• Java Desktop: ??? (c’è qualcosa di nuovo da dire?)
• Java Real Applications: esempi reali di progetti reali (che sono sempre fra gli interventi più interessanti)

Nei giorni scorsi sono state aperte le iscrizioni per raccogliere le proposte di partecipazione attiva all’evento: chi è interessato può compilare la form di sottomissione del proprio contributo al vaglio del comitato scientifico del Javaday di Roma che ha il compito di selezionare quelli di maggior aderenza ai temi della conferenza. La deadline è fissata per il 1° Dicembre 2008.

Il 16 Aprile scorso si è tenuto a Roma il Cognos Finance Forum 2008 (in replica il 6 Maggio a Milano). L’evento, incentrato su Financial Performance Management, Forecasting e Planning, ha visto il contributo di diversi attori che hanno portato la propria esperienza teorica e pratica nel merito dei temi trattati.

L’evento, sponsorizzato da alcuni partner fra cui Everis e Sopra Group, si è articolato in quattro interventi spezzati da un coffe break:

• introduzione di Federico Della Casa, country manager di Cognos Italia, che ha presentato i disegni futuri di IBM per il settore dell’Information Management e le motivazioni che hanno portato all’acquisizione di Cognos;
• intervento di Fritz Roemer di The Hackett Group che ha illustrato alcuni dei risultati più interessanti emersi dal costante studio effettuato dalla prestigiosa società di consulenza in merito alle scelte manageriali in ambito finanziario e organizzativo delle più importanti società del mondo e alla comparazione dei risultati conseguiti;
• presentazione del caso di successo Baxter Italia che ha testimoniato le difficoltà e i traguardi raggiunti nell’introduzione di un sistema di Business Intelligence e Corporate Performance Management nella realtà quotidiana di una grande impresa farmaceutica;
• dimostrazione pratica dei prodotti della suite Cognos Planning.

Un sunto dei diversi interventi è disponibile nel filmato.

In questi giorni a Roma è stata presentata la versione 3.0 della suite Business Objects XI. L’evento, oltre a celebrare la nuova release, è stato anche l’occasione per fare il punto sulla recente acquisizione.

Ad illustrare le strategie per SAP e BO c’era sul palco Augusto Abbarchi (AD di SAP Italia dal 2005). Primo comandamento della strategia sinergica fra le due aziende è: 1 + 1 = 3; il che, tradotto in pratica, significa che i budget imposti ad entrambe le aziende per il 2008 prevedono una forte componente di ricavi legata al cross-selling.

Ma la parte del leone l’ha fatta, come giusto, la demo delle novità introdotte nella suite. Fra quelle presentate, la più avveniristica è stata Polestar (purtroppo non ho potuto riprenderla): un ambiente di analisi guidata per l’esplorazione dei dati che sembra uscito da un incrocio con Google e iTunes. Il primo ha chiaramente ispirato le funzionalità di ricerca delle informazioni di interesse, con tanto di scoring dei risultati che cambia a seconda del dettaglio con cui si forniscono le chiavi di ricerca. Mentre l’interfaccia di analisi e navigazione, con un sistema di filtri a cascata nella parte superiore e la visualizzazione dei dati (con diversi formati grafici) nell’area sottostante, richiama anche nelle logiche di funzionamento quelle del noto strumento di gestione delle library musicali.

Altra novità che è stata presentata è il Rich Client di Web Intelligence che consente di lavorare su dati locali (es. fogli excel) in modalità “scollegata” dal sistema Enterprise con le stesse funzionalità disponibili con la versione on-line; i dati locali (non necessariamente mappati in uno strato semantico) possono anche essere combinati con quelli corporate. A chiudere la presentazione sono state le funzionalità di integrazione con Office (Live Office) e i widgets per Windows Vista (basati su Xcelsius) attraverso cui è possibile avere, integrati sul proprio desktop, degli indicatori sintetici costantemente aggiornati.

Restano da vedere in azione le tecnologie di Text Analysis la cui presentazione si è limitata a illustrare, mediante slide PowerPoint, alcune logiche di funzionamento; lo stesso dicasi per Data Services il prodotto frutto dell’integrazione delle componenti di back-end.

Nel mese di febbraio è stata pubblicata da Gartner la consueta analisi, aggiornata al 2008, sul posizionamento delle diverse piattaforme di Business Intelligence.

Come è noto, nel corso del biennio 2006-2007 (ma sopratutto nell’ultimo anno) si sono susseguite una serie di importanti acquisizioni che hanno ridefinito gli attori e le strategie nel mercato della Business Intelligence. Questo stravolgimento non ha mutato le previsioni di Gartiner che conferma lo scenario di crescita delle revenue del settore con un incremento complessivo superiore al 50% per il 2011 (che corrisponde ad un CAGR del 8.6% per un periodo di cinque anni a partire dai risultati del 2006).

Una prima valutazione sugli effetti delle diverse strategie messe in atto dai principali player del settore può essere desunta dal diverso posizionamento loro assegnato da Gartner sui “Magic Quadrant” degli anni 2006, 2007 e 2008. Il trend comune per tutte le aziende è stata una crescita lungo l’asse della capacità realizzativa (Ability to Execute) dei propri disegni.

Lo sforzo profuso da Oracle nel processo di integrazione all’interno dei propri piani di sviluppo (per altro ancora in corso) di due diverse realtà come Siebel e Hyperion è testimoniato da una crescita contenuta proprio della capacità realizzativa; d’altro canto le importanti acquisizioni hanno giovato alla completezza dell’offerta (completness of vision) sia attuale che prospettica (vedi progetto fusion che travalica anche il mercato della sola BI).

Al tortuoso “percorso” di Oracle si contrappone quello lineare di Microsoft che, anche attraverso una serie di acquisizioni mirate (anche se di minore entità), raggiunge il quadrante dei ledears di mercato rafforzando la posizione sia in termini di completezza di visione del mercato che nella capacità di realizzare tale visione. La posizione che occupa (una elevata capacità realizzativa rispetto alla visione del mercato) è caratteristica del gigante di Redmond che (in qualità di follower) dimostra una grande capacità nel concretizzare in maniera assai efficace le migliori intuizioni che altri concorrenti hanno già dimostrato essere promettenti.

Cognos e Business Objects, i due player principali del mercato in termini di fatturato (tralasciando SAS che ha la maggior parte dei ricavi legati alle componenti di analisi statistica), continuano ad occupare il settore più centrale (e quindi più bilanciato) del quadrante dei leaders. Entrambe le aziende sono state oggetto di acquisizione, rispettivamente da parte di IBM e SAP, ma gli effetti di tali recenti acquisizioni non hanno ancora avuto un riscontro significativo nei piani di sviluppo fin qui adottati dai due vendor per la realizzazione delle due proprie suite di prodotti.

Da alcuni giorni è stata annunciata la nuova release 3.0 di Business Objects XI: l’ultima concepita prima dell’acquisizione di SAP. Il lancio ufficiale della suite in Italia è previsto a Milano per il 19 Marzo e a Roma per il 3 Aprile.

Nonostante venga rilasciata sotto il marchio “Business Objects, an SAP company”, l’unica traccia dell’influenza del gigante tedesco sui piani di sviluppo è consistita nel potenziamento dell’interfacciabilità con SAP BW. Diverse sono invece le novità annunciate: una maggiore integrazione a livello di piattaforma, le nuove versioni delle più innovative componenti della suite come Crystal, Xcelsius e Voyager e la fusione in un unico prodotto (battezzato Data Service) di Data Integrator e Data Quality.

L’attesa maggiore è però riservata a Polestar, il tool di interrogazione delle fonti dati non strutturate che, grazie alle funzionalità di text-mining ereditate dall’acquisita Inxight, consentirà di analizzare congiuntamente informazioni numeriche e testuali, integrate in un’unica piattaforma di Business Intelligence. Altra caratteristica molto attesa è la possibilità di definire dei widgets da posizionare sul proprio desktop, che consentano di monitorare in tempo reale i KPI di proprio interesse, analogamente a quanto è già possibile fare ad esempio per le quotazioni in borsa del proprio portafoglio azionario. Questo con la speranza che i top-manager, fra una sbirciata e l’altra data al valore delle proprie stock-options, buttino un occhio anche alle principali metriche che concorrono a definire l’andamento dei risultati aziendali.

Gli obiettivi perseguiti da BO nella realizzazione di questa release sono in linea con le acquisizioni e gli sviluppi degli ultimi anni: realizzare una suite completa ed integrata per affrontare le sfide di una BI sempre più pervasiva nei confronti dei processi di business a tutti i livelli aziendali e che favorisca l’interazione sia verticale che orizzontale fra tutti i dipendenti. Sarà interessante verificare quali siano le strategie e i progetti che SAP ha in serbo per BO. Stando alle dichiarazioni rilasciate dal CEO di SAP Henning Kagermann, i piani di integrazione fra i due mondi sono al quanto SAP-centrici:

use the Business Objects acquisition to create what it calls a “closed loop,” in which SAP users can rapidly adjust business processes in SAP applications based on business intelligence they get from Business Objects and SAP apps

Non c’è da stupirsi se in Business Objects, come accade spesso nei mesi che seguono un’importante acquisizione, c’è grande attesa (e forse un po’ di comprensibile apprensione) per le sfide del futuro. Pesa anche il confronto diretto con Cognos (storico rivale a livello worldwide), anch’essa recentemente acquisita da IBM: chi trarrà i maggiori benefici dalle rispettive acquisizione?