Modernizzare il data management agendo sia a livello organizzativo che tecnologico e favorendo business agility e riduzione dei costi di integrazione.
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.
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:
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:
A livello tecnologico il focus è sull’automazione dei processi di integrazione, realizzata per mezzo di:
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.
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:
La composizione delle responsabilità dei team prevede due casi limite:
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.
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.
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.
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.
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.
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.
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:
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
Video
Free
Slide
Subscription
Video
Free
