by Colin White

Maggio 2004

La tecnologia EII ripropone il data warehousing virtuale?

Il data warehousing è stato frequentemente oggetto di accesi dibattiti. Alcuni punti di discussione compaiono per scomparire poi rapidamente, mentre altri continuano a dominare articoli sulla stampa e dibattiti di settore. Esempi di quest’ultima categoria comprendono, naturalmente, argomenti relativi ai data mart e alla progettazione multidimensionale.
Recentemente, è sorta una nuova controversia a proposito dell’integrazione delle informazioni dell’impresa, indicata con l’acronimo EII (Enterprise Information Integration). Alcune persone (particolarmente venditori e responsabili di marketing dei fornitori interessati) affermano che la tecnologia EII elimini la necessità di costruire un data warehouse. Dall’altra parte, i puristi del data warehousing ribattono che la EII rappresenta solamente un’altra forma di data warehousing virtuale, ovvero una strada già tentata senza successo nel passato.
Per comprendere i pro e i contro di questo dibattito, per prima cosa dobbiamo categorizzare i diversi tipi di integrazione utilizzati all’interno delle organizzazioni e, quindi, identificare come le tecniche EII e il data warehousing si possano applicare a supporto dei diversi tipi di integrazione.
Esistono quattro grandi categorie di integrazione utilizzate all’interno dei sistemi It. Rispettivamente applicabili all’interfaccia utenti, ai processi dell’impresa, alle applicazioni ed ai dati.
Molti prodotti sono particolarmente adatti per ciascuna di queste categorie ma, come vedremo più avanti, esiste un trend nel settore verso prodotti in grado di supportare molteplici tecnologie d’integrazione, con il risultato che la linea di demarcazione tra le quattro categorie talvolta appare poco distinguibile.
L’integrazione dell’interfaccia utente fornisce una visione unica dei dati operativi e decisionali, oltre che delle applicazioni, al livello di presentazione logica di un sistema It. Un portale d’impresa costituisce l’esempio di un prodotto che supporti l’integrazione dell’interfaccia utente. Un aspetto fondamentale dell’integrazione al livello dell’interfaccia utente è che, anche se a quest’ultimo viene fornita una visione unica di applicazioni multiple che girano su sistemi eterogenei, proprio questa soluzione enfatizza la mancanza di un’integrazione dei dati e delle applicazioni tra i sistemi interessati..
Per questo motivo, alcuni fornitori di portali hanno dotato i rispettivi prodotti della capacità di costruire applicazioni composite, che inseriscono un livello di semantica dell’impresa tra l’interfaccia utente ed i sistemi di back-end. Questo livello semantico aggiuntivo rappresenta una prima base di integrazione dei processi dell’impresa.
L’integrazione dei processi dell’impresa consente agli sviluppatori di separare la fase di progetto da quella di attivazione dell’applicazione. Gli strumenti di progettazione dei processi operativi mettono in grado gli sviluppatori di analizzare i processi dell’impresa e di rappresentarli sotto forma di modelli.
Gli strumenti di automazione e integrazione dei processi consentono, poi, di implementare questi modelli di processo, utilizzando le tecnologie di integrazione delle applicazioni che sottintendono. Il beneficio maggiore consiste nell’isolamento del processo di progettazione dalla fase di implementazione fisica da parte del livello semantico dell’impresa inserito nei modelli così realizzati.
 
