Indice
Introduzione
Siamo nell’era dell’abbondanza informativa, eppure le aziende stanno morendo di sete di informazioni. Negli ultimi dieci anni, il mantra della “Data Driven Company” ha spinto i CTO di tutto il mondo a investire budget faraonici in infrastrutture di storage, data lake e pipeline ETL complesse. Il risultato? Abbiamo costruito cattedrali tecnologiche tecnicamente ineccepibili, ma strategicamente isolate.
Il vero collo di bottiglia oggi non è più la conservazione del dato, ma la sua fruibilità immediata. Se un decision maker deve attendere giorni (o settimane) perché un team di ingegneri traduca una necessità di business in una query SQL, abbiamo un fallimento architettonico.
Di questo abbiamo discusso con Enrico La Sala, Software Architect, AWS Community Builder e CTO di hiop, per capire come l’ingegneria dei dati debba cambiare rotta per sopravvivere alla velocità dell’intelligenza artificiale.
La “palude” dei dati: il costo dell’isolamento tecnico
Molte aziende hanno sostituito i vecchi silos dipartimentali con nuovi silos tecnologici. Abbiamo team di Data Engineering che parlano un linguaggio, team di Backend che ne parlano un altro, e stakeholder di business che restano alla finestra.
Secondo La Sala, il problema risiede nella frammentazione del moderno stack tecnologico. Oggi, per gestire un flusso di dati end-to-end, un’azienda deve spesso orchestrare strumenti diversi: uno per l’ingestione, uno per la trasformazione, uno per la qualità e un altro per la visualizzazione. Questa “catena di montaggio” crea una latenza strutturale. Ogni passaggio è un potenziale punto di rottura e, soprattutto, un muro che allontana chi costruisce il dato da chi lo deve usare per decidere.
Oltre il codice: l’approccio dichiarativo e Git-based
Una delle riflessioni più interessanti emerse dal confronto riguarda il modo in cui costruiamo le pipeline. Tradizionalmente, la gestione dei dati è stata vista come un’attività ancillare, spesso slegata dalle buone pratiche del software engineering.
L’evoluzione necessaria è il passaggio a una logica dichiarativa. Immaginate di poter definire l’intera infrastruttura dati – dalle sorgenti alle trasformazioni – attraverso file di configurazione (come YAML) versionati su Git. Questo non è solo un vezzo tecnico: significa portare il rigore del DevOps nel mondo dei dati. Permette di automatizzare i test, garantire la qualità e, soprattutto, rendere il sistema scalabile senza dover riscrivere codice ogni volta che il business cambia domanda.
Il fattore Legacy: AS400 e la realtà del mercato italiano
Mentre il mondo tech parla di Real-time Analytics e Cloud Native, i CTO italiani si scontrano quotidianamente con una realtà diversa. Gran parte del valore aziendale è ancora intrappolato in sistemi legacy, database on-premise o, non raramente, in architetture AS400 protette da VPN impenetrabili.
La sfida della modernizzazione non è “cancellare il passato”, ma creare layer di astrazione capaci di esporre questi dati in modo moderno. La Sala sottolinea come la vera competenza di un architetto oggi risieda nella capacità di creare connettività sicura ed efficiente tra questi mondi contrapposti, permettendo anche a un sistema vecchio di trent’anni di alimentare un modello di intelligenza artificiale all’avanguardia.
L’Intelligenza Artificiale richiede dati “lucidi”
L’esplosione della Generative AI ha cambiato le regole del gioco. Se prima l’utente finale del dato era un umano, oggi è sempre più spesso un AI Agent. Gli agenti autonomi hanno una fame insaziabile di dati, ma hanno bisogno di dati “parlanti” e, soprattutto, affidabili.
Se il layer semantico non è coerente, l’AI allucina. Non possiamo permetterci che un agente prenda decisioni basate su dati mal interpretati a causa di una pipeline mal configurata. Qui entra in gioco il concetto di Semantic Layer: un unico punto di verità dove le definizioni di business (cos’è un “fatturato”? cos’è un “cliente attivo”?) sono scritte una volta sola e sono accessibili sia agli umani che alle macchine.
Conclusioni: la sfida culturale per il CTO
Democratizzare il dato non è (solo) una scelta tecnologica, è una rivoluzione organizzativa. Il consiglio che emerge chiaramente per ogni Tech Leader è quello di smettere di misurare il successo del proprio team in base alla quantità di dati processati o alla complessità dello stack utilizzato.
La vera metrica del successo è la riduzione della latenza decisionale. Quanto tempo passa tra una domanda del CEO e una risposta data-driven? Se la risposta si misura in giorni, il problema non è il database: è l’architettura dei processi. Il futuro appartiene a chi saprà rendere il dato invisibile e onnipresente, trasformandolo da “progetto tecnico” a infrastruttura vitale, trasparente come l’elettricità.
