Una delle mie sessione alla SQL Conference di settimana prossima è dedicata ad un tema molto importante e delicato, e secondo me assolutamente sottovalutato in massima parte, ossia l’ingegnerizzazione del processo di sviluppo di una soluzione di BI.
Secondo quanto riportato da Wikipedia (http://it.wikipedia.org/wiki/Ingegneria_del_software), “L'ingegneria del software identifica una formalizzazione del processo di realizzazione e di manutenzione di un sistema informativo.”
In questa sessione parleremo, quindi, di come poter definire una serie di regole nello sviluppo di una soluzioni di BI che ci permettano
- assicurare una qualità minima a prescindere da chi sviluppa la soluzione
- facilitare la crescita del team aggiungendo velocamente altre persone allo stesso, senza diminure la qualità tecnica della soluzione ed in modo che I nuovi arrivati sia immediatamente operativi e confermi agli stili ed alle scelte adottate
- evitare gli errori più comuni
- formalizzare delle soluzioni standard a problemi comuni
- facilitare la manutezione
Il tutto con l’obbiettivo di permettere a chi sviluppa tali soluzioni di concentrasi al più possibile sui problemi di business, non sui problemi tecnici. Le problematiche tecniche devono essere risolte in automatico, in modo efficiente tramite l’utlizzo di tool specifici, eventualmente creati ad-hoc.
Ovviamente, facendo in modo che la soluzione cosi costruita abbia comunque una flessibilità tale da potersi “adattare” in corsa alla nuove esigenze, senza portare la soluzione ad un semplice insieme di “patch” di praticamente impossibile manutenzione ed espansione.
Parleremo quindi delle regole a cui dobbiamo aderire per far si che lo sviluppo di una soluzione di BI complessa possa essere guidata in modo deterministico e predicibile, senza affidarsi solamente sul buon senso di chi la sviluppa e di chi la manutiene.
Regole con in SolidQ applichiamo ormai da ben 5 anni, con estremo successo, e che definiscono dei precisi binari su cui chi sviluppa si può muovere. Il tutto con l’obbiettivo di dargli quanta più libertà possibile. Ma sensa sfociare nell’anarchia.
Il risultato? Possiamo creare i package che si occupano di caricare una qualsiasi dimensione, SCD1, SCD2 o un insieme delle due possibilità in meno di un minuto, e possiamo controllare la qualità della soluzione prima di rilasciarla usando le tecniche di Unit Testing prese in prestito dallo sviluppo di applicazioni “classiche”.
Una sessione a tutto tondo, dalla definzione di Naming Convention, ai processi di ETL, dall’uso ragionato degli schemi all’automazione totale di alcune fasi dello sviluppo: questi sono i contenuti che, se sviluppate soluzioni di BI, non dovreste perdervi!
Ed in più, per i partecipanti, un utile regalo! 
PS
Questa è la versione ridotta della sessione che ho tenuto al PASS 2010 a Seattle. In quel caso avevo 6 ore a disposizione, qui ne ho solo 1….quindi per ovvie ragioni ho dovuto eliminare tutto ciò che non è specifico alla fase di “ingegnerizzazione”, dando quindi per scontato che chi assiterà ha già sviluppato soluzioni di BI e/o cmq ha confidenza con la materia e sa bene cosa cosa sono Fatti e Dimensioni, cos’è uno Star Schema ed un Snowflake Schema, quali sono i pro ed I contro di ognuno, e cosa sono e come si gestiscono le Slowly Changing Dimension.