Cos’è il Data Mesh e perché risolve problemi

Il Data Mesh fornisce un’alternativa al modello organizzativo e architetturale e centralizzato del data lake con un’architettura distribuita e decentralizzata progettata per aiutare le imprese ad avere agilità e scalabilità aziendale.

Nonostante gli innumerevoli vantaggi che offre, spesso abbiamo la sensazione che la tecnologia, invece che aumentare la produttività, renda il nostro lavoro più difficile e più complesso.

Questo accade quando è male implementata, con regole troppo rigide o una logica di funzionamento che non segue le necessità dell’utente o, ancora, quando sembra intromettersi senza alcun motivo (basta provare a spostare di un millimetro un’immagine in Word per assistere a una reazione esagerata che reimpagina l’intero documento).

Ciò non vuol dire che rimpiangiamo il tempo in cui dovevamo guidare con in grembo una mappa di carta, prima dell’avvento dei navigatori satellitari, o quando bisognava sfogliare le pagine gialle alla ricerca di un albergo, un ristorante o anche soltanto il numero di telefono di un’azienda.

Insomma, abbiamo bisogno di tecnologie che ci aiutino davvero e con le quali sia piacevole lavorare. Il Data Mesh, come il Signor Wolf nel film “Pulp Fiction”, risolve problemi in modo efficace, veloce e senza fronzoli. Vediamo che cosa significa in pratica.

Data Mesh e problemi reali

Oggi la sfida in un’azienda moderna è trovare dati affidabili. Non si tratta solo di sapere dove si trovano i dati, ma anche se possiamo davvero fidarci di loro. Nel mondo degli affari, sempre più competitivo, evitare spese extra e non rinunciare ad un’opportunità è un must assoluto. E non puoi permetterti questi passi falsi “solo” perché non riesci a trovare o fidarti dei tuoi dati. Oggi è altamente improbabile che un’azienda non abbia i dati di cui ha bisogno per un report, un KPI diverso, per una nuova iniziativa di Business Intelligence o Business Analytics, per un’analisi per validare una nuova business proposition e così via.

Al contrario, sembriamo sommersi dai dati e sempre in lotta per gestirli; con continue domande sulla loro qualità. Sono affidabili? Chi li ha creati? Provengono dall’interno dell’azienda o sono stati acquistati? Derivano da un set di dati di origine diversa? Sono aggiornati? Trovo tutte le informazioni di cui ho bisogno in un unico posto? Sono in un formato compatibile con le mie esigenze? Qual è la complessità (e quindi il costo) di estrarre le informazioni di cui ho bisogno da quei dati? C’è qualcun altro in azienda che ha già sfruttato quel set di dati e, in caso affermativo, com’è stata la sua esperienza?

Potrebbero quindi esserci problemi che devono essere risolti prima di poter utilizzare un determinato asset di dati. Non c’è da stupirsi che succeda: ogni nuova analisi aziendale, ogni nuova iniziativa di BI ha una propria serie di ostacoli. La vera sfida, però, sta nella capacità di stimare questi sforzi in anticipo, in modo da non incorrere in sforamenti di budget o altri costosi ritardi.

Sembra che ogni volta che si tenti di analizzare la situazione non si possa mai ottenere una risposta definitiva dai data engineer, per quanto riguarda la qualità dei dati o anche il tempo necessario per determinare se i dati siano adeguati. Non c’è modo di impostare un budget (sia in termini di tempo sia di risorse) per risolvere i problemi quando non è possibile sapere in anticipo quali problemi i dati potrebbero avere e quanto costoso sarebbe scoprirlo.

È assolutamente impossibile stimare un Time-To-Market se non si conoscono le sfide da affrontare. Pertanto, come è possibile determinare se un prodotto o un servizio sarà rilevante sul mercato, quando non c’è modo di sapere quanto tempo ci vorrà per lanciarlo? E‘ un rischio da correre, o meglio bloccare l’intero progetto? Questo è il tipo di enigma a cui porta la scarsa osservabilità e riutilizzabilità dei dati, combinata con politiche inefficaci di governance dei dati.

Ciò che le aziende cominciano a capire è che il problema della data integration debba essere affrontato come un tema di organizzazione, piuttosto che tecnico. Le Business Unit sono (o almeno dovrebbero essere) responsabili degli asset di dati, assumendo la proprietà sia in senso tecnico che funzionale.

Nell’ultimo decennio, al contrario, le architetture di Data Warehouse e Data Lake, in tutte le loro declinazioni, hanno liberato i data owner dal fardello tecnico e allo stesso tempo hanno mantenuto la conoscenza e la competenza di questi dati nelle mani della Business Unit che li ha creati.

