Data mesh: la novità che ottimizza la rete dei dati aziendali

Il data mesh, la struttura dei dati “a rete”, è un paradigma organizzativo e tecnologico che, nelle intenzioni di chi lo propone, dovrebbe rivoluzionare i modelli architetturali più diffusi, a cominciare dal data lake. Che si tratti dell’ennesima buzzword partorita nell’ambiente IT o di un effettivo cambiamento destinato a durare nel tempo, è ancora presto per dirlo. A distanza di poco più di 3 anni dal suo conio, vediamo in cosa consiste e quali sono le sue caratteristiche principali.

Che cosa si intende con data mesh

IBM definisce il data mesh come “un’architettura di dati decentralizzata che organizza i dati in base a uno specifico dominio di business – ad esempio marketing, vendite, servizio clienti e altro ancora – fornendo maggiore proprietà ai produttori di un determinato dataset”. In teoria, questo “approccio federato” dovrebbe eliminare i colli di bottiglia operativi derivanti da sistemi monolitici e centralizzati, come i data lake o i data warehouse, poiché questi ultimi verrebbero utilizzati su più repository di dati decentralizzati invece che su un’unica piattaforma di dati centralizzata. Con la conseguenza che l’impiego dei dati, da parte dei vari team, sarebbe più immediato e basato sulle rispettive competenze di dominio e non più sulla ownership esclusiva affidata al personale tecnico.

Chi ha inventato il data mesh

Zhamak Dehghani, che non a caso sul suo profilo Twitter si autodefinisce “Data Mesh founder”, nel 2019 scrisse un lungo testo dal titolo Come superare un data lake monolitico per passare a un data mesh distribuito. Nell’articolo, a cui 3 anni dopo si è aggiunto un libro, l’autrice sosteneva che il data mesh, in quanto trasversale all’organizzazione nel suo complesso, andasse di pari passo con l’adozione di piattaforme cloud e soluzioni cloud-native. Il nuovo paradigma è assimilabile a queste tecnologie perché ne condivide scalabilità e flessibilità, caratteristiche che si possono rinvenire ad esempio nelle moderne infrastrutture basate sui microservizi che stanno innovando il mondo delle applicazioni così come l’abbiamo conosciuto finora. Nella visione di Dehghani, l’avvento del data mesh non coincideva con la scomparsa del data lake o del data warehouse, quanto piuttosto con la trasformazione di entrambi in semplici nodi della rete.

A cosa serve una rete di dati

Nell’incipit del suo articolo, la “founder” del data mesh spiegava che l’obiettivo di una rete di dati è quello di far diventare un’organizzazione data-driven per i vantaggi che questo comporta, tra cui:

• fornire la migliore esperienza ai clienti sulla base dei dati e dell’iper-personalizzazione;
• ridurre i costi e i tempi operativi grazie alle ottimizzazioni basate sui dati;
• dare ai dipendenti dei “super poteri” grazie all’analisi dei trend e alla Business Intelligence.

Fino a quel momento, secondo Dehghani, le aziende avevano provato a ottenere questi vantaggi, investendo nella creazione di piattaforme abilitanti, ma i risultati non erano stati adeguati alle attese. Ecco perché occorreva abbracciare una nuova architettura che facesse tesoro della “natura sempre presente, ubiqua e distribuita dei dati”.

I principi del data mesh

Sempre a detta di Zhamak Dehghani, sono 4 i principi del data mesh:

Proprietà dei dati guidata dal dominio

Questo principio allude al fatto che ciascuno dei team o delle unità che possiedono un dominio dovrebbe essere anche proprietario dei dati creati al suo interno. La proprietà non riguarda solo i dati, ma implica la responsabilità delle pipeline, del software, della pulizia, della deduplicazione e dell’arricchimento dei dati.

Dato come prodotto

L’idea di fondo per cui i dati devono essere visti come un prodotto implica che siano corredati da una serie di descrizioni che ne facciano comprendere il valore. Non più perciò un semplice file o una riga di comando, ma un “oggetto” che si auto-descrive, che abbia un indirizzo univoco e che sia interoperabile.

Infrastruttura dati self-service come piattaforma

Il principio si ispira all’applicazione del “platform thinking” al contesto dei dati, vale a dire all’impacchettamento degli sforzi dell’azienda in una medesima piattaforma a cui si può attingere come servizio. Un po’ come avviene quando si attinge alle risorse di un cloud provider, personalizzandole in funzione delle proprie esigenze e senza dovere ogni volta reiterare i processi di customizzazione realizzati in precedenza.

Governance computazionale federata

Il concetto di “federalizzazione” contenuto nel quarto principio fa riferimento a una struttura di governo che opera a parità di livelli distinti, centrale e locale. A livello centrale, vengono definite regole imprescindibili quali ad esempio quelle imposte dalla normativa dei paesi in cui si opera; a livello locale, i team guidati dai Data Product Owner sono responsabili dello sviluppo dei loro prodotti con un elevato grado di autonomia, decidendo su tutte le questioni tecniche e procedurali di loro competenza, ovviamente entro i confini dello stack tecnologico aziendale.

