Data Mesh, cos’è e a cosa serve

La genesi e rapida evoluzione del data mesh porta a nuove opportunità nella gestione dei dati in azienda

Capiamo meglio di cosa si tratta e quali siano i vantaggi

Data Mesh: cosa è

Data mesh è un paradigma organizzativo e tecnologico che permette di realizzare e governare un’architettura del dato decentralizzato. Il dato è pensato come un prodotto, gestito dalle persone e dai team che lo utilizzano, e quindi lo conoscono a fondo.

Data mesh, in virtù delle sue interconnessioni tra aspetti tecnologici e aspetti socio-organizzativi, è definibile anche come paradigma sociotecnico.

Sarebbe errato demandare la realizzazione di una strategia data mesh a strumenti informatici o applicativi, allo stesso modo con il quale sarebbe errato demandare una strategia omnicanale ad un CRM.

Data mesh prevede una gestione del dato decentralizzato in quanto ogni singolo data producer diventa anche un data owner. Il ciclo di vita del dato (data lifecycle) è integro e autoconsistente in tutte le sue fasi, e gestito da unità business che ne conoscono a fondo le peculiarità.

Il data owner è anche libero di scegliere il percorso tecnologico per intervenire sul dato più congeniale, all’interno della governance tecnologica stabilita e approvata a livello aziendale.

Il termine “mesh” richiama una struttura a maglia di network tra loro interconnessi (grafi, o rete) che utilizzano il dato in diverse fasi del ciclo di vita del dato stesso.

Data Mesh e Domain-Driven Design

Data mesh attinge dal principio Domain-Driven Design (DDD), proprio dell’ambito software e introdotto da Eric Evans.

Secondo il principio Domain-Driven Design, la struttura e il linguaggio del codice (es. nomi, metodi e variabili delle classi) devono essere allineate e comparabili al dominio aziendale e alla logica delle sue componenti. DDD è uno dei principi fondanti di un’architettura a microservizi.

Data mesh porta i principi del Domain-Driven Design nelle componenti delle architetture dati per promuoverne una gestione orientata alle necessità di business, in relazione con i domini aziendali, e gestita dagli utenti del dato stesso. In contrapposizione ad una struttura monolitica prevalentemente guidata da scelte tecnologiche.

Data Mesh vs Data Lake

Per comprendere appieno la peculiarità del paradigma data mesh, è bene confrontarlo con architetture tradizionali e centralizzate, come data lake, o, più semplicemente, il tradizionale Datawarehouse (DWH).

Le architetture dati centralizzate come DWH, data lake, e le conseguenti derivazioni, intendono sollevare l’incarico di gestione del dato dai team di business (tipicamente gli utenti finali del dato), segregandone le complessità tecniche in capo a unità IT specifiche (team di data engineering, per esempio).

Questa scorporazione però porta alla creazione di una proprietà centralizzata del dato e delle sue specificità e complessità, lontana dagli utenti finali. La conoscenza del dato rimane in capo al team tecnico. Gli utenti finali non possono operare sul dato in autonomia, per ragioni organizzative in primis, ma anche per competenze.

L’intervento sul dato avviene quindi con un passaggio forzato, attraverso il team tecnico.

L’inconveniente è manifesto: il team tecnico, correttamente, non ha conoscenza business sul dato sul quale opera e pertanto non è in grado di apprezzarne la sensatezza in sede di manipolazione.

La risultante è una mancanza di padronanza e spirito critico durante il ciclo di vita del dato. Gli utenti business possono in casi limite trovarsi a non poter riporre fiducia nel dataset fornito.

Un caso reale

Il caso riscontrabile nel mondo reale può essere il seguente:

