Cuore di qualsiasi applicazione software, il dato oggi è al centro delle strategie aziendali. Grazie all’analisi e all’interpretazione dei dati, le imprese possono estrarre informazioni utili per aumentare le conoscenze e calibrare le mosse future, pianificando le azioni in base alle evidenze nascoste, agli eventi futuribili e ai modelli previsionali.
Tuttavia, per attuare una trasformazione insights-driven, occorre sviluppare una data architecture solida ed efficace, che permetta il governo di grandi moli di dati, eterogenei e provenienti da fonti diverse.
Giulio Roggero, Chief Technology Officer di Mia-Platform, spiega come si costruisce un’architettura per la gestione dei dati, quali sono le alternative e perché scegliere una soluzione distribuita.
Cosa è una data management architecture e a cosa serve?
«La data architecture – spiega il CTO – si riferisce all’insieme di buone pratiche, metodologie e strumenti, che permette di gestire l’intero ciclo di vita delle informazioni, dalla generazione alla pubblicazione fino agli utilizzi specifici. Consente inoltre di effettuare le operazioni di manutenzione per preservare la qualità del dato, che deve essere autentico, sempre disponibile, facile da ricercare, fruibile per diversi scopi».
La tipologia e la destinazione delle informazioni determinano la scelta della data architecture, che può differire per organizzazione dei dati, velocità di lettura e scrittura, sistemi di archiviazione e così via.
«Ad esempio – suggerisce Roggero – le informazioni che devono essere richiamate e lette rapidamente hanno processi di scrittura lunghi e costosi, perché vanno costruiti indici di ricerca complessi. Se l’obiettivo invece è salvare enormi quantità di dati in breve tempo, non sarà possibile ottenere elevate prestazioni in termini di lettura. Alcune informazioni, come quelle finalizzate agli audit, richiedono conservazione sul lungo periodo ma non devono essere lette con frequenza, mentre altre vanno aggiornate e processate in tempo reale. I dati dell’Internet Of Things vanno archiviati in grande quantità, per essere organizzati successivamente a seconda degli utilizzi futuri. Insomma le variabili in gioco, che dipendono sostanzialmente dai casi di utilizzo delle informazioni, richiedono architetture dati differenti».
I limiti di un approccio monolitico alla data architecture
Con l’avvento dei Big Data, si è consolidato un approccio monolitico alla data architecture: si considerava infatti preferibile archiviare tutti i dati in un unico repository centralizzato, così che le informazioni fossero subito disponibili e potessero essere facilmente incrociate tra loro all’occorrenza, in base alle future destinazioni d’utilizzo.
«Tecnicamente – commenta Roggero – l’approccio monolitico potrebbe anche funzionare. I dati risiedono in un unico punto come singola fonte di verità, quindi non sono replicati in tanti sistemi differenti e mantengono la consistenza. Il problema delle piattaforme monolitiche sono le dimensioni “mastodontiche”, che impediscono di ottenere performance soddisfacenti di lettura e scrittura. Perché l’utente possa accedere alle informazioni con tempi sotto al secondo e aggiornamenti continui, i sistemi devono supportare il data streaming ed essere costruiti con certi indici. Invece, per ottenere reportistica in grado di gestire terabyte di dati, occorre che le informazioni siano organizzate diversamente e diventa estremamente costoso ottenere persistenza e velocità di lettura».
Insomma, se “sulla carta” le architetture monolitiche hanno un senso, mostrano dei grossi limiti nel rendere fruibile il dato quando, come e a chi serve.
Roggero racconta il caso di un cliente per chiarire la necessità di passare a un modello distribuito. «L’azienda – spiega – aveva un data warehouse, con informazioni consistenti e di buona qualità. Tuttavia, quando i sistemi gestionali richiamavano i dati, bisognava attendere parecchio tempo perché fossero correttamente organizzati e resi disponibili. Non era quindi possibile agganciare eventuali applicazioni di clienti e partner che richiedevano l’aggiornamento dei dati in real-time. Ad esempio, se un utente decideva di comprare un prodotto, avrebbe visualizzato l’acquisto tra gli ordini effettuati solo dopo qualche ora. L’update delle informazioni sarebbe stato troppo lento per garantire una buona user-experience. La soluzione quindi è stata abbandonare l’approccio monolitico e organizzare i dati per scopo, rendendo disponibili alle applicazioni solo sottoinsiemi minimi delle informazioni, accelerando la velocità di fruizione e riducendo i costi di manutenzione».
Perché passare a un’architettura dati distribuita
Sostanzialmente, come precisa Roggero, l’approccio monolitico prevede che qualsiasi dato venga pulito, archiviato e manutenuto in un unico grande data store. Organizzare la data architecture per scopo invece significa avere a disposizione sorgenti di dati grezzi, che vengono aggregati in sottoinsiemi a seconda delle finalità d’uso. «Così – prosegue il CTO – vengono resi disponibili alle applicazioni solo i dati pertinenti; ad esempio, tornando al caso precedentemente descritto, diventano accessibili l’anagrafica del cliente e gli articoli acquistati, senza che vengano comunicati dati accessori, come il punto vendita o le caratteristiche tecniche del prodotto. Tutte le altre informazioni sono comunque presenti in archivio, quindi possono essere utilizzate per scopi futuri da altri canali, ma al momento non vengono portate a livello di dato veloce. Per ogni tipologia di applicazione, si possono quindi costruire degli aggregati a seconda del business case».
Organizzando i dati per scopo, la manutenzione dei diversi sottoinsiemi viene semplificata e rimane in carico allo stesso team o area aziendale che utilizza quell’aggregato e non agli amministratori centrali. «Esistono quindi – puntualizza Roggero – un sistema e un team che garantiscono a livello centralizzato le fonti dati e la qualità delle informazioni. L’arricchimento, l’aggregazione e la manipolazione dei dati viene quindi eseguita per scopo, in modalità self-service dagli utenti».
L’evoluzione del Data Warehouse tradizionale
Dopo avere chiarito i vantaggi dell’approccio distribuito rispetto al modello monolitico, Roggero passa in rassegna le diverse tipologie di architetture.
Nell’accezione più tradizionale, l’Enterprise Data Warehouse (EDW) è un archivio fisico unico per informazioni provenienti da fonti eterogenee, che serve molteplici applicazioni. Prima di essere caricati, i dati vengono standardizzati, puliti e preparati attraverso processi ETL (Extract, Transform, Load), così da garantire consistenza, affidabilità e accuratezza.
Il Logical Data Warehouse (LDW) rappresenta l’evoluzione virtualizzata dell’EDW e nasce per supportare le aziende nella gestione di informazioni che crescono per volumi, varietà e velocità. Consiste nello sviluppo di un layer di virtualizzazione che, abilitando l’accesso a una pluralità di fonti differenti (database transazionali, data lake, applicazioni gestionali, risorse cloud, servizi web e così via), offre un unico punto di archiviazione a livello logico piuttosto che fisico. I dati non vengono trasformati a monte del processo di archiviazione come avviene con l’EDW, ma solo quando richiamati dall’applicazione, con un processo in real-time.
Data Mesh e Data Fabric, le architetture dati di nuova generazione
Tuttavia, il bisogno crescente delle aziende di attuare sistemi efficaci per il data management ha portato a ulteriori progressi in termini di framework e tecnologie.
Roggero prosegue nell’excursus e si addentra nella distinzione tra Data Mesh e Data Fabric, due approcci architetturali differenti che tuttavia hanno l’obiettivo comune di superare la sfida dei silos informativi e risolvere altre criticità relative alla gestione e accessibilità dei dati.
Il Data Mesh promuove un modello decentralizzato, che organizza le informazioni in sottoinsiemi indipendenti e interoperabili, a seconda del dominio di business. Lo scopo è delegare ai singoli team le attività di elaborazione e manutenzione dei dati pertinenti al dominio di appartenenza, secondo un approccio self-service: avendone la conoscenza più approfondita, ogni team ha la responsabilità dei dati rigurdanti il proprio dominio. È comunque importante garantire una governance federata delle informazioni perché siano interoperabili e fruibili anche ad altri domini a livello aziendale. Il dato deve pertanto essere gestito “come prodotto”, quindi accessibile a qualsiasi utente, dentro e fuori al dominio, in modo facile e veloce.
Il Data Fabric invece è un approccio basato sui metadati, con l’obiettivo di collegare fonti eterogenee sotto un unico layer virtuale, facilitando l’interazione e la governance e abilitando logice di automazione. I metadati forniscono infatti indicazioni sui dati presenti all’interno di un’organizzazione e permettono di regolare il flusso informativo con policy condivise. Attraverso i metadati, infatti, è possibile identificare e creare connessioni tra i dati multi-source, permettendo un’organizzazione strutturata di tutte le informazioni.
La differenza più evidente tra le due architetture riguarda il metodo di governo delle informazioni, distribuito oppure centralizzato. Mentre il Data Mesh crea più sistemi di gestione specifici per il dominio, il Data Fabric segue l’approccio opposto, amministrando più fonti da un’unica piattaforma virtuale. Nel primo caso, le regole condivise per il data management vengono definite con il contributo dei singoli domini, mentre nel secondo caso con un approccio top-down. Tuttavia, è importante sottolinare che Data Mesh e Data Fabric non si escludono a vicenda e, se correttamente implementati, possono coesistere e permettere di sfruttare i punti di forza di entrambi.
L’approccio di Mia-Platform alla gestione dei dati
Al netto di tutti i modelli architetturali per la gestione delle informazioni, Mia-Platform ha sviluppato un approccio proprietario denominato Fast Data, con caratteristiche uniche basate sui trend emergenti.
«Come suggerisce il nome – argomenta Roggero – la nostra soluzione si concentra sui dati in movimento, che cambiano nel tempo all’interno del flusso di un processo aziendale. Consideriamo ad esempio il ciclo di vita di un cliente, che viene gestito da diversi sistemi, come il CRM (Customer Relationship Management) per le anagrafiche, il ciclo attivo per le fatture, l’e-commerce per i prodotti acquistati. Qualora un cliente dovesse chiedere di vedere le fatture relative agli articoli comprati nell’ultimo mese, tutti i sistemi pertinenti dovrebbero essere interrogati, rilasciando infine una joint delle informazioni per soddisfare la richiesta. Con Fast Data, invece, l’integrazione delle informazioni viene eseguita ogni volta che cambia il modello dati per quel cliente, all’interno di uno o più sistemi. Ad esempio, se l’e-commerce registra un nuovo acquisto completato, manda un evento che viene consolidato all’interno di una Single View, centrica rispetto al modello di business o dominio, ovvero, in questo caso, il cliente».
Semplificando, all’interno di Fast Data, il cliente, con la sua anagrafica, gli ordini e le fatture, rappresenta una Single View che viene aggiornata ogni volta che un sistema esegue una modifica sui dati attinenti. Così, in caso di richiesta, non occorre più richiamare e integrare i dati disseminati su più fonti, ma ogni sistema contiene già l’informazione raffinata, predisposta allo scopo di fornire indicazioni sul dominio pertinente, ovvero il cliente.
Ma come si posiziona Fast Data rispetto alle diverse architetture di data management?
Fast Data per accelerare il cambiamento
«Fast Data – sintetizza Roggero – può essere vista come un silo all’interno del Data Mesh e come uno strumento del Data Fabric, che permette di raggiungere uno scopo ovvero semplificare la gestione dei dati in movimento, utilizzati non per per fare reportistica, ma per rendere più fluida l’esperienza utente attraverso le API».
La user experience infatti richiede dati freschi, sempre disponibili e veloci nel reperimento. Quindi, anziché basarsi su quest che devono essere validate di volta in volta, Fast Data segue un approccio event-driven, che aggrega le informazioni secondo il modello dati preferito (ad esempio, il profilo del cliente), rendendole accessibili all’interno di un data store ad alte prestazioni, così da servire canali e applicazioni in millisecondi.
«Fast Data – conclude Roggero – crea un percorso evolutivo per la gestione delle informazioni, a completamento delle altre architetture oppure come elemento di innovazione. Se un cliente utilizza già un’architettura Data Mesh, basterà aggiungere alcune nostre componenti per aggregare le informazioni nelle Single View. Oppure, se la volontà dell’azienda è rinnovare le politiche esistenti di data management, la nostra soluzione introduce un sistema end-to-end predefinito e replicabile in contesti differenti. Insomma, Fast Data permette di accelerare il cambiamento nella gestione dei dati, passando da un approccio monolitico a un’organizzazione divisa per scopi di business».
