Scegliere l’architettura dei dati giusta per l’organizzazione che si ha realmente

Le decisioni sull’architettura dei dati sono diventate più rilevanti man mano che le organizzazioni investono maggiormente in analisi, automazione e IA. La pressione è comprensibile. I leader vogliono report più puliti, insight più rapidi, una governance migliore e dati più facili da utilizzare per team e sistemi. Il problema è che le conversazioni sull’architettura moderna dei dati vengono spesso trascinate nel linguaggio delle mode prima che l’organizzazione abbia risposto a una domanda più basilare: quale modello operativo siamo realmente in grado di sostenere?

In questa conversazione emergono spesso due approcci: data mesh e data fabric. Spesso vengono discussi come se fossero tecnologie concorrenti. Questa interpretazione è troppo semplicistica. La data mesh è principalmente un modello operativo basato sulla responsabilità dei domini e sui dati come prodotto. La data fabric è principalmente un’architettura di integrazione e governance che utilizza metadati, automazione e connettività per rendere i dati più facili da trovare, governare e utilizzare tra sistemi diversi.

Entrambi gli approcci possono essere validi. Entrambi possono anche creare problemi costosi se scelti per le ragioni sbagliate. Un’iniziativa di data mesh può fallire se i team di dominio non sono pronti ad assumersi la responsabilità dei prodotti dati. Un’iniziativa di data fabric può fallire se l’organizzazione considera la piattaforma un livello magico in grado di compensare una scarsa qualità dei dati, una responsabilità debole o una governance poco chiara.

La domanda giusta non è “Quale architettura è migliore?” La domanda migliore è “Quale modello è adatto alla maturità, alla cultura della governance, alla struttura dei team e agli obiettivi aziendali a breve termine dell’organizzazione?”

Data mesh: la responsabilità come architettura

La data mesh cambia chi è responsabile dei dati. Invece di dipendere da un team dati centrale che raccolga, pulisca, modelli, documenti e renda disponibili i dati per tutti gli altri, la data mesh trasferisce la responsabilità più vicino ai domini aziendali che conoscono meglio quei dati.

In un modello di data mesh maturo, i team di dominio pubblicano i dati come prodotti. Ciò significa che i dati non vengono semplicemente scaricati in un ambiente condiviso. Hanno una responsabilità chiara, documentazione, aspettative di qualità, modalità di accesso e un pubblico definito. Il team di dominio è responsabile di rendere i dati utili agli altri, non soltanto di produrli per le proprie esigenze operative.

Questa è la promessa. La difficoltà è che non si tratta solo di un cambiamento tecnologico. È un cambiamento organizzativo. Flexera descrive la data mesh come un approccio decentralizzato che dà ai team specializzati per dominio la possibilità di gestire e possedere i propri dati, mentre Alation la considera utile quando il problema di fondo riguarda responsabilità poco chiare, colli di bottiglia in un team dati centrale o qualità dei dati incoerente tra i domini. Sono problemi reali, ma risolverli richiede più dell’installazione di uno strumento. Richiede team di dominio che abbiano tempo, competenze, incentivi e supporto per diventare responsabili dei dati.

È qui che molte iniziative di data mesh incontrano difficoltà. Un team dirigenziale può apprezzare l’idea del decentramento, ma i team di dominio potrebbero non avere una maturità dei dati uniforme. Un gruppo può disporre di solide competenze analitiche e sistemi operativi puliti. Un altro può dipendere da fogli di calcolo, definizioni informali e pulizia manuale. Considerare questi domini ugualmente pronti ad assumersi la responsabilità dei prodotti dati può creare più incoerenza, non meno.

Data fabric: automazione e connettività come architettura

La data fabric segue un percorso diverso. Invece di partire dalla responsabilità decentralizzata, si concentra sul connettere, governare e rendere utilizzabili i dati in un ambiente complesso. Una data fabric può utilizzare metadati, catalogazione, lineage, policy di accesso, automazione e livelli di integrazione per aiutare i team a trovare e utilizzare i dati presenti in data warehouse, data lake, applicazioni, piattaforme cloud e sistemi operativi.

Questo può essere interessante per le organizzazioni che hanno bisogno di ottenere valore più rapidamente o che hanno dati distribuiti su molti sistemi, ma non sono pronte per un modello completo di responsabilità per dominio. Atlan descrive la data fabric come un approccio che richiede meno cambiamenti culturali rispetto alla data mesh, ma una maggiore sofisticazione tecnica. SAP descrive analogamente la data fabric come focalizzata su come i dati vengono connessi, governati e resi utilizzabili, mentre la data mesh si concentra su come viene distribuita la responsabilità dei dati.

Il vantaggio è pratico. Una data fabric può contribuire a ridurre il lavoro manuale di integrazione, migliorare la coerenza della governance e offrire ai team un modo più unificato di accedere ai dati, senza costringere ogni dominio a diventare fin dal primo giorno un’organizzazione pienamente matura nella gestione dei prodotti dati.

