Il Data Mesh e il consumo self-service dei dati come prodotti

Photo by John Schnobrich on Unsplash

Abstract

Questo è il settimo articolo di una serie di blog post finalizzata a trasmettere i punti salienti della visione delle architetture IT enterprise e del Data Management che, come Quantyca, proponiamo ai nostri clienti.

Per chi non li avesse letti, consiglio di leggere gli articoli precedenti della serie, dai titoli:

• “I principi di un moderno Data Management”: descrive le sfide dell’IT nella nuova era di digitalizzazione e i driver che spingono verso la ricerca di un cambio di paradigma nella progettazione delle architetture dati
• “L’approccio data-centrico che cambia l’IT”: descrive i principi e i vantaggi di un orientamento di progettazione delle architetture IT che considera i dati come asset centrale e riusabile e le applicazioni come elementi effimeri che producono o consumano dati di interesse per l’intera azienda
• “L’esigenza di governo nella gestione dei dati”: descrive i principali aspetti di governance da considerare per abilitare architetture IT data centriche e distribuite e mantenere il controllo dei dati a riposo e in movimento
• “L’adattabilità della piattaforma di integrazione in un modello Data Fabric”: descrive un modello emergente di progettazione delle piattaforme dati basato sull’uso avanzato dei metadati per rendere la piattaforma più automatizzata, self-service e versatile alle diverse esigenze degli utilizzatori
• “Il Domain Driven Design applicato ai dati per una maggiore agilità nella progettazione”: descrive i principi basilari del modello di progettazione software Domain Driven Design, che ha introdotto l’idea della decentralizzazione delle responsabilità e ha avuto grande influenza sul Data Management
• “Il Data Mesh e la spinta verso una gestione dati distribuita”: descrive lo scenario di Data Management precedente al modello Data Mesh e le ragioni che hanno portato alla ricerca di decentralizzazione delle responsabilità sui dati in una prospettiva domain-oriented

L’articolo conclusivo, dal titolo “La Data Strategy come motore dell’IT” chiude la serie con un riassunto dei principi architetturali che riteniamo basilari per una strategia di Data Management efficace e una visione del ruolo dell’Enterprise Architect nel delineare l’evoluzione delle architetture dati.

Zhamak Dehghani, negli articoli How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh e Data Mesh Principles and Logical Architecture, ha proposto un cambio di paradigma radicale per il mondo del Data Management, che ha poi ripreso ed esteso nel libro Data Mesh. Il paradigma, chiamato appunto Data Mesh, si basa su quattro pillar basilari:

• domain ownership
• data as a product
• selve-serve data platform
• federated computational governance

In Quantyca riteniamo che le idee alla base del paradigma Data Mesh siano interessanti e che questo rappresenti una direzione di pensiero architetturale e organizzativo per il mondo del Data Management in linea con le aspettative di un business che intende essere sempre più data-driven. Nell’articolo precedente abbiamo discusso il primo pillar, quello della Domain Ownership: ora tratteremo gli altri tre principi fondamentali.

Data as a Product

Il paradigma Data Mesh è in linea con i principi del data-centrismo, in quanto riporta il dato ad avere piena dignità di prodotto digitale (Data as a Product) e a non essere più considerato come by-product delle applicazioni in cui esso viene generato.

Il concetto di Data Product è centrale nel paradigma Data Mesh: esso rappresenta un’unità di deploy afferente ad un determinato ambito di dominio, che mette a disposizione dei consumatori un set di entità dati logicamente correlate e tutte le strutture necessarie per rendere fruibile il loro utilizzo: interfacce di consumo (data API), diagrammi del modello concettuale, logico e fisico dei dati, documentazione funzionale, service level objectives (SLO), metriche di qualità, definizione delle modalità di accesso, delle finalità e dei termini ammessi di utilizzo e, naturalmente, implementazione e deploy delle data pipeline per alimentare le strutture dati che costituiscono il prodotto. Ogni Data Product ha un Data Product Owner, che è la figura responsabile della sua gestione e della sua roadmap di evoluzione.

