Come fare ETL con strumenti di data governance

La familiarità con i sistemi legacy e la resistenza al cambiamento possono anche ostacolare l'adozione di nuove metodologie, limitando la capacità dell'azienda di evolvere e di sfruttare appieno le opportunità offerte dal progresso. Inoltre, con le crescenti esigenze di data governance - tra le priorità strategiche per il 2025 secondo Forrester, Gartner®, IDC e Capgemini (fonte: Business Wire) - diventa fondamentale per le aziende non solo adottare nuove tecnologie, ma anche implementare strutture di data governance solide che assicurino un utilizzo responsabile e strategico di tali innovazioni.

Anche alcuni dei nostri clienti stanno affrontando la sfida. Uno, in particolare, che prenderemo ad esempio per questo case study, ha investito in nuovi strumenti con l'obiettivo di migliorare l'efficienza e la qualità dei propri report, ma a causa di paradigmi di sviluppo obsoleti e quindi tempistiche di rilascio che vanno a rilento, è ancora vincolato al sistema legacy, che produce dei CSV cruciali per la generazione dei report tramite Excel.

In questo conteso, abbiamo accolto la sfida di accompagnare il cliente in una transizione graduale dai sistemi legacy alle nuove tecnologie. Per farlo, ci siamo impegnati a realizzare una soluzione ibrida temporanea che permetta di integrare i nuovi strumenti senza stravolgere i processi e le abitudini degli utenti finali. Questo approccio "ponte" consente di avviare la modernizzazione in modo controllato, minimizzando l'impatto sui flussi di lavoro esistenti e favorendo l'accettazione delle nuove tecnologie da parte degli utenti. 

Invece di attendere il completo sviluppo delle funzionalità di reporting dei nuovi strumenti, ci siamo posti l'obiettivo di abilitare il cliente alla generazione degli stessi CSV prodotti dal sistema legacy, consentendogli di continuare a utilizzare Excel per l'analisi dei dati. 
Per fare questo, abbiamo optato per la creazione di una soluzione dinamica, facile da utilizzare e non soggetta a errori umani, in attesa che i nuovi strumenti e le nuove implementazioni raggiungessero la piena maturità.

Questo approccio presenta delle difficoltà: i nuovi strumenti non sono progettati per questo scopo specifico, e ci troviamo a dover adottare “soluzioni creative”, con un conseguente dispendio di tempo e risorse. Tuttavia, questa sfida rappresenta anche un'opportunità: ci spinge a esplorare a fondo le potenzialità dei nuovi strumenti, a ideare soluzioni innovative e a sviluppare competenze preziose per il futuro.
 

Il Contesto

 

Quando un'azienda intraprende un processo di modernizzazione dei propri strumenti, con impatto diretto sulle aree business interne, adottare un approccio agile diventa fondamentale: anziché attendere il completamento dell'intero progetto di modernizzazione, l'approccio agile consente di rilasciare nuove funzionalità o report in modo incrementale. Questo permette alle aree business di beneficiare rapidamente dei vantaggi dei nuovi strumenti, migliorando l'efficienza e la qualità delle analisi.

Al contrario, un approccio tradizionale, basato su un lungo ciclo di sviluppo con un unico rilascio finale, può comportare diversi svantaggi, che elenchiamo di seguito.

• Ritardi nell'ottenere benefici. Le aree business devono attendere il completamento dell'intero progetto prima di poter utilizzare i nuovi strumenti e le nuove funzionalità, ritardando l'ottenimento di miglioramenti nell'efficienza e nella qualità delle analisi.
• Maggiore difficoltà nell'adattarsi ai cambiamenti. Le esigenze di business possono evolvere durante il lungo periodo di sviluppo. Un rilascio finale unico rischia di non essere più allineato alle nuove necessità, con conseguente frustrazione e necessità di ulteriori modifiche.
• Aumento dei rischi. Un singolo rilascio "big bang" aumenta il rischio di errori e malfunzionamenti, con un impatto potenzialmente elevato su tutte le aree business coinvolte.
• Mancanza di feedback precoce. L'assenza di rilasci intermedi impedisce di raccogliere feedback dagli utenti finali durante lo sviluppo, aumentando il rischio di sviluppare soluzioni non perfettamente allineate alle loro esigenze.
• Demotivazione. L'attesa prolungata per l'utilizzo dei nuovi strumenti può generare demotivazione e resistenza al cambiamento da parte degli utenti finali, nonchè dubbi sull'effettivo valore aggiunto dato dall'investimento.

