Un’architettura per la nuova intelligence

La Business Intelligence, o ‘intelligence’ tout court, come si potrebbe dire estendendo la conoscenza e analisi delle proprie attività a quella del mercato di riferimento, dei mercati potenziali e, via via crescendo, del contesto sociale ed economico nei quali questi si collocano, è una risorsa irrinunciabile per ogni impresa. Questo si sa, come si sa che oggi la BI si trova da un lato a doversi organizzare per diventare, come s’è detto, una fonte d’intelligence globale, dall’altro a doversi attrezzare per far fronte al crescere in volume, tipologia e complessità dei dati da considerare e alle necessità del business. Che si possono, in ultima analisi, ridurre a tre: massima velocità di risposta, possibilità di analisi predittive e simulazioni e, soprattutto, possibilità di far da sé, senza chiedere troppo aiuto a uno staff It che, peraltro, ha poche risorse e tanti problemi.

Stando così le cose, perché la BI sia efficace occorre che sia inquadrata in un’architettura generale che faccia da riferimento a chiunque, dagli sviluppatori e amministratori ai project manager, sia responsabile a qualsiasi titolo di farla crescere e funzionare. Vediamo come, basandoci su uno studio che Forrester ha condotto discutendo con fornitori e aziende utenti sino a tracciare un modello generale che si può applicare alla grande maggioranza dei casi aziendali. A tale modello e allo schema di massima relativo (figura 1) ci riferiremo quindi nei paragrafi seguenti citando in corsivo, per comodità di chi legge, la nomenclatura in esso riportata.

Fonti e razionalizzazione dei dati, il punto di partenza

Le basi dati, i file, gli stream e i repository che forniscono i dati sui quali sviluppare le informazioni costituiscono il livello Data Source e il supporto a tutti i processi Oltp. È il punto di partenza per i dati dell’information lifecycle, che questi siano strutturati (Dbms relazionali e no), semi-strutturati (log file, streams, documenti Xml…) o non strutturati (testi, dati forniti da sensori, file d’immagini, video e audio…) e che risiedano nel data center, nei client (smartphone compresi) o sul cloud (figura 2).

Sui dati agiscono gli strumenti del livello di Data Rationalization, federation movement and virtualization, che comprendono:

1) le tecnologie di data integration, data quality e data services;

2) le best practices per la movimentazione fisica o virtuale dei dati tra le varie applicazioni e i vari archivi;

3) le logiche e le business rules che regolano la ‘pulizia’, validazione e aggregazione dei dati.

Figura 1: Modello di architettura della "nuova" business intelligence Fonte: Forrester Research

È un livello di transito, dove i dati risiedono solo temporaneamente per essere poi inviati al livello successivo, quello delle Derived data sources (vedi più avanti). Poiché lo scopo ultimo di questo livello è di mappare dati eterogenei (comparare arance con mele, come dice Forrester) per trarne informazioni utili, il passaggio tra i tre livelli (fonte, razionalizzazione e derivati) può diventare un ciclo ripetibile, con i dati derivati che fanno da fonte per le tecnologie di razionalizzazione, in modo da ottenere dati sempre più raffinati e adatti a complesse applicazioni analitiche.

I componenti architetturali tipici sono quelli illustrati in figura 3. Non elenchiamo caratteristiche e funzionalità di soluzioni consolidate nel Data management, vale a dire gli strumenti di Data virtualization e di Data quality e di Master data management (Mdm), questi ultimi disponibili anche in versione unidirezionale o analitica (dove i dati sono ‘puliti’ e riconciliati all’Mdm solo verso la fonte derivata), più economica di quella bidirezionale, dove i dati corretti sono rinviati alla fonte primaria. Né diremo dei vari tool di Etl o Elt (a seconda che la trasformazione dei dati avvenga prima o dopo il loro caricamento). Vogliamo invece citare gli strumenti di Business event processing e di text processing. I primi analizzano i flussi di attività (come l’andamento delle azioni, lo stato delle spedizioni o le comunicazioni machine-to-machine di un processo di lavorazione) per intercettare schemi o valori predefiniti e avviare allarmi o anche azioni di risposta automatica. Si servono delle tecnologie di Dbms streaming, Complex event processing (Cep) e Business activity monitoring (Bam). Il secondo, detto anche Natural language processing (Nlp), estrae invece dai file di testo contenuti e significati ed è in grado di correlarli tramite regole linguistiche e algoritmi di autoapprendimento.