1. La Business Unit (BU) ha necessità di estrarre dati di vendita in un dato periodo, presenti su CRM, e confrontarli con i dati di campagna provenienti dai social media.
2. BU richiede tale estrazione dati al team di data engineering. Il team è a proprio agio con l’estrazione dal punto di vista tecnologico, ma ha difficoltà a comprendere il significato intrinseco della richiesta, essendo formulata con termini propri del mondo dell’advertising e facente riferimento a peculiarità specifiche di prodotti, non note a priori.
3. L’estrazione viene comunque portata a termine e messa a disposizione della BU richiedente su uno strumento di data visualization.
4. Il team di data engineering, non  conoscendo le necessità operative della BU, crea una vista non significativa.
5. La BU si trova spiazzata dall’estrazione e deve intervenire per modificarla. Non sentendosi certa a priori della bontà dell’estrazione, un significativo effort è speso per tentare di riconciliarne i punti salienti tramite estrazioni individuali fatte alla fonte, su CRM e piattaforme social utilizzate per la campagna.
6. Al termine del processo, il team di data engineering non ha percepito un particolare valore nell’operazione compiuta, e il valore aggiunto apportato non è stato significativo. La BU d’altra parte ha avuto un prodotto subottimale.

Data mesh permette invece di accoppiare la gestione del dato con la necessità dell’utente finale, che può quindi intervenire in autonomia e essere totalmente responsabile dell’intero ciclo di vita del dato.

Il beneficio non trascurabile è quello di creare conoscenza e competenza a contatto con il dato stesso, che viene seguito in tutte le sue fasi (dalla genesi all’estrazione di valore) con chiare responsabilità.

Un po’ di storia

Il termine “Data Mesh” è stato coniato e diffuso per la prima volta da Zhamak Dehghani.

La Dehghani ideò il termine nel 2018, allora nel ruolo di VP of Emerging Technologies  in Thoughtworks.

Il suo ruolo, a stretto contatto sia con sistemi distribuiti e architetture big data, ha favorito la nascita di un nuovo paradigma rivolto alla gestione dei dati in modo decentralizzato, per promuovere un approccio ai dati più funzionale e democratico.

“Decentralized technology solutions are the foundations for democratization.”

Zhamak Dehghani ha definito data mesh un paradigma in grado di superare i data lake monolitici e centralizzati, per passare a un’architettura intenzionalmente decentralizzata. Grazie al data mesh è possibile abbracciare e comprendere la natura costante, ubiqua e distribuita dei dati.

D’altra parte l’ideatrice ha messo in guardia sulle incomprensioni insite nel nuovo approccio. In particolare, scambiare data mesh per una tecnologia o uno strumento, o scambiarla con un termine modaiolo per descrivere architetture data lake o tecnologie di data virtualization.

Il concetto di data mesh ha avuto una rapida diffusione tanto che testate di primaria importanza hanno indicato proprio l’adozione del data mesh come una delle principali sfide per le aziende per il prossimo futuro.

I 4 pilastri del Data Mesh

Il paradigma sociotecnico di data mesh appoggia su quattro principi cardine.

Domain Ownership (responsabilità del dominio del dato)

Nelle architetture dati tradizionali, un database centralizzato (data lake, DWH) è alla base di molte decisioni di business. Questo approccio centralizzato porta come visto alla necessità di avere competenze tecniche nella fase di data ingestion e data storage, disaccoppiate dalle competenze necessarie a utilizzare il dato e metterlo al servizio delle unità operative aziendali.

Il concetto di domain ownership (proprietà del dominio) insiste proprio su questa dicotomia, sancendo che produttori e consumatori di dati dovrebbero lavorare a stretto contatto. Idealmente in un unico team che produce e consuma i dati di cui ha bisogno.

In tal modo vi è un perfetto match tra interessi, competenze, capacità e conoscenza, che matura e evolve nello stesso team, di pari passo con l’evoluzione del dato e della sua genesi. Inoltre, in caso di aumento dei dati o delle necessità aziendali, è agevole aumentare il numero di nodi autonomi della rete, preservandone la scalabilità.

Se un unico team rimane spesso una visione utopica nell’intricato ecosistema aziendale, creare team che agiscono sul dato e comunicano direttamente, senza gap gerarchici o intermediari, risulta essere un valido punto di partenza.

Data as a Product (dati come prodotti)

Il paradigma data mesh contesta la pregressa modalità di estrazione di valore dei dati da parte delle aziende.

In particolare la cura nella raccolta e organizzazione dei dati non è bilanciata da un’equivalente estrazione di valore del dato stesso.

Le aziende hanno a disposizione terabyte di dati, ma a questo non corrisponde un comparabile effetto moltiplicativo sulla qualità dei processi decisionali o un ricorso quantitativamente comparabile a scelte dettate dal dato (data-driven).