BAM registra le performance
È anche importante sottolineare che gli strumenti di automazione dei processi dell’impresa non solo gestiscono l’implementazione delle singole applicazioni, ma controllano anche il flusso delle informazioni tra le applicazioni stesse.
Molti strumenti per la modellazione dei processi dell’impresa stanno aggiungendo capacità di monitoraggio all’interno di questo flusso di processo, con lo scopo di analizzare le performance dell’impresa. Questa è una forma di monitoraggio dell’attività dell’impresa, definita come BAM (Business Activity Monitoring).
La tecnologia di integrazione delle applicazioni supporta il flusso di transazioni dell’impresa tra i sistemi applicativi presenti all’interno o all’esterno dell’organizzazione. In quest’area, il trend evolutivo è verso un’architettura orientata al servizio, che impiega servizi Web basati sul linguaggio XML per definire e muovere le transazioni dell’impresa tra i sistemi. Se i sistemi interessati condividono una definizione comune (ad esempio un metamodello comune dell’impresa) per le transazioni che transitano al loro interno, allora sono necessarie poche o addirittura nessuna trasformazione delle informazioni.
In mancanza, invece, di una definizione comune, il software d’integrazione delle applicazioni deve trasformare le informazioni per renderle riconoscibili e corrispondenti ai diversi metamodelli dell’impresa riferiti alle applicazioni interessate.
Anche se la tecnologia d’integrazione delle applicazioni era inizialmente progettata per muovere le transazioni dell’impresa tra sistemi, attualmente viene impiegata anche per trasferire i dati tra le applicazioni. Nel mondo del data warehousing, ad esempio, molti strumenti Etl operano con un software di integrazione delle applicazioni per estrarre i dati da un workflow applicativo, in modo da trasformarli e caricarli in un data warehouse.
Questa tendenza è enfatizzata dal fatto che molti venditori di strumenti Etl adesso presentano i loro prodotti come piattaforme per l’integrazione dei dati.
 
A supporto delle decisioni
Prima continuare a parlare di integrazione dei dati, è importante puntualizzare alcuni aspetti fondamentali relativi a quanto abbiamo detto fino a questo momento. La prima cosa da notare è che le tecnologie d’integrazione relative all’interfaccia utenti, ai processi di business e alle applicazioni vengono utilizzate non solo per i processi operativi, ma anche per quelli a supporto delle decisioni.
Un’altra considerazione è che tre tipi d’integrazione possono agire contemporaneamente, oltre a interagire tra di loro. Questo avviene perché il mercato si sta muovendo verso un software d’integrazione di portali, processi di business e applicazioni, il tutto all’interno di una piattaforma di server applicativo del tipo, ad esempio, di IBM WebSphere. Una nota finale circa le tre tecnologie d’integrazione è che i metadati e i metamodelli a livello dell’impresa rivestono un ruolo fondamentale nel processo d’integrazione.
Per l’integrazione dei dati si possono usare una serie di tecnologie, che comprendono server di duplicazione e trasformazione dei dati, strumenti Etl e, adesso, middleware EII. La tecnologia utilizzata dipende da molteplici fattori come, ad esempio, il tipo di elaborazione, il volume dei dati, le specifiche di circolazione e l’ammontare delle trasformazioni necessarie per i dati da trattare.
In termini elaborativi, le tecnologie d’integrazione dei dati sono state tradizionalmente separate in due filoni comprendenti, rispettivamente, le tecniche usate per i processi operativi e quelle relative ai processi di supporto alle decisioni. Per quanto riguarda le elaborazioni per i processi operativi, spesso vengono utilizzati server di replica e trasformazione dei dati (invece dell’integrazione delle applicazioni), che richiedono il trattamento e la duplicazione di grandi quantità di dati in modalità batch.
In alcuni casi, la duplicazione dei dati viene usata per fornirli alle applicazioni con la cadenza e la tempestività desiderate. In questo modo viene posta una grande attenzione alla potenza elaborativa disponibile, in termini di performance e di capacità di trasformazione dei dati, tenendo in scarsa considerazione la semantica dell?impresa ed i processi interessati. In altri termini, i metadati dell’impresa e i modelli dei processi raramente giocano un ruolo significativo in questo tipo di elaborazioni.
 