In particolare, la demotivazione ha portato il nostro cliente a ritenere necessaria una soluzione ibrida temporanea. Dopo un lungo periodo di attesa, il business aziendale desiderava vedere i nuovi strumenti integrati nell'ecosistema e funzionanti, li voleva in grado di generare valore con un ROI (un ritorno  sull'investimento) misurabile. Questa impazienza, unita alla volontà di ottenere risultati concreti nel breve termine, ha spinto il cliente a richiedere una soluzione che consentisse di utilizzare i nuovi strumenti in modo pratico e immediato, anche se questo comportava uscire dallo “scope” per cui tali strumenti erano pensati.

Il Problema

Scendiamo, ora, nel dettaglio. Attualmente, nella soluzione “legacy”, il nostro cliente si avvale di un portale web della suite SAS per la generazione di report. Attraverso questo portale, ciascun analista può definire una serie di parametri dinamici, come la lista di campi, per cui vuole raggruppare i dati, e una serie di range di date per cui vuole filtrare.

Sulla base di questi parametri, il sistema SAS elabora i dati provenienti da una tabella, applica i filtri sulle date, le aggregazioni sui campi indicati e calcola una serie di circa 100 campi aggregazioni fissi (KPI come somme, count, medie). Infine, il portale genera quattro file CSV:

• tre di questi file CSV contengono i dat filtrati e raggruppati, con i nuovi campi calcolati;
• il quarto file CSV contiene i metadati, le informazioni inserite nel portale dall'analista, ovverosia gli intervalli di date e l'elenco delle colonne utilizzate per il raggruppamento, più il numero di righe esportate in ciascuno dei tre file CSV contenenti i dati.

I quattro file CSV vengono depositati, sempre dal portale SAS, su una share di rete da cui Excel li legge e, tramite una serie di macro, produce il report finale.

Questa soluzione "legacy" basata su SAS ed Excel è destinata ad essere sostituita da una nuova architettura che prevede l'utilizzo di Denodo e Tableau.

• Denodo si occuperà della preparazione dei dati non aggregati a partire dai dati provenienti da diverse sorgenti.
• Tableau fornirà gli strumenti per l'aggregazione dinamica dei dati e la creazione di report interattivi e personalizzabili.

Tuttavia, al momento, la migrazione verso questa nuova architettura non è ancora stata completata. Denodo e Tableau, sebbene già presenti nell'ecosistema aziendale, non sono ancora in grado di replicare completamente le funzionalità della soluzione “legacy” basata su SAS: in Denodo è stata implementata, in ambiente di “sviluppo”, la vista datamart che deve alimentare questa logica, ma nulla di più. Per venire incontro alle esigenze del business, il team IT sta dedicando un notevole sforzo alla progettazione di una soluzione ibrida temporanea, sempre in ambiente di sviluppo. L'obiettivo è replicare il processo “legacy” utilizzando Denodo, e le componenti della piattaforma, per generare i quattro file CSV necessari ad alimentare il report Excel.

Tuttavia, questo sforzo si è scontrato con diverse difficoltà, legate principalmente all'elevato grado di personalizzazione richiesto.

• Personalizzazione dei CSV. Ogni analista (in totale 21) deve poter generare i quattro CSV con colonne di raggruppamento e intervalli di date specifici che possono variare ad ogni esecuzione. Le colonne di raggruppamento possono essere da una a nove, scelte tra i circa 200 campi della vista datamart.
• Struttura dei CSV. I quattro CSV devono avere una struttura ben definita per poter essere processati da Excel
• Nomenclatura dei file. I file CSV devono essere nominati in modo univoco per ciascun analista, seguendo una convenzione predefinita.
• Deposito dei file. I file CSV devono essere depositati in una cartella di rete condivisa, accessibile agli analisti e alla connessione da Excel.

Lo sviluppo della soluzione ibrida è ulteriormente complicato dalla natura delle query necessarie per estrarre i dati aggregati destinati ai tre file CSV, che richiedono, a seconda del job, due o tre join della stessa vista con se stessa, aumentando la complessità dello sviluppo e il carico computazionale.

Questi requisiti di personalizzazione hanno reso complessa l'implementazione della soluzione ibrida con Denodo, richiedendo un elevato livello di configurazione e la gestione di numerose variabili.
 

Gli Obiettivi

