AI
Platform Engineering
Governance
Quantyca Data Mesh use cases image
Scopri

Contesto

Il mercato dei dati e degli analytics continua a crescere costantemente e tutte le organizzazioni riconoscono nei dati un asset chiave per il proprio vantaggio competitivo. Tuttavia il data management si trova in difficoltà tra il dover soddisfare le richieste continue e il dover fare i conti con team IT che fanno da collo di bottiglia e i cui principali sforzi sono legati alla gestione dei dati e alle integrazioni necessarie per la loro  fruizione.

 

Quantyca Data Mesh: evoluzione de ruolo nella tecnologia

 

Storicamente l’IT veniva visto come un centro di costo alla mercé del business e la tecnologia come uno strumento per creare asset digitali, nel tempo c’è stata una convergenza che, con la quarta rivoluzione industriale, ha visto il riconoscimento del ruolo centrale della tecnologia non solo per digitalizzare i processi ma anche per la realizzazione di nuovi processi o modelli di business.

L’IT ha sempre meno una funzione di supporto e si afferma come vera e propria funzione di business. I dati sono protagonisti di questo cambio di assetto, spodestando il ruolo ricoperto storicamente dalle applicazioni, e imponendo un ripensamento e adeguamento del data management.

Tra le principali difficoltà degli approcci tradizionali al data management ci sono:

  • l’inadeguatezza del budget IT, che non cresce in modo proporzionale alla domanda e porta ad un gap tra richieste del business e capacità di delivery dell’IT
  • l’esigenza della digital transformation di un numero costantemente in crescita di applicazioni
  • la crescita dell’offerta tecnologica e la spinta della digital transformation, che portano ad un aumento della spesa per le integrazioni
  • la sempre maggior complessità delle integrazioni, dovuta principalmente a :
    • approccio storicamente centrato sulle applicazioni 
    • moltiplicarsi delle sorgenti e dei consumatori dei dati
    • convergenza tra use case transazionali e analitici

 

I moderni approcci al data management al fine di poter scalare i processi di acquisizione, consolidamento e utilizzo dei dati si concentrano su aspetti di natura sia organizzativa che tecnologica. A livello organizzativo il focus è sulla scalabilità del modello operativo, realizzata per mezzo di:

  • gestione strategica dei dati come prodotti
  • decentralizzazione delle ownership sui domini

 

A livello tecnologico il focus è sull’automazione dei processi di integrazione, realizzata per mezzo di:

  • Active metadata
  • Declarative services
  • AI driven integrations

 

Mentre l’approccio Data Fabric si sofferma esclusivamente sugli aspetti tecnologici, il Data Mesh si concentra prima sugli aspetti organizzativi per poi arrivare a quelli tecnologici e si fonda su quattro principi:

Domain Ownership
distribuire le  responsabilità relative ai dati non per fase della pipeline di integrazione (ad esempio,  ingestion, transformation, enrichment, ecc.) ma per dominio di business (ad esempio, Product Discovery, Payments, Shipment, ecc..). La responsabilità del dato è più prossima al team che lo produce e non è affidata ad altri intermediari.

Data as a Product
trattare come un vero e proprio prodotto, ad esempio definendo in modo chiaro le loro interfacce di accesso, garantendone la qualità, prevedendone il versionamento, documentando tutto il necessario  e rispettando SLO e SLA concordati con i diversi consumatori. Un prerequisito è la possibilità di gestire il dato insieme ai processi che lo generano e all’infrastruttura sottostante come un unità atomica di deployment (architectural quantum).

Self-Serve Data Platform
una piattaforma condivisa agnostica rispetto ai singoli domini che offre servizi in modalità self service per  le funzionalità necessarie allo sviluppo dei data product evitando che se ne faccia carico ogni singolo dominio. Obiettivo è abbattere la complessità di utilizzo permettendo ai team di prodotto di concentrarsi maggiormente sulle logiche di integrazione e meno su aspetti tecnici.

Federated Computational Governance
garantire l’interoperabilità tra i dati esposti dai diversi data product per mezzo di un processo di governance federato in cui un team centrale, spesso composto dai rappresentati dei diversi team di prodotto e piattaforma, definisce delle policy globali che poi devono essere implementate localmente con il supporto della piattaforma e verificate in modo automatico.

Punti Critici

Il data mesh ha galvanizzato tutta la comunità del data management e propone un approccio innovativo con impatti tecnologici ma anche, e soprattutto, organizzativi. Tuttavia è un approccio giovane che deve ancora dimostrare su vasta scala la sua validità, richiede molti sforzi e non è adatto per tutte le organizzazioni

L’attuazione del paradigma Data Mesh deve fare i conti con diverse difficoltà, tra cui:

impatti organizzativi e tecnologici
non è un prodotto acquistabile e utilizzabile istantaneamente, è un approccio al data management che interviene sia a livello organizzativo che tecnologico

