Essere agile in un progetto di Data Warehouse e Business Intelligence è possibile. Bisogna solo farsi guidare da una corretta metodologia.

1. Pensare «Agile» deve essere una metodologia, una filosofia
progettuale da applicare a tutto il ciclo di vita
del progetto.

2. INTRODUZIONE
Un progetto di Data Warehouse e Business Intelligence, è un lavoro lungo e complesso che richiede molti
mesi, spesso anni, sopratutto se parliamo di Enterprise Data Warehouse, per poter vedere la luce.
Anzi, penso che dovremmo smettere di chiamarlo progetto, ma dovremmo chiamarlo Processo. Però non è
un processo qualunque: è il processo che trasforma i dati in conoscenza, la conoscenza in previsione, la
previsione in azione. Applichiamo per fare un esempio, questo processo al mondo CRM (Customer
Relationship Management).
I dati grezzi dei clienti che giungono da sistemi diversi, si trasformano nella maggiore conoscenza dei clienti
e delle loro preferenze. Dalla conoscenza dei clienti possiamo prevedere le loro attitudini future. La
conoscenza del futuro ci permette di agire per cambiarlo o adattarlo. Questo è quello che ci permette il
processo di Data Warehouse e Business Intelligence.
Potete bene immaginare come questo processo sia indispensabile per ogni azienda che voglia competere
sul mercato globale. Purtroppo quello che spaventa di più gli investimenti in progetti di Data Warehouse è il
tempo. Infatti il fattore tempo è cruciale, e nella frenetica vita odierna, non si vuole attendere e si cercano
scorciatoie per avere i risultati attesi nel più breve tempo possibile. Ecco perchè si parla di Agile Data
Warehouse.
COSA È E COSA NON È L'AGILE DATA WAREHOUSE
Chiariamo subito cosa non dovrebbe essere.
Non deve essere un prodotto commerciale o un tool venduto da qualche società.
Non deve essere un Database o un diverso design della struttura tabellare logica o fisica.
Deve essere una metodologia, anzi una filosofia progettuale da applicare a tutto il ciclo di vita del processo.
Poichè mi piace essere pragmatico, provo subito a entrare nella realtà del processo.
2Micro ETL Foundation

3. Idealmente e, molto semplicemente,possiamo suddividere un processo di Data Warehouse in tre macrofasi
principali.
Sottolineo semplicemente,perchè dietro queste macrofasi, ci sono numerose fasi progettuali che
conosciamo bene (raccolta dei requisiti, analisi, programmazione,..).
 Build: Tutta l'attività di caricamento che porta alla fase di test.
 Test: Tutta l'attività di verifica e controllo che, prima e dopo il deploy in produzione, termina con
l'accettazione del sistema fatta dagli utenti finali.
 Maintenance and Iterative evolution: tutta l'attività inerente alla gestione e alla crescita del Data
Warehouse.
Per realizzare con successo un Processo di Agile Data Warehouse, dobbiamo essere «agile» in ognuna di
queste componenti.
3Micro ETL Foundation
Build Test
Maintenance
and Iterative
evolution

4. BUILD
Dobbiamo essere agile nella fase di costruzione. C'è poco da spiegare. Questa necessità si comprende
facilmente.Dobbiamo cercare di ridurre il più possibile i tempi del processo ETL che, storicamente, è la fase
più time-consuming del processo.
TEST
Dobbiamo essere agile nella fase di test e collaudo. Questa fase è critica perchè è la fase in cui gli utenti
finali iniziano a vedere i dati e iniziano a valutare il risultato ottenuto.
Questo significa essere rapidi nei tempi di risposta agli utenti finali. Attenzione. Non sto parlando dei tempi
di risposta dei report o delle query sul Data Warehouse (questo lo dò per scontato) ma nei tempi di risposta
alle cause di anomalie e problemi. Mi spiego meglio.
Come affermato all'inizio, dobbiamo essere agile in tutto il ciclo di vita del Data Warehouse. Molti
penseranno che essere agile significa solamente giungere al deply in produzione in tempi brevi.
In pratica riuscire ad accelerare il più possibile il processo ETL al fine di mettere a disposizione degli
utenti finali i Data Mart per le loro analisi. Ma questa è solo una parte della storia.
A mio avviso, il momento più importante in cui dobbiamo essere “agile” è DOPO avere concluso la parte di
build. Il vero successo del Data Warehouse dipenderà da quanto saremo veloci nel rispondere alle
domande degli utenti finali, alla loro contestazione dei dati visualizzati, nell’identificare i problemi del
processo di caricamento, nel sapere dove sono avvenuti e perché.
E dobbiamo essere agile nella risoluzione dei problemi.
MAINTENANCE AND ITERATIVE EVOLUTION
Infine dobbiamo essere agile nella manutenzione ed evoluzione iterativa. Questo vuol dire che dobbiamo
rispondere velocemente alle richieste di modifica del sistema e sopratutto della sua evoluzione. Non
dimentichiamo che è un processo.
4Micro ETL Foundation