Figura 2: Database di riferimento per la BI Fonte: Forrester Research

Figura 3: Componenti architetturali tipici della BIFonte: Forrester Research

Le fonti derivate al servizio della BI

Al livello delle Derived data sources si collocano quelle fonti secondarie, alimentate dalle fonti primarie tramite il livello di razionalizzazione di cui sopra, il cui scopo è di riconciliare, consolidare, sincronizzare e conservare quelli che, dopo i passaggi precedenti, si possono già chiamare elementi d’informazione. Lo scopo è di averne una visione unitaria, fedele e condivisa (la famosa ‘verità unica’ senza la quale la BI è inefficace) e renderli disponibili in modalità batch, real-time o accesso virtuale alle applicazioni di BI vere e proprie. I componenti di questo livello sono:

1. Staging area: di solito semplici copie fisiche delle tabelle Oltp per dati strutturati o semi-strutturati che servono a ridurre il carico sugli strumenti di estrazione e a poterle replicare in vista di ulteriori processi di analisi.

2. Operational data store (Ods): combinano più fonti e ne ottimizzano i dati per produrre report operativi in near-real-time. Possono però servire come staging area per processi di data quality o altre parti specifiche del percorso di sviluppo delle informazioni, o come database consolidato per applicazioni Oltp multiple.

3. Data warehouse (Dw): al contrario degli Ods, servono soprattutto per analisi storiche; raccolgono dati da tutta l’organizzazione aziendale e sono di regola la fonte cui attingere per le analisi basate su sequenze temporali.

4. Data mart (Dm): hanno funzioni analoghe ai Dw ma limitate a un’area di attività (finanza, marketing, produzione…) o a una linea di business. Mentre un Dw deve contenere dati di dettaglio un Dm può contenere solo dati aggregati, alleggerendo il Dw dei processi di aggregazione. Il Dm può essere separato dal Dw in modo fisico o virtuale, come subset di tabelle aggregate. In ogni caso bisogna che i Dm siano ‘conformi’, cioè tutti creati con le stesse logiche e gli stessi strumenti, in modo che i dati siano consistenti tra loro.

5. Cubi Olap: operano al di sopra dei Dw e dei Dm per fornire analisi rapide e mirate; possono essere anch’essi fisicamente separati dalle fonti usate (come per Ibm Cognos) o virtualizzati all’interno del Dw o della piattaforma di BI (come per Microstrategy).

Il livello semantico: semplificare per capire

Lo scopo di questo livello, che Forrester chiama di Analytical data virtualization, è di nascondere agli occhi di chi disegna i report e di chi se ne serve (che nelle soluzioni self-service avanzate possono essere la stessa persona) la complessità e talvolta la criticità delle tabelle dati. Si possono quindi dare ai dati definizioni chiare per gli utenti business; disegnare viste logiche che raggruppano per argomenti e materie più tabelle fisiche; introdurre metriche standard e familiari agli utenti e anche fornire query predefinite.

Poiché molte società dispongono di più d’una piattaforma di BI, Forrester raccomanda di:

• Scegliere un metadata repository (preferibilmente dotato di strumenti di Etl/Elt) come hub sul quale sincronizzare i metadati delle diverse piattaforme e applicazioni di BI. Per evitare conflitti sull’uso di tali metadati tra applicazioni concorrenti conviene che questi aderiscano agli standard d’interscambio, come lo Xml Metadata Interchange (Xmi) o il Common Warehouse Metamodel (Cwm). Bisogna anche che alle entità condivise più importanti, tipo i key master data e i metadati che fanno riferimento a dati-chiave, sia assegnata una scala di priorità.

• Creare un livello di virtualizzazione inferiore dove portare metadati, modelli e oggetti logici vari (query, metriche, aggregati…) in modo che i tool di BI vi si possano connettere eliminando la duplicazione dei metadati nel livello semantico.

• Sfruttare il livello così creato per avviare un programma di data governance, essendo la gestione dei metadati un punto chiave per definire e governare gli standard di qualità e le strutture dei master data.

Scenari d’uso e delivery: al servizio degli utenti