Un Data Product può produrre le proprie entità dati a partire da entità elementari prodotte da altri Data Product, applicando logiche di integrazione, arricchimento e trasformazioni di rilievo per il dominio di business di afferenza e producendo in output dati derivati, che costituiscono nuova fonte di informazione e che, a loro volta, potranno essere consumati da differenti Data Product presenti nella rete. In questo modo i Data Product formano una rete di architectural quanta pienamente auto-consistenti, ma che garantiscono interoperabilità, per generare ad ogni interazione un contenuto informativo di livello più alto, con una semantica allineata con la terminologia e il modello logico proprio del dominio di riferimento. L’integrazione tra potenzialmente molteplici Data Product differenti per produrre nuovi dati elaborati viene fatta dal Data Product consumatore. In quest’ottica, non si ottiene più un unico modello dati enterprise troppo generico e difficile da evolvere, come accade nel paradigma Data Lakehouse tradizionale, ma il modello dati nel suo complesso è formato da un insieme di sotto-modelli federati specifici di un particolare dominio, eventualmente combinabili.

Modello dati federato ottenuto come mesh di diversi Data Product domain-oriented

Affinchè i Data Product possano fornire il valore analitico atteso, devono essere:

• rintracciabili e facilmente accessibili: dovrebbero essere registrati su un portale aziendale che ne permetta la ricerca, l’esplorazione e la sottoscrizione da parte dei sistemi consumatori interessati;
• comprensibili e auto-descrittivi: dovrebbero essere corredati da adeguata documentazione e caratterizzati da una terminologia business-oriented, che esprima chiaramente il significato semantico dei dati che rappresentano;
• affidabili e autentici: dovrebbero indicare service level objectives (SLO) e service level agreements (SLA), metriche di qualità, il riferimento del product / team owner;
• auto-consistenti e componibili: di base, ogni Data Product dovrebbe poter essere utilizzabile in modo indipendente ma anche insieme ad altri data product per generare informazione derivata;
• sicuri: dovrebbero prevedere tecniche di Data Protection sugli attributi sensibili, politiche di concessione dei permessi di accesso basate sul principio di minimo privilegio e ai soli soggetti autorizzati.

Self-serve Data Platform

Dal punto di vista infrastrutturale e tecnologico, affinchè l’integrazione tra i diversi Data Product a responsabilità distribuita sia efficiente e sostenibile, è necessario predisporre una Data Platform condivisa e fruibile in modalità self-serve a livello aziendale, moderna e poliglotta, che metta a disposizione il set di tecnologie e di servizi di utilità fondamentali per implementare la pubblicazione e la messa a disposizione dei Data Product verso i sistemi consumatori nel modo più efficace possibile.

E’ importante sottolineare che un paradigma come il Data Mesh, che prevede una rete di Data Product auto-consistenti e componibili uno con l’altro non deve essere interpretato nè come una spinta a produrre dei data silos nè come la proposta di uno stile di integrazione punto a punto: al contrario, l’integrazione dovrebbe seguire uno stile hub & spoke e pattern scalabili quali, ad esempio, il pattern Publish — Subscribe, secondo cui un dominio di business pubblica i propri Data Product su uno o più componenti di middleware (come ad esempio un data bus o un object store), o li rende accessibili tramite un gateway di Data API: i domini consumatori che intendono utilizzare un Data Product di un altro dominio possono farne richiesta e ottenerne l’accesso tramite un modello a sottoscrizione.

Nell’ottica del Data Mesh, ogni dominio può attingere dati da uno o più Data Product messo a disposizione sulla piattaforma di integrazione condivisa, applicare le proprie logiche funzionali, generare nuovi dati da pubblicare a loro volta sulla piattaforma condivisa sotto forma di nuovi Data Product, come mostrato nella figura seguente.

Il ruolo della piattaforma di integrazione condivisa e self-serve nell’integrazione dei data product