5. Non dimentichiamo che sulla base di un Data Warehouse iniziale, poco per volta si aggiungeranno, nel
tempo, nuove dimensioni di analisi e nuovi Data Mart da analizzare. E molto probabilmente sarà
necessario aggiungere nuove informazioni alle Dimensioni e ai fatti già costruiti.
Spero che ora sia chiaro cosa vogliamo ottenere quando parliamo di agile Data Warehouse. Ma il punto
essenziale è come raggiungere questi obiettivi. Come detto precedentemente, non è necessario un
prodotto, ma solo una buona metodologia. Ecco alcuni consigli personali dettati dall'esperienza.
Possiamo agire su vari aspetti, molti dei quali sono già stati oggetto di riflessioni sul mio Blog o su
Slideshare.
AGILE NEL BUILD - NAMING CONVENTION
Non mi stancherò mai di sottolineare l’importanza di impostare una precisa naming convention per tutti gli
oggetti del progetto. Lo dobbiamo fare subito, prima di creare qualunque tipo di struttura informativa.
Questo ci permetterà di avere una visione chiara e una gestione semplificata di tutte le componenti logiche
e fisiche (tabelle, sequenze, viste, files, documentazione, ecc.) che costituiscono il Data Warehouse.
Non solo. Seguire una precisa naming convention ci permette di creare degli automatismi di
configurazione,creazione e controllo molto velocemente.
AGILE NEL BUILD – RIDUZIONE DELLA CATENA ELABORATIVA
Un altro punto da considerare è la filosofia di modellazione del Data Warehouse. Anzi, probabilmente è la
prima cosa da considerare. Non voglio entrare nello storico dibattito relativo all'approccio Inmon e
all'approccio Kimball.
Entrambi sono validi con i loro punti di forza e di debolezza.
5Micro ETL Foundation

6. Però se parliamo di "agile", per me la scelta dell'approccio Kimball è fondamentale. Tutto quello che mi
permette di ridurre la catena elaborativa e strutturale presente nel processo ETL è senza dubbio un fattore
importante.
Penso che avere un ODS (Operational Data Store), cioè in pratica una duplicazione storicizzata di quasi
tutte le strutture già presenti in Staging Area, prima delle strutture dedicate all'analisi, è una attività che
costa tempo e denaro.
AGILE NEL BUILD – SEMPLIFICAZIONE DEI TIPI
Un altro modo per essere “agile” è una conseguenza della regola generale di pensare sempre in modo
semplificato. Dobbiamo ridurre al minimo i tipi di dati (nel senso di database) presenti nel Data Warehouse.
Un RDBMS come Oracle, e lo stesso discorso vale per gli altri produttori, ha più di 30 tipi di dati diversi
(NUMBER di vario tipo, CHAR, VARCHAR, DATE, ecc).
Non possiamo pensare di avere questa varietà di tipi nel Data Warehouse. Troppe complicazioni nel loro
trattamento e conversione.
Provate a pensare ai flussi di alimentazione: tranne alcuni casi particolari, sono tutti files di testo.
A lunghezza fissa o con terminatore di colonna, sono sempre files che potete facilmente aprire con un
qualsiasi editor di testo. Il massimo della semplicità. Il mio consiglio è di mantenere quasi intatta questa
semplicità imponendo nel Data Warehouse solo due tipi di dato.
 Numerico – solo per dati di tipo importo, quantità, percentuale, ecc.
 Alfanumerico – per tutti gli altri dati.
Manteniamo il tipo di dato DATE solo per campi tecnici, tipo data di inserzione, ultimo aggiornamento,ecc.
Anche se nei sistemi alimentanti i dati che rappresentano dei codici, indicatori, flag, sono numerici,
manteniamoli alfanumerici nel Data Warehouse. Tutte i dati che rappresentano delle date, trasformiamoli
in alfanumerico e in formato standard YYYYMMDD.
6Micro ETL Foundation