Tempi e strumenti
Gli strumenti Etl dominano il mercato per l?estrazione e la trasformazione dei dati operativi, per consentirne il caricamento in un data warehouse. Normalmente, le informazioni contenute nel data warehouse vengono utilizzate per l’analisi e il reporting, sia a livello tattico che strategico.
In tempi più recenti, gli strumenti di performance management estendono questo tipo di elaborazioni alle tecniche di uso delle scorecard, che confrontano le informazioni di intelligence, prodotte dalle elaborazioni di supporto alle decisioni, con le pianificazioni e gli obiettivi attualizzati, informando i responsabili interessati degli eventuali scostamenti e anomalie.
Nel costruire un data warehouse, gli strumenti Etl prestano scarsa attenzione alla semantica dell’impresa e ai processi interessati.
Al di fuori del warehouse, alcuni strumenti di analisi e di gestione impiegano una semantica dell’impresa, oppure un livello di metadati, per isolare analisi e report dalle strutture di data warehouse utilizzate. In questo modo, però, rimane ancora a carico dell’utente la mappatura dei risultati con riferimento ai processi dell’impresa considerati.
Nelle organizzazioni, esiste un crescente bisogno di soluzioni che comprendano elaborazioni mirate al supporto delle decisioni per il business giornaliero, come, ad esempio, l’analisi e il reporting operativo. Questo tipo di elaborazioni consentono di rispondere meglio alle esigenze del mercato.
Esempi di tali elaborazioni sono l’interrogazione e l’analisi di dati operativi correnti o utilizzati saltuariamente, gli allarmi generati dalla Business Intelligence con i relativi automatismi di decisione, oppure le raccomandazioni fornite dal sistema in base a regole predefinite e, infine, l’analisi predittiva.
Dal punto di vista dei dati, le elaborazioni a supporto delle decisioni possono essere eseguite utilizzando direttamente i dati operativi, oppure con l’uso di un data store a bassa latenza del tipo ODS. I dati operativi possono essere utilizzati in maniera diretta quando si richieda una trasformazione limitata dei dati, o ne risulti bassa la complessità e i volumi di interrogazione e di analisi. Quando, invece, sia necessaria una trasformazione e un’analisi approfondita dei dati, potendo anche tollerare un determinato livello di latenza delle informazioni, l’approccio migliore è l’uso di un deposito di memorizzazione a bassa latenza.
L’uso di un data store a bassa latenza spesso è causa di confusione, perché può essere utilizzato in molti modi diversi. In tutti i casi, la motivazione per creare un deposito a bassa latenza è l’integrazione e la validazione dei dati operativi. Questo tipo di data store non è necessario, se la fonte dei dati operativi risulta integrata e significativa. Il medesimo discorso vale anche per i data warehouse: se i sistemi origine mantengono dati integrati, significativi, correnti e con validità storica, allora non è necessario costruire un data warehouse.
Un data store a bassa latenza ha molteplici usi. Alcuni di questi sono associati con processi operativi, mentre altri sono correlati con il supporto alle decisioni. In realtà, tuttavia, la distinzione tra questi due tipi di elaborazioni risulta spesso indefinita, oppure presenta aree di sovrapposizione, risultando spesso rilevante solamente da un punto di vista organizzativo o di politica interna all’organizzazione.
Nelle elaborazioni operative, un data store a bassa latenza può essere usato per integrare dati operativi e dati consolidati. L’insieme di questi dati può essere usato come base per nuove applicazioni operative, per la migrazione di vecchie applicazioni proprietarie e per la propagazione dei dati verso applicazioni a valle.
 