Secondo data mesh, il dato deve essere trattato come un prodotto. I consumatori di tale dato vanno pertanto trattati effettivamente come “consumatori” inteso qui in un voluto gioco di parole nel senso proprio del marketing, ossia utenti finali che vanno soddisfatti e deliziati.

Questa declinazione viene portata in senso letterale, tanto che data mesh promuove la creazione di ruoli specifici quali il DDPO (Domain Data Product Owner) e la validazione della soddisfazione dei data user mediante strumenti quali il Net Promoter Score.

Le figure insistenti sul dato quindi sono le stesse che devono garantire soddisfazione lungo la filiera di utilizzo. Esse dovranno interpretare i bisogni degli utilizzatori e le finalità del dato all’interno dell’azienda.

Data as a Product è un modello organizzativo invertito rispetto ai paradigmi precedenti, in quanto sancisce una responsabilità del dato prossima alla genesi del dato stesso, non più a valle. La filiera del dato si accorcia ed il processo di discovery di eventuali anomalie o pattern inattesi è intuitivamente più efficace.

Self-serve Data Platform (piattaforme accessibili)

Quanto fin qui esposto non potrebbe esistere senza la possibilità per gli utilizzatori del dato di interagire con il dato stesso con strumenti a portata del loro livello di conoscenza e competenza.

Data mesh promuove la rimozione di attriti e complessità tecnologiche nelle interazioni tra coloro che producono il dato e coloro che lo consumano, lo utilizzano.

Esplicitamente il paradigma data mesh afferma che:

“L’infrastruttura di dati self-service permette di  rendere autonomi gli utilizzatori del dato direttamente sul dominio pertinente.”

In pratica questo si traduce in una lista di requisiti puntuali che le data platform devono avere per essere accessibili agli utenti finali. Alcuni di questi sono:

• Crittografia dei dati.
• Accessi unificati con controllo di log.
• Implementazione e orchestrazione di data pipeline.
• Governance dei dati e loro standardizzazione.
• Gestione federata delle identità.
• Product discovery, creazione di cataloghi e loro pubblicazione.

Prendendo spunto dalla filosofia Agile, data mesh emana anche alcuni Governing Principles associati al principio della self-service data platform:

• Servire dati piuttosto che ingerire dati.
• Scoprire e utilizzare i dati piuttosto che estrarre e caricare dati.
• Pubblicazione di eventi in flussi piuttosto che flussi dati centralizzati.
• Ecosistema di data product piuttosto che data platform centralizzate.

Federated Computational Governance (gestione federata)

Dovrebbe essere chiaro a questo punto che data mesh prevede una raccolta dei dati indipendente, legata all’effettivo utilizzo dei dati e al loro unico ciclo di vita, creata e gestita da team indipendenti.

Sarebbe tuttavia impensabile creare all’interno dell’azienda delle unità di gestione del dato tra loro davvero indipendenti. Questo in quanto specifiche di sicurezza, di potenza computazionale, di estrazione di valore, così come anche applicazioni e tecnologie insistenti sul dato stesso, come applicazioni informatiche o statistiche agiscono a un livello superiore.

Il soddisfacimento di entrambe le esigenze richiede una governance federata, dove entità indipendenti e decentralizzate possono interagire e comunicare tra loro in base a regole standardizzate e note a livello globale, una topologia dinamica e una gestione automatizzata delle attività tra le diverse piattaforme.

Organizzazioni a confronto

La governance data mesh

La struttura organizzativa prevista dal paradigma data mesh può essere così riassunta:

• Un team federato, che definisce e gestisce la definizione e cura della qualità del dato.
• Composto da membri rappresentativi dei domini dei dati, quindi con competenze specifiche sui dati oggetto dello stream.
• In carico di definire modalità di accesso al dato, attraverso sistemi accessibili e self-service.
• Con l’obiettivo di abilitare un flusso di dati dinamico, in continua evoluzione e con una topologia volutamente mutabile.
• I processi sono implementati sulla piattaforma e in modo automatico, anche con lo scopo di individuare anomalie.
• Il successo è dato dalle effettive connessioni raffiguranti l’utilizzo del dato.

La governance classica

