Le soluzioni di business intelligence sono, in ultima analisi, un insieme organizzato di applicazioni che, operando su alcune serie di dati, ricavano ed evidenziano le informazioni che vogliamo avere. È chiaro quindi che la loro efficacia dipende da come i dati sottostanti sono strutturati e organizzati, cioè dalla loro architettura. Un’architettura dati funzionale alla soluzione di BI ne migliora prestazioni, flessibilità e scalabilità (aiutando quindi ad accelerarne il Roi), così come le può frenare in caso contrario. Purtroppo, però, non esiste un’architettura dati ‘ideale’ per la BI. Ognuna ha dei pro e contro che possono assumere diverso peso a seconda del tipo di analisi di cui si necessita. Per impostare un progetto di BI bisogna quindi prima definire i requirement analitici necessari e poi studiare l’architettura dati che meglio vi può rispondere.
I fattori da considerare sono parecchi. Oltre ovviamente al budget disponibile, si deve tener conto degli aspetti di sicurezza, governabilità, affidabilità (se la BI serve a prendere decisioni operative deve avere la disponibilità delle applicazioni business), compliance e corrispondenza agli standard It aziendali. Vi sono però due elementi determinanti che riguardano l’impresa e il suo business: l’eventuale presenza di esigenze informative separate oppure sovrapposte e il tipo di decisioni cui il progetto è indirizzato.
Riguardo al primo punto si tratta di verificare se vi siano aree (linee di business, regioni geografiche…) che operino in modo autonomo, e quindi possano o debbano avere esigenze di analisi e reporting ad hoc, e di verificare se vi siano processi di business che coinvolgano più dipartimenti e comportino quindi la condivisione di analisi e report. In certi processi (tipo il budgeting, il risk management e altri) la condivisione è la norma, ma ogni azienda ha le sue regole. Conoscerle serve a capire se consolidando le basi dati si avrà efficienza per le applicazioni analitiche o se ciò, nel caso di numerose analisi concorrenti sugli stessi dati, non diventerà un freno.
Sul secondo punto, è chiaro che a un top manager che deve decidere su investimenti, budget e strategie di mercato, occorrono rapporti basati su serie storiche rilevanti e con tavole e grafici capaci di evidenziarne le relazioni. All’opposto, chi deve prendere molte decisioni operative al giorno ha bisogno di analisi semplici, basate su pochi dati essenziali e soprattutto tempestive. Nella tabella di figura 1, Forrester mette in rapporto le caratteristiche di una soluzione di BI con il tipo di supporto, strategico, tattico o operativo, che è chiamata soddisfare.
Figura 1 – Tipical Enterprise Decision Types
(cliccare sull’immagine per visualizzarla correttamente)
Quattro architetture di riferimento
Vi sono molti modi in cui i dati destinati ad alimentare le applicazioni analitiche si possono organizzare e qui analizziamo brevemente i pro e contro di quattro diverse architetture. Nel valutare il peso relativo di questi aspetti in funzione dei requirement aziendali bisogna però tener presente che non è detto che ci si debba per forza concentrare su una sola architettura escludendo le altre. Può darsi che un approccio ibrido, che combini capacità e caratteristiche di più di un modello sia quello più adatto alla singola realtà.
Data mart distribuiti – È l’approccio più facile e anche più economico nel breve termine. Ogni dipartimento si costruisce il suo parco-dati estraendo dai sistemi aziendali solo ciò che serve alle analisi di cui ha bisogno. I problemi di riconciliare e consolidare le diverse forme che uno stesso dato può avere presso i diversi comparti non esistono o sono ridotti al minimo. Ciò significa che un progetto può partire in breve tempo (non si devono mettere d’accordo stakeholder diversi) e se si accetta che ogni linea di business abbia la propria ‘verità’, non si perde tempo e fatica per integrare i dati. Inoltre, poiché ogni funzione utente paga per il suo data mart che usa secondo le sue regole, si risparmiano all’It i problemi di attribuzione dei costi. Il difetto è uno, ma fondamentale: è un approccio che evidentemente non si presta a una visione del business e dell’impresa nel suo insieme. Ogni volta che occorre un’analisi che copra più funzioni o linee di business (una cosa che in un contesto di decisioni strategiche non si può evitare) occorre fare un’integrazione dati ad hoc. Inoltre, costruire e mantenere più data mart porta inevitabilmente a duplicazioni del lavoro dello staff It. Ciò significa che i bassi costi iniziali lievitano nel tempo e non si avranno economie di scala.
Enterprise data warehouse – L’approccio Edw è uno dei più importanti ai fini della BI in quanto offre una visione consolidata di tutti i dati rilevanti forniti da tutte le fonti che hanno valore per il business. L’Edw viene aggiornato regolarmente e i dati sono filtrati da sistemi d’estrazione, trasformazione e caricamento (Etl) che ne assicurano l’omogeneità. Infine, è ospitato su un server calibrato per i carichi di lavoro delle applicazioni analitiche, il che ne ottimizza le prestazioni. Pertanto, se è importante avere una visione globale del business l’Edw è la soluzione migliore, essendo in grado, se ben gestito, di fornire la famosa ‘versione unica della verità’. Purtroppo, realizzare un Edw è complicato e costoso, come lo sono i processi di Etl correlati. La manutenzione di un grande Edw non è facile e siccome le sue fonti dati persistono nei Dbms dei sistemi transazionali è difficile anche giustificare il costo delle risorse server e storage necessarie a mantenerle sull’Edw. La centralizzazione inoltre fa sì che sul’Edw convergano utenze e query concorrenti, con il risultato di possibili cadute delle prestazioni nel momento meno opportuno.
Struttura a stella (hub-and-spoke) – Quest’architettura, che prevede un Edw centrale che alimenta più data mart, offre notevoli vantaggi. I data mart sono tra loro conformi nel data model e si possono organizzare per aree d’analisi, collegate ai relativi dominii dati. Ciò permette d’avere elevate prestazioni ‘locali’ mantenendo la consistenza dati garantita dall’Edw. Il modello offre inoltre un’elevata agilità, in quanto le esigenze di nuove query richieste dal business si possono rapidamente soddisfare aggiungendo un nuovo ‘raggio’ alla stella senza toccare la struttura dell’Edw. La contropartita sta nella complessità e nei costi di ownership. Gli investimenti in Etl e data quality sono gli stessi di un Edw, con in più l’onere di mantenere le copie dei dati nei data mart. Occorrono risorse economiche e umane tali che non tutte le imprese se le possono permettere.
Data Federation – Quest’architettura, detta anche Eii (Enterprise information integration) prevede che le query siano direttamente applicate alle fonti dati tramite un middleware che provvede a instradarle sui sistemi-sorgente e a ricevere e aggregare le risposte di ritorno. Ciò consente di avere analisi in near-real-time, senza il ritardo dovuto allo scambio fisico dei dati associato all’Edw e ai data mart. Non occorrendo duplicare e mantenere dei repository dati, la Data federation garantisce analisi basate su dati correnti e rende più facile integrare dati di diverse fonti e formati. Il problema è che i Dbms delle applicazioni transazionali non sono adatti alle applicazioni analitiche (è per questo che esistono Edw e data mart). Quindi può darsi che la soluzione di BI risulti meno performante di quanto in teoria le sarebbe permesso dall’architettura. O addirittura che una query complessa, che chieda di collegare tabelle di diversi sistemi transazionali, ne rallenti l’esecuzione. Infine, non esistendo il filtro dell’Etl, qualità, consistenza e uniformità dei risultati delle analisi dipendono solo da quanto queste stesse doti sono presenti nei dati di partenza.