Sfortunatamente, una conseguenza diretta è stata che l’IT centrale (o data engineering team), una volta messo in atto il primo processo di inserimento, ha “acquisito” la proprietà di tali dati, forzando così una proprietà centralizzata. Qui l’integrazione si interrompe: i potenziali consumatori che potrebbero creare valore dai dati devono ora passare attraverso il team di data engineering, che non ha alcuna reale conoscenza aziendale dei dati che forniscono come risultati ETL. Questo porta i potenziali consumatori a non fidarsi o non essere in grado di sfruttare effettivamente le risorse di dati e quindi non essere in grado di produrre valore nella catena.

I quattro principi del Data Mesh

Quanto detto implica che è ora il momento non solo di un’altra architettura o tecnologia, ma piuttosto di un paradigma completamente nuovo nel mondo dei dati per risolvere tutti questi problemi di integrazione (e organizzazione).

È proprio qui che entra in gioco Data Mesh. Si tratta, prima di tutto, di un nuovo modello organizzativo e architetturale basato sul principio del domain-driven design, un concetto che si è dimostrato di grande successo nel campo dei micro-servizi, che ora viene applicato agli asset di dati per gestirli con strategie e domini orientati al business e non solo all’applicazione / tecnologia.

In altri termini significa far lavorare i dati per le nostre esigenze, invece che intervenire per risolvere loro complessità tecniche. Data Mesh è sia rivoluzionario, per i risultati che fornisce, sia evolutivo, in quanto sfrutta le tecnologie esistenti e non è legato ad una specifica sottostante. Proviamo ora a capire come funziona, dal punto di vista del problem-solving.

IL Data Mesh è ora basato su 4 principi:

• Proprietà e architettura dei dati decentralizzate, orientate al dominio
• I dati come prodotto
• Infrastruttura dati self-service come piattaforma
• Governance computazionale federata.

Come già accennato, uno dei motivi più frequenti dei fallimenti nelle strategie dati è il modello di proprietà centralizzata, a causa della sua intrinseca “forma di collo di bottiglia” e dell’incapacità di scalare verso l’alto.

L’adozione del Data Mesh, prima di tutto, scompone questo modello trasformandolo in uno decentralizzato (domain-driven). I domini devono essere i proprietari dei dati che conoscono e che forniscono all’azienda. Questa proprietà deve essere sia da un punto di vista funzionale al business, sia da un punto di vista tecnico/tecnologico, in modo da consentire ai domini di muoversi alla propria velocità, con la tecnologia con cui sono più a loro agio, fornendo allo stesso tempo risultati preziosi e accessibili a qualsiasi potenziale consumatore di dati.

Fiducia e budget

Il dato come prodotto è apparentemente un concetto semplice, quasi banale. I dati sono presentati come se si trattasse di un prodotto, facilmente individuabile, descritto in dettaglio (cos’è, cosa contiene e così via), con metriche di qualità pubbliche e garanzia di disponibilità.

I prodotti hanno maggiori probabilità di essere venduti (riutilizzati, se parliamo di dati) se è possibile costruire un rapporto di fiducia con i potenziali consumatori, ad esempio consentendo agli utenti di scrivere recensioni / faq per aiutare la comunità a condividere la propria esperienza con quella risorsa. Il successo di un asset di dati è guidato dalla sua accessibilità, per questo i data product devono fornire diverse opportunità di accesso per soddisfare le esigenze dei consumatori (tecniche e funzionali), poiché maggiore è la flessibilità che i consumatori trovano, più è probabile che sfruttino tali dati.

Oggi è necessario avere sempre a disposizione anche versioni precedenti dei dati, tenendo traccia dei cambiamenti e potendo accedere in modalità differenti, come ad esempio di tipo stream, o flusso di eventi (sempre che questo sia ragionevole e compatibile con la tipologia di dato), senza essere vincolati alla struttura di tabelle di un database. Ma non concentriamoci troppo sul lato tecnico. L’aspetto veramente rivoluzionario è che ora i dati, come prodotto, hanno un prezzo predefinito e ben determinato, con evidenti effetti sulla capacità di budgeting e reporting di un progetto. In un sistema tradizionale, anche moderno come un data lake, tutte le operazioni sui dati (dall’inserimento, al recupero, alla loro preparazione) sono richieste ai data engineer. Se hanno tempo a disposizione e possono soddisfare subito la richiesta, è ottimo per l’utente, ma non troppo per l’azienda, in quanto implica che c’è sovraccapacità. Ciò non è efficiente e molto, molto costoso. Se sono invece allocati con la precisa capacity per affrontare le esigenze operative quotidiane e i progetti già in cantiere, qualsiasi nuova attività verrà di conseguenza rimandata.

