Al giorno d’oggi, i dati rappresentano per le realtà imprenditoriali un asset fondamentale da cui non è più possibile prescindere se si vuole vincere la concorrenza ed emergere nel proprio settore di competenza – qualsiasi esso sia. Strumenti di primaria rilevanza per il management che grazie a una corretta gestione ed elaborazione dei dati è in grado di prendere decisioni migliori massimizzando le performance aziendali. La trasformazione in una data driven company non deve tuttavia essere considerata come una semplice adozione di una tecnologia, ma un cambiamento più profondo che coinvolge l’azienda su più livelli. Una modifica nella cultura, nel mindset e nell’organizzazione aziendale. Come intraprendere questa evoluzione? Varie le modalità esistenti, ma, attualmente, una in particolare sta attirando l’attenzione del mercato e degli addetti ai lavori: il Data mesh.
Data mesh, cos’è
Introdotto nel 2019 da Zhamak Dehghani, questo innovativo paradigma abbraccia modifiche socio-tecnologiche per agevolare futuri sviluppi e iniziative legati ai dati con il fine ultimo di incrementare flessibilità e agilità nell’accesso, utilizzo e condivisione degli stessi.
Uno degli obiettivi che questo approccio si propone di raggiungere è infatti la riduzione del gap tra chi produce i dati – responsabili dei vari sistemi/processi di business – e chi li consuma, che in questo modo può usufruire di informazioni affidabili.
Prima di analizzare nel dettaglio gli aspetti organizzativi essenziali per un’efficace introduzione del Data mesh è necessario definire i quattro elementi chiave che costituiscono l’anima di questo approccio.
I quattro pillar del Data mesh
In letteratura, il Data mesh si fonda su quattro pilastri volti a superare le principali criticità di un approccio tradizionale al Data warehouse e al Data lake: decentralizzazione, data as a product, infrastruttura self-service e governance federata.
- La decentralizzazione dei domini: alla base del Data mesh vi è il concetto di “dominio” al quale vengono delegate tutte le attività di gestione del dato e di business rule. Il gruppo di lavoro di esperti dedicato è così in grado di amministrare in autonomia le proprie pipeline di elaborazione dei dati (ETL). Una volta che i dati sono stati raccolti e in seguito trasformati dal rispettivo dominio di business, gli owner possono quindi sfruttarli e condividerli per esigenze analitiche o operazionali.
- Data as a product: considerando il dato come un prodotto tutti i soggetti (interni ed esterni al dominio di appartenenza del dato) possono utilizzarlo facilmente. Per essere considerato tale, il Data product deve essere reperibile, accessibile, affidabile, comprensibile, interoperabile e sicuro.
- Infrastruttura self-service: bisogna predisporre una self-serve data infrastructure ovvero una Data platform che espone servizi e capabilities per abilitare i team di dominio nella gestione il ciclo di vita dei Data product in autonomia.
- Governance federata: al fine di rendere i Data product interoperabili tra loro, e facilmente “consumabili” da tutti è opportuno che vi sia un modello di governance che – oltre a decentralizzare i domini e mantenere l’autonomia dei team – definisca un set di regole globali da applicare a tutti i Data product e alle loro interfacce di comunicazione.
Da considerare che un Data mesh di successo non si ottiene tramite la semplice adozione degli elementi appena citati, ma attraverso un approccio olistico che prenda in analisi aspetti organizzativi, metodologici, architetturali e culturali (in termini di data culture). L’azienda deve essere perfettamente consapevole che il paradigma – ben lontano dall’essere una semplice tecnologia da integrare nei propri sistemi – è il motore che innesca trasformazioni in vari ambiti quali, ad esempio, mindset, responsabilità e mansioni.
Il focus sulla struttura aziendale interna
Sono diversi i fattori critici di successo che influiscono sulla corretta e snella implementazione a livello aziendale. Ad esempio, la sola individuazione di una Data strategy – attraverso la quale definire domini, use case, priorità, ownership, aspetti architetturali – non è del tutto sufficiente.
In parallelo, risulta vitale adottare un piano di decentralizzazione valutando gli aspetti e le caratteristiche dell’azienda comprendendo così quando è opportuno spostare l’ownership dei domini o, al contrario, mantenere un assetto maggiormente centralizzato.
Si riscontra però anche la necessità di effettuare un passaggio graduale e incrementale. Idealmente si dovrebbe, infatti, prevedere un’adozione iniziale di alcuni aspetti, da ampliare progressivamente, affinché il Data mesh possa affinarsi e migliorarsi, evolvendo in un concetto più esteso che coinvolga l’intera organizzazione aziendale.
Prima di indirizzare la propria realtà verso il Data mesh, come detto, sono vari gli aspetti da tenere in considerazione. In questo articolo verrà approfondito l’aspetto del modello organizzativo attraverso il quale si intende definire una struttura interna in grado di facilitare l’interoperabilità tra le unità di business e il ruolo dei dati per favorire la gestione, l’innovazione e la massimizzazione dell’utilizzo degli stessi.
Storicamente sono stati rilevati alcuni modelli organizzativi per la gestione dei dati che presentano diversi livelli di autonomia e centralizzazione:
- Centralizzato: l’amministrazione del dato in questo caso è estremamente centralizzata. Viene effettivamente impostata una modalità di visione del “data as a product” e stabilita una suddivisione dei domini, ma al contempo alla governance viene garantito un controllo centrale;
- Hub & Spoke: è lo schema intermedio che prevede livelli di centralizzazione e decentralizzazione diversificati a seconda del dominio preso in considerazione, delle BU e delle use case;
- Fully Autonomous BU: le varie business unit sono totalmente autonome nella definizione del proprio data product. In questa casistica tutti gli elementi dei quattro pillar sono completamente sviluppati.
Hub & Spoke: il modello più idoneo
Sebbene il Data mesh propenda verso una forte decentralizzazione, più opinioni concordano che sia il governo centrale (HUB) a facilitare la cooperazione di tutti gli attori coinvolti fornendo strumenti e tecnologie di riferimento che possano essere usate, con svariati livelli di autonomia, da tutti i domini (spoke).
Il diverso livello di maturità ed esigenze propri di aziende e domini all’interno delle stesse, richiederà una significativa flessibilità e adattabilità nel tempo del modello Hub & Spoke, che viene effettuata centralizzando o decentralizzando maggiormente alcuni ruoli e attività. Al contrario, viene fornito dall’Hub centrale un maggior supporto e conoscenze a quei domini che non avrebbero le capacità e competenze per portare a valore da soli i propri dati.
Una suddivisione cruciale visto che anche le competenze e le figure di riferimento variano: agli Hub di solito sono correlati esperti più tecnici – data architect o data engineer – solitamente interni all’azienda; mentre verso gli spoke, i professionisti più interessati sono data owner e data steward, per i quali è importante possedere una conoscenza approfondita del processo del dato e delle strategie di business.
Sicuramente l’Hub & Spoke è il modello che più facilmente abilita la transizione anche perché più vicino al modello organizzativo maggiormente diffuso oggi presso le aziende. Un vantaggio che sicuramente diminuisce sensibilmente le barriere all’ingresso e la complessità legata al cambiamento.
In conclusione, considerando l’innovazione introdotta dal paradigma del Data mesh, l’applicabilità, il livello e la modalità di adozione dello stesso devono essere accuratamente valutare in funzione di obiettivi e contesto aziendale per assicurare così successo e durata della trasformazione data driven intrapresa.