L’utilizzo della BI in un’impresa ha, come ovvio, finalità diverse a seconda del business e degli utenti e ciò si riflette sui processi e sulle tecnologie coinvolte. Le modalità d’uso sono parecchie e nello schema di dettaglio del modello Forrester (figura 4) il livello di Data Usage ne considera sette. Non ripeteremo cose note relative alle modalità più diffuse, come le differenze tra i report e le query ad hoc rispetto alle analisi Olap, né la funzione di sintesi dei ‘cruscotti’ (dashboard) basata su Kpi. Lo stesso vale per le Process analytics e l’Analytical performance management, che più che alla BI attengono alle soluzioni di Business process e business performance management. Altre modalità vanno invece citate:

1. Exploration and Discovery: costruire con tecnologia relazionale o multidimensionale un data model che copra tutti i tipi di dati rilevanti per il business di un’azienda è praticamente impossibile. Gli strumenti di esplorazione e scoperta permettono invece di guardare ai dati anche senza un data model e di esplorarli incrociandoli in ogni possibile dimensione e attributo potendo quindi scoprire relazioni inaspettate. Un caso particolare è l’Exploration e Discovery svolta in-memory, dove data model e report sono una cosa sola e cambiando il report, l’utente cambia il modello sottostante (micromodeling o in-line modeling).

2. Predictive analytics: le piattaforme e applicazioni di BI devono oggi avere strumenti per prevedere l’evoluzione degli eventi e valutare i pro e contro delle scelte. Questi tool sono dotati di funzionalità di data mining, statistica, simulazione, modellazione descrittiva e predittiva, text analysis e altro.

Lo stesso discorso vale per il livello di Data delivery (vedi ancora figura 4) i cui componenti di regola comprendono l’integrazione di servizi di BI nei processi e nelle applicazioni aziendali, un portale come punto d’accesso per i report, i dashboard e le query, vari tipi di alert e strumenti di collaborazione. Queste ultime due componenti si possono, anzi si devono, integrare nelle piattaforme di comunicazione con i terminali mobili, nelle intranet per la collaborazione aziendale ed eventualmente nelle reti sociali, mentre l’integrazione con le applicazioni d’ufficio dovrebbe potersi estendere alla posta elettronica (sarebbe utile ricevendo una mail da un cliente poter aprire il report a lui relativo). Un discorso a parte va fatto per le Actions: se al verificarsi di dati eventi o condizioni (trigger) oltre agli alert si attivano automaticamente azioni di risposta (tipo l’ok o il rifiuto di una nota spese) o l’avvio di procedure (tipo la spedizione di un ordine) si parla di BI prescrittiva.

Figura 4: Le differenti modalità d'uso identificate da ForresterFonte: Forrester Research

In conclusione, che fare?

In mancanza di un’architettura di riferimento, sviluppare una strategia di BI capace di dare le risposte necessarie al business e di prevedere le risorse per metterla in atto è un compito difficile per l’It. Per realizzare con successo il modello che abbiamo illustrato è necessario che i livelli architetturali siano concepiti in modo indipendente da processi, applicazioni, piattaforme e strumenti particolari, in modo da essere abbastanza flessibili per adattarsi a nuove tecnologie, tipo Hadoop o in-memory e cloud computing. D’altra parte, bisogna capire che situazioni contingenti, come necessità urgenti e prioritarie del business, possono comportare delle deviazioni dal modello.

La raccomandazione, come sempre nei grandi progetti, è di partire piccoli pensando in grande. Forrester propone un approccio in cinque punti: 1) fare un elenco delle priorità del business (non dell’It) che bisogna indirizzare; 2) metterle in ordine a seconda del grado di difficoltà, ricordando che il miglior punto di partenza sta nelle iniziative a basso impegno ma ad alta priorità; 3) scegliere quelle che si possono fare in rapporto al budget e alle risorse disponibili; 4) avviarne l’esecuzione con soluzioni di rapida delivery e breve ciclo di vita; 5) dedicare una parte (diciamo un quarto o un quinto) delle risorse e del tempo alle iniziative strategiche, come la costruzione di un nuovo Edw. Infine, non credere che una migrazione ai servizi cloud possa rimediare a una scarsità di skill e di esperienza. Una buona parte dell’elaborazione passerà certamente al cloud, ma per quanto si può capire del futuro, questo non potrà mai sostituire la BI tradizionale, specie in rapporto alle pratiche di data management. Nel comporre l’architettura di Bi il cloud va quindi visto non tanto come un diverso approccio quanto come un set di componenti e di strumenti complementare.