In uno scenario in cui l’IT è un costo fisso per l’azienda, la capacity non può essere ampliata su richiesta. Anche potesse, sarebbe quasi impossibile determinare quanto dello sforzo aggiuntivo è direttamente collegata al nuovo progetto, quanto del lavoro può o potrebbe essere riutilizzato in futuro, quanto alla fine avrebbe dovuto essere fatto e così via. Quando diversi nuovi progetti iniziano contemporaneamente, il sovraccarico IT può facilmente diventare un costo indiretto e, a volte, fuori controllo. Con Data Mesh si ha visibilità immediata della disponibilità dei dati, quanto (e come) vengono utilizzati e qual è il costo associato. Tempo e denaro non sono più sconosciuti (o peggio, indeterminabili in anticipo).

Il punto di svolta

Per comprendere il significato dei prossimi due punti, “Self-service data infrastructure as a platform” e “Federated computational governance“, tracciamo un parallelo con un tipo di piattaforma che in passato ha cambiato le regole del gioco.

È una semplificazione forse eccessiva, ma utile allo scopo. Immaginiamo di lavorare nella logistica e di dover prenotare un hotel per una riunione del reparto vendite. Ci sono alcuni requisiti (numero di camere disponibili, prezzo entro il budget, sala conferenze in loco, parcheggio agevole) e una lista di “nice-to-have” (mezza pensione o ristorante in modo da non dover prenotare un catering per il pranzo, navetta da e per l’aeroporto per chi vola, non troppo lontano dall’aeroporto o dal centro città).

Il Data Lake aziendale contiene tutti i dati che servono: elenca tutti gli hotel della città in cui si svolgerà l’incontro. Ma anche le “Pagine Gialle” di una volta. Quanto tempo ci vuole per trovare un hotel adatto utilizzando una tale directory? È praticamente impossibile da determinare: se l’Abbey Hotel, il primo della lista, soddisfa tutti i requisiti, non troppo, ma se bisogna arrivare allo Zephir Hotel, tra gli ultimi dell’elenco, le cose non funzionano.

Non soltanto sono ordinati in modo predeterminato (in ordine alfabetico), ma è necessario controllare ogni struttura in sequenza, chiamando al telefono per conoscere disponibilità, prezzo e così via. Inoltre, la quantità di informazioni disponibili per ogni hotel nelle Pagine Gialle è selvaggiamente incoerente.

Sarebbe bello poterne escludere un certo numero, quindi non doverli chiamare, ma alcuni hotel hanno acquistato grandi spazi dove scrivono se hanno una sala conferenze o un ristorante, altri hanno solo elencato un numero di telefono.

Se vogliamo controllare anche la qualità di una location, per evitare di mandare il Direttore delle Vendite in una squallida locanda, la complessità cresce esponenzialmente, come l’incertezza di quanto tempo ci vorrà per capirlo. Magari siamo fortunati, e troviamo un collega che è già stato lì e può darci un feedback, altrimenti non resta che verificare di persona. Quando si preventiva la riunione di vendita dell’azienda come si fa a capire quanto costerà, in termini di tempo e denaro, solo trovare l’hotel giusto? Come se non bastasse, il Direttore Commerciale è furioso perché questo problema si ripete ogni anno e non è mai possibile avere una stima, perché il tempo che è stato necessario per trovare un hotel l’ultima volta non è affatto indicativo di quanto tempo ci vorrà la prossima.

Se ora sostituiamo la parola “hotel” con “dati” nell’esempio precedente, ci accorgiamo che il parallelismo può apparire un po’ estremo, ma non così inverosimile. Un Data Mesh è, in questo senso, come una piattaforma di prenotazione (si pensi a hotels.com o booking.com) dove ogni data producer diventa proprietario di dati e, proprio come un proprietario di hotel, vuole essere trovato da chi utilizza la piattaforma. Per poter essere visualizzato in risposta ad una ricerca, però, è necessario che rispetti alcune regole imposte dalla governance federata.

Il proprietario dell’hotel deve elencare un prezzo (costo) e disponibilità (uptime), nonché una descrizione strutturata dell’hotel (set di dati) che includa l’indirizzo, la categoria e così via, e tutti i metadati richiesti (c’è un parcheggio? un ristorante? una piscina? la colazione è inclusa? ecc.). Ognuna di queste funzionalità diventa facilmente visibile (è sempre presente e mostrata nello stesso posto), ricercabile e può fungere da filtro. Le persone che soggiornano presso l’hotel (utilizzano il set di dati) lasciano anche recensioni, che aiutano sia gli altri clienti nella scelta, che il proprietario dell’hotel nel migliorare la qualità della sua offerta o almeno l’accuratezza della descrizione.

