Il settore industriale dei dati negli anni scorsi ha investito milioni di dollari in moderni stack di dati, dando ai team di data scientist potenti data warehouse in cloud e strumenti all’avanguardia che, negli stessi anni, si sono ingranditi a volte senza una gestione adeguata.

Verrebbe da pensare che tutti questi investimenti siano basati sul successo e su un mercato sempre in positivo.
Purtroppo, in realtà, non è così, e oggi iniziano a scricchiolare una serie di elementi. In generale il mercato è ancora in crescita, si parla di circa il 20%, ma si cominciano a vedere i primi limiti.

Le notizie più recenti alimentano la percezione che ottenere insight affidabili sia molto più difficile di quanto sembri: c’è una specie di costo nascosto che ogni mese aumenta un po’ di più. Come un peso sulle spalle che aumenta costantemente.
Se qualche anno fa sembrava tutto bello e rapido da fare, oggi le cose si fanno più complesse, e il boom dell’AI aiuta a evidenziare proprio questi limiti.

Volendo fare un discorso semplicistico si direbbe che la colpa è dei software di gestione dati, oppure di bug isolati, o ancora del codice scadente e fatto di corsa. Ma non è così. Molti problemi delle piattaforme dati sono multifunzionali e spesso invisibili, e soprattutto non risiedono solo nei difetti del sistema di gestione.

Flussi di lavoro che diventano velocemente obsoleti, logica aziendale non focalizzata, sicurezza fragile e infine il fallimento strategico nel trasformare i dati passivi in un asset attivo: tutto questo genera problemi e costi difficili da risolvere.

È un problema che si può vedere dal vivo, ed effettivamente esiste. Aziende che due anni fa collezionavano dati oggi non hanno chiaro come usarli o come renderli profittevoli.

Questi problemi richiedono un nuovo approccio diagnostico per ogni leader, ingegnere e architetto dei dati, spostando l’attenzione dalla sola qualità del codice o dalla quantità di dati verso domande più importanti e urgenti su processi, architettura, sicurezza e strategia.

Insomma, bisogna vedere tutto dall’alto, ampliare la visione: dalla fase di lavorazione dei dati a come organizzare il lavoro del team, come impostare una sicurezza adeguata e come architettare bene l’infrastruttura, ma anche come preparare i dati di test e sfruttare al meglio il tempo a disposizione.

Quando i flussi di lavoro si trasformano in blocchi stradali: il debito procedurale

La fonte più comune e spesso sottovalutata di debito nascosto risiede nei processi umani che governano l’interazione delle persone con la piattaforma.

Queste difficoltà nell’accesso ai dati soffocano lo sviluppo del prodotto e quell’innovazione che nasce dalla pratica e dall’esperienza, proprio ciò che la tecnologia dovrebbe invece agevolare.

Un problema abbastanza comune per i data center riguarda quelle organizzazioni che investono massicciamente in tecnologie moderne ma non tengono allo stesso livello i processi legacy che ne controllano l’accesso o le procedure di sviluppo.
Un fatto che ho sentito raccontare da molte aziende alla scorsa RHC Conference, e di cui abbiamo parlato con Valentina Panichi di Gyala, che si occupa proprio di cyber resilience.

Oppure quelle aziende in cui, per richiedere l’accesso, esiste un sistema di ticketing, persino per l’ambiente di sviluppo che deve accedere ai dati di test, e quei ticket vengono risolti dopo giorni o settimane.

Oltre alla frustrazione di chi ci deve lavorare sopra, questo modo di fare diventa una vera e propria tassa, con costi aziendali quantificabili in termini di opportunità mancate e sforzi ingegneristici sprecati, aumentando i costi dello sviluppo e allungando il time to market del prodotto.

Quando la progettazione è superficiale: il debito architettonico

Ma non è sempre colpa dei clienti. Un’altra significativa fonte di problemi si trova nell’architettura stessa della piattaforma.

La mancanza di revisione della progettazione crea problemi che si propagano attraverso ogni pipeline e ogni analisi, portando a una sfiducia diffusa da parte dei clienti e a sforzi duplicati per aggirare gli ostacoli. Le cause più frequenti sono fondamentalmente tre.

La prima è la logica aziendale frammentata. Srujan Akula, CEO di The Modern Data Company, sostiene che uno dei difetti architettonici più persistenti e sottovalutati è la logica aziendale dispersa e incorporata nei posti sbagliati. Un modo elegante per dire che l’architettura software è slegata dalla struttura aziendale. Questi problemi si tenta di risolverli con dashboard, fogli di calcolo o pipeline fatte al volo, senza visibilità né controllo di versione: le famose pipeline fantasma che conosce solo chi le ha create.

Quando accade questo, vuol dire che la logica che guida le decisioni non è chiara né spiegata correttamente, e si finisce per creare soluzioni poco riutilizzabili o difficili da governare e mantenere. Se prendiamo il prodotto sui dati, vediamo che spesso dipende dalla definizione delle metriche dei dati stessi: quelle definizioni delle operazioni su quelli che si possono chiamare gli “atomi” e le “molecole” dei dati, ad esempio il numero di letture e scritture, gli eventuali aggregati e tutte quelle definizioni delle statistiche.