→ immaturità e lacune del mercato tecnologico
le tecnologie in circolazione risolvono problemi puntuali o sono tentativi di riposizionarsi in questo spazio di offerta da parte di grandi player ed è necessaria una struttura di engineering preparata per costruire la propria piattaforma

stabilità della soluzione
è un approccio piuttosto recente e le organizzazioni disposte ad adottarlo devono avere capacità e voglia di sperimentare soluzioni ancora da perfezionare

propensione al cambiamento e sponsorship
una profonda trasformazione organizzativa richiede forte sponsorship e diffuso buy-in ed è sostenibile solo per organizzazioni in grado di metabolizzarla e pronte a mettere in discussione le scelte del passato

Inoltre il data mesh può essere adottato secondo diverse declinazioni in funzione della decentralizzazione che si pensa di attuare e che lavora su due assi:

  • le responsabilità dei team
  • il perimetro della governance centrale

La composizione delle responsabilità dei team prevede due casi limite:

  • totale decentralizzazione con un’organizzazione che prevede tutti i team autonomi nei loro domini e il loro affiancamento da un team di platform
  • totale centralizzazione prevedendo la sola separazione tra il team di platform e l’unico team che si occupa di tutti i data product

Il perimetro d’azione del team centrale di governance può limitarsi allo stretto indispensabile dando luogo a un mesh con topologia completamente distribuita con la massima libertà per i team di prodotto e una piattaforma a supporto snella. Se invece il perimetro è vasto si avrà un mesh fortemente governato, con meno gradi di libertà per i team di prodotto e una piattaforma a supporto più articolata e convergente verso un modello data fabric.

 

Quantyca Data Mesh decentralizzazione

 

Molteplici sono quindi le possibili combinazioni di livelli di decentralizzazione lungo queste due dimensioni che possono portare alla traduzioni dei principi originari in implementazioni del modello data mesh anche molto diverse tra loro. Spesso una stessa organizzazione può passare in modo incrementale attraverso diversi modelli di mesh prima di raggiungere il livello di decentralizzazione ottimale per il suo contesto.

Soluzione

Attraverso i nostri servizi di advisory guidiamo i nostri clienti nel definire la data strategy e attuarla implementando soluzioni con un approccio moderno al data management. E’ all’interno di questo processo che si valuta anche l’adeguatezza del paradigma data mesh sia a livello organizzativo che tecnologico. Per sostenere l’implementazione del data mesh abbiamo inoltre prodotto degli strumenti per gestire le sfide relative alla tecnologia e alla governance.

La nostra soluzione ha inizio con la comprensione della realtà di un’organizzazione e dei suoi bisogni, ciò avviene durante le fasi di analisi del processo di definizione della data strategy, in cui si chiariscono tutti gli elementi funzionali e applicativi di un’organizzazione, tra cui le difficoltà e le aspettative, il modello di business e la struttura organizzativa, i processi e i domini, i sistemi e i dati. A questa fase segue la definizione della soluzione, declinata sulle stesse dimensioni, in cui, se applicabile, si valuta l’adozione del paradigma data mesh e la produzione dei dettagli con cui implementarlo.

 

Se il contesto è stato reputato adeguato per l’adozione del paradigma data mesh, due ingredienti sono fondamentali per consentire lo sviluppo dei suoi costituenti base, i data product:

un contratto che descrive formalmente le interfacce esterne, i componenti interni e chi è responsabile dei dati esposti

una piattaforma in grado di mantenere questi contratti, farli rispettare e utilizzarli per automatizzare il ciclo di vita del prodotto in modalità self-service

Il contratto è fondamentale in quanto garantisce un metodo condiviso e chiaro per descrivere tutti gli elementi dei data product. Il ruolo della piattaforma è invece quello di rendere il più possibile semplice, scalabile e automatizzata la gestione dei data product utilizzando i suoi servizi e workflow interni, come la registrazione, la convalida, la creazione e la distribuzione.

 

DataMesh: consumer infrastructure

 

La specifica, e di conseguenza il descriptor, descrive il data product, mentre la piattaforma utilizza i descriptor per automatizzare le operazioni del prodotto. Come specifica adottiamo la Data Product Descriptor Specification (DPDS), una specifica aperta che definisce in modo dichiarativo un data product in tutti i suoi componenti utilizzando un documento descrittore JSON o YAML. È rilasciata sotto licenza Apache 2.0 e gestito dalla Open Data Mesh Initiative. DPDS è indipendente dalla tecnologia  e raccoglie la descrizione di tutti i componenti utilizzati per costruire un data product: dall’infrastruttura fino alle sue interfacce. DPDS è stato progettato per essere facilmente estendibile utilizzando proprietà personalizzate o sfruttando standard esterni come OpenAPI, AsyncAPI, Open SLO, ecc. per definire i suoi componenti.