Per rendere sostenibile la decentralizzazione delle responsabilità e della gestione dei Data Product nei diversi team cross-funzionali dei domini di business, è fondamentale mascherare ai domini la complessità tecnica delle operazioni di Data Management comuni, arricchendo l’infrastruttura con servizi di integrazione intelligenti, capaci di automatizzare i task ripetitivi ed esenti da logiche di dominio specifiche e permettere ai domini di focalizzarsi sullo sviluppo di Data Product di qualità. La piattaforma di integrazione self-serve si pone questo obiettivo, pertanto richiede un team centrale di Platform-Engineers e Data-Ops a cui affidare la responsabilità di ingegnerizzare la piattaforma, arricchire le feature di automazione e i servizi di utilità disponibili, oltre che implementare dei framework per fare enforcing continuo delle policy definite per garantire l’interoperabilità dei Data Product.

A livello organizzativo il cambiamento che ne deriva è significativo: si passa dallo scenario precedente, in cui figure specializzate in data engineering e data warehouse erano riunite in un team centrale responsabile di implementare i flussi di integrazione dati di ambiti di dominio più disparati, senza conoscerne il significato funzionale, con un effort significativo di coordinamento e passaggi di consegna con i team di dominio, ad un nuovo scenario, in cui i team di dominio gestiscono in autonomia il ciclo dei dati end-to-end, avvalendosi del supporto di una piattaforma di integrazione altamente ingegnerizzata da un team di specialisti che si concentrano solamente sugli aspetti tecnici.

Un’altra caratteristica che si osserva sempre di più nel panorama digitale è la convergenza tra processi operazionali e use case analitici, abilitata dalle tecnologie che permettono di integrare servizi ed elaborare dati in real time. L’esempio più evidente in questo senso è dato dai sistemi di real time recommendation personalizzata, che sfruttano l’output di processi analitici a bassa latenza per abilitare azioni che hanno un impatto diretto sull’esperienza utente e, di conseguenza, sull’andamento del core business. Pertanto, la piattaforma di integrazione usata per condividere i Data Product deve supportare questi use case ibridi, a cavallo tra il contesto operazionale e il mondo di Data Management analitico.

Il ruolo della piattaforma self-serve è fondamentale per implementare la parte applicativa del quarto e ultimo pillar di Data Mesh, ovvero la Federated Computational Governance, che descriviamo nella sezione seguente.

Federated Computational Governance

L’ultimo pillar del paradigma Data Mesh pone il focus sul modello di governance che è necessario adottare in uno scenario in cui i team che operativamente gestiscono lo sviluppo e la manutenzione dei Data Product sono molteplici e le responsabilità sono distribuite.

Tradizionalmente si è portati a pensare che l’indipendenza di diversi gruppi di lavoro e la garanzia di rispettare standard e convenzioni comuni siano inversamente proporzionali, pertanto la soluzione a cui spesso si fa ricorso è quella di centralizzare la facoltà di definire le policy, implementare il modello dati e sviluppare le pipeline in un unico team, che applica gli standard condivisi e detiene i permessi per usare gli strumenti tecnologici aziendali, come i tool di integrazione e orchestrazione dati e i data store alla base del data lake e del data warehouse.

Tuttavia, l’obiettivo di democratizzazione e di diffusione dei dati come asset su larga scala a cui mira il paradigma Data Mesh poco si sposa con modelli organizzativi che prevedano soggetti centrali che rallentino il lavoro autonomo delle diverse anime funzionali dell’azienda. D’altra parte, affichè i Data Product non diventino dei silos ma formino realmente una rete di elementi interoperabili e riusabili, alcuni standard sulla definizione e il trattamento dei dati condivisi vanno garantiti, altrimenti si corre il rischio di generare prodotti di bassa qualità e poco affidabili.