Come si sarà ormai inteso, quello che si vuole ottenere è una soluzione temporanea ibrida per alimentare l'Excel tramite elaborazioni in Denodo, per perseguire diversi scopi.

In primis garantire l'utilizzo - e una buona usability - agli analisti fornendo a loro uno strumento intuitivo e facile da usare, che replichi la semplicità del sistema SAS, eliminando la necessità di scrivere query complesse e riducendo il rischio di errori.

In secondo luogo validare l'investimento in Denodo, dimostrando al business che Denodo è uno strumento versatile e potente, in grado di sostituire il sistema legacy SAS, avvalorando in tal modo l'investimento effettuato.

Infine, stimolare l'innovazione e incoraggiare gli sviluppatori a pensare in modo creativo per trovare soluzioni non convenzionali, che possono essere ottenute utilizzando gli strumenti a disposizione in modi nuovi e originali.
La soluzione ibrida così concepita non solo colma un gap temporaneo, ma rappresenta anche un'opportunità per sperimentare, innovare e creare valore aggiunto per l'intera organizzazione.
 

La Soluzione

Nella ricerca della soluzione temporanea ideale, abbiamo esplorato diverse strade, che però si sono rivelate inadatte a causa di due ostacoli principali:

• l'esigenza di elevata personalizzazione richiesta dagli analisti in termini di colonne di raggruppamento, intervalli di date, nomenclatura dei file e percorsi di salvataggio, che non si poteva gestire in modo efficiente.
• Il rischio di errori da parte degli analisti. Poiché alcune soluzioni avrebbero richiesto agli analisti di intervenire direttamente sul codice, sarebbe aumentata la probabilità di errori e questo avrebbe compromesso l'affidabilità del processo e la certificazione del dato prodotto.

Le soluzioni scartate perché rischiose per la data governance

Le  soluzioni che abbiamo inizialmente preso in esame sono state molte, ma ognuna presentava dei limiti che ci hanno dissuaso dal metterle in pratica. Vediamole brevemente.

• Query Salvate nel Data Catalog. Questa ipotesi consisteva nel salvare, tra le query del Denodo Data Catalog, un template di query di aggregazione per ogni analista e per ogni file CSV. In questo template, ciascun analista avrebbe dovuto modificare i campi di raggruppamento e gli intervalli di date direttamente nel codice. Questa soluzione è stata abbandonata per complessità e rischio di errori: gli analisti avrebbero dovuto modificare manualmente il codice SQL delle quattro query, con un elevato rischio di introdurre errori e un rischio altrettanto elevato di modifica della definizione delle metriche dei KPI. Così procedendo, non sarebbe stato possibile garantire l'integrità delle query e la correttezza dei calcoli.
• Aggregazione con Tableau. Questa soluzione prevedeva di estrarre i dati non aggregati da Denodo e importarli in Tableau, creando l'aggregazione direttamente in Tableau e poi esportando i risultati in formato CSV. Il limite di questa soluzione era dovuto a Tableau che, durante l'export, rinomina i campi sostituendo gli underscore con spazi, creando problemi di compatibilità con le macro Excel utilizzate dal cliente.
• Viste ad hoc su Denodo. Con questo approccio avremmo dovuto creare viste personalizzate per ogni analista, consentendo di modificare i campi di aggregazione e i filtri, per poi esportare i dati tramite una query sulla vista dal Denodo Data Catalog. In questo caso, avremmo dovuto creare un numero elevato di viste, con conseguente difficoltà di gestione e manutenzione, inoltre ci saremmo scontrati con le policy di sicurezza aziendali, che impediscono la modifica di oggetti in ambiente di produzione.

La soluzione adottata

Per rispondere alle esigenze di personalizzazione di ciascun analista e affrontare tutte le criticità che il problema presentava, abbiamo dunque implementato una soluzione articolata che prevede la creazione di una serie di oggetti dedicati per ciascuno degli analisti (ventuno analisti in totale). La soluzione si articola in questo modo.

Vista "Dummy" Personalizzata. Ogni analista dispone di una vista "dummy" in Denodo, che non espone dati reali, ma funge da contenitore per le informazioni specifiche dell'analista, ovvero i campi di aggregazione sui quali l'analista desidera aggregare i dati e gli intervalli di date per l'analisi.