Utilizzando la specifica si può garantire l’interoperabilità tra i vari data product definendo a livello centrale delle policy, responsabilità del team di governance federato, mentre i team di prodotto sono responsabili dell’implementazione di prodotti conformi a questi standard.

 

DataMesh: data product entity

 

Per l’implementazione si fa affidamento su una piattaforma condivisa tra i vari team di prodotto e accessibile in modalità self-service. L’obiettivo dell’architettura è controllare e facilitare l’implementazione di standard condivisi, contenere il carico cognitivo sui vari team di prodotto, ridurre il TCO e automatizzare il più possibile le attività di gestione dei dati. I suoi servizi possono essere organizzati in questi tre gruppi:

utility plane: è responsabile della fornitura dei servizi per l’accesso alle risorse infrastrutturali sottostanti. I servizi esposti disaccoppiano i consumatori dalle applicazioni e dalle risorse effettive fornite dall’infrastruttura sottostante

data product experience plane: offre una serie di operazioni per gestire il ciclo di vita dei dati: creazione, aggiornamento, controllo delle versioni, convalida, distribuzione, ricerca e disattivazione

data mesh experience plane: in grado di operare con più data product sfruttandone i metadati, mira a offrire un marketplace in cui i data product possono essere cercati, approfonditi e collegati.

 

DataMesh platform

 

La piattaforma Open Data Mesh (ODM) è la soluzione che utilizziamo internamente per realizzare questa architettura. Sarà open source all’inizio del 2023. La piattaforma ODM al momento ricopre esclusivamente i servizi dell’utility plane e del data product experience plane, mentre il data mesh experience plane può essere sviluppato utilizzando strumenti di governance disponibili sul mercato, come Collibra o Blindata, o attraverso soluzioni personalizzate.

L’Utility Plane espone le principali funzionalità presenti dell’infrastruttura sottostante che verranno successivamente orchestrate dal data product experience plane per fornire servizi di alto livello ai team di prodotto in modo self-service e dichiarativo. Alcuni esempi di servizi comunemente esposti dal piano di utilità includono:

Policy Service, che controlla le politiche di governance globale

Meta Service, che propaga i metadati associati al data product su un sistema di gestione dei metadati dedicato, come Confluent Schema Registry, Collibra o Blindata.

Provision Service, responsabile della gestione dell’infrastruttura

Build Service, che compila le applicazioni e genera artefatti eseguibili

Integration service, che esegue il deployment degli artefatti delle applicazioni

L’Utility Plane disaccoppia i servizi del Data Product Experience Plane dall’infrastruttura sottostante, consentendone l’evoluzione indipendente con un impatto minimo sui prodotti già implementati. Ogni servizio dell’Utility Plane è composto da un’interfaccia standard e da un adattatore collegabile che interagisce con una specifica applicazione infrastrutturale sottostante: peculiarità che rende la piattaforma facilmente estendibile e adattabile.

 

DataMesh diagramma

 

Il Data Product Experience Plane espone i servizi necessari per gestire il ciclo di vita di un data product. Tra i servizi base che un tipico piano di prodotto deve fornire ci sono il Registry Service e il Deployment Service. Il Registry Service consente di pubblicare e associare una nuova versione del descriptor al data product e di renderlo disponibile su richiesta. Il Deployment Service è responsabile della gestione, della creazione e del rilascio del Data Product Container basato sul descriptor. Per fare ciò, orchestra i servizi offerti dall’Utility Plane nel modo seguente:

  • Analizza il codice dell’applicazione e genera un file eseguibile, ove necessario, utilizzando il Build Service
  • Crea l’infrastruttura utilizzando il Provision Service
  • Registra tutti i metadati nel repository di metadati esterno attraverso il Meta Service
  • Distribuisce le applicazioni utilizzando l’Integration Service

Inoltre, ogni volta che si verifica una modifica significativa allo stato del data product, è possibile chiamare il Policy Service per verificare la conformità con i criteri globali

Vantaggi

Facilità di accesso ai dati
Interoperabilità dei dati
Maggiore Data Governance
Flessibilità e autonomia dei team
Agilità e scalabilità
Migliore data quality

Resources

Slide
Subscription
06/10/2022

Digital Integration Hub per il monitoraggio in near-real time della logistica: il caso Arcese – Data in Motion Milan 2022

Video
Free
06/10/2022

Digital Integration Hub per il monitoraggio in near-real time della logistica: Il caso Arcese

Hai bisogno di una consulenza personalizzata? Contattaci per trovare la soluzione migliore!

Questo campo serve per la convalida e dovrebbe essere lasciato inalterato.

Entra a far parte del team Quantyca, facciamo squadra!

Siamo sempre alla ricerca di persone di talento da inserire nel team, scopri tutte le nostre posizioni aperte.

VEDI TUTTE LE POSIZIONI APERTE