L’aspetto self-service è duplice. Dal punto di vista dell’utente significa che con tale piattaforma il reparto Vendite può scegliere e prenotare direttamente l’hotel, senza bisogno (e pagando) dell’aiuto della Logistica (team di Data Lake Engineer). Dal punto di vista del proprietario (hotel o proprietario dei dati) significa che è possibile scegliere e pubblicizzare autonomamente quali servizi offrire (camere con aria condizionata, vasche idromassaggio, servizio maggiordomo e così via) al fine di soddisfare e persino superare i desideri e le richieste dei clienti. Nel mondo dei dati questo secondo aspetto riguarda la libertà dei Data Producer di scegliere autonomamente il proprio percorso tecnologico, in conformità con gli standard approvati dalla governance federata.

Ultimo, ma sicuramente non meno importante, l’architettura Data Mesh comporta la facilità di scalabilità (una volta che sono disponibili tutti gli hotel/set di dati, il sistema può crescere per ospitare anche quelli di altre città/includerne di nuovi) e il riutilizzo. Riutilizzo significa che lo sforzo speso per creare una soluzione può, almeno in parte, essere impiegato (riutilizzato) per crearne un’altra. Atteniamoci all’analogia dell’hotel. Se è stato creato l’anno scorso e ora si vuole procedere con il medesimo sistema per i B&B, c’è molto che può essere sfruttato e non è necessario ripartire da zero. Certo, i “metadati” saranno diversi (i Bed and Breakfast non hanno sale conferenze), ma sarà comunque possibile utilizzare lo stesso sistema di feedback degli utenti, la stessa tecnologia per raccogliere informazioni su prezzi e disponibilità, che, ancora una volta, toccherà al proprietario del B&B tenere aggiornato.

Un progetto e un cambiamento organizzativo

Detto così, sembra che Data Mesh sia un gioco da ragazzi. E questo potrebbe essere vero forse per le grandi aziende, ma costruire un Data Mesh è un progetto mastodontico. Se abbiamo solo tre o quattro hotel, va da sé, non ha senso costruire una piattaforma di prenotazione.

Ciò che è importante tenere a mente, è che un’architettura Data Mesh, per esprimere tutto il suo potenziale, richiede un profondo cambiamento organizzativo in azienda. Per citare l’aspetto più ovvio, i data engineer devono “migrare” dal centro (il Data Lake) ai produttori di dati, per guidarli nel processo di corretta “data preparation”, conformandosi alle regole di governance federata ed esponendoli correttamente in modo che possano essere trovati e utilizzati (generando così anche entrate attraverso le vendite interne per il proprietario dei dati). Richiede anche un cambio di mentalità, in modo che l’intera azienda possa iniziare a considerare i dati come un prodotto, liberandosi dai limiti e dai colli di bottiglia di un Data Lake, raccogliendo i benefici di un’architettura veramente distribuita e quindi, del nuovo paradigma.

Luca Maestri, Chief Financial Officer di Apple, ha affermato che le persone tendono ad attribuire il successo di grandi aziende, come Apple, Amazon, Google o Facebook, al loro essere laboratori creativi, dove possono emergere un gran numero di idee innovative, ma la sua esperienza gli ha insegnato che non è così. Queste aziende hanno successo perché sono “execution machines”, in altre parole, una grande idea non ha valore se non è possibile eseguirla in modo efficace e rapido, rispettando tempi e budget.

Creare un Data Mesh è un’impresa enorme, ma significa costruire le solide basi che supporteranno l’evoluzione del business basato sui dati. Possiamo avere tutti i dati del mondo nel nostro Data Lake, ma se non riusciamo a sfruttarlo, in modo efficace e sostenibile, non ne avremo alcun beneficio. Poiché nel mondo di oggi stare fermi significa tornare indietro, l’unico modo per rimanere competitivi è creare nuovi prodotti, servizi e soluzioni per i propri clienti. Per essere una “execution machine”, è necessario dedicare tempo alla ricerca di opportunità, invece che a cercare dati nel proprio Data Lake, analizzare il mercato e inseguire nuovi clienti. Una volta raggiunto l’obiettivo, la ricompensa potrà essere un week-end rilassante e gratificante, per guardare il placido lago dalla propria casa e ricordare il tempo in cui il proprio Data Lake era ugualmente immobile e non trasparente.