Ma la data fabric presenta anche rischi propri. Se la piattaforma diventa il luogo in cui devono essere risolti tutti i problemi di accesso ai dati, governance, trasformazione e integrazione, può trasformarsi in un nuovo collo di bottiglia. L’organizzazione potrebbe centralizzare la complessità sotto un’etichetta più moderna. Se i metadati sono scadenti, i sistemi di origine sono disordinati o la responsabilità non è chiara, la fabric potrebbe rendere questi problemi più evidenti anziché risolverli.

I due modelli risolvono problemi diversi

Il modo più utile per confrontare data mesh e data fabric è chiedersi quale problema l’organizzazione stia realmente cercando di risolvere.

Se il problema principale è che la responsabilità dei dati non è chiara, i team dati centrali sono sovraccarichi, i team di dominio non si fidano dei dataset condivisi e gli esperti aziendali sono troppo lontani dalle decisioni sui prodotti dati, la data mesh può rappresentare la direzione migliore nel lungo periodo.

Se il problema principale è costituito da sistemi frammentati, accessi incoerenti, governance manuale, lineage debole, scarsa reperibilità e troppi ostacoli nello spostare i dati tra ambienti, la data fabric può essere il primo passo più pratico.

Molte organizzazioni finiranno per aver bisogno di elementi di entrambi gli approcci. SAP descrive i due approcci come distinti ma complementari: la data mesh offre ai team di dominio maggiore controllo, mentre la data fabric fornisce una base tecnica per connettere e governare i dati in tutta l’organizzazione. Questa visione ibrida è spesso più realistica che trattare la scelta come una decisione in cui uno dei due approcci deve prevalere interamente.

Tuttavia, la sequenza è importante. Un’organizzazione non pronta alla responsabilità distribuita potrebbe incontrare difficoltà se passasse direttamente alla data mesh. Un’organizzazione che investisse soltanto in un livello di fabric potrebbe avere problemi se nessuno fosse responsabile del significato, della qualità e dell’utilità dei dati connessi.

Errori comuni nella data mesh

I fallimenti della data mesh derivano spesso dalla sottovalutazione del modello operativo. L’architettura può sembrare elegante nelle sessioni strategiche, ma il lavoro quotidiano è meno affascinante.

I team implementano strumenti prima che i team di dominio comprendano cosa significhi essere responsabili di un prodotto dati.
La leadership sottovaluta il cambiamento organizzativo necessario per il processo decisionale distribuito.
L’organizzazione presume che la maturità dei dati sia uniforme tra i vari domini, quando raramente lo è.
La governance viene decentralizzata solo a parole, mentre approvazioni e standard continuano a essere rallentati da un team centrale.
Ai team di dominio viene assegnata la responsabilità senza fornire loro capacità, formazione o incentivi sufficienti per mantenere prodotti dati di alta qualità.

Il risultato può essere frustrante. L’organizzazione può pensare di stare decentralizzando, mentre in realtà ha semplicemente distribuito la confusione. Invece di avere un unico collo di bottiglia centrale, ora presenta pratiche di dominio incoerenti, documentazione disomogenea, standard poco chiari e un modello di governance di cui nessuno si fida pienamente.

Errori comuni nella data fabric

Le iniziative di data fabric falliscono in modo diverso. Il rischio riguarda meno la distribuzione troppo rapida della responsabilità e più l’idea che la piattaforma possa assorbire tutta la complessità sottostante.

I team considerano la fabric una soluzione universale per la scarsa qualità dei dati di origine.
Metadati, lineage e catalogazione vengono trattati come attività tecniche anziché come fondamenta della governance.
L’organizzazione connette i sistemi senza chiarire chi sia responsabile delle definizioni chiave, delle metriche e delle aspettative sulla qualità dei dati.
L’accesso diventa più semplice, ma la fiducia non migliora perché gli utenti continuano a non sapere quali dati siano corretti.
La piattaforma di data fabric diventa una dipendenza che richiede investimenti continui, disciplina architetturale e responsabilità operativa.

Una data fabric può rendere l’ambiente dei dati più facile da navigare. Da sola, però, non può trasformare dati scadenti in dati di qualità. Non può risolvere definizioni contrastanti di ricavi, cliente, inventario, utilizzo o rischio. Queste sono domande di business e di governance che richiedono ancora una responsabilità umana.

Criteri di selezione che contano davvero

Prima di scegliere una direzione, i responsabili dovrebbero valutare onestamente l'organizzazione. I criteri più importanti non sono astratti.

