Paolo Platter, CTO & Co-Founder di Agile Lab, spiega come sia necessario aggiornare la percezione del Data Engineering, occorrono conoscenza e consapevolezza.
Nell’immaginario collettivo, il Data Engineer è un individuo che elabora e rende i dati disponibili ai potenziali consumatori, con un ruolo tradizionalmente considerato focalizzato sul raggiungimento di un risultato molto pratico: far arrivare i dati – dove e quando servono.
Purtroppo, questa visione limitata ha portato a situazioni decisamente non ottimali, in azienda e non solo. Ma perché?
Il Data Engineering è una pratica, non (solo) un ruolo
In passato, molti professionisti hanno affrontato il problema di “estrarre valore dai dati” come una sfida tecnologica, o al massimo architetturale (DWH, Data Lake, ora Cloud-native SaaS based pipeline, etc.), ma ciò che è sempre mancata è la consapevolezza che il Data Engineering sia una pratica, che deve essere studiata, coltivata, sviluppata e diffusa.
L’attività del Data Engineering Engineer non consiste semplicemente nel trasferire i dati da un luogo a un altro o nell’eseguire una serie di query velocemente (grazie a qualche aiuto tecnologico), ma nel “supportare” i data scientist. Data Engineering, come dice la parola stessa, significa ingegnerizzare la pratica di gestione dei dati.
Mi piace usare il parallelismo con il Software Engineering che, dopo tanti anni, è entrato in una nuova era in cui la scrittura del codice è andata ben oltre i modelli di progettazione, adottando tecniche e pratiche di governance come, ad esempio, version control, test e integrazione, monitoraggio, documentazione e molto altro…
Data Engineering
Questa evoluzione non è stata guidata da ingegneri con troppo tempo libero, ma è avvenuta perché il settore ha compreso l’impatto significativo del software, nel tempo, su tutto e tutti. Un software malfunzionante, con scarsa automazione, non sicuro by design, difficile da mantenere o far evolvere ha un costo intrinseco devastante (chiamiamolo Debito Tecnico) per l’organizzazione che lo possiede (e, implicitamente, per chi lo usa e vi si affida).
Per mitigare questi rischi, tutti hanno cercato di ingegnerizzare la produzione di software per renderla sostenibile nel lungo periodo, consapevoli dell’aumento dei costi iniziali.
Quando si parla di Engineering, in un’ottica più ampia, si punta proprio a questo: progettare architetture dettagliate, adottare metodologie, processi, best practice e strumenti per realizzare prodotti e servizi affidabili, manutenibili, evolvibili e riutilizzabili che soddisfino i bisogni della nostra società.
Camminereste su un ponte di assi di legno più e più volte?
Alcune persone parlano di Data Engineering quando, invece, si riferiscono solo alla creazione di alcuni dati o all’implementazione di attività ETL/ELT. È come parlare di Bridge Engineering quando ci si riferisce a porre delle assi di legno tra due pilastri: qui le assi di legno sono i processi ETL/ELT che collegano i flussi di dati tra due sistemi. Si desidera sostenere in questo modo un’azienda presumibilmente data-driven?
Vi è una significativa disconnessione tra strategie di business e implementazioni tecniche: tonnellate di pianificazione tattica e soluzioni tecnologiche senza driver strategici.
È come se si volesse ristrutturare il sistema di viabilità di un paese iniziando a costruire strade o ponti di legno qua e là.
Data Engineering
È un metodo che non può funzionare. Servono un piano strategico, investimenti e, soprattutto, bisogna sapere cosa si sta facendo, coinvolgendo i migliori progettisti e costruttori per assicurarsi che i ponti non crollino dopo dieci anni. Non si può improvvisare, senza competenze adeguate, metodologia e un progetto dettagliato sperando di consegnare qualcosa di importanza strategica. Purtroppo, in molti cercano ancora di ottimizzare e salvare il presente senza preoccuparsi del futuro.
Da quando è giunta l’ondata DevOps, la situazione è molto cambiata, la consapevolezza è aumentata, ma siamo ancora lontani dall’avere uno standard qualitativo medio soddisfacente.
Parliamo di dati
I dati stanno diventando il sistema nervoso di ogni azienda indipendentemente dalle sue dimensioni, un elemento fondamentale per differenziarsi sul mercato in termini di offerta di servizi e supporto automatizzato alle decisioni aziendali.
Se si crede davvero che siano una colonna portante, bisogna trattarli con cura e in modo professionale; se li si considera davvero un bene, un servizio o un prodotto, bisogna ingegnerizzarli. Non esiste un prodotto di successo che non sia stato adeguatamente ingegnerizzato e l’azienda che li produce è stata senza dubbio super-ingegnerizzata per garantire bassi costi di produzione uniti ad assenza di difetti di fabbricazione ed elevata sostenibilità.
È fondamentale comprendere se i dati siano così critici per il business e comportarsi di conseguenza. Ingegnerizzare l’azienda ma non il prodotto, o viceversa, porta sicuramente a un fallimento nel mondo reale. È importante ingegnerizzare il ciclo di vita della produzione dei dati e i dati stessi come bene digitale, prodotto e servizio. I dati non hanno una connotazione univoca, anzi, sono naturalmente volubili. Si potrebbero definire come un sistema che deve rimanere in equilibrio perché, esattamente come nei sistemi quantistici, la realtà dei dati non è oggettiva, ma dipende dall’osservatore.
Noi vediamo un mondo in cui i migliori data engineer fanno davvero la differenza per il successo di un’iniziativa focalizzata sui dati. Eppure, tutto questo non è riconosciuto e ben identificato come nello sviluppo software, perché ancora in pochi sanno in che cosa consista una buona gestione dei dati.
Ma questo sta per cambiare perché, con l’ascesa del Data Mesh, i team responsabili dei dati dovranno cambiare marcia, quando i prodotti e la loro qualità saranno misurabili oggettivamente. L’aspetto rivoluzionario del Data Mesh consiste nel non limitarsi alla semplice tecnologia quando si parla di Data Engineering. Troppi data engineer si concentrano su strumenti e framework, ma in realtà sono le pratiche, i concetti e i modelli a contare anche di più: le tecnologie sono destinate a diventare obsolete, mentre le buone pratiche organizzative, metodologiche e ingegneristiche possono durare ben più a lungo.
Come ottenere un Data Engineering di successo. Best practice ed elementi fondamentali
Qualità del software
Il software che produce e gestisce i dati deve essere di alta qualità, manutenibile e con la possibilità di evolversi. Non c’è molta differenza tra il software che implementa una pipeline di dati e un microservizio in termini di standard di qualità! Modelli e principi di progettazione del software devono essere applicati anche allo sviluppo delle pipeline di dati.
Osservabilità dei dati
Test e monitoraggio devono essere applicati ai dati, così come al software. Testare i dati significa considerare l’ambiente e il contesto in cui vivono e vengono osservati. È bene ricordare che i dati offrono realtà diverse a seconda del momento e luogo in cui vengono valutati, quindi, è importante applicare i principi del monitoraggio continuo a tutte le fasi del ciclo di vita, dallo sviluppo al deployment, non solo all’ambiente di produzione.
Disaccoppiamento
È diventato un mantra nei sistemi software avere componenti ben disaccoppiati che siano testabili e riutilizzabili in modo indipendente. È essenziale utilizzare le stesse misure con diverse sfaccettature nelle piattaforme e nelle pipeline di dati e avere layer ben disaccoppiati a livello di piattaforma, specialmente per storage e calcolo.
Riproducibilità
Bisogna essere in grado di eseguire nuovamente le pipeline di dati in caso di crash, bug e altre situazioni critiche, senza generare effetti collaterali. Nel mondo del software, la gestione di eventuali problemi è fondamentale, proprio come (o anche di più) in quello dei dati (a causa della gravità). Ed è altrettanto importante progettare tutte le pipeline di dati sulla base dei principi di immutabilità e idempotenza.
Un aspetto ancora più critico è la riproducibilità dello stato degli ambienti e delle piattaforme sottostanti. Essere in grado di (ri)creare un ambiente di esecuzione senza o con il minimo sforzo “manuale” può davvero fare la differenza per test on-the-fly, test di non regressione su grandi quantità di dati, migrazioni di ambienti, aggiornamenti di piattaforme, accensione/simulazione di disaster recovery.
Versioning dei dati
I problemi di osservabilità e riproducibilità sono radicati nella capacità di muoversi agilmente sui dati da ambienti diversi così come da versioni differenti nello stesso ambiente. I dati, proprio come il software, devono essere distinti in versioni e portabili con il minimo sforzo da un ambiente all’altro.
Valutazione delle vulnerabilità
In generale, la responsabilità di un ingegnere è occuparsi della sicurezza. In questo caso, la protezione dei dati sta diventando sempre più importante e deve essere affrontata con una logica by-design. È essenziale cercare eventuali vulnerabilità nei dati, in modo automatico e strutturato, per scoprire informazioni sensibili prima che vengano pubblicati in modo accidentale.
Sicurezza dei dati a riposo
Devono esistere meccanismi di autenticazione e autorizzazione granulari per impedire l’accesso indesiderato ai dati (anche solo a una parte di essi). I dati devono essere protetti, e le pipeline di elaborazione sono proprio come qualsiasi altro consumatore/produttore, motivo per cui le policy devono essere applicate a storage e utenti (dell’applicazione), questo è anche il motivo per cui il disaccoppiamento è così importante.
Problemi con i dati
Come si documentano i problemi? Come ci si comporta quando si verifica un incidente che coinvolge i dati? L’ultima cosa che si desidera fare è “rattopparli”, e quello che si deve fare è sistemare le pipeline (applicazioni) che poi sistemeranno i dati.
In primo luogo, i problemi legati ai dati dovrebbero essere segnalati proprio come qualsiasi altro bug software. Devono essere documentati accuratamente, associandoli a tutte le informazioni contestuali estratte dai dati stessi, per chiarire quali sarebbero state le aspettative, cosa invece è accaduto, quali test sono stati preparati e perché non hanno intercettato il problema. È fondamentale identificare le azioni correttive a livello applicativo (potrebbero guidare la remediation automatico) così come i test aggiuntivi che devono essere implementati per risolvere il problema.
Un altro aspetto da considerare è la capacità di associare i problemi di dati alla versione specifica sia del software che dei dati stessi, responsabile del problema.
Revisione dei dati
Così come le revisioni del codice sono una buona pratica, un buon team di dati dovrebbe eseguire e documentare le diverse revisioni dei dati, da effettuare in diverse fasi di sviluppo per coprire molteplici aspetti come la completezza di documentazione e dati, la correttezza semantica e sintattica, le prestazioni, etc.
Documentazione e metadati
Documentazione e metadati dovrebbero seguire lo stesso ciclo di vita del codice e dei dati. Le policy di governance computazionale della piattaforma di dati dovrebbero impedire che nuove iniziative legate alle informazioni siano portate in produzione se non ben accoppiate con il giusto livello di documentazione e metadati. Questo aspetto nel Data Mesh diventerà una base per avere buoni prodotti di dati che siano veramente auto-descrittivi e comprensibili.
Prestazioni Performance
Prestazioni Performance e scalabilità sono due fattori ingegneristici critici in ogni ambiente basato su dati. In architetture complesse, ci possono essere centinaia di aspetti che hanno impatto sulla scalabilità, che dovrebbero essere principi di progettazione di ogni data engineer.
Quindi riassumendo il Data Engineering d’elite non si concentra solo sui dati, ma garantisce che siano di alta qualità, trovando e correggendo gli errori in modo semplice, con costi ridotti di manutenzione ed evoluzione, e semplici da utilizzare e comprendere. Si tratta di pratica, cultura dei dati, modelli di progettazione, ampia sensibilità su molti altri aspetti a cui si potrebbe già essere abituati quando “si tratta di software”. Il Data Engineering d’élite sarà l’unico fattore di successo di ogni iniziativa data-driven e per questo è fondamentale investire in formazione interna continua e attività di mentoring.
