Data Fabric, Mesh e Lakehouse: La nuova architettura dei sistemi informativi digitali

La prima volta che ho sentito l’espressione data warehouse è stato nel 1985. Ero da poco system architect ed ero inesperto, e facevo parte di un piccolo team nel laboratorio software interno di IBM Ireland. Ci era stato chiesto di proporre un nuovo approccio per fornire informazioni di gestione coerenti e affidabili ai team di vendita e finance di IBM Europa, che erano in difficoltà a causa dei notevoli cambiamenti nei tipi e nella gamma di prodotti hardware e software che venivano venduti.

La soluzione tecnologica era preimpostata nei database relazionali allora emergenti, e avrebbe permesso di illustrare il DB2 di IBM, lanciato nel 1983. Anche se i database relazionali avrebbero poi conquistato il mondo entro la metà degli anni 90, all’epoca non potevano eguagliare nei sistemi operativi la potenza e la funzione dei database gerarchici allora dominanti, come IMS. DB2 stava cercando una nicchia di mercato, fu scelto il supporto decisionale. Fornimmo un’architettura per uso interno nel 1986 e la descrivemmo pubblicamente nel 1988 (Devlin, B.A. and Murphy, P.T. – “An Architecture for a Business and Information System”, 1988, IBM Systems Journal, 27). Tra gli altri componenti, il sistema conteneva un data warehouse business (BDW) strutturato attorno a entità aziendali di alto livello e una directory di dati di business (BDD), entrambi implementati nel modello relazionale. Nel corso dell’anno, diversi grandi clienti internazionali ci contattarono, rivelandoci che stavano tentando sistemi simili. Nel 1991, IBM lanciò commercialmente il concetto come “Information Warehouse”, ma non fu mai un grande successo, così fu lasciato a evangelisti come Bill Inmon e Ralph Kimball e alle società di software come Teradata di divulgarne il concetto e soprattutto costruirne il mercato.

Plus ça change, plus c’est la même chose – La ragione di questo breve viaggio nella memoria è che offre lezioni architetturali oggi rilevanti, quando il cambiamento tecnologico è ampio come lo era negli anni 80. Con la recente introduzione di almeno tre nuovi concetti, le considerazioni sull’architettura diventano sempre più importanti nella scelta dell’eventuale data fabric, data mesh o data lakehouse da perseguire.

Oggi, metto in guardia i clienti sul fatto che la selezione del prodotto dovrebbe avvenire solo dopo che l’architettura concettuale e logica è stata ben definita, ed è stata completata una review dei sistemi esistenti. Tuttavia, il nostro settore spesso prende la strada opposta, con sviluppatori e fornitori di software di infrastruttura in prima linea nella progettazione di architetture di sistema, guidati dai “più recenti e più grandi” progressi nel software. Il concetto di data lake e, più recentemente, la data lakehouse, entrambi provenienti dall’ecosistema Hadoop esteso e open source, ne sono un buon esempio. Il data lake è stato ostacolato per anni da una comprensione limitata o dall’aderenza ai principi di gestione e governance dei dati da parte di molti dei suoi sostenitori, portando a paludi di dati ben documentate. Le discussioni sui data lakehouse si incentrano anche in gran parte sulle caratteristiche tecnologiche e sulle possibilità offerte dai prodotti che ne sono alla base. La tecnologia, ovviamente, conta profondamente. Come negli anni 80, quando stavamo assistendo a grandi cambiamenti nella gestione dei dati dai database gerarchici e di rete a database relazionali, e nello storage dai mainframe centrali ai minicomputer e ai PC distribuiti, ora siamo nel mezzo di un altro cambiamento epocale, con il cloud computing, le enormi quantità di volumi di dati e l’intelligenza artificiale che cambiano il panorama tecnologico. Da questo cambiamento sono emersi sia il data fabric sia il data mesh. Gartner ha iniziato a parlare di data fabric già nel 2018. Nato come sviluppo del loro precedente pensiero sul data warehouse logico dal 2012, il data fabric è uno dei Gartner Top 10 Data and Analytics Trends del 2021 (Gartner Top 10 Data and Analytics Trends, 2021). L’idea di fondo è quella di migliorare l’accessibilità dei dati in un ambiente multi-cloud altamente distribuito on-premise e ibrido, che utilizza una serie di principi architetturali e di progettazione relativi a servizi di dati riutilizzabili, metadati attivi, grafici semantici e intelligenza artificiale. Al contrario, il data mesh (Dehghani, Z., “How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh”, 2019), un approccio sviluppato dal gruppo di consulenza di ThoughtWorks in collaborazione con diversi clienti, resetta il mindset sui tradizionali e multipli archivi di dati (warehouse, mart, sistemi operativi, e altro) creati e utilizzati dalle aziende. Viene proposta una modalità data-as-a-product, supportata da un’architettura distribuita basata sul dominio con un’infrastruttura come piattaforma. Sebbene ciò si allinei bene con il mindset dei microservizi e i metodi agili, il (quasi) completo disconoscimento degli archivi di dati consolidati e riconciliati per supportare l’uso dei dati interfunzionali mette preoccupazione. Inoltre, le aziende che hanno supportato maggiormente questo approccio (come Netflix, Intuit e Zalando) mostrano ambienti e organizzazioni di dati probabilmente molto meno complessi rispetto alle aziende fisiche più tradizionali, in particolare nei servizi finanziari.

