Il Data Mesh è da qualche anno uno tra i main topics in ambito data management ma si tratta di un approccio che non è ancora diventato dirompente: non si parla solo di un cambiamento a livello tecnico ma di un vero e proprio stravolgimento della cultura e dell’organizzazione aziendale che poggia su una nuova concezione di dato inteso come prodotto e che abbraccia un modello decentralizzato e distribuito di gestione dei dati. Un percorso che per ora ha coinvolto circa il 3% delle imprese europee e italiane infondendo un certo ottimismo negli addetti ai lavori grazie ai vantaggi che il Data Mesh è in grado di portare per le aziende che decidono di adottarlo. Trattandosi di un processo complesso, che si basa su una visione a lungo termine ma che prevede step da misurare a brevissimo termine, diventa fondamentale approcciare il tema in sinergia con partner specializzati capaci di fornire il giusto supporto: Axiante, Business Innovation Integrator che a febbraio 2023 ha inaugurato la sua nuova business unit Data Driven, pensata per supportare le organizzazioni alle prese con una molteplicità di dati distribuiti su più ambienti eterogenei, si candida per lavorare fianco a fianco con le aziende nella definizione e messa in atto di percorsi di Data Mesh.
Giovanni Mazzucato, Project Leader di Axiante, ci ha guidato alla scoperta del mondo del Data Mesh approfondendone il concetto e prendendone in considerazione anche i vantaggi e i punti di forza, così come i limiti: “A prescindere dal proprio settore di appartenenza, un’azienda che desideri operare efficacemente nel proprio mercato, ha la necessità di considerare la gestione dei dati non come un semplice fattore tecnico, ma come un asset strategico del business, dal quale non è più possibile prescindere – esordisce Mazzucato -. La trasformazione in una Data Driven Company non è l’adozione di una tecnologia ma un cambiamento profondo e multilivello dell’intera azienda che coinvolge la cultura, la mentalità e al contempo l’intera organizzazione aziendale.
Il Data Mesh affina l’approccio socio-culturale e tecnologico con cui l’azienda si pone in merito al trattamento e alla distribuzione dei dati, con la prospettiva di favorire futuri sviluppi e iniziative, con il fine ultimo di incrementare l’agilità nell’accesso e la flessibilità, la fruizione e la condivisione dei dati stessi.
Tra gli obiettivi di questo paradigma vi è la riduzione del gap tra chi produce i dati – responsabili dei vari sistemi/processi di business – e chi ne usufruisce, con l’obiettivo reale di rendere “il dato” affidabile e arricchito”.
Quali sono i pillar su cui poggia un approccio Data Mesh?
“Il Data mesh si fonda su quattro pilastri volti a superare le principali criticità di un approccio tradizionale al Data Warehouse e al Data Lake: Decentralizzazione dei domini, Dato come Prodotto, Infrastruttura Self-Service e Governance Federata
La Decentralizzazione dei Domini: alla base del Data mesh abbiamo il concetto di “dominio”, al quale sono delegate tutte le attività di gestione del dato e di business rule. Un team di esperti dedicato è così in grado di amministrare in autonomia la propria pipeline di elaborazione dei dati (ETL). Una volta che i dati sono stati raccolti e trasformati dal rispettivo dominio di business, gli owner possono quindi sfruttarli e condividerli per esigenze analitiche o operazionali.
Data As a Product: considerando il dato come un prodotto tutti i soggetti (interni ed esterni al dominio di appartenenza del dato) possono utilizzarlo facilmente. Per essere considerato tale, il Dato come Prodotto deve essere reperibile, accessibile, affidabile, comprensibile, interoperabile e sicuro.
Infrastruttura Self-Service: è necessario predisporre una self-serve data infrastructure, ossia una Data Platform che esponga servizi e capabilities per abilitare i team del dominio alla gestione autonoma del ciclo di vita del Dato come Prodotto.
Governance Federata: al fine di rendere i Data Product interoperabili tra loro e facilmente “consumabili” dal modello di governance che – oltre a decentralizzare i domini e mantenere l’autonomia dei team – permetta la definizione di un set di regole globali da applicare a tutti i Data Product e alle loro interfacce di comunicazione”.
Che vantaggi porta alle aziende il Data Mesh? Perché passare da un modello centralizzato di gestione dei dati a uno distribuito?
“Negli ultimi anni molte organizzazioni hanno utilizzato, anche con successo, modelli di architettura e analitici moderni, capaci di combinare tecnologie di data warehousing e tecnologie big data più recenti. Tuttavia, alcune organizzazioni riscontrano problemi durante la distribuzione di soluzioni analitiche che usano modelli analitici: di norma, infatti, queste soluzioni sono implementate come monolitiche e un singolo team è sia il provider di piattaforma, sia il team che sta eseguendo l’integrazione dei dati. Le organizzazioni, anche dimensionalmente più contenute, con un elevato livello di centralizzazione dal punto di vista della configurazione del team possono invece utilizzare un singolo team.
Un’organizzazione più estesa che utilizza un singolo team genera un collo di bottiglia. Questo collo di bottiglia causa un backlog enorme, con la conseguente attesa di servizi di integrazione dei dati e soluzioni analitiche per una parte, più o meno rilevante, dell’organizzazione d’impresa.
Questo modello diventa più comune quando le organizzazioni adottano soluzioni moderne di Data Science, che richiedono più dati rispetto alle soluzioni di business intelligence tradizionali del passato, poiché introducono un enrichment del dato.
L’utilizzo di microservizi come modello di sviluppo applicativo è un’altra causa del sovradimensionamento del backlog relativo all’integrazione dei dati, perché aumenta il numero di Data Source a cui la funzione IT deve necessariamente accedere.
Un singolo team che gestisce tutti gli inserimenti dati in una singola piattaforma in un’organizzazione di grandi dimensioni rappresenta un punto di criticità, soprattutto perché raramente un singolo team ha esperti per ogni origine dati.
Diversamente, la stragrande maggioranza delle organizzazioni è decentralizzata e distribuita dal punto di vista aziendale. Diverse Business Unit e Reparti gestiscono parti differenti dell’operatività aziendale: quindi gli esperti di Dati sono in genere distribuiti tra le varie funzioni.
L’obiettivo del Data Mesh è abilitare i team distribuiti a lavorare condividendo le informazioni in modalità agile e decentralizzata, con l’obiettivo di ridurre il backlog dei tempi di delivery del dato e, sfruttando la padronanza dei data scientist propri del dominio dati di cui si occupano, arricchiscono il dato stesso offrendo, al contempo, una maggiore affidabilità delle informazioni oggetto di delivery ed altresì, una qualità del dato più aderente alle richieste degli utilizzatori”.
Alla base del Data Mesh, come abbiamo visto, c’è anche una diversa concezione del dato, che deve essere di qualità e soprattutto è visto come un prodotto. Ci spieghi meglio…
“I Data As a Product sono una componente importante del Data Mesh. Il Dato come Prodotto traspone l’idea di Prodotto al mondo dei dati. Similmente a quanto è accaduto in passato con la frammentazione virtuale delle linee di produzione per l’applicazione del Kaizen, e nella Qualità Totale poi, in cui ogni frammento di una linea produttiva concepiva come cliente il frammento successivo, allo stesso modo ogni Team di Dominio Dati concepisce come clienti la popolazione utenti che fruirà di tali dati. Tale responsabilizzazione determinerà un incremento della qualità del dato e una maggiore conformità dello stesso alle esigenze del “Cliente”, inteso come fruitore finale.
Per assicurare il successo del Dato come Prodotto, è necessario fornire un valore aziendale a lungo termine, in primis per giustificarne l’investimento. Nel Data Mesh, un prodotto dati include i Dati in senso stretto, Asset di Codice, Metadati e Criteri Correlati. Il Dato come Prodotto può essere distribuito via API, Report, Tabelle oppure un Dataset in un Data Lake”.
Che caratteristiche deve avere il Dato As a Product?
“Il Dato come Prodotto deve necessariamente essere:
- Fattibile: deve essere realizzabile. Se in realtà non è possibile compilarlo, il prodotto non può essere un successo. Il prodotto deve essere fattibile sia per la disponibilità dei dati che da un punto di vista tecnico.
- Prezioso: Il Prodotto Dati deve mantenere valore nel tempo. Se nel lungo termine perde valore, non può avere esito positivo.
- Utilizzabile: Il Prodotto Dati deve avere utenti esterni al dominio dati immediato.
Gli Asset di Codice di un Prodotto Dati includono il codice che lo genera e il codice che lo distribuisce ed includono le pipeline utilizzate per creare il Prodotto Dati ed il report finale del Prodotto Dati”.
Come deve essere strutturata una buona piattaforma Data Mesh?
“Prima di parlare della piattaforma è importante comprendere l’aspetto del modello organizzativo mediante il quale definiamo una struttura interna capace di facilitare l’interoperabilità tra le Business Unit ed il ruolo dei dati per favorire la gestione, l’innovazione e la massimizzazione della loro fruizione.
Osservando il passato recente, possiamo notare che sono stati utilizzati alcuni modelli organizzativi per la gestione dei dati che presentano gradi differenti circa l’autonomia e la centralizzazione:
- Il Modello Centralizzato: l’amministrazione del dato in questo caso è estremamente centralizzata. Viene effettivamente impostata una modalità di visione del “Data As a Product” e stabilita una suddivisione dei domini, ma al contempo alla governance viene garantito un controllo centrale
- Il Modello Hub & Spoke: è lo schema intermedio che prevede livelli di centralizzazione e decentralizzazione diversificati a seconda del dominio preso in considerazione, delle Business Unit e delle Use Case
- Il Modello Fully Autonomous Business Unit: le varie Business Unit sono completamente indipendenti nella definizione del proprio Data Product. In questa configurazione tutti gli elementi dei quattro Pilastri sono completamente sviluppati.
In realtà, il Data mesh propenderebbe verso una decentralizzazione spinta, ma è diffusa la convinzione che sia il governo centrale (HUB) a facilitare la cooperazione di tutti gli attori coinvolti fornendo strumenti e tecnologie di riferimento che possano essere usate, con svariati livelli di autonomia, da tutti i domini, ossia gli spoke.
Il posizionamento circa il grado di centralizzazione o decentralizzazione attraverso specifici ruoli e attività sarà determinata dal differente grado di maturità e di esigenze definendo quindi il modello Hub & Spoke applicabile per una determinata corporate. Diversamente per tutti i domini dati che non avrebbero la capacità né le competenze per gestire in autonomia il processo di delivery del dato sarà l’Hub centrale il fornitore di supporto e conoscenze.
Questa è una distinzione fondamentale poiché le competenze e le figure di riferimento variano: agli Hub di solito sono correlati esperti più tecnici, i Data Architect o Data Engineer, solitamente interni all’azienda; mentre nell’area degli Spoke, troviamo professionisti come il Data Owner, il Data Steward e i Data Scientist, per i quali è fondamentale possedere una profonda conoscenza del processo del dato, delle strategie di business e del dato stesso al pari del fruitore finale.
Certamente l’Hub & Spoke è il modello che più facilmente abiliterà la transizione perché più vicino al modello organizzativo maggiormente diffuso oggi presso le aziende. Un vantaggio che sicuramente diminuisce sensibilmente le barriere all’ingresso e la complessità legata al cambiamento”.
Il Data Mesh quindi non è un preciso prodotto che troveremo a scaffale…
“È indispensabile che la Piattaforma utilizzata, per applicare le direttive del Data Mesh, consenta la definizione di ruoli per la decentralizzazione dei Domini di Dati. Aspetti quali strumenti self-service per utenti non tecnici e efficaci modelli per la governance dei dati sono aspetti importanti tanto per l’architettura di Data Mesh quanto per altre metodologie di gestione dei dati più centralizzate e classiche che troviamo nell’offerta dei maggiori player attuali.
Accadde nei primi anni ’80, agli albori della nascita del Data Warehousing, che database relazionali progettati per evitare la de-normalizzazione vennero usati con uno scopo differente.
Oggi consideriamo normale trovare all’interno dell’offerta di un database relazionale il supporto a funzioni per il Data Warehousing. Similmente, l’offerta attuale integrerà un più ampio spettro di funzioni al fine di adeguarsi al meglio per la gestione del Data Mesh”.
Quali sono i punti deboli di questo approccio e dei modelli attuali?
“Il punto debole del Data Mesh è ciò che non è:
Non è un prodotto a scaffale e non è nemmeno un predefinito e ben delimitato oggetto.
Non è un progetto o una fase consulenziale.
Non è una struttura di dati: anche se è concettualmente correlato, il concetto di struttura di dati è più vasto comprendendo una molteplicità di stili d’integrazione e di gestione dei dati. Diversamente il Data Mesh è, nella sostanza, orientato a modelli di progettazione basati su decentralizzazione e dominio.
Non è un prodotto di Analytics Self-Service: l’analytics self-service tool, la preparazione e il data wrangling possono essere parte del Data Mesh, come altre architetture di dati.
Un Data Mesh è una modalità di pensiero, un modello organizzativo e un approccio all’architettura dei dati aziendali con strumenti e ruoli professionali a supporto.
Considerando l’innovazione introdotta dal paradigma del Data Mesh, l’applicabilità, il livello e la modalità di adozione devono essere accuratamente valutate in funzione di obiettivi e contesto aziendale per assicurarne il successo e la durata della trasformazione a Data Driven Company”.
Quali sono le maggiori criticità che le imprese si trovano ad affrontare nell’avvicinarsi al Data Mesh?
“Un efficace Data Mesh non è ottenibile applicando i quattro pilastri come semplici regole di una checklist. Occorre necessariamente considerare gli aspetti culturali, organizzativi, architetturali e tecnologici.
Dati per assunto i capisaldi aziendali di possibilità di decentramento e volontà nel definire un percorso per la Data Strategy, è necessario realizzare la scomposizione funzionale per spazi di problema, similmente all’approccio Domain-Driven Design. Il DDD è un metodo per supportare lo sviluppo di software che consente la descrizione di sistemi complessi. DDD distingue tra contesti delimitati, domini e sottodomini. I domini sono gli spazi di problema da risolvere.
Questo processo presuppone un esame approfondito dell’architettura aziendale quando si raggruppano gli spazi di problema.
All’interno dell’architettura aziendale sono disponibili funzionalità aziendali: capacità o capacità che l’azienda possiede o scambia per raggiungere uno scopo o un risultato specifico. È importante anche il linguaggio, inteso come set gergale comune ad un dato dominio. Questa astrazione permette la compressione dei dati, dei processi, dell’organizzazione e della tecnologia in uno specifico contesto, in linea con gli obiettivi e gli obiettivi aziendali strategici.
La mappa delle funzionalità aziendali mostrerà quali aree funzionali soddisferanno la missione e la visione aziendale per l’emersione del Dominio e la sua autonomia”.
Da questa premessa è evidente che la definizione di cosa sia un Dominio non è semplice come si potrebbe essere portati a pensare…
“Se prendessimo come esempio il processo aziendale relativo al CRM e analizzassimo la gestione dei Claim potremmo rilevare moltiplicazioni del Dominio, forse, per ogni Business Unit, poiché le BU possono trattare una criticità in modo differente e avere esigenze di trattamento totalmente differenti, basate sulle caratteristiche del prodotto o del servizio. Sebbene il linguaggio possa permanere comune tra gli addetti del Claim le informazioni necessarie possono discostarsi di molto tra una Business Unit ed un’altra.
La stesura della Mappa relativa alla scomposizione delle funzionalità aziendali e la trasmutazione in Domini rilevanti, l’individuazione o l’acquisizione dei profili professionali operanti sul dominio dati sono le criticità maggiori che un’azienda riscontrerà nell’adottare il Data Mesh”.
In questo contesto per le imprese è fondamentale affidarsi al giusto: Axiante come si approccia al Data Mesh e come affianca le aziende?
“Come abbiamo visto l’adozione del Data Mesh è un percorso che l’azienda può intraprendere. Il primo passo, mosso dal cambio prospettico di mentalità, è la scelta del partner. Axiante da sempre opera in affiancamento, a volte in integrazione, dei responsabili aziendali.
La definizione degli obiettivi è sempre un co-lavoro tra il Cliente ed Axiante. Il primo obiettivo è sempre la semplificazione sia dei problemi che debbono risolvere che degli obiettivi. È importante che l’introduzione del Data Mesh abbia una visione a medio lungo termine, quale faro guida, ma necessariamente è fondamentale che l’approccio si graduale con delivery a breve se non brevissimo termine. L’esperienza così maturata sarà il lastricato dei passi successivi”.
Che plus assicura la proposta dei servizi di Axiante per il Data Mesh?
“Axiante, a febbraio di quest’anno, ha annunciato la creazione di una nuova business unit, Data Driven, pensata anche per supportare le organizzazioni alle prese con una molteplicità di dati distribuiti su più ambienti eterogenei, dall’on premise al cloud, dai data generati internamente a quelli esterni.
In poche parole, la missione di questa BU è accompagnare le aziende nella definizione di una data strategy su misura, sia essa tendenzialmente offensiva o prevalentemente difensiva. Lavoriamo in squadra con i business manager ed i team IT interni dei nostri clienti, con un approccio step by step, dove è possibile definire obiettivi concreti e immediatamente misurabili. Questo è sicuramente il modo migliore per introdurre e far apprezzare il Data Mesh”.
Il Data Mesh va bene per tutti? E come ne vedete l’adozione in Italia e all’estero?
“Assolutamente no: non tutti i business sono adatti al modello espresso dal Data Mesh.
Vi sono elementi imprescindibili al fine di ottenere risultati:
- Il contesto organizzativo deve permette la decentralizzazione dei domini.
- L’azienda non è in grado di esprimere una Data Strategy chiara
- L’assenza di Use-Case che aggiungano valore alle Business Unit
- La mancanza o carenza di specifiche figure professionali altamente specializzate: Data Owner, Data Steward e i Data Scientist.
Le indagini recenti indicano l’interesse delle aziende italiane ed europee per il Data Mesh nell’ordine di tre aziende su dieci. È certamente un dato confortante e possiamo essere fiduciosi in una crescita di tale tendenza. In questo contesto, non ci sorprende che l’intelligenza artificiale ed il machine learning siano riconosciute come tecnologie d’elezione da oltre un terzo delle aziende italiane”.