Questo si contrappone alla governance tradizionale, che invece prevede:

• Un team centralizzato.
• Composto da membri con competenze tecnologiche ma agnostici rispetto al significato intrinseco dei dati e del loro dominio.
• Responsabile in via unica e centralizzata di tutti gli aspetti di sicurezza, raccolta, utilizzo, accesso al dato.
• Con l’obiettivo di definire un flusso di dati statico e quanto più definito in modo puntuale e immutabile.
• I processi sono implementati sulla piattaforma manualmente.
• Il successo è definito in base al volume di dati gestiti.

Architettura data mesh: la tecnologia

Data mesh è un paradigma sociotecnico, pertanto dal punto di vista implementativo non è corretto ridurlo a un novero di strumenti o applicativi da utilizzare. Nessuno strumento tecnologico o informatico può di per sé abilitare al data mesh, senza adeguati processi a supporto e evoluzioni organizzative.
In sintesi, data mesh non può essere acquistato.

É d’altra parte vero però che la tecnologia costituisce un abilitatore tecnologico per il paradigma data mesh.

La logica che i provider stanno seguendo è quella di integrare capacità di gestione federata del dato, self-servicing, e in generale, quanto rispondente ai pilastri data mesh, in prodotti già esistenti.

Pertanto è probabile che i prodotti già in uso presso le aziende che ricorrono a architetture big data, ad esempio, siano già “data mesh ready”.

I componenti di un’architettura data mesh tipicamente possono essere:

• Microsoft Azure, con l’utilizzo di Synapse Analytics, Power BI, Cognitive Services, Azure Machine Learning.
• Google Cloud, con Google Big Query, Google Dataplex, Google Dataflow, Google Data Studio.
• Amazon Web Services, con Amazon Athena, Amazon Redshift, Amazon SageMaker.
• Snowflake, sia con prodotti nativi che integrazioni di terze parti.
• Databricks, con Databricks Workspaces.

La lista non ha pretesa di esaustività ma piuttosto di esemplificare alcuni possibili approcci.

Data mesh: i vantaggi

Le aziende sono sempre più dipendenti da decisioni prese rapidamente, su dataset strutturati e mutevoli, e con dipendenze gerarchiche all’interno delle organizzazioni sempre più complesse, liquide, e in evoluzione.

Possiamo pertanto affermare che in prima battuta data mesh consente alle aziende di rispondere alle nuove esigenze insite nell’operare in tale contesto.

Volendo però essere più specifici, possiamo desumere i seguenti vantaggi derivanti dall’adozione del paradigma data mesh.

Rimozione dei colli di bottiglia: rimuovendo la logica del dato centralizzato, cessano i ruoli di singoli attori che gestiscono l’intero ciclo di vita del dato aziendale. La filiera del dato è corta, azionabile, chiara, trasparente e più efficentabile. Ciascun team federato è responsabile per il proprio data stream, senza poter accusare dipendenze o inefficienze esterne.

Migliore comunicazione: data mesh non solo facilita ma anzi incentiva grandemente la comunicazione cross-gerarchica all’interno dell’azienda. Sviluppatori con marketer, product manager con analisti, data scientist con sviluppatori.

Indipendenza operativa: ciascun team può operare con processi e strumenti a propria discrezione e scelta, secondo necessità e competenze.

Trasparenza nei processi: ciononostante, il layer di governance centralizzato operante ad alto livello garantisce regole di ingaggio chiare, e protocolli noti a priori da tutti gli attori operanti nell’ecosistema.

Crescita del team: operando direttamente sul dato, ciascuna entità accresce direttamente il proprio know-how. Si creano competenze specifiche sui domini del dato, che possono essere sfruttate per estrarre valore dai dati stessi.

Cultura del dato: data mesh consente, forse più di ogni altro approccio, modello, paradigma, di creare in azienda una vera cultura data-driven. Ciascuna Business Unit agisce e cura il ciclo di vita dei dati di propria pertinenza e ne risponde, anche di fronte a scelte puntuali di business.

Data mesh in pratica

La tua azienda ha adottato il paradigma data mesh e vorresti aggiungere il tuo punto di vista?

Vorresti saperne di più su aspetti implementativi specifici?

Siamo a disposizione! Contattaci.