Una base neutrale di confronto – Questi tre nuovi contendenti – fabric, mesh e lakehouse – mostrano approcci sorprendentemente diversi alle opportunità e alle sfide di questa nuova era nella tecnologia e nel business digitale. Il confronto tra loro e, in effetti, con le soluzioni esistenti, come data warehouse, data lake e logical data warehouse, non può essere effettuato facilmente con semplici caselle di controllo e metodi di punteggio. Eppure, un confronto è esattamente ciò che dobbiamo fare per sapere se i loro punti di forza sono di valore o le loro debolezze un problema in una specifica azienda, e se offrono un buon rapporto qualità-prezzo per considerare la sostituzione dei sistemi esistenti, con tutto il lavoro e il rischio che comporta. Ciò di cui abbiamo bisogno è un’architettura neutra, a livello sia concettuale sia logico, con cui misurare tutti i contendenti, vecchi e nuovi. Concettuale per comprendere l’interazione tra esigenze di business e possibilità tecnologiche (e ostacoli). Logico per l’analisi funzionale e il confronto dei diversi approcci. I framework architetturali delineati nel mio libro del 2013, dal titolo Business unIntelligence, forniscono tale base. Presi insieme, formano la Digital Information Systems Architecture (DISA), che consente il confronto richiesto. Per fare un esempio, l’asse affidamento/utilizzo delle informazioni definisce diversi ambiti di affidamento che si applicano a diversi set di informazioni/dati. L’ambito aziendale descrive il nucleo di un data warehouse; l’ambito locale, al contrario, si applica ai data mart; l’ambito personale ai fogli di calcolo. Le decisioni a livello aziendale non dovrebbero essere prese sulla base di un foglio di calcolo: questo è ovvio, anche se spesso viene ignorato nella pratica. L’applicazione di queste stesse classi a un mesh di dati, costruita attorno ai dati come prodotto, pone sfide nell’effettuare riconciliazioni cross-aziendali in un data mesh.

Conclusioni – Il lavoro di architettura dei data warehouse originale degli anni 80 è stato intrapreso in un mondo IT in rapida evoluzione con un occhio alle tecnologie innovative, ma con i piedi ben saldi sul terreno dei sistemi esistenti e di business driver ben definiti. Gli anni 2020 richiedono una combinazione simile di approcci per fornire una serie di soluzioni longeve e rispettate come il data warehousing.