Di tanto in tanto arriva un nuovo modo di fare le cose che cambia tutto. A volte si tratta di nuove tecnologie, infrastrutture e servizi che consentono di ottenere importanti benefici ma, in questo caso, è necessario uno sforzo collettivo da parte dei “tecnici” per promuovere il cambiamento e far comprendere quali siano i vantaggi che si possono ottenere. In altre situazioni, invece, è il mercato stesso a richiedere una nuova, più efficace ed efficiente soluzione per un problema che si trova ad affrontare e questo è senza dubbio un “motore del cambiamento” molto più potente.
Sono già passati 15 anni da quando Clive Humby affermò che “i dati sono il nuovo petrolio” intendendo, con questo, che il greggio non ha di per sé una grande utilità se preso singolarmente ma deve essere raffinato per ottenere benzina, gasolio, plastica, ecc. … e allo stesso modo anche i dati devono essere “lavorati” per creare valore. Le aziende che hanno compreso questa lezione hanno creato un intero ecosistema per i propri dati con strumenti di data management, processing, governance, ecc. … e si sono impegnate nel creare sistemi gestionali e decisionali basati sui dati, ovvero nel diventare “data-driven”, dimostrando così tutto il valore che questi sono in grado di generare. Ciò ha, inoltre, consentito di ottenere le risorse necessarie per lo sviluppo di tutte le tecnologie, gli standard e i servizi Big Data e Cloud che sono oggi ampiamente diffusi e conosciuti.
Questa prima fase si è concentrata sulla centralizzazione dei dati, partendo da una suddivisione nei cosiddetti “silos” per arrivare ad un’unica piattaforma (spesso sia logica che fisica), generalmente nota come “Data Lake”. Contestualmente, l’architettura di sistema diventava invece sempre più distribuita e si creavano soluzioni di Cloud “ibridi” (un mix di infrastrutture on-premise, servizi su Cloud privati e/o pubblici) e nuovi modelli di business in cui il software, le piattaforme e l’intera infrastruttura non venivano più acquistate o realizzate internamente dalle aziende ma “affittate” come servizi forniti da terzi, secondo il modello “as a Service” (abbreviato in aaS) che si è declinato in SaaS, PaaS e IaaS. Si è trattato, quindi, di un grande investimento per il miglioramento infrastrutturale a scapito di attenzione verso aspetti come la proprietà dei dati, la garanzia della qualità degli stessi, la governance scalabile, l’usabilità, la fiducia tra consumatore e produttore, la disponibilità e l’accessibilità dei dati: fattori chiave (e sono solo alcuni) che consentono agli utenti di trovare, comprendere e utilizzare con fiducia i dati in modo sicuro per creare valore aziendale.
Proprio questa mancanza nelle piattaforme monolitiche e nei Data Lake ha generato l’esigenza di un cambio di paradigma, che si è concretizzato con il Data Mesh. Quest’ultimo si può considerare allo stesso tempo rivoluzionario, per i risultati che promette di ottenere, ma anche evolutivo, in quanto sfrutta tecnologie già esistenti e può essere adottato senza essere vincolato a una specifica tecnologia sottostante. La caratteristica innovativa più rilevante è che si tratta di un nuovo modello organizzativo e di architettura che riconosce l’importanza di un approccio distribuito e domain-driven per quanto riguarda l’organizzazione dei dati assieme ad uno centralizzato per quanto riguarda la relativa governance. Questo consente di pensare ai dati come prodotti offerti e gestiti da specifici domini, andando così incontro ai reali requisiti di business di una compagnia, più che alle singole esigenze applicative.
Indice degli argomenti
Quando il Data Lake porta a un mare di guai
Per comprendere meglio i principali vantaggi del Data Mesh e dei suoi principi architetturali dobbiamo fare un passo indietro e guardare a ciò che era (e nella maggior parte dei casi ancora è) lo stato dell’arte nella gestione dei dati.
Negli ultimi anni, la tendenza principale nella gestione dei dati è stata quella di creare un unico Data Lake centralizzato, concentrando così ownership tecnica, funzionale e di governance in un’unica piattaforma. Mentre quest’ultima si è rivelata vincente, nonostante la necessità di importanti investimenti tecnologici, le prime due sono risultate controproducenti sia dal punto di vista organizzativo, sia da quello tecnico, per diversi motivi.
Come si è detto, in fase di creazione dei Data Lake, la prima priorità è stata quella di “aprire i silos”, ovvero portare il più presto possibile i dati dai sistemi esterni (proprietari, chiusi) verso un’unica piattaforma centralizzata, aperta e accessibile a tutti all’interno dell’organizzazione. Il compito di progettare e realizzare i processi di questa migrazione dei dati è stato generalmente affidato al gruppo di ingegneri informatici interni del Data Lake, che ha realizzato un’ampia varietà (per far fronte a tutte le possibili sorgenti dati) di processi di ETL (Extract, Transform, Load – Estrazione, Trasformazione e Ingestione), talvolta sfruttando strumenti di CDC (Change Data Capture). Questa, che sembrava una scelta assolutamente logica, non ha però tenuto conto del fatto che, una volta impostata l’integrazione, anche la proprietà dei dati sarebbe passata automaticamente nelle mani dei data engineers, quantomeno nei confronti dei consumatori a valle della catena. Il gruppo IT in seno dalla gestione del Data Lake e dei suoi processi si è trovato così a dover investire non solo nella continua formazione tecnica, per essere pronto ad affrontare le sfide sulle innumerevoli tecnologie venute fuori anno dopo anno, ma anche nella continua formazione funzionale e nella conoscenza del dominio (se un dato cambiava alla sorgente, il team di piattaforma era costretto a gestirne l’evoluzione facendosi carico di garantire le funzionalità a valle, lato consumer). Sforzo troppo grande e poco scalabile, che spesso ha portato necessariamente a tralasciare aspetti, comunque, di grande importanza quali documentazione dei dati, garanzia di qualità su di essi, e così via. Nel tempo, però, queste problematiche sono riemerse – con forza – comportando in reazione la necessità di definire e implementare controlli, metriche, misurazioni della qualità su dati con ulteriore pressione sul team di data engineers.
Un problema ancora più profondo è poi emerso con l’utilizzo nel tempo. L’approccio basato sull’integrazione si rivela deleterio quando cambia qualcosa sul sistema di origine, come ad esempio modifiche allo schema, specifiche del dominio di origine in evoluzione, introduzione del GDPR e così via. Si tratta, infatti, di un modello che non può essere ampliato, specialmente per le multinazionali che centralizzano dati provenienti da diverse filiali o Paesi, con relative specifiche e regolamentazioni locali o nazionali. Inoltre, i sistemi di origine non sono a conoscenza del processo di gestione centralizzata dei dati (data warehousing), non conoscono le esigenze di chi utilizza i dati e non sono focalizzati sul garantirne la qualità, perché questo non rientra nel loro obiettivo aziendale. Tutto ciò, di solito pone le basi per un totale disimpegno nella generazione di dati in ottica di creazione di valore aggiunto per l’intera organizzazione.
Un altro classico problema di un Data Lake è la sua struttura a layer, cioè a livelli, dove ogni layer ha una caratteristica tipicamente tecnica (pulizia, standardizzazione, armonizzazione). Ciascuno di questi livelli rappresenta un’ulteriore barriera tra i dati e le esigenze di business, che rallenta costantemente il processo di integrazione e, quindi, di creazione valore.
Data Mesh: che cosa cambia?
Il nuovo paradigma del Data Mesh è attualmente definito da quattro principi (secondo Zhamak Dehghani, che è stata la prima a proporlo):
- Proprietà e architettura dei dati decentralizzata organizzata in domini
- Dati come prodotti
- Infrastruttura per dati e servizi self-service e as-a-platform
- Governance computazionale e sui dati federata.
Per capire che cosa sta cambiando rispetto al passato è utile iniziare a modificare il proprio vocabolario. Nel Data Mesh parliamo più di pubblicazione che di importazione, poiché è più importante individuare e utilizzare i dati piuttosto che estrarli e caricarli da un’altra parte.
Ogni spostamento o copia dei dati ha un costo intrinseco, generato principalmente dallo sviluppo (l’ETL deve essere sviluppato, testato e distribuito) e, soprattutto, dalla manutenzione. È, inoltre, necessario monitorare questi processi, adattarli quando le fonti cambiano, occuparsi della cancellazione dei dati e della dispersione della loro proprietà.
- Spesso lo spostamento o la copia dei dati è necessario per i seguenti motivi (che non sussistono invece in un Data Mesh):
- Layer tecnici
Necessità tecnologiche: per esempio i dati risiedono su S3, ma SAP richiede di avere i dati in una propria tabella interna per elaborarli. Oppure si dispone di un enorme set
di dati su Redshift e lo strumento di Machine Learning per la formazione richiede invece che i dati siano su S3.
- Mancanza di funzionalità di time-travel e di cronologia: in questo caso è necessario eseguire uno snapshot (cioè una copia che rappresenta lo stato attuale come una “fotografia”) di un’origine dati.
- Vincoli di sicurezza e di ownership: alcuni sistemi non possono fornire a terzi accesso ai dati di produzione
È importante specificare che spostamento e copia dei dati non implica denormalizzazione degli stessi. La denormalizzazione è abbastanza usuale quando si hanno più utenti con esigenze diverse, ma ciò non implica un trasferimento di proprietà dei dati. Quando i dati vengono spostati da un sistema o da un team all’altro, invece, viene trasferita la proprietà e si creano dipendenze che non hanno nessun valore aggiunto da un punto di vista business. Al contrario, il Data Mesh trasferisce la proprietà dei dati soltanto nel caso in cui i dati assumano un nuovo significato funzionale e/o di business.
Il paradigma Data Mesh rappresenta anche una fortissima garanzia contro il rischio dell’obsolescenza tecnologica. In futuro, quando emergeranno nuove tecnologie, ogni “sistema sorgente” (ovvero dove i dati vengono creati) potrà adottarle senza problemi. La continuità di funzionamento dell’intero sistema è infatti assicurata dalla possibilità di creare nuovi connettori, specifici per i dati generati da queste nuove tecnologie, che permettano di renderli disponibili al resto dell’azienda tramite servizi Mesh (da cui l’intero Data Mesh prende il nome) attraverso quello che è definito come un sistema di scaffolding, ovvero un’impalcatura che circonda e mette in comunicazione i dati provenienti dai vari sistemi sorgente.
Per comprendere il concetto del Data Product, ovvero quello del pensare al dato come un prodotto ed è un punto cardine del Data Mesh, possiamo usare un’analogia con quanto avviene, ad esempio, su Amazon. Il venditore espone il proprio prodotto in una “vetrina virtuale” o catalogo di prodotti, in maniera sostanzialmente autonoma: Amazon non ne riceve infatti una copia per fotografarla, scriverne la descrizione, stabilire il prezzo e così via. L’acquirente ha immediata visibilità di che cosa è disponibile e non deve interagire con il venditore per trovare un accordo, ad esempio, sulle modalità di pagamento, che vengono gestite dalla piattaforma di e-commerce. Oltre a fornire un servizio, Amazon si occupa anche di stabilire delle regole (ad esempio non si possono vendere armi o sostanze illecite) in ottemperanza con le leggi vigenti nei vari Paesi; crea, inoltre, uno standard per la presentazione dei prodotti disponibili che il venditore deve adottare per poter essere trovato dai possibili acquirenti, nonché fornisce un sistema che consenta ai potenziali consumatori di valutare la qualità dei prodotti offerti (come ad esempio la valutazione dello stesso da parte di altri consumatori, visibile a tutti). Il valore di un prodotto è dato dalla quantità di consumatori (soddisfatti) dello stesso: lo stesso principio vale in un ecosistema dati.
È abbastanza evidente che la creazione di un marketplace come Amazon, capace di crescere per gestire un sempre maggior volume di prodotti, non sia un’impresa banale. Allo stesso modo anche la creazione di un Data Mesh richiede un iniziale ingente investimento in termini di infrastruttura, nonché di ridisegno dell’intero sistema di gestione dei dati in azienda. In particolare, è necessario implementare un’architettura di tipo self-service per infrastruttura e servizi, tramite la quale ogni dominio è libero di percorrere la propria roadmap tecnologica, utilizzando gli strumenti che meglio si adattano alle necessità dei propri data product, mantenendo trasparente e visibile l’utilizzo delle risorse per consentire una più accurata analisi dei costi a livello di organizzazione. Il concetto di self-serve si declina anche nella forma di consultazione e “approvvigionamento” autonomo da parte dei potenziali data consumers, attraverso un catalogo nel quale ogni data product esponga la propria offerta (in termini di porte di output), dipendenze (in termini di lineage dati), conoscenza sui dati esposti (in termini di documentazione), recensioni e feedback di altri eventuali utilizzatori, il tutto finalizzato a favorire autonomia, riutilizzo, accessibilità e creazione di fiducia tra le business units.
L’offerta e l’approvvigionamento dei dati, dunque, deve avvenire tramite modalità e formati standardizzati, oppure tramite layer di astrazione “normati” a livello di policy di accesso, standard di sicurezza, ecc. … Questo compito è affidato alla “governance computazionale federata”, altro pillar del paradigma Data Mesh. È importante, in questo caso, mettere a fuoco la differenza tra governance centralizzata/esternalizzata (come nell’esempio di Amazon), rispetto al paradigma federato: nel primo caso, infatti, le regole sono imposte da una terza parte (nei confronti di chi realmente vende i prodotti). La “governance computazionale federata”, come dice il nome stesso, è invece una federazione di proprietari di Data Product (quindi assolutamente interna all’organizzazione) con il compito – impegnativo – di creare regole, standard, garantire una misurazione di metriche comuni e trasversali, garantire il monitoraggio della piattaforma e automatizzare (o almeno semplificare) l’aderenza a tali standard seguendo, per quanto possibile, metodologie DevOps e Infrastructure-as-code.
Una piattaforma Data Mesh deve essere in grado di fornire, quindi, lo scaffolding per implementare i connettori (e rendere dunque disponibili i dati dei source system), scegliendo standard per l’accesso ai dati (analitico e basato sugli eventi) ove possibile indipendenti dalla tecnologia, cioè creare interoperabilità attraverso la standardizzazione globale. Deve facilitare e promuovere questi standard concordati internamente ma, allo stesso tempo, non bloccare mai i team di prodotto all’interno di gabbie tecnologiche. Anche la governance computazionale federata dovrebbe essere molto aperta al cambiamento, lasciando che la piattaforma evolva insieme con i propri utenti (team di prodotto) per rispondere sempre puntualmente alle loro esigenze, che mutano nel tempo, e adattarsi efficacemente alle nuove tecnologie che emergeranno.
