Roberto Coluccio, Data Architect di Agile Lab, spiega come accelerare l’adozione del data mesh e ottenere risultati misurabili migliorando l’engagement dei domini
Negli ultimi anni, la tendenza principale nella gestione dei dati è stata quella di centralizzarli – assieme alle relative competenze tecniche per elaborarli e gestirli – sia a livello fisico (modello Data Lake e Data Warehouse) che tecnico/organizzativo (team centrale IT/Data Engineering). Il panorama tecnologico globale ha supportato queste strategie proponendo, anno dopo anno, sistemi e piattaforme per l’elaborazione dati sempre più efficienti e meno costosi. Tuttavia, questi approcci in contesti “enterprise”, dove la complessità tecnica è pareggiata (se non superata) da quella organizzativa di persone, sistemi, dipendenze, gestione budget e progetti, hanno evidenziato importanti limiti di scalabilità generando scarsi ritorni di investimento sulle piattaforme di elaborazione dati, frustrazione nei team centrali divenuti colli di bottiglia della catena del valore e mancanza di fiducia e garanzie di allineamento a standard di qualità e compliance.
In quest’ottica, la comunità scientifica ha recentemente promosso l’adozione di un nuovo paradigma, il Data Mesh, come alternativa ai modelli Data Lake e Data Warehouse basato su un’architettura (tecnica ed organizzativa) distribuita e decentralizzata, progettata per aiutare le imprese ad acquisire agilità e scalabilità e che riconosce l’importanza di un approccio distribuito (in termini di ownership) e domain-driven – per quanto riguarda l’organizzazione dei dati e del loro ciclo di vita – unito ad uno federato per la relativa governance. Questo consente di pensare ai dati come prodotti offerti e gestiti da specifici domini, andando così incontro ai reali requisiti di business di un’impresa, più che alle singole esigenze applicative, sicuri che gli standard definiti a livello di governance centrale siano rispettati in quanto resi “built-in” in una piattaforma a supporto dei domini, che consenta la creazione guidata di “data products” assieme all’approvvigionamento in modalità “self-service” di risorse infrastrutturali (compute, storage, …).
Ma come intraprendere un progetto Data Mesh di successo? Come è noto, nel mondo IT ogni decisione è tradizionalmente basata sul rapporto costi/benefici. Ci si aspetta che i domini inizino a sviluppare “data product” il prima possibile perché utili a validare l’approccio, ma spesso questo è visto come extra budget da dedicare (sia di sviluppo che di infrastruttura, se è vero che si vuole promuovere e agevolare il consumo di dati al fine di automatizzare e guidare con essi sempre più decisioni di business e fornire servizi avanzati), spaventa in quanto novità, e non sempre è chiaro il valore che il Data Mesh potrebbe portare all’azienda. Ecco dieci consigli pratici per affrontare al meglio questa situazione e implementare una strategia efficace.,
Data mesh, risorse computazionali per la fruizione dei dati a carico dei consumatori
Questa è una decisione architetturale generale, più che un consiglio: sarebbe opportuno progettare le porte di output (e il loro modello di consumo) in modo da fornire un accesso governato condiviso ai potenziali consumatori. Con semplici ACL sulle risorse è possibile offrire un accesso sicuro in sola lettura alle porte di output dei prodotti dati di modo che non siano necessarie risorse di calcolo a livello di dominio (sorgente)/prodotto per consumare quei dati, ma solo se si adottano tecnologie che consentano di disaccoppiare archiviazione e processamento dati (ad esempio, le canoniche architetture con RDBMS non consentono questo disaccoppiamento). In questo modo, le risorse computazionali per la lettura dati sono allocate (e contabilizzate) sul fronte di chi effettivamente li utilizza. Abbiamo quindi trovato un modo per evitare (o ridurre?) il TCO per i nostri data product. Ma quando si tratta del budget per svilupparli?
Progettare una roadmap per la creazione di data product che faccia uso dei flussi di budget già previsti per la manutenzione dei sistemi operazionali
Nelle organizzazioni complesse spesso ci sono diversi flussi di budget destinati alla manutenzione dei sistemi operazionali: è bene sfruttarli per creare Source Aligned Data Product (che fanno parte del dominio, lo stesso che controlla quel budget).
Molto bene, probabilmente ora abbiamo maggiore trazione, ma perché si dovrebbe mantenere la proprietà e responsabilità nel lungo termine su questi data product?
Modello di fatturazione pay-as-you-consume
Questo consiglio è visionario, quasi utopico oggi, ma c’è un punto chiave da cogliere: se si trova un modo per “restituire qualcosa” ai creatori/proprietari/manutentori di Data Product, che sia un budget extra per ogni 5 utilizzatori di una porta di output, o la partecipazione dei consumatori al budget di manutenzione … qualsiasi cosa può sollevare il morale e diffondere la percezione che non debba essere “solo una spesa interna”, bensì un costo condiviso, se non addirittura una fonte di acquisizione di extra budget tanto più si sviluppano prodotti dati di qualità.
Iniziare in piccolo, puntando a dati senza dipendenze “operative” ma con grande potenziale impatto di business
Nessun big bang, scegliere il giusto caso d’uso, cercando opportunità legate alle dirette necessità di business, e farne la propria storia di successo per promuovere l’adozione del paradigma a livello aziendale, senza rischiare troppo intervenendo su flussi dati con dipendenze operative.
Questo probabilmente renderà felici i dirigenti, gli stessi che chiedono ripetutamente budget per migrare (almeno) i workload analitici nel Cloud, senza ottenerlo “perché si sta ancora ammortizzando la spesa per un sistema on-premise”. Ecco lo spunto: se si vuole costruire un Data Mesh, si avrà bisogno di uno stack infrastrutturale che permetta di sviluppare la “Self-Serve Infrastructure-as-a-Platform”. Da qui deriva:
Sfruttare il passaggio verso il Data Mesh come opportunità per migrare al cloud
I team di dominio saranno probabilmente felici di compiere un salto in avanti (nel presente) e lavorare su soluzioni basate su cloud.
Da qui, tuttavia, potrebbero emergere alcune preoccupazioni…
Il Data Mesh è un cambiamento organizzativo che coinvolge i processi e, soprattutto, le persone. Gli individui di solito sono spaventati dalle novità, specialmente nell’ambiente di lavoro dove potrebbero essere “il punto riferimento” per un determinato sistema, o pensare di perdere potere e controllo “diventando semplicemente parte del Data Product Team di un dominio decentralizzato”.
Per questo, ancora prima, è necessario intraprendere i seguenti passaggi organizzativi:
Formare le persone
Fornire Formazione e mentoring alle persone chiave in tutti i domini è un metodo testato con successo per far comprendere perché l’azienda abbia deciso di abbracciare questo percorso. Gli esperti Data Mesh dovrebbero fare da mentori in modo che i responsabili possano, a loro volta, diffondere entusiasmo all’interno dei loro team.
Ma probabilmente i team hanno anche paura di essere costretti a imparare cose nuove, quindi:
Fare in modo che le persone con un background legacy capiscano che questa è la prossima “grande rivoluzione” nel mondo dei dati
Vogliono davvero perdere questa opportunità? Cambiamenti come questo possono avvenire una volta ogni 10 o 20 anni nelle grandi organizzazioni: è bene non sprecarla e uscire dalla zona di comfort!
Ci sono contesti dove il domain-driven-design è già parte integrante del modello organizzativo, ma spesso quando si parla di dati si sottovalutano le relazioni e le dipendenze tra domini diversi. È importante canalizzare e non ignorare i problemi di integrazione (tecnica e di processo), nel modo giusto:
Organizzare workshop collaborativi in cui figure tecniche e business si confrontino e condividano punti di vista e incertezze
Si verrà sorpresi dalla quantità di “debito tecnico nascosto” che emergerà, e le persone inizieranno a entrare in empatia tra loro: si comincerà a trasferire il concetto che i dati che possono portare valore reale all’organizzazione.
Tutto questo termina una volta che i data product sono stati rilasciati? Assolutamente no! Abbiamo parlato di “proprietà e responsabilità nel lungo termine”, quindi dobbiamo fornire una “motivazione a lungo termine”.
Raccogliere chiari insight sul valore prodotto grazie ai dati e renderli accessibili a tutti all’interno dell’organizzazione
Si può iniziare in modo semplice con il “numero di consumatori di un data product” (e se fosse zero?) e passare poi a metriche più complesse come il time-to-market (ci si aspetta che sia ridotto, è il tempo per portare in produzione un nuovo data product), l’effetto rete (più sono le interconnessioni tra i domini, più valore viene probabilmente aggiunto di volta in volta), e altre metriche più specifiche e preziose per l’azienda.
Una volta convinti a sviluppare data product, sorge spontanea la domanda: “da dove si inizia?”
Organizzare workshop collaborativi per identificare le opportunità sui dati
Seguendo la pratica DDD (Domain Driven Design) su cui si basa il primo pilastro di Data Mesh, la Domain-oriented Decentralized Ownership, e aggiungendola a quella del Data-as-a-Product si ottiene un modello di design guidato dalle “decisioni di business” per identificare le opportunità sui dati a supporto (cioè i Data Product da creare per sostenere/automatizzare le decisioni di business guidate dai dati).
