Non è un mistero. Molti dei “progetti dati” lanciati negli ultimi anni non hanno prodotto i risultati attesi, spesso a fronte di investimenti faraonici. Per esempio, si calcola che solo il 13% dei progetti di Big Data / Artificial Intelligence / Machine Learning vada in produzione (fonte: VentureBeat) sebbene gli investimenti in queste aree crescano del 30% anno su anno (fonte: Forbes)
Le organizzazioni, in particolare quelle tradizionali, faticano a creare valore dai propri dati, anche quando questi sono ricchi ed affidabili, faticano ad utilizzare i dati nei propri processi decisionali, faticano a creare una cultura “data-driven”. Ne abbiamo parlato con Enrico Piccinin, Principal di Thoughtworks Italia e di Alessandro Confetti, Technical Principal di Thoughtworks Italia
Secondo i due manager, i sintomi sono spesso gli stessi. Progetti guidati dalle scelte tecnologiche (quale è il miglior prodotto per il Data Lake?), mesi spesi nella fase di progettazione (quale è lo schema dati che copre tutte le mie esigenze aziendali?), tentativi di portare a bordo tutta l’azienda invece di cercare di portare in produzione casi d’uso limitati ma a valore. Spesso le iniziative dati sono di responsabilità di un team centrale, costruito attorno a competenze tecnologiche (il team degli esperti DWH, degli esperti Spark, degli esperti Kafka) su cui vengono scaricati tutti i dati aziendali, dati da cui però questo team fatica ad estrarre valore perchè non ne conosce il significato.
«A fronte di queste evidenze negli ultimi anni è nato e si è sviluppato in Thoughtworks il Data Mesh, un nuovo approccio ai progetti dati che sta riscuotendo grandissimo interesse in tutto il mondo ed in tutti i settori economici, dai servizi finanziari all’energy alla salute alla pubblica amministrazione. Questo nuovo concetto è stato lanciato nel 2019 con un articolo di Zhamak Dehghani (https://martinfowler.com/articles/data-monolith-to-mesh.html) ed è stato poi adottato e sviluppato in diverse esperienze sia da Thoughtworks che da altri attori che operano nell’ambito delle tecnologie dati avanzate».
Di che cosa si tratta? In sintesi, possiamo dire che il Data Mesh sia una nuova modalità socio-tecnologica decentralizzata per gestire progetti in ambito “big-data”. Le parole chiave in questa definizione sono socio-tecnologico e decentralizzato.
Socio-tecnologico. È importante realizzare che ciò che determina il successo, oppure il fallimento, di una iniziativa in ambito dati non è solo la tecnologia. Avere la giusta tecnologia, e saperla usare, è un requisito fondamentale. Ma a questa deve accompagnarsi anche una giusta organizzazione, una giusta distribuzione di responsabilità, giusti meccanismi premianti. Senza questi elementi socio la tecnologia da sola serve a ben poco e rischia di essere un investimento che non produce risultati.
Decentralizzato. È proprio nella decentralizzazione che sta la differenza nell’approccio Data Mesh. Decentralizzazione si applica sia a livello tecnologico che a livello organizzativo; quindi, con team autonomi che siano in grado di trattare i dati di cui sono responsabili come veri e propri “prodotti” facili da usare da parte di chi, in azienda, ne è interessato. Certo, anche nel Data Mesh troviamo un team centrale, ma questo ha “solo” la responsabilità di creare una “data platform” che fornisca, in modo facile e controllato, i servizi infrastrutturali necessari. Questi servizi sono utilizzati dai team autonomi per creare i propri “data products”. Sono i team distribuiti quindi ad essere responsabili della semantica, anche analitica, dei propri dati.
Abbiamo detto che questo nuovo modo di affrontare i progetti dati ha riscosso successo a livello mondiale, ed anche in Italia abbiamo visto un sempre crescente interesse verso questo approccio. Un interesse che si è concretizzato in alcune esperienze progettuali che, come Thoughtworks Italia, abbiamo avuto l’opportunità di sviluppare assieme ad alcuni nostri clienti.
«Vogliamo raccontarvi una di queste esperienze, nella quale abbiamo potuto utilizzare un approccio Data Mesh in una grossa azienda italiana, integrando questa architettura all’interno di un complesso mondo legacy», hanno affermato Piccinin e Confetti
Alla fine del progetto, durato meno di otto mesi, abbiamo consegnato al cliente una piattaforma dati tramite la quale è possibile sviluppare e portare in produzione un nuovo “prodotto dati” in meno di un mese, un risultato a nostro parere notevole se confrontato con la media delle esperienze in questo campo. Tramite questa piattaforma il cliente è stato in grado di creare una nuova “vista cliente a 360 gradi”, aggiornata in real time, a partire dai dati raccolti dai sistemi transazionali legacy, senza però dover intervenire su questi.
Il problema di business
“Dobbiamo costruire una nuova vista cliente a partire dai nostri transazionali legacy. Deve essere aggiornata in tempo reale. I volumi sono alti: migliaia di transazioni al minuto e milioni di clienti. Ah, dimenticavo, non possiamo permetterci di cambiare i legacy. Sapete, sono sistemi un poco datati, non abbiamo i test automatici, ed ogni intervento è un bagno di sangue”.
La sfida che ci aveva proposto il cliente era questa. Abbiamo pensato potesse essere una buona occasione per provare il Data Mesh. Si trattava di costruire una “piattaforma dati” che desse la possibilità ai team dei sistemi legacy di creare i propri “data products” (producer-oriented) ed al team del CRM (responsabile della vista cliente) di accedere facilmente a tali “producer-oriented data products” per creare la nuova “vista 360”, ovvero il proprio “data product” (consumer-oriented) da offrire a vari canali che lo volevano utilizzare, mobile, rete, web.
Gli ingredienti della soluzione
In questo caso dovevamo costruire un Data Mesh sulla base di una architettura ad eventi.
Passare a un’architettura guidata dagli eventi, senza dover modificare una riga di codice dei sistemi legacy su cui questi eventi si basano, potrebbe sembrare un sogno irrealizzabile. Al contrario è risultato sorprendentemente semplice. C’è solo bisogno di utilizzare il giusto insieme di tecnologie, il giusto insieme di pratiche di software engineering e qualche buon esperto di dominio.
In primo luogo, abbiamo bisogno di esperti di dominio che sappiano come funzionano i sistemi legacy e, più specificamente, conoscano il modello di dati di questi sistemi.
Poi abbiamo bisogno del cloud, che ci offre l’elasticità richiesta, e di un prodotto di Change Dta Capture (CDC), che consente di intercettare gli eventi elementari (ovvero le variazioni sulle tabelle di interesse) da trasformare poi in veri e propri eventi di business. Per ultimo abbiamo bisogno di “DevOps on steroids”, in sostanza dobbiamo automatizzare ogni passaggio, dalla creazione alla distribuzione fino all’aggiornamento continuo, per poter gestire un’infrastruttura dinamica complessa.
Tutti questi ingredienti li incolliamo assieme con un linguaggio di configurazione (DSL), che diventa l’esperanto per esperti di dominio, persone InfraOps, utenti aziendali fino ad arrivare ai financial controllers.
Tutto inizia con gli esperti di dominio ed il CDC
Ci servono due tipi di esperti di dominio: quelli che conoscono il modello dati dei sistemi legacy di partenza e quelli che conoscono il modello da costruire per il “data product” finale, in questo caso la “vista cliente 360”. Questi esperti si devono parlare per capire quali siano le tabelle da tenere monitorate per intercettare le variazioni che, dopo opportune trasformazioni, generano variazioni nel “data product” finale.
Supponiamo che una sezione della “vista cliente 360” debba contenere gli ordini che il cliente ha fatto.L’esperto di dominio della “vista cliente 360” conosce questo requisito e lo comunica all’esperto del sistema legacy che gestisce gli ordini. Quest’ultimo capisce che le tabelle da monitorare, per questo specifico requisito, sono le tabelle “Order” (ordine) e “OrderItem” (dettaglio ordine). Ogni volta che qualche cosa cambia in queste tabelle, la “vista cliente 360” potrebbe dover essere aggiornata.
Il punto chiave, in questa prima fase, è capire quali sono le tabelle dei sistemi legacy che devono essere tenute monitorate per soddisfare il requisito del “data product” finale. Gli esperti di dominio devono indicare tali tabelle e queste devono essere messo sotto il monitoraggio del CDC.
Le pipeline di trasformazione
Per ottenere il risultato voluto dobbiamo partire dagli eventi elementari, le variazioni sulle tabelle di interesse, applicare delle trasformazioni e poi scrivere i risultati sullo schema che rappresenta il “data product” da creare.
La prima fase: replica dei dati
Ora che sappiamo quali tabelle monitorare con il CDC, possiamo iniziare a costruire la prima fase della nostra pipeline, ovvero creare una replica. I flussi di eventi generati dal CDC sono collegati ad alcune code. Queste code hanno dei “consumer” che scrivono semplicemente tali modifiche in un database di replica.
In questo modo siamo in grado di mantenere una replica in tempo reale delle tabelle operative legacy di nostro interesse.
Questo è un passaggio cruciale, ma è solo il primo. Spesso però le architetture che sfruttano CDC si fermano a questo passaggio, ovvero la costruzione di una replica real time. Ma una semplice replica del database legacy non risolverà il problema che abbiamo: la necessità di generare veri “eventi di business” e poi trasformarli.
Eventi elementari ed eventi di business
Casa è un evento di business. Nell’esempio degli ordini, un evento di business potrebbe essere “il cliente XY ha inserito un nuovo ordine”.
Gli eventi generati da CDC sono eventi elementari ed estremamente granulari. Per esempio, l’inserimento di un nuovo ordine può tradursi in diverse operazioni di inserimento e modifica delle tabelle legacy. Ciascuna operazione è un evento CDC. Ma questa pletora di eventi rappresenta un solo evento di business.
Dobbiamo quindi filtrare il rumore del CDC per generare l’evento di business che ci interessa. E questo è quello che facciamo nella seconda fase della pipeline.
La seconda fase: filtraggio e raggruppamento degli eventi elementari
Più eventi CDC possono in realtà rappresentare solo un singolo evento di business. Quindi dobbiamo applicare un modo di raggruppare tali eventi.
Raggruppare, in una architettura ad eventi, significa applicare una finestra temporale durante la quale, appunto, si raggruppano gli eventi CDC e poi si analizzano.
Nel nostro esempio possiamo immaginare una finestra temporale di 1 secondo. Raggruppiamo tutti gli eventi CDC che si riferiscono allo stesso “numero d’ordine” e queste le trasformiamo in un solo evento “qualche cosa è successo su un ordine”.
La terza fase: la business logic
Ciò che esce dallo Stage 2 è un’indicazione di un possibile evento di business, ma tale indicazione deve essere comunque verificata con specifiche logiche. Si tratta per esempio di capire se è un nuovo ordine oppure la variazione di un ordine esistente.
Inoltre magari la “vista cliente 360” richiede, a fronte di cambiamenti negli ordini, che si aggiorni anche il totale di quanto un certo cliente ha generato nel tempo.
Ciò significa che quando riceviamo un evento in uscita dalla Fase 2, dobbiamo eseguire della logica di business che trasforma ed arricchisce tale evento per portarlo nella forma richiesta dal “data product” di arrivo.
Lo stesso evento, oltre a generare una scrittura sulla “vista cliente 360”, può essere reso disponibile per i consumatori in una coda, dando quindi la possibilità di comporre tali trasformazioni in modo modulare.
Ma in concreto come posso codificare questa logica di business?
In maniera del tutto generale, la logica di business può essere espressa tramite funzioni che contengono gli algoritmi richiesti e accedono, se dobbiamo arricchire l’evento, ai dati nel database di replica. Tali funzioni sono raggruppate in librerie e identificate secondo convenzioni specifiche.
Spesso, tuttavia, la logica di business è può essere espressa direttamente nel linguaggio del database di replica, ad esempio SQL standard o il linguaggio di query specifico supportato dai database noSQL. Questo è il caso che più spesso noi abbiamo incontrato nelle nostre esperienze e, come vedremo, questo fatto ha delle ripercussioni molto interessanti e contribuisce molto nel semplificare la gestione della piattaforma dati.
Pipeline di trasformazione come configurazione
Se osserviamo con attenzione, possiamo notare che i componenti delle pipeline di trasformazione e le relazioni tra di loro possono essere descritti in termini di relativamente pochi elementi: le tabelle da monitorare; la finestra temporale da utilizzare; le regole di filtraggio e raggruppamento; la business logic da applicare.
Ciò significa che possiamo definire un protocollo di configurazione per descrivere il sistema di pipeline che dobbiamo costruire. Questo protocollo altro non è che il linguaggio con cui descriviamo quanto la piattaforma dati deve fare ed è un concetto chiave dell’intera soluzione, come vedremo in seguito.
Stiamo quindi costruendo un vero e proprio Domain Specific Language (DSL) ovvero un linguaggio specializzato nel descrivere pipeline di trasformazione che girano su una data platform.
Un’infrastruttura elastica
Tutti i moduli delle pipeline, tutti quei blocchetti azzurri nelle figure, sono componenti software parametrici.
Ogni fase è semplicemente un container Docker che, in fase di lancio, legge la propria configurazione. Per ciascuna pipeline, gli stessi container vengono istanziati con i parametri richiesti dalla specifica logica della pipeline.
Questi componenti necessitano di un’infrastruttura per essere eseguiti. Le nostre pipeline possono avere requisiti non funzionali (NFR) e SLA molto diversi. Una pipeline, ad esempio, potrebbe dover notificare in tempo reale i propri eventi aziendali; un’altra potrebbe avere requisiti più rilassati. Una pipeline potrebbe dover elaborare carichi enormi in determinate finestre temporali, ad es. durante la notte a causa dell’elaborazione batch, ed dover sopportare un carico molto inferiore durante il giorno. Il cloud è quindi il luogo ideale per eseguire tale infrastruttura. Il cloud, se opportunamente gestito, può garantire la flessibilità e l’elasticità necessarie per soddisfare gli SLA con un’efficienza ottimale nell’uso delle risorse.
Raggruppando contenitori e code sul cloud, possiamo assegnare le risorse richieste da ciascuna pipeline e possiamo modificare dinamicamente tali assegnazioni per rispondere al meglio a diverse situazioni, ad es. profili di carico e SLA variabili nel tempo, considerando anche i vincoli di costo per il cloud.
Possiamo configurare le risorse inizialmente assegnate ai cluster così come le loro soglie. Allo stesso modo, tramite le configurazioni possiamo specificare obiettivi SLA e profili di costo come vincoli.
Questa grammatica di configurazione è il secondo elemento costitutivo del nostro DSL.
Un DSL per la piattaforma dati
Ricapitoliamo i punti chiave.
- Il business esprime i requisiti funzionali: quali eventi di business sono di interesse, cosa questi devono generare nei data product di arrivo per far sì che i consumer li possano utilizzare facilmente; il business inoltre specifica anche gli SLA desiderati (requisiti non funzionali). I budget determinano i vincoli di costo del cloud che devono essere rispettati.
- Gli esperti di dominio dei team applicativi definiscono, tramite configurazione (ovvero tramite il DSL della piattaforma dati), una serie di pipeline che generano gli eventi aziendali di alto livello e definiscono anche come questi vadano ad aggiornare i “data product” di arrivo. Tali pipeline sono l’implementazione dei requisiti funzionali espressi dal business e ne costituiscono la documentazione eseguibile.
- Gli esperti di Infra Ops definiscono, sempre tramite la configurazione (ovvero sempre tramite il DSL della piattaforma), l’infrastruttura su cui eseguire tali pipeline, inclusa la flessibilità che vogliamo che ogni componente abbia e i vincoli di costo che l’intera soluzione deve rispettare in fase di esecuzione. Si tratta dell’attuazione dei requisiti non funzionali (SLA e profili di costo) sempre espressa tramite DSL.
Abbiamo tradotto l’insieme completo dei requisiti in una configurazione governata da un linguaggio formalizzato. Questa configurazione elimina ogni ambiguità, è totalmente trasparente e può essere ispezionata in qualsiasi momento per capire cosa dovrebbe fare il sistema. Può anche essere versionata insieme al resto del codice, rendendo il sistema perfettamente verificabile (auditability).
Tutto è codice — DevOps on steroids
Se l’intero sistema può essere definito con DSL, allora può essere costruito automaticamente, testato automaticamente, avviato automaticamente e adattato dinamicamente in base alle specifiche di configurazione DSL. Tutte queste automazioni sono implementate dagli strumenti DevOps che sono parte integrante della piattaforma.
Quando si adotta un tale modello in scenari di business reali, la complessità può crescere rapidamente. Possiamo facilmente avere a che fare con centinaia di istanze di componenti in esecuzione in parallelo. Gli strumenti DevOps diventano lo strumento attraverso il quale possiamo controllare questa macchina complessa. E una volta che il meccanismo è ben rodato e controllato, i risultati che offre possono essere impressionanti.
Dal punto di vista del business siamo in grado di liberare valore a partire dai sistemi legacy senza dover entrare nei loro interni e toccare la loro logica stratificata.
Dal punto di vista tecnologico, abbiamo un sistema elastico in grado di estrarre il massimo del valore dalle tecnologie cloud.
Il modello organizzativo
Finora abbiamo costruito una piattaforma dati che i team applicativi possono utilizzare, in maniera autonoma, per creare i loro “data product” tramite uno specifico linguaggio (DSL della piattaforma).
La piattaforma non possiede alcuna logica applicativa ma offre servizi infrastrutturali ai team applicativi per implementare l’intera serie di requisiti provenienti dal business, sia funzionali che non funzionali.
Come si vede questo disegno organizzativo segue perfettamente i dettami del Data Mesh. Team autonomi nel creare i propri “data products” ed un team centrale responsabile di fornire i servizi infrastrutturali richiesti.
Si tratta di applicare la manovra inversa di Conway (Inverse Conway’s Maneuver). La legge di Conway ci dice che l’architettura di un sistema riflette la struttura dell’organizzazione che lo costruisce. La Inverse Conway’s Maneuver è una tecnica che parte dall’architettura che si vuole ottenere ed, a seguire, definisce una struttura organizzativa che rifletta l’architettura desiderata. Seguendo tale tecnica, se si desidera adottare l’approccio delineato finora, si consiglia di disporre di un team trasversale centrale responsabile della piattaforma DevOps dell’infrastruttura dati. I servizi vengono poi utilizzati in modalità self-service dai team applicativi che sfruttano la DSL della piattaforma e le sue API per costruire i “data products” richiesti.
I team applicativi sono gli unici responsabili della definizione dei “data products” secondo le proprie competenze di dominio. Il team della piattaforma offre supporto infrastrutturale ma non è coinvolto nella realizzazione delle logiche di business richieste dai vari “data products”.
Conclusioni
Siamo partiti da requisiti a prima vista molto difficili da soddisfare: creare una architettura ad eventi, partendo da sistemi legacy, che potesse permettere di creare “data products” aggiornati in real time, il tutto lasciando invariati i sistemi legacy.
Siamo finiti con una piattaforma dati che risponde a questi requisiti con un approccio orientato al Data Mesh. Team autonomi possono creare i loro “data products” tramite un linguaggio DSL che configura la piattaforma dati. La piattaforma dati è supportata da un team centrale, che è responsabile di fornire i servizi infrastrutturali richiesti ma non entra all’interno delle logiche specifiche dei vari data products.
Per raggiungere questo obiettivo, utilizziamo tecnologie consolidate come CDC e sfruttiamo ampiamente il cloud, utilizzando DevOps come collante.
Abbiamo ancora bisogno di competenze di dominio, ma la piattaforma offre funzionalità self-service agli esperti di dominio e promuove una chiara separazione delle responsabilità tra i team.
In questo modo siamo in grado di estrarre nuovo valore dal mondo legacy, con costi e rischi limitati, e forniamo a tutti coloro che devono affrontare l’onere di 20, 30 o anche 40 anni di logica stratificata la possibilità di affacciarsi su architetture moderne in modo semplice ed efficiente.