Il paradigma Data Mesh propone di adottare un modello di governance computazionale federato, in cui si cerca di formare una community di persone che siano rappresentanti dei diversi team di dominio che sviluppano i Data Product, del team di Platform Engineering che industrializza la piattaforma, del team di Enterprise Architecture che definisce gli stili architetturali raccomandati, uniti a esperti di aree tematiche specifiche (Subject Matter Expert) come la data privacy e la compliance normativa. La community così costituita definisce in modo cooperativo e federato le best practice, i pattern, le guidelines e i guardrail basilari a cui tutti i team di dominio devono attenersi nella realizzazione dei propri Data Product e nell’interazione con la piattaforma di integrazione self-serve condivisa.

Modello di governance computazionale federato del Data Mesh

Alcuni esempi di standard e convenzioni possono essere:

• l’assegnazione delle ownership sui data product ai team di dominio;
• la gestione degli identificativi delle entità dati core tra diversi sistemi;
• la definizione di policy di evoluzione delle interfacce (data API e schemi degli eventi), regole di compatibilità backward e forward;
• la definizione dei metadati comuni da inserire nei flussi dati per tracciare classificazione dati e lineage;
• i pattern di integrazione da seguire per i diversi casi d’uso;
• i processi per fare richiesta di accesso e sottoscrizione ad un dataset;
• la scelta della mappa tecnologica;
• il periodo di retention consentito e i vincoli per la rappresentazione in chiaro di dati sensibili.

L’implementazione del modello di governance federato fa leva sulle funzionalità avanzate di automazione messe a disposizione dall’infrastruttura self-serve alla base: infatti, mentre la definizione delle regole deve essere fatta dalla community federata di soggetti incaricati appena descritta, l’applicazione dei guardrail e di alcuni tipi di policy, affinché sia robusta, affidabile, sicura e manutenibile, dovrebbe evitare il più possibile attività manuali, che spesso sono soggette a errori, ma essere automatizzata tramite script e utility basate su codice versionabile, portabile e riproducibile.

Punti di contatto tra Data Mesh e Data Fabric

Le caratteristiche proprie della piattaforma di integrazione self-serve prevista dal paradigma Data Mesh e il suo punto di contatto con l’implementazione effettiva della governance computazionale sembrano essere in linea con i pillar basilari di un design Data Fabric (fatta eccezione per il carattere federato del modello di governance Data Mesh): in questo senso, si può comprendere come Data Mesh e Data Fabric non siano due opposti, ma rappresentano due modelli che possono coesistere, come mostrato nella figura seguente.

Coesistenza tra modello Data Fabric e paradigma Data Mesh: il modello di governance computazionale diventa effettivamente federato con l’adozione di Data Mesh

Infatti il modello di piattaforma Data Fabric può rappresentare una tipologia di implementazione della componente tecnologico-infrastrutturale del Data Mesh, fornendo una piattaforma di integrazione intelligente, che permette di rimuovere dai team che realizzano le data pipeline l’onere di replicare funzionalità comuni a complessità puramente tecnica, invarianti rispetto alle logiche funzionali di un particolare dominio.

Inoltre, la forte ricerca dell’automazione e la propensione all’apprendimento continuo metadata-driven che caratterizza una Data Fabric può essere, in un certo senso, un fattore abilitante per un cambiamento organizzativo in direzione Data Mesh, in particolare verso l’obiettivo di superare una divisione dei team per competenze tecniche specifiche verticali a favore della formazione di team cross-funzionali. Questo diventa possibile in quanto molte delle attività manuali normalmente affidate ad esperti di tecnologia o di aree specifiche del Data Management verrebbero automatizzate o gestite in parte tramite intelligenza artificiale dalle funzionalità della Data Fabric.

L’implementazione completa di un approccio Data Mesh può avvenire come fase successiva rispetto al consolidamento di una Data Fabric, nel momento in cui l’azienda è matura per introdurre un utilizzo della piattaforma di integrazione basato su un modello organizzativo decentralizzato, domain-oriented e controllato con un principio di governance computazionale federata.