Job di Aggregazione ed Export. Tre job (per ciascun analista) in Denodo Scheduler sono responsabili dell'elaborazione dei dati. Questi jobs leggono i parametri inseriti dall'analista nella sua vista “dummy” personalizzata, ovvero i campi di aggregazione e gli intervalli di date; leggono le metriche statiche, cioè i KPI calcolati, da un'ulteriore vista "dummy" condivisa tra tutti gli analisti, garantendo coerenza nei calcoli; eseguono le query di aggregazione, estraendo i dati dalla sorgente e applicando i filtri e i raggruppamenti specificati; salvano i risultati in tre file CSV, nominandoli secondo la convenzione stabilita e depositandoli nella cartella di rete condivisa corretta.

Job per il file CSV dei Metadati. Sempre per ciascun analista, un quarto job si occupa di generare il file CSV contenente i metadati dell'operazione: legge i nomi dei campi di aggregazione e gli intervalli di date dalla vista "dummy" dell'analista; legge il numero di righe esportate in ciascun file CSV di dati, accedendo alle informazioni di log di Denodo tramite una vista dedicata; genera il file CSV con i metadati, nominandolo e salvandolo secondo la convenzione definita.

Con questa soluzione, per poter produrre i propri file CSV, un analista deve solo eseguire la modifica della propria vista “dummy”, usando i nomi dei campi di aggregazione e i range di date, ed eseguire i quattro jobs in sequenza. 
 

I Risultati

Questa soluzione, sebbene sia complessa e non priva di punti critici, offre un vantaggio fondamentale: soddisfa appieno le esigenze di personalizzazione e di sicurezza del cliente. Ogni analista può generare autonomamente i report di cui ha bisogno, con la massima libertà nella scelta dei campi di aggregazione e degli intervalli di date. Il tutto avviene senza dover modificare il codice delle query, ma semplicemente aggiornando la propria vista "dummy" con i parametri desiderati.

Questo approccio garantisce:

• semplicità d'uso: gli analisti non devono effettuare modifiche particolari agli oggetti coinvolti nel processo, se non ai campi delle proprie viste “dummy”: per questa operazione non è necessario possedere competenze tecniche di scrittura di query SQL in quanto la modifica è effettuata tramite il Wizard grafico dell'interfaccia di sviluppo web di Denodo. Questo rende il processo intuitivo e accessibile a tutti.
• Affidabilità: l'eliminazione della modifica manuale del codice, in particolare delle metriche di aggregazione calcolate, riduce drasticamente il rischio di errori, garantendo la correttezza e la coerenza dei dati.
• Flessibilità: ogni analista può adattare i report alle proprie esigenze specifiche, senza dipendere da interventi esterni o configurazioni complesse.

In definitiva, abbiamo creato un sistema "a prova di errore" che coniuga la potenza di Denodo con la semplicità di utilizzo richiesta dagli analisti.

Raccomandazioni conclusive

Lo sviluppo di questa soluzione temporanea ha portato indubbi benefici, soddisfacendo le esigenze di diverse aree aziendali, in particolare rassicurando il business, dimostrando concretamente il valore dei nuovi strumenti e la loro capacità di generare risultati tangibili, ripristinando la fiducia nell'investimento effettuato. Ha permesso di colmare un gap temporaneo fornendo una soluzione immediata e funzionale in attesa del completamento della nuova architettura. Infine, è sicuramente stata utile per acquisire nuove competenze, permettendo al team IT di approfondire la conoscenza di Denodo e di sperimentare soluzioni innovative.

Tuttavia, è fondamentale sottolineare che questa soluzione ha una natura temporanea. La sua complessità di implementazione e manutenzione la rende inadatta come soluzione a lungo termine. In casi di questo genere è sempre cruciale proseguire e, se possibile, accelerare con la migrazione verso la nuova architettura - che nel caso appena illustrato si basa su Denodo e Tableau - che offrirà una piattaforma di reportistica più robusta, scalabile e facile da gestire.

È fondamentale coinvolgere attivamente gli attori in gioco - gli analisti nel nostro caso - nella progettazione della nuova soluzione e raccogliere i loro feedback e le loro richieste, per garantire che la nuova soluzione soddisfi appieno le loro esigenze, sia user-friendly e sia allineata ai loro processi di lavoro.

Come dimostrato dallo sviluppo della soluzione temporanea, l'approccio agile si rivela fondamentale per gestire la complessità e l'incertezza dei progetti di modernizzazione. Adottare questo paradigma permette di adattarsi rapidamente ai cambiamenti, ridurre i rischi e massimizzare il valore per il business.