Cosa serve per creare un data mesh

I passi da compiere per implementare con successo un’architettura data mesh hanno a che fare più con il cambiamento di mentalità che con la scelta di una determinata tecnologia. In sostanza, non esiste uno strumento pronto all’uso che aiuti a impostare un sistema data mesh, ma se si seguono i 4 principi illustrati sopra è possibile ottenere i vantaggi a cui il paradigma tende.

Ad esempio, per trattare i dati come prodotto bisogna stabilire uno standard per la documentazione dei set di dati e per le dashboard, adottando criteri di catalogazione che garantiscano caratteristiche quali scopribilità, indirizzabilità, interoperabilità, sicurezza e integrità. Così come è necessario mappare la distribuzione della proprietà del dominio dei dati con tecniche di Domain-Driven Design (DDD) con cui raggruppare gli insiemi di dati in domini diversi.

Una volta catalogati correttamente i dati e assegnati i domini, il passo successivo è l’allineamento sulle tecnologie da utilizzare (cloud provider, linguaggi di programmazione, strumenti di job scheduling ecc.). Un passo che presuppone, a monte, un lavoro collaborativo improntato alla governance federata che coinvolga tutti gli stakeholder che, a vario titolo, partecipano al progetto.

Meglio data mesh o data lake?

La recente ascesa del data mesh come modello architetturale alternativo, rispetto soprattutto al data lake, non significa che sia adatto a ogni azienda. Quelle più piccole potrebbero non ottenere i benefici auspicati, in quanto i loro dati aziendali non presentano quei livelli di complessità che sarebbero semplificati grazie al data mesh. Di contro, alcune grandi aziende con sistemi legacy consolidati o che sono soggette a policy particolarmente stringenti, potrebbero non essere pronte ad adottare il nuovo paradigma.

Va ricordato, in ogni caso, che mentre un data lake è un repository unico per l’archiviazione di dati provenienti da diverse unità aziendali o reparti, il data mesh invece è in grado di integrare e analizzare tali dati. Il che significa che non devono per forza essere visti in ottica antitetica. Se ad esempio un’organizzazione dispone già di un data warehouse con disparati sistemi scollegati, il data mesh può integrare i dati provenienti da questi sistemi scollegati e archiviarli in un data lake.

Le differenze tra data mesh e data fabric

Se tra data meh e data lake è possibile prevedere talvolta una possibile conciliazione, il problema invece non si pone con il data fabric. Quest’ultimo, infatti, identifica un tipo di architettura che consente di automatizzare l’integrazione dei dati tra sistemi hybrid e multicloud, tant’è vero che per farlo si avvale di algoritmi di machine learning.

Nel data fabric, quindi, i dati vengono centralizzati, a differenza di quanto accade nel data mesh, dove sono memorizzati all’interno di ciascun dominio dell’azienda. Tuttavia, il primo è incentrato sulla tecnologia, mentre il secondo si focalizza sul cambiamento organizzativo. Ne deriva che l’uno non preclude la presenza dell’altro. Basti pensare che il data fabric potrebbe migliorare il data mesh automatizzando alcune sue parti, a cominciare dalla creazione più celere di prodotti di dati o dalla migliore orchestrazione delle funzioni di governance globale con i domini federati.

Esempi di data mesh

Il data mesh oggi può rappresentare la risposta al continuo aumento del volume di dati da raccogliere che vedono le aziende in condizione di doverli archiviare, senza però essere in grado di organizzarli, pulirli e categorizzarli prima. La “democratizzazione” introdotta con il data mesh si presta, al contrario, a fornire l’accesso ai dati così che si possano sfruttare in maniera più rapida ed efficace. Da qui l’ampia gamma di casi d’uso che possono essere supportati tramite questo nuovo paradigma. Ecco 3 esempi:

Customer Intelligence

I reparti marketing possono contare su un punto di vista unico sul cliente per ridurre il tempo medio di gestione, aumentare la risoluzione del primo contatto e migliorare la customer experience. Possono anche ottenere insight utili alla iper-segmentazione, tale da individuare la campagna giusta per il cliente giusto da lanciare nel momento più adatto e con il canale più pertinente.

IoT Analytics

I team di prodotto dei dispositivi IoT possono ottenere informazioni puntuali sulle modalità di utilizzo dei device, così da ottimizzare continuamente sia la loro adozione sia la redditività collegata ai singoli prodotti.

Monitoraggio dei sistemi

Infine, i team IT possono concentrarsi sull’osservazione dei sistemi distribuiti, arrivando alla causa di un problema e alla sua risoluzione più velocemente, senza dover passare dai silos che un’architettura monolitica crea di solito tra un sistema e l’altro.