Nell'ultimo anno e mezzo, la strategia di integrazione dei dati è stata al primo posto per molti dei leader della tecnologia aziendale.
Nel primo post di questa serie sulla capitalizzazione dell'economia dei dati, abbiamo esplorato i motivi per cui i dati sono così preziosi. Nel secondo post, abbiamo introdotto il concetto di liquidità dei dati e come le API possono essere utilizzate per “liquefare” i dati.
In questo terzo e ultimo post, esamineremo l'approccio emergente della data mesh, analizzandone le implicazioni sull'accesso distribuito ai dati nell'azienda e come si inserisce in un approccio consigliato per affrontare l'intersezione degli ambiti analitici e applicativi.
Il concetto di data mesh è stato introdotto all'inizio del 2019 da Zhamak Dehghani. Ha lo scopo di risolvere i problemi tipici dell'analisi dei dati aziendali. Per sfruttare il rapido ritmo dell'innovazione tecnologica nel regno dei big data, le piattaforme dati - e, per associazione, i dati su di esse archiviati - sono state in genere di proprietà e gestite da team centralizzati di esperti.
Questo approccio monolitico provoca colli di bottiglia e la mancanza di esperienza nel dominio aziendale nel team centralizzato ha portato a problemi di proprietà e qualità dei dati.
Il concetto di data mesh è stato originariamente definito con tre principi. Il primo consiste nell'utilizzare un approccio architetturale basato su dominio distribuito con i dati per disporre di dati allineati al business e stabilire la proprietà appropriata.
Questo ha lo scopo di aiutare a migliorare la qualità dei dati e la scalabilità organizzativa. Il secondo principio consiste nell'adottare un approccio di pensiero legato al prodotto per gestire i dati del dominio.
Si tratta di fare in modo che i team di dominio si assicurino che i loro dati siano rilevabili, indirizzabili, affidabili, autodescrittivi, interoperabili e sicuri. Questo insieme di attributi estende i principi dei dati “fair” che stanno diventando sempre più popolari.
Il terzo principio consiste nell'adottare un approccio self-service alla piattaforma di dati, per liberare il team di ingegneria dei dati centralizzati dall'essere i proprietari generali dei dati e della piattaforma per concentrarsi sulla progettazione, la manutenzione e la gestione di una piattaforma multi-tenant.
Questo principio ha lo scopo di aiutare i team di dominio a lavorare nel modo più indipendente possibile per rimuovere i colli di bottiglia e avere un impatto positivo sulla qualità, facendo in modo che i team che producono i dati siano più vicini ai consumatori degli stessi.
I tre principi sono riassunti nell'immagine sottostante.
Ora che abbiamo capito cos'è una data mesh e qual è il suo scopo, parliamo brevemente di cosa non è.
Tendiamo a sovraccaricare i termini nella tecnologia e la vertiginosa serie di parole d'ordine che incontriamo può portare le persone a fare supposizioni.
Pensiamo, ad esempio, ai microservizi. In quanti sono ossessionati da quanto dovrebbe essere grande un microservizio quando non è mai stato questo il punto centrale?
Bene, in effetti esiste un concetto separato noto come "data fabric" che è stato nel settore per diversi anni. Originariamente era usato per descrivere l'idea di unire tutti gli strumenti nel ciclo di vita dell'analisi dei dati in un'unica piattaforma, ma Gartner ha recentemente utilizzato il termine per definire un concetto più incentrato sui metadati associati al panorama dei dati di un'organizzazione. In ogni caso, data fabric non è uguale a data mesh.
Un altro concetto popolare nell'ambito delle applicazioni distribuite è "service mesh". Potrebbe essere allettante pensare alla data mesh come a una "service mesh per i dati" ma sarebbe sbagliato.
Secondo MuleSoft, "service mesh" è molto più di un approccio di implementazione distribuita alla comunicazione tra servizi in un paradigma applicativo basato su container.
Un'analogia migliore è pensare alla data mesh come all'applicazione dei principi dell'architettura a microservizi al paradigma dell'analisi dei dati.
È importante, in questo caso, opporre resistenza al pensiero analogico ed essere il più aperti mentalmente possibile. Il mondo analitico rappresenta una grande parte del panorama di ingegneria del software, è molto diverso dal mondo dell’interfaccia utente, delle applicazioni in tempo reale.
Considerazioni diverse cambiano le modalità con cui potresti ottimizzare e quali decisioni architetturali dovresti prendere, alcune delle quali sono abbiamo trattato nel precedente post.
Vedere la situazione con tale mentalità ha portato MuleSoft a sottolineare alcune aree in cui il concetto di data mesh sarà messo in discussione mentre le aziende si sforzano di adottarlo.
In primo luogo, le forze fondamentali stanno guidando la centralizzazione dei dati. Nella prima parte di questa serie di post, abbiamo detto che l'economia dei dati dimostra che la correlazione dei dati, a volte anche fortuitamente, può portare alla crescita esponenziale del suo valore.
Zhamak Dehghani, Director of Emerging Technologies, Data Mesh Founder, Member of Tech Advisory Boards, associa questa esigenza a dati correlati e aggregati; secondo MuleSoft, le forze di centralizzazione saranno ancora più difficili da superare della gravità dei blocchi monolitici nel mondo delle applicazioni (che è già abbastanza difficile).
In secondo luogo, il modo in cui viene proposta la data mesh, MuleSoft ritiene che ci sarà la tendenza a "cominciare dal retro" e provare a dividere i domini dei produttori e ad avere team di prodotto allineati per ciascuno.
Anche se questo si adatta a un approccio architetturale purista, potrebbe essere un passo falso per le organizzazioni.
Per instillare una certa mentalità di prodotto, è necessario concentrarsi sullo scambio di valore. Sono i consumatori che stanno acquisendo valore nello scenario della data mesh, quindi MuleSoft ritiene che il primo posto per introdurre il pensiero del prodotto sia sui prodotti di dati che vengono consumati e non sugli elementi costitutivi del dominio sottostanti.
Abbiamo osservato nel progettare le API come prodotti, che è sempre meglio iniziare con il consumatore e lavorare a ritroso.
Una considerazione da fare sulle aziende che implementano la data mesh è che ci sono molti fattori da considerare (in particolare metodi statistici particolarmente validi) quando si tratta di qualità dei dati, e la data mesh non potrà risolverli tutti. Come con tutti i nuovi approcci, è importante ottenere il contesto giusto.
L'ultimo aspetto della data mesh che vogliamo evidenziare è quello forse più intrigante, ed è proprio lì nel nome. Quando esaminano le proprie strategie sui dati, molte organizzazioni si concentrano su dove inserire i dati.
Data warehouse, data lake e piattaforme di dati cloud contengono tutti un riferimento intrinseco alla posizione dei dati stessi.
Se osserviamo il mondo dei dati dal punto di vista del consumatore, la posizione dei dati è secondaria rispetto alla capacità di accedervi dal punto di utilizzo. In sostanza, ai consumatori non interessa una piattaforma dati, ma ciò di cui hanno bisogno è una rete di dati. E la rete di dati è progettata con una mentalità di rete.
In conclusione, c’è sicuramente molto altro da esplorare sull'intersezione di analisi e applicazioni tramite le API. Se desideri saperne di più sulle offerte di MuleSoft nell’ambito dello spazio dati invia una mail a cio@florence-consulting.it o chiama lo (055) 538-3250.
Visita la pagina dedicata sul nostro sito per ricevere ulteriore materiale informativo o per richiedere una demo gratuita.
In alternativa, puoi compilare il form sottostante con la tua domanda.