7. AGILE NEL BUILD – SEQUENZIALITA’
Dobbiamo cercare di pensare, e nel 90% dei casi si può fare, che ogni componente del processo sia
collegata a quella successiva, e che la loro esecuzione sequenziale porti al caricamento finale del Data
Warehouse.
Intendiamoci, non sto dicendo che non è possibile il parallelismo, ma individuare quali componenti siano fra
loro completamente indipendenti al punto da poter girare in parallelo, non è un compito facile; senza
contare tutti i ragionamenti necessari alla loro sincronizzazione.
Inoltre il parallelismo richiede anche configurazioni hardware particolari e impostazioni del database
particolari per beneficiare effettivamente di un miglioramento delle performance che, parlo per esperienza,
non è affatto scontato.
Certamente, le tabelle dimensionali potrebbero essere caricate in parallelo (se non ci sono collegamenti
logici fra di loro) ,ma in ottica "agile" dobbiamo cercare di ragionare in modo semplice e sequenziale.
Non dimentichiamo che il processo ETL, per sua natura è fisiologicamente sequenziale. Non si può
caricare un Data Mart di livello 2 se prima non si sono caricati quelli di livello 1. Il Data Mart di livello 1 non
è caricabile se prima non si sono caricate le Dimensioni di analisi, che a loro volta, non si possono caricare
se non sono state caricate le tabelle di staging area, e così via.
AGILE NEL BUILD – RIDUZIONE DEI TOOL ESTERNI
E’ una scelta progettuale, dipendente da molti fattori, se e quale strumento utilizzare per l’implementazione
del Data Warehouse. Ogni Company ha le sue regole e, soprattutto un budget disponibile. Se avete molto
denaro a disposizione (e sopratutto un sacco di tempo nell'imparare a usarli) comprate pure i tool.
Se il vostro budget è scarso, il mio consiglio è quello di utilizzare il minor numero possibile di strumenti.
Spesso si tende a cercare strumenti specifici per fare lavori come quadrature, controlli di processo, controlli
di qualità, schedulazione, ecc.
7Micro ETL Foundation

8. Non dimentichiamo che ognuno di essi ha strutture proprie, che devono poi dialogare con tutte le altre,
aumentando la complessità dell’intero sistema.
La mia opinione è qualla di investire molto di più nell’avere una ottima conoscenza del linguaggio di
programmazione del Database ,un buon editor e un buona interfaccia di accesso al Database.
Questi tre elementi, da soli, ci faranno risparmiare molto tempo.
AGILE NEL TEST - CONFIGURATIONE E LOG
Per essere agile in questa fase, dobbiamo avere costruito un'architettura di controllo molto precisa. Ho già
scitto molto su come segnalare automaticamente le anomalie e avere il controllo dei moduli di un processo
ETL. Il mio consiglio è di avere sempre presente la magica coppia di strutture (tabelle): configurazione e
log. Al minimo:
Configurazione del caricamento della Staging Area - Log del caricamento della Staging Area
Configurazione del caricamento delle tabelle dimensionali - Log del caricamento tabelle dimensionali
Configurazione del caricamento delle tabelle dei fatti - Log del caricamento tabelle dei fatti.
AGILE NEL TEST – DATA LINEAGE
Avere una struttura di Data Lineage significa essere in grado di percorrere tutto il cammino della
informazione vista dall'utente finale, a ritroso fino all'origine del dato. Complicato, non sempre possibile
(vedi i dati calcolati) ma essenziale per dimostrare la correttezza del processo di caricamento.
Per dirla in parole povere, dobbiamo poter dimostrare che l'anomalia era già presente nel flusso
alimentante. Quindi sarà necessario utilizzare alcune tabelle di metadata per gestire il Data Lineage
8Micro ETL Foundation

9. AGILE NELLA MAINTENANCE AND ITERATIVE EVOLUTION - MODULARITÀ (E INCERTEZZA)
Per essere agile in questa fase dobbiamo essere modulari. E' l'incertezza che ci costringe a essere
modulari. Incertezza non nel senso che è ammesso essere incerti su come procedere, ma nel senso di
essere certi che qualcosa cambierà. Mi spiego meglio.
In un processo di Data Warehouse, è raro che tutte le logiche siano ben definite già dall’inizio. Non
bisogna necessariamente pensare a carenze di analisi (che spesso ci sono) o a errori nella raccolta dei
requisiti: il problema è che le logiche si evolvono man mano che si procede nel lavoro. Lo ritengo un
processo naturale, legato alla complessità del sistema, con cui si deve fare i conti senza drammi.
I sistemi alimentanti forniscono dei dati che non è detto siano precisamente quelli attesi dall’analisi, sia
come formato che come contenuto.
Questo spesso lo si scopre dopo, quando i dati iniziano ad essere analizzati (e quindi dopo averli caricati).
Gli utenti di business cambiano idea, a volte il business stesso cambia indirizzo. Si scopre, dopo,
che serviva anche un altro dato non previsto dall’analisi. Gli utenti vogliono fare il confronto anche con
altri dati che non erano stati previsti, ecc..
Esiste un detto molto eloquente relativo alle esigenze degli utenti finali. Il detto è: “I will know when I will
see”. Saprò quello che voglio quando lo vedrò. Assolutamente vero.
9Micro ETL Foundation

10. Questo ci obbliga a modificare continuamente i programmi per venire incontro alle nuove esigenze
progettuali. Logiche (e quindi programmi) da aggiungere, da modificare, da togliere; logiche che sono da
aggiungere ma, fra due mesi saranno da togliere, insomma, chiunque abbia un po’ di esperienza, avrà
sicuramente dovuto affrontare queste situazioni.
Per limitare le conseguenze dell’incertezza, è fondamentale il principio della modularità. Ecco perché a
ogni esigenza di business o di processo deve corrispondere una unica unità elaborativa, semplice o
complessa che sia.
Se devo caricare una tabella di Staging Area, ci deve essere uno più moduli che lo fanno, e fanno solo
quello. Se devo eseguire un controllo di quadratura fra 3 tabelle, deve esserci un modulo che lo fa, e fa
solo quello. Quando poi si scopre che le tabelle da controllare sono 4, aggiungerò nuovi moduli.
Se devo aggiungere il calcolo del prezzo di un prodotto finanziario derivato, ci deve essere un modulo che
lo fa; non importa se quel modulo lo mando a sviluppare a un programmatore che vive in un’altra parte del
mondo. L’importante è la immediatezza con cui lo inserisco nel sistema.
In questo modo non pretendo di eliminare l’incertezza, ma con la modularità la gestisco meglio.
AGILE NELLA MAINTENANCE AND ITERATIVE EVOLUTION – INDIPENDENZA DAL CONTESTO
L'ultimo consiglio è l’indipendenza dal contesto, cioè la netta separazione fra il business e l'infrastruttura.
La avete già vista in azione in alcuni miei articoli precedenti. Le semplici tecniche esposte di messaggistica
e controllo sono indipendenti dal contesto. Sono infrastruttura, non business. Che il business legato al Data
Warehouse sia in ambito finanziario, automotive, o per la grande distribuzione organizzata, non influenza
minimamente l’utilizzo di quelle tecniche.
Esse utilizzano tabelle di configurazione e di log assolutamente indipendenti dal contesto in cui lavorano.
Questo ci permette, per esempio, di aggiungere un nuovo Data Mart concentrandoci esclusivamente sul
business legato al Data Mart ,riutilizzando tutto il software indipenedente dal contesto per il monitoraggio
del processo.
10Micro ETL Foundation

11. 11Micro ETL Foundation
Build
Maintenance and
Iterative evolution
Test
Data Lineage
Modularità
Configuratione e log
Riduzione della catena
elaborativa
Naming Convention
Semplificazione dei tipi dato
Sequenzialità
Riduzione dei tool esterni
Indipendenza dal contesto
Agile
Agile
Agile

12. 12Micro ETL Foundation
CONCLUSIONE
Essere agile in un processo o progetto di Data Warehouse e Business Intelligence è possibile. Bisogna
solo farsi guidare da una corretta metodologia che ho cercato di riassumere nei punti descritti.
RIFERIMENTI
http://www.slideshare.net/jackbim/tecniche-di-naming-convention-parte-1
http://www.slideshare.net/jackbim/tecniche-di-naming-convention-parte-2
http://www.slideshare.net/jackbim/note-di-data-warehouse-e-business-intelligence-il-sistema-di-messaggistica-1
http://www.slideshare.net/jackbim/note-di-data-warehouse-e-business-intelligence-il-sistema-di-messaggistica-2
http://www.slideshare.net/jackbim/recipe-9-techniques-to-control-the-processing-units-in-the-etl-process