I vantaggi dell'integrazione continua per la Business Intelligence

In che modo il settore della Business Intelligence può trarre vantaggio dall'integrazione continua

In termini di settore, Business Intelligent (BI) è ancora un campo relativamente nuovo. Come molti settori basati sulla tecnologia, la BI è progredita nelle sue fasi iniziali con implementazioni soggette a processi ad hoc e successi ampiamente variabili. In passato, era normale che più progetti di BI implementati dalla stessa organizzazione adottassero approcci completamente diversi verso obiettivi molto simili. Negli ultimi anni, tuttavia, le organizzazioni lungimiranti hanno aumentato le proprie capacità di BI attraverso la centralizzazione delle conoscenze e delle competenze di BI. Con modelli come il "BI Competency Center" (BICC) e il "BI Center of Excellence" che stanno diventando sempre più diffusi, queste organizzazioni stanno ora definendo stack tecnologici di BI, set di strumenti, processi e tecniche per l'intera organizzazione per garantire il successo e massimizzare il ROI su nuove iniziative di BI. Stanno anche prendendo spunto dalle migliori pratiche nelle categorie collaterali, in questo caso l'industria del software.

Una best practice che non è stata ancora riconosciuta dalla comunità BI è quella dell'Integrazione Continua (CI). Nel campo dello sviluppo software, CI è il processo mediante il quale una base di codice software viene creata automaticamente e testata a intervalli frequenti nell'ambiente di sviluppo. In un tipico progetto software abilitato per CI, un "build server" monitora il repository del codice sorgente del progetto e, quando vengono rilevate modifiche, estrae una copia pulita del sorgente, esegue una ricostruzione completa, esegue tutti i test di regressione e notifica in modo proattivo lo sviluppo squadra di eventuali fallimenti. Ogni ciclo1 completamente riuscito produce un set di file binari installabili per il prodotto software.

Questa frequente integrazione automatizzata rileva rapidamente eventuali errori introdotti nel sistema (spesso entro pochi minuti dalla loro introduzione) e rende molto più facile vedere chi ha introdotto l'errore e quando. Difetti e incompatibilità sono invariabilmente più economici da correggere quando vengono rilevati entro pochi minuti dalla loro introduzione (specialmente se non escono mai dall'ambiente di sviluppo).

I principi fondamentali dell'integrazione continua (CI)

• Processi di compilazione e test ripetibili e automatizzati.
• Questi processi di compilazione e test automatizzati vengono eseguiti frequentemente in modo che i problemi di integrazione vengano rilevati in anticipo.
• Cicli frequenti e automatizzati forniscono avvisi precoci per artefatti rotti/incompatibili.
• Convalida e test quasi immediati di tutte le modifiche al sistema.

Non c'è dubbio che la pratica della CI sia diventata uno strumento inestimabile nell'arsenale della moderna organizzazione di sviluppo software. CI migliora sia la qualità che lo slancio dei team di sviluppo software. I team di sviluppo esperti che hanno abbracciato il concetto di CI non possono immaginare di intraprendere alcun progetto software di grandi dimensioni senza di esso.

Anche il settore della BI potrebbe trarre vantaggio dalla pratica dell'integrazione continua?

Assolutamente. Nei prossimi anni, la pratica della CI sarà riconosciuta per il suo enorme potenziale quando applicata ai moderni ambienti di sviluppo della BI. Gli ecosistemi di BI sono intrinsecamente complessi (vedi figura 1). Sono spesso costituiti da molte parti mobili, con molte interdipendenze. Ad esempio, un tipico ecosistema di BI può contenere:

• Più origini dati upstream.
• I processi ETL estraggono, puliscono e caricano periodicamente i dati da ciascuna di queste origini upstream in data mart o data warehouse.
• Molti prodotti BI aggiungono uno strato di "modello" sopra questi mercati o magazzini.
• Gli autori BI professionisti creano contenuti BI rispetto a questo livello del modello (ad es. report).

Come possono attestare i professionisti BI esperti, piccoli cambiamenti in uno qualsiasi di questi livelli possono diffondersi in tutto il sistema generale, creando errori o inefficienze nei risultati BI risultanti. A seconda di dove si trova il team di BI in un ciclo di rilascio, questi errori o inefficienze possono passare inosservati per giorni, settimane o addirittura mesi.

Ecco alcuni esempi reali:

• Una modifica apparentemente innocua a livello del modello provoca modifiche impreviste ai numeri di un report che non viene modificato da mesi. Queste modifiche riducono anche le prestazioni dello stesso report (una condizione ancora più difficile da quantificare e rilevare manualmente).
• Una modifica in una vista in un DB provoca un notevole aumento dei tempi di esecuzione dei report.
• Un modellatore rinomina o elimina una colonna da cui dipende un report.
• Un autore di report tenta di ottimizzare un report, ma il nuovo report non produce risultati corretti quando vengono impostati parametri facoltativi.

Nella maggior parte degli ambienti di sviluppo BI, il test dei contenuti BI in fase di sviluppo viene spesso eseguito in modo molto manuale (ad esempio "esegui un report, controlla i numeri, verifica che siano corretti"). I team di BI tendono a concentrare questo test manuale sugli artefatti3 che stanno attivamente modificando, piuttosto che su quelli che non sono stati modificati di recente. Questa tendenza si presta a problemi non rilevati quando le modifiche a un livello inferiore del sistema iniziano a propagarsi verso l'alto e interessano molti artefatti BI.

