Autore: Raffaele Camanzo
Da alcuni anni la sfida principale per le aziende digitali di qualunque dimensione si è spostata dalla produzione e salvataggio dei dati alla capacità di gestirli ed estrarne valore. Le tecnologie coinvolte sono moltissime e in continua espansione con nuove soluzioni e nuovi paradigmi a supporto di una strategia di data management sempre più articolata e complessa.
L’Hype Cycle 2021 sul data management pubblicato da Gartner a luglio censisce decine di nuovi paradigmi tecnologici emergenti (non tiene infatti conto di quelli che hanno raggiunto il livello di completa maturità) restituendo un’istantanea degli strumenti a supporto dell’evoluzione in questo campo.
Nel documento è censita anche la “Data Hub Strategy”, la cui adozione è considerata ad alto beneficio e con una previsione di adozione di massa nei prossimi 2-5 anni; una strategia che per dirlo con le parole degli analisti “guida l’implementazione di uno o più data hub, architetture logiche che abilitano la condivisione di dati tra produttori e consumatori di dati”. La ragione per cui la strategia è importante è che “i business digitali richiedono un’enfasi nelle connessioni tra sistemi, persone e cose come fonte di vantaggio competitivo. Le aziende di solito ottengono questo obiettivo con due approcci:
Entrambi gli approcci diventano sempre costosi e poco flessibili. Applicare una data hub strategy abilita una migliore condivisione dei dati attraverso un flusso dati più consistente, scalabile e ben governato”.
In aziende strutturate i sistemi coinvolti nello scenario descritto possono essere diverse decine, tipicamente gestiti ed evoluti da team distinti con i propri obiettivi e roadmap; proviamo ad approfondire quali sono le principali limitazioni dei due approcci tradizionali descritti.
L’utilizzo di soluzioni che mirano a centralizzare dati o servizi porta benefici in termini di razionalizzazione e organizzazione dei flussi di lavoro, che tuttavia è limitato al breve periodo. Le cause principali di deriva di questo modello non sono di carattere tecnologico ma riguardano aspetti organizzativi ed evolutivi dei sistemi aziendali.
I temi organizzativi sono di due categorie: la prima dipende dalla disponibilità del team che manutiene ed evolve la struttura centralizzata, per quanto competenti possano essere i suoi componenti, non è un modello scalabile e diventa inevitabilmente un collo di bottiglia, causando ritardi e disappunto sul tipo di scelta operata; la seconda è dovuta alla composizione del team stesso, che non potendo racchiudere in sé tutte le conoscenze sui domini del business è tipicamente di composizione tecnica e quindi distante dalle necessità tanto dei produttori che dei consumatori dei dati/servizi che gestisce/crea. L’aspetto evolutivo è anche più complesso e difficile da misurare, perché non procede secondo un modello lineare, le necessità possono mutare in maniera contraddittoria rispetto al passato, si può procedere per raffinamenti successivi dell’idea originale, tipicamente creando un debito tecnico che nel tempo riduce l’efficacia e la manutenibilità delle soluzioni.
Non mancano comunque gli aspetti tecnici: centralizzare tutte le necessità su un singolo sistema lo rende un single point of failure particolarmente critico perché la sua indisponibilità ha impatto su tutti i servizi, far convergere tutte le esigenze crea complessità e interdipendenze difficili da tracciare ed evolvere nel tempo; infine i sistemi che centralizzano servizi mantengono una dipendenza diretta con i sistemi produttori, le cui prestazioni possono limitare l’esperienza d’uso dei sistemi a valle, scenario particolarmente critico se questi ultimi sono servizi B2C.
La figura sotto descrive cosa accade a livello logico quando si adotta una strategia punto-punto, il diagramma mostra a colpo d’occhio un rischio concreto di confusione, entropia e inefficienza dovuti al proliferare di soluzioni ad hoc via via realizzate per rispondere ad ogni necessità di integrazione, ma non mostra gli ulteriori grandi limiti di questo approccio, ovvero le dipendenze dal punto di vista delle risorse, funzionali e dei tempi di realizzazione.
Le dipendenze su risorse utilizzate e funzionali sono evidenti, esponendo servizi direttamente dai sistemi sorgente, questi sosterranno il traffico diretto proveniente dai sistemi consumatori e qualunque evoluzione coinvolgerà inevitabilmente sistemi a monte e a valle della catena. Questo tipo di integrazione incide sui tempi di realizzazione ben oltre quanto necessario per realizzare le interfacce, essendo queste necessità slegate dal processo evolutivo dei sistemi produttori si sommano alle attività già in carico ai team che se ne occupano, richiedono negoziazione, inserimento all’interno dei backlog di attività e ovviamente manutenzione.
Il data hub è un pattern architetturale che realizza un livello di disaccoppiamento tra i sistemi produttori e consumatori, acquisendo i dati dalle sorgenti per renderli disponibili attraverso un layer di servizi; le caratteristiche fondamentali sono condivisione dei dati e governance. Come evidenziato nel documento di Gartner, a seconda delle necessità e dimensioni dell’azienda, la strategia di adozione di queste tecnologie può richiedere la realizzazione di uno o più hub, così da non incorrere nei problemi affrontati sopra sulla centralizzazione di tutti i flussi verso una singola componente dell’architettura aziendale.
Rispetto alle soluzioni precedenti, introdurre uno strumento di questo tipo presenta diversi vantaggi:
Con un data hub avviene una copia fisica dei dati, questo aspetto potrebbe indurre qualche perplessità su quanto sia applicabile e sostenibile operare una scelta in questa direzione, di seguito alcune considerazioni sul tema:
Il diagramma della figura sotto mostra in che modo cambia l’interazione tra sistemi con l’introduzione di un data hub.
Joyce è un data hub cloud native con architettura event-driven, utilizza Kafka e MongoDB per garantire scalabilità, affidabilità e performance. La piattaforma ha un modello dichiarativo basato su JSON Schema che permette di realizzare velocemente integrazioni dati; ogni schema viene indicizzato e salvato in un catalogo suddiviso in categorie personalizzabili per poter ricercare e organizzare i contenuti con semplicità ed efficacia.
Il concetto su cui si fonda Joyce è lo schema, che permette di definire il formato dei dati caricati e come questi verranno resi disponibili ai sistemi consumatori, gli schemi sono di tre categorie:
I dati caricati e generati dalla piattaforma vengono resi disponibili immediatamente attraverso API auto generate in formato standard REST e GraphQL, le API REST sono documentate secondo lo standard OpenAPI 3 e interrogabili attraverso un client Swagger, gli schemi GraphQL sono documentati e interrogabili attraverso un client GraphiQL.
Per i servizi consumatori che hanno un’architettura event-driven è possibile accedere ai dati nel momento in cui sono disponibili in piattaforma consumando gli eventi pubblicati su un topic Kafka dedicato a questo scopo.
La piattaforma utilizza diversi meccanismi per garantire sicurezza e controllo di accesso ai dati e alle interfacce:
L’ambiente runtime di Joyce è Kubernetes, ogni componente del sistema è stata realizzata per garantire il parallelismo e sfruttare il potenziale messo a disposizione dall’orchestratore e dal cloud computing per gestire efficacemente enormi moli di dati e traffico, l’architettura disaccoppia completamente le componenti di acquisizione da quelle di interfaccia per adattare il comportamento alle specifiche necessità del contesto in cui opera.
L’integrazione dei dati aziendali è un tema ricorrente e che si affronta da decenni, tuttavia come evidenziato da Gartner, diversi fattori hanno reso questa necessità più urgente e più complessa da gestire, soprattutto applicando logiche ed approcci del passato. Il bisogno di agire velocemente e l’aumento esponenziale della quantità e varietà dei dati a disposizione sono fattori determinanti da tenere in considerazione quando si opera una scelta su quale soluzione adottare. Joyce è uno strumento flessibile e potente che utilizza il cloud computing, tecnologie scalabili e un’architettura distribuita per supportare un’ampia gamma di casi d’uso; la capacità di collegarsi immediatamente a diverse decine di fonti e il suo modello dichiarativo permettono di realizzare integrazioni dati complesse in pochi giorni ed evolvere il suo comportamento al mutare dei bisogni nel tempo con un notevole risparmio economico e di risorse.