Maturità dei domini: I domini aziendali sono in grado di definire, mantenere, documentare e supportare i prodotti di dati con una coerenza ragionevole?
Solidità della governance: L'organizzazione dispone già di standard chiari per qualità, accesso, lineage, privacy e responsabilità?
Capacità tecnica: I team sono in grado di gestire la piattaforma, l'automazione, l'integrazione, la catalogazione, il monitoraggio e i processi di supporto necessari?
Prontezza culturale: L'organizzazione è a suo agio con una responsabilità distribuita o il processo decisionale dipende ancora fortemente dal controllo centralizzato?
Obiettivi di intelligenza artificiale e analisi: L'organizzazione ha bisogno di prodotti di dati governati e riutilizzabili per casi d'uso avanzati oppure deve prima migliorare la connettività e la reperibilità?
Capacità di cambiamento: Quanto cambiamento organizzativo può assorbire l'azienda continuando a svolgere il lavoro quotidiano?

Questi criteri non hanno lo scopo di rallentare i progressi. Aiutano a evitare costose operazioni di facciata. Una strategia dei dati che ignora la maturità si trasforma solitamente nell'implementazione di uno strumento. Un'implementazione di uno strumento che ignora la responsabilità si trasforma solitamente in un altro progetto di pulizia dei dati con una dashboard migliore.

Come Ridiculous Engineering affronta questa decisione

In Ridiculous Engineering, affrontiamo l'architettura dei dati come un problema di progettazione sia tecnica sia organizzativa. Lo schema, la piattaforma, le integrazioni e l'automazione sono importanti. Lo sono anche la responsabilità, i processi, la governance, gli incentivi e la capacità dei team di mantenere ciò che viene realizzato.

Questo è particolarmente importante mentre le organizzazioni si preparano ai flussi di lavoro supportati dall'intelligenza artificiale. I sistemi di intelligenza artificiale sono utili solo quanto l'ambiente di dati che li circonda. Se i dati sono governati male, definiti in modo incoerente, difficili da tracciare o sparsi tra sistemi privi di una responsabilità chiara, l'intelligenza artificiale non li trasformerà magicamente in informazioni aziendali affidabili. Potrebbe semplicemente produrre risposte più sicure a partire da input deboli.

Il nostro ruolo è aiutare i clienti a rallentare quanto basta per prendere la decisione architetturale corretta prima di impegnarsi in un percorso costoso. Ciò può significare valutare la maturità attuale dei dati, mappare i domini e le responsabilità, individuare le lacune nella governance, valutare le opzioni per la piattaforma dati, modernizzare le integrazioni o progettare una roadmap incrementale che offra all'organizzazione dati migliori senza imporre un modello di maturità che non è ancora in grado di supportare.

A volte la risposta giusta è passare verso il data mesh. A volte è investire prima in un livello di data fabric. Talvolta il percorso più pratico è un approccio ibrido che migliori la connettività e la governance, preparando gradualmente i team dei domini ad assumersi nel tempo la responsabilità di prodotti di dati di qualità superiore.

La decisione dovrebbe riflettere la realtà, non le aspirazioni

Data mesh e data fabric non sono parole magiche. Sono modi diversi di organizzare responsabilità, governance e accesso in un ambiente di dati complesso. Possono funzionare insieme, ma solo se l'organizzazione comprende quale problema dovrebbe risolvere ciascun approccio.

Il rischio consiste nello scegliere in base alle aspirazioni. Un'azienda potrebbe voler essere decentralizzata, ma continuare a operare con un processo decisionale centralizzato e una maturità dei domini disomogenea. Un'altra potrebbe desiderare un data fabric sofisticato, ma non disporre della disciplina necessaria per i metadati e della responsabilità operativa indispensabili per mantenerlo affidabile. In entrambi i casi, l'architettura comincia ad allontanarsi dalla realtà.

L'approccio migliore è più onesto. Occorre partire dal punto in cui l'organizzazione si trova realmente. Comprendere i problemi relativi ai dati che causano maggiore attrito. Individuare le lacune nella responsabilità. Decidere quali capacità debbano migliorare per prime. Poi scegliere un'architettura che supporti la fase successiva della maturità, invece di fingere che l'organizzazione sia già arrivata a quel punto.

Se la tua organizzazione sta valutando il data mesh, il data fabric o un più ampio percorso di modernizzazione dei dati, Ridiculous Engineering può aiutarti a valutare i compromessi, progettare una roadmap realistica e costruire i sistemi e i modelli operativi necessari per rendere l'architettura utile nella pratica.

La migliore architettura dei dati non è quella con il nome più alla moda. È quella che la tua organizzazione è in grado di gestire, governare, considerare affidabile e migliorare nel tempo.

Fonti e ulteriori letture: Flexera: data mesh e data fabric a confronto, Alation: data fabric e data mesh a confronto, Atlan: data mesh e data fabric a confronto, SAP: data fabric e data mesh a confronto, Apptad: data mesh e data warehouse centralizzato a confronto

Data mesh o data fabric: la decisione sul decentramento che costa milioni