La maggior parte delle organizzazioni fornirà periodicamente le linee di base del contenuto BI da un ambiente di sviluppo a un ambiente di test o di assicurazione della qualità (QA), dove saranno sottoposte a test più formali da parte di professionisti del QA. A seconda dell'accuratezza del team QA, qui possono essere rilevati difetti o degradi delle prestazioni, ma a questo punto il costo per correggere questi problemi è aumentato considerevolmente. Una volta che un difetto è uscito dall'ambiente di sviluppo (ad esempio in un ambiente QA), diventa molto più costoso correggerlo. Il tipico flusso di lavoro per la correzione include la creazione di un ticket del problema che descrive come riprodurre il difetto (da parte del team QA), il triage del team BI di tutti i ticket del problema in sospeso (per decidere quali avere la priorità), la riproduzione del problema in fase di sviluppo, l'implementazione di un correzione e quindi ridistribuzione di un'altra linea di base al QA. Allo stesso modo, i difetti scoperti negli ambienti di produzione sono ancora più costosi da riparare rispetto a quelli scoperti nel QA.

Utilizzando i principi della CI, un team di sviluppo BI può rilevare in modo proattivo problemi come questi (spesso entro pochi minuti dalla modifica che li ha causati) e intraprendere azioni correttive mentre il contenuto BI è ancora nell'ambiente di sviluppo. Ciò significa che il costo complessivo della correzione è molto meno costoso.

Quindi, come possono essere applicati i principi di CI a un tipico progetto di Business Intelligence? Per alcuni esempi concreti, prenderemo in considerazione MotioCI™, uno strumento commerciale che consente l'integrazione continua per gli ambienti di sviluppo di Business Intelligence. MotioCI fornisce ai team di BI le seguenti funzionalità:

Integrazione continua per la Business Intelligence

1. Convalida automatizzata di tutti gli artefatti BI rispetto al modello corrispondente. Ciò garantisce che qualsiasi modifica al modello o al database non "rompa" gli artefatti BI esistenti.
2. Esecuzione automatizzata di casi di test per ogni artefatto. Questi casi di test possono essere utilizzati per garantire cose come:
   1. L'esecuzione del manufatto ha prodotto dati accurati
   2. L'esecuzione dell'artefatto ha prodotto la quantità di dati prevista
   3. Le prestazioni dell'artefatto sono accettabili (l'esecuzione viene completata nel tempo previsto)
3. Controllo di coerenza automatizzato. Per ogni manufatto:
   1. Verifica che aderisca al progetto stabilito o agli standard aziendali per cose come colori, caratteri, stili, immagini incorporate, ecc.
   2. Verifica che i nomi dei parametri siano coerenti tra gli artefatti
   3. Verificare che le relazioni di drill tra gli artefatti siano ancora valide
4. Tracciamento dei cambiamenti dell'ecosistema BI in modo che quando un test inizia a fallire, le parti interessate del progetto hanno una visione chiara di "chi ha cambiato cosa" dall'ultimo ciclo. Per esempio:
   1. Quali modelli sono stati modificati (e da chi?)
   2. Quali artefatti sono stati modificati (e da chi?)
   3. Sono state apportate modifiche allo schema delle origini dati pertinenti?
   4. Sono state apportate modifiche drastiche alle quantità di dati nelle relative fonti di dati?

Automatizzando il processo di cui sopra e facendolo eseguire a intervalli frequenti, il contenuto BI prodotto da un team sarà continuamente verificato per accuratezza, coerenza e prestazioni mentre è ancora nell'ambiente di sviluppo. Se il processo CI rileva un errore, notificherà in modo proattivo il problema al team BI, oltre a catalogare le modifiche all'ecosistema BI che si sono verificate dall'ultimo ciclo di successo. Questo metodo consente al team di BI di rilevare rapidamente i problemi creati dalle modifiche recenti, intraprendere azioni correttive e ridurre al minimo i costi.

Risultati netti dell'implementazione dell'integrazione continua per BI

1. Errori, inefficienze e violazioni degli standard vengono rilevati molto presto (di solito entro pochi minuti o ore dalla loro introduzione.
2. Il team di BI recupera innumerevoli ore altrimenti spese a testare manualmente tutti gli artefatti per assicurarsi che qualcosa non si sia rotto, risparmiando tempo, ma anche mantenendo lo slancio (consente agli autori di BI di concentrarsi su attività di sviluppo reali).
3. Il team di BI ottiene una maggiore visibilità su "chi sta cambiando cosa" nel proprio ecosistema di BI.
4. Gli output prodotti dal team di BI sono di qualità molto più elevata.
5. Le organizzazioni QA a monte possono concentrare le proprie energie su test più di alto livello (tutti i "frutti a bassa portata" vengono automaticamente filtrati prima che il contenuto della BI fosse promosso in QA).

In sintesi, man mano che l'industria della BI matura e stabilisce le migliori pratiche nel consolidamento, nella gestione e nell'applicazione della business intelligence, i BICC emergenti dovrebbero esaminare e sfruttare le lezioni apprese nelle categorie collaterali, in particolare nell'industria del software. CI non è solo una best practice per l'industria del software, ma si sta anche evolvendo in una procedura operativa standard. Con l'adozione di pratiche comprovate come la CI, i BICC continueranno a maturare come disciplina di core business non solo migliorando il throughput di un team di BI (fondamentale per la scalabilità), ma anche aumentando la qualità dei suoi risultati. Questo duplice impatto rappresenta un balzo in avanti nelle prestazioni BICC e sarà presto un pilastro per i moderni ambienti di BI.

1 Un ciclo di successo è quello in cui nessun test fallisce.
2 Il documento originale di Martin Fowler che descrive l'integrazione continua è stato pubblicato nel settembre del 2000.