Guidati dagli eventi
La controversia relativa a un data store a bassa latenza è se un deposito di questo tipo possa essere giustificato solamente per le elaborazioni a supporto delle decisioni, oppure debba servire anche per il reporting e le analisi operative. In molte applicazioni, i benefici ottenuti dall’impresa possono giustificare la realizzazione dello store. In altri casi, ciò non è sostenibile.
Questo è il motivo per il quale molte organizzazioni sono alla ricerca di modalità per effettuare reporting e analisi operative, senza la necessità di costruire un data store a bassa latenza. Si tratta di una situazione che rende attraenti soluzioni di monitoraggio dell’attività dell’impresa, note come BAM (Business Activity Management), proposte da venditori indipendenti e specializzati nell’integrazione delle applicazioni.
Tali soluzioni sono in grado di effettuare un’analisi dei processi dell’impresa, operando direttamente in memoria durante le elaborazioni operative e riportandone i risultati, senza la necessità di creare un data store separato. Questo tipo di software BAM risulta attraente anche perché, a differenza di molte tecniche di integrazione, è guidato dagli eventi ed è collegato direttamente ai processi dell’impresa. È da notare, tuttavia, che le tecniche BAM non sono adatte per le applicazioni a supporto alle decisioni tattiche e strategiche.
Un altro approccio che supporta il reporting e l’analisi operativa senza la necessità di creare un data store separato è definito come EII (Enterprise Information Integration), ovvero integrazione totale delle informazione dell’impresa. Questa tecnologia si basa su di un server d’interrogazione federato che può ritrovare e integrare i dati a partire da molteplici fonti non integrate.
Un server di questo tipo è utilizzato principalmente per l’interrogazione e l’accesso a dati operativi strutturati. Alcuni prodotti, tuttavia, supportano anche data store non strutturati. I risultati forniti dal server d’interrogazione possono essere elaborati da applicazioni operative, oppure da strumenti d’interrogazione e analisi a supporto delle decisioni.
Tali risultati possono essere usati anche come input per uno strumenti Etl, con lo scopo di costruire un data warehouse. Poiché la maggior parte dei prodotti EII non sono guidati dagli eventi, non risultano adatti per costruire un data store a bassa latenza, nel quale il ritardo debba risultare il più vicino possibile al real time.
 
L’EII è diverso dai DBMS?
Nell’analizzare i prodotti EII, emergono numerose questioni. Tra queste, una fondamentale è in che cosa la tecnologia EII risulti diversa dalle tradizionali interrogazioni distribuite, tipiche dell’accesso ai DBMS relazionali. La risposta è che la EII rappresenta un’evoluzione delle funzionalità fornite da tali prodotti.
L’enfasi della EII è sull’ottimizzazione degli accessi a dati eterogenei, oltre che sulla presentazione di questi con una visione univoca. Tuttavia, i prodotti risultano diversi nelle rispettive capacità. Ad esempio, DB2 Information Integrator di IBM pone una forte enfasi sulla prpria capacità di accesso a dati non strutturati (fornisce anche una funzionalità di duplicazione dei dati).
Altri prodotti non DBMS come, ad esempio, MetaMatrix e Certive, enfatizzano la potenza di analisi e di uso dei metadati. I venditori di prodotti di integrazione delle applicazioni, come BEA con Liquid Data, ad esempio, si stanno muovendo con l’obiettivo di espandersi nell’area EII.
La questione di fondo della controversia EII è se questa neghi la necessità di un data warehouse, ovvero se la tecnologia EII possa essere usata in termini di data warehouse virtuale. Anche se la EII fornisce capacità al di sopra e oltre quelle dei tradizionali prodotti DBMS relazionali (che, nel passato, sono stati utilizzati per realizzare i data warehouse virtuali), tuttavia non è ancora in grado di risolvere i problemi di qualità dei dati, esistenti in molti sistemi operativi.
Considerare la tecnologia come front end per i dati operativi è come realizzare un portale a fronte di sistemi d’impresa multipli. La tecnologia può fornire un punto di accesso singolo a informazioni disparate, ma non può nascondere i possibili problemi di integrazione dei dati o dei sistemi.
Per tale motivo, la EII è adatta per l’accesso a dati operativi reali solamente quando venga richiesto un ritardo pari a zero e quando non esistano problemi d’integrazione, ovvero quando non siano richieste trasformazioni e analisi complesse di dati.
Un punto finale da considerare è che la EII è ancora una tecnologia guidata dagli eventi e che, come molte altre tecnologie di integrazione dei dati, soffre del fatto ignorare completamente le semantiche e i processi delle imprese.
Perché abbia successo, i venditori debbono impegnarsi fortemente nel risolvere i problemi dei metadati, tenendo conto dell’enfasi posta nel promuovere il grande numero di fonti diverse che sono in grado di supportare. Se non risolveranno il problema, sarà difficile integrare questa tecnologia con l’insieme di tutte le integrazioni necessarie nelle imprese.