La seconda è lo “schema drift”, unito alla mancanza di comunicazione. Lo schema drift è un problema un po’ pernicioso: si tratta di una specie di debito persistente e silenzioso che si crea nel tempo o nell’uso e che può produrre danni molto seri. Immaginate un piccolo rallentamento che cresce insieme ai dati; quando il problema diventa evidente, il danno ormai è fatto.

La mancanza di comunicazione, invece, avviene quando si apportano modifiche allo schema senza coordinamento e senza avvisare nessuno, spesso per risolvere un problema specifico senza considerare l’impatto sul resto dei dati o su chi ne fa uso. Potete immaginare tutti coloro che usano quello schema e che vedono le loro procedure saltare dopo mesi o anni, magari senza errori chiari, perché – obiettivamente – chi se lo aspetta un cambio improvviso dello schema?

Per questo è importante mantenere la gestione dei dati centralizzata, ben governata e con una comunicazione tempestiva e costante tra tutti i team che lavorano sugli schemi. E, come si dice spesso, oltre alla documentazione di ciò che si è fatto, anche un piccolo commento sul perché delle modifiche aiuta tantissimo.

La terza riguarda i modelli dati rigidi. Pensare che modelli e schemi debbano rimanere intoccabili appare oggi un po’ anacronistico, anche se non tutti la pensano così. Modelli di dati rigidi, incapaci di scalare per i casi d’uso in tempo reale, e con elaborazioni lente, portano a costi operativi elevati.
Con le tecnologie odierne, poi, è proprio una idea da fondamentalista più che da architetto.

È fondamentale evitare di mantenere i modelli rigidi fin dall’inizio, negando qualsiasi iniziativa di modernizzazione, se non altro per evitare colli di bottiglia e difficoltà nella scalabilità: sono problemi che mettono a rischio il prodotto.

Buchi di sicurezza e infrastruttura obsoleta: il debito fondamentale

Anche una piattaforma ben progettata e con processi perfetti può diventare un incubo se la sicurezza non è adeguata o se l’infrastruttura tecnologica è obsoleta. Questo debito fondazionale spesso passa inosservato perché viene considerato “infrastruttura noiosa”, eppure rappresenta un singolo punto di fallimento per l’intero ecosistema dati.

L’accesso alla piattaforma deve sempre essere al passo con i tempi: affidarsi a credenziali protette solo da password, oggi, non è più una garanzia di sicurezza. Discorso analogo, che coinvolge soprattutto i data center, riguarda il mancato aggiornamento delle piattaforme alle ultime tecnologie e versioni, in particolare per quei data center che lavorano molto con l’AI.

Quando il tuo asset maggiore diventa una passività: il debito strategico

Tutti questi debiti procedurali, architettonici e fondamentali culminano nel problema più pericoloso di tutti: il debito strategico. Un problema che capita di osservare di persona.

I costi del mantenere i dati si sono alzati, così come i costi delle piattaforme. Collezionare dati che poi non vengono usati è una spesa che rischia di diventare più alta dei guadagni. È un fallimento della visione strategica del business, e una lettura sbagliata di quale uso dei dati possa essere realmente profittevole.

Questo dipende anche dal fatto che, fino a poco tempo fa, il business dei dati era in fortissima crescita e c’era un grande entusiasmo nei mercati. Oggi le posizioni si stanno stabilizzando, favorendo chi ha saputo mantenere le infrastrutture al passo con la tecnologia e con il business che su quei dati si basa.

Modernizzare la mentalità, non solo la tecnologia

Se ho descritto in maniera sufficientemente chiara i problemi nascosti di queste piattaforme, avrete visto che, come in tante altre situazioni, costi e problemi vanno a braccetto. Nel mondo dei dati i problemi sono sfaccettati e si manifestano sia nei processi umani sia nell’architettura della piattaforma, negli schemi e nelle comunicazioni, fino ad arrivare alla strategia aziendale.

Per prevenirli, Mayank Bhola, co-fondatore e Head of Products di LambdaTest, sottolinea l’importanza di adottare una mentalità di gestione del prodotto applicata ai dati stessi. In pratica i dati vanno trattati come un prodotto a sé stante, con un proprietario dedicato, un versioning chiaro, API documentate per l’accesso e una progettazione pensata per servire le esigenze di chi quei dati li consuma.
Molto diverso da quello che, ad esempio, facevo 15 anni fa, in cui i dati erano “un accessorio” del sistema, e non un asset.

Questo approccio “data as a product” riallinea le priorità dell’organizzazione, spingendo i team a costruire prodotti dati affidabili, facili da trovare e da usare, e aiutando a prevenire le cause profonde dei problemi descritti, sia sul piano architettonico sia su quello strategico.

In definitiva, la sfida non è semplicemente modernizzare uno stack tecnologico, ma modernizzare una mentalità, assicurando che la piattaforma possa adattarsi e prosperare di fronte all’innovazione futura.

Oggi tenere i dati pronti all’uso non significa soltanto salvarli in uno storage evoluto: sono dati dall’utilizzo sfaccettato, che spesso vanno a risolvere problemi che ieri nemmeno esistevano.