Data Engineering decentralizzato e Data Mesh, la ricetta di Agile Lab

La corsa per diventare un’azienda data-driven è sempre più sfrenata e mette in discussione le basi stesse del data engineering. Su questo tema riflette Paolo Platter, CTO & Co-Founder di Agile Lab

Analizziamo il fenomeno del data mesh, che propone un approccio socio-tecnologico per decentralizzare la proprietà dei dati ai domini aziendali.

La “rapida adesione” che i principi del data mesh ottengono da parte dei responsabili aziendali dimostra che questi principi toccano un tasto dolente per le grandi imprese. Le iniziative sui dati richiedono maggiore agilità e un migliore time to market.

Per implementare con successo un data mesh su larga scala, sono necessarie variazioni non banali a diversi pilastri di riferimento aziendali:

• Organizzazione
• Cultura e alfabetizzazione dei dati
• DataOps e DevOps
• Pratiche di Data Engineering
• Processi di delivery

Per questo motivo, è consigliabile procedere per gradi e apportare una serie di miglioramenti ai pilastri tecnici e di processo sopra menzionati prima di lanciarsi nel viaggio di adozione del data mesh. In questo modo, tutto verrà più naturale e sarà possibile concentrare maggiori energie sugli elementi che tipicamente oppongono la resistenza più significativa: persone e organizzazione.

Ad esempio, la parte pratica del data engineering rientra tipicamente nella responsabilità di un singolo dipartimento e non richiede una convergenza multifunzionale per realizzare il cambiamento.

D’altra parte, i processi di delivery complessivi sono solitamente più interfunzionali e, senza un cambiamento organizzativo, difficili da far evolvere.

Nella practice di data engineering, possiamo muovere diversi passi verso i seguenti obiettivi per incrementare l’adozione del data mesh:

• aumentare la velocità di delivery
• consentire a team multipli e paralleli di lavorare su iniziative diverse in modo più autonomo e indipendente
• incrementare la standardizzazione delle practice
• automatizzare la funzione di governance dei dati e renderla computazionale

In generale, esistono quattro modi per impostare una practice di data engineering, che dipendono dalle dimensioni e dalla maturità dell’ecosistema dei dati in azienda. Quest’ultimo è quello che riteniamo possa essere un ottimo primo passo verso l’adozione del data mesh:

Data Engineering centralizzato

L’approccio centralizzato è il più comune quando un’azienda decide di affrontare il mondo dei dati e il primo passo è l’assunzione di un Responsabile dei Dati. Inizierà a strutturare i processi e a scegliere una tecnologia per creare la piattaforma che conterrà tutti i dati aziendali, organizzati ed elaborati secondo tutti i noti requisiti di gestione dei dati.

In questo scenario, l’elaborazione dei dati a fini analitici avviene all’interno di un’unica piattaforma tecnologica governata da un unico team, suddiviso in diverse funzioni (acquisizione, modellazione, governance, ecc.). L’adozione di un’unica piattaforma tecnologica, che generalmente include anche la maggior parte dei requisiti di conformità e governance, genera un ecosistema di funzionalità ben integrate e un’esperienza utente ottimale.

Il team Dati gestisce la piattaforma e l’implementazione dei casi d’uso. Per chi definisce principi e pratiche, è facile allineare il team perché ha il controllo diretto sulle persone e sul processo di delivery. Questa metodologia garantisce un livello elevato (almeno in teoria) di compliance e governance. Tuttavia, in genere non soddisfa i requisiti di time-to-market degli stakeholder aziendali perché è l’intera pratica a rivelarsi un collo di bottiglia quando viene adottata in un’organizzazione su larga scala. Gli stakeholder non hanno però alternative, se non quella di adattarsi ai tempi e al paradigma di consegna del team dati.

Shadow Data Engineering

Quando il data engineering centralizzato genera troppa frustrazione per gli utenti, di solito si assiste all’emergere del cosiddetto “Shadow IT”, che porta così a:

• Adozione di nuove piattaforme tecnologiche per l’elaborazione e la manipolazione dei dati.
• Creazione di nuovi team (spesso composti da data scientist) che portano le iniziative sui dati direttamente in produzione per ottenere un migliore time-to-market
• Creazione di “bolle” che operano fuori dagli standard indicati

Questa pratica, all’inizio, è vista solo come un valore aggiunto perché, all’improvviso, le iniziative aziendali entrano in funzione in tempi incredibili, e crea anche l’illusione che “alla fine, non è così difficile trattare i dati”.

Questo genera un effetto volano: i budget aumentano, l’azienda inizia a sfruttare sempre di più il modello e vengono introdotte nuove tecnologie. Poiché tutte queste tecnologie di solito non si integrano nativamente tra loro, la cosa si riflette immediatamente anche sui dati, perché tutte queste piattaforme e team hanno bisogno di insourcing di dati per operare.

Non appena i dati vengono memorizzati, è necessario affrontare tutte le questioni relative alla gestione dei dati (sicurezza, privacy, conformità, ecc.). La Business Intelligence è in genere la prima area in cui si applica questo schema, perché l’azienda opera in modo autonomo con team dedicati. Gli strumenti di BI, invece di consentire solo l’esplorazione e la presentazione dei dati, spesso si trasformano in strumenti di gestione dei dati a tutti gli effetti, perché ne richiedono l’acquisizione di una copia (integrazione dei dati) per ottenere prestazioni migliori.

Lo stesso fenomeno si verifica con le piattaforme di Machine Learning, che consentono ai data scientist di analizzare, generare e distribuire nuovi dati all’interno di un’organizzazione, operando con grande flessibilità e libertà. Le piattaforme di machine learning diventano rapidamente un nuovo modo di distribuire dati all’azienda.

All’inizio tutti questi modelli sembrano generare valore per l’organizzazione. Tuttavia, ogni volta che si istituiscono pratiche e tecnologie scollegate dalle esigenze di governance e conformità dei dati, si genera un data debt, un “debito” di dati che si manifesta tardivamente e su larga scala con i seguenti effetti:

• Dati incoerenti e inaffidabili
• Costi di manutenzione elevati
• Complessità della risoluzione di problemi relativi ai dati
• Difficoltà a responsabilizzare le persone sui dati generati

Quando compare il cosiddetto Shadow Data Engineering, il team dati principale perde credibilità perché l’organizzazione vede solo risultati lampo e relativi impatti sul business. È difficile dimostrare gli effetti negativi a lungo termine quando questi non sono ancora visibili. Dopo qualche anno, quando inizieranno a manifestarsi i danni collaterali, sarà ancor più complicato tornare indietro.

Stabilire buone pratiche di data engineering in questo scenario è impossibile, anche con un mandato chiaro. Quando un responsabile dei dati chiede di implementare alcune best practice di data management, gli stakeholder che operano in modalità shadow le abbracceranno formalmente. In ogni caso, essendo completamente autonomi sulla loro piattaforma, i loro obiettivi personali bypasseranno sempre l’implementazione delle linee guida. Gli MBO degli stakeholder mirano sempre a risultati a breve termine e i team che lavorano sui dati ricevono pressioni per fornire valore al business.

Data Engineering a Silos Multi-Tech

Una volta che lo Shadow Data Engineering funziona per un paio d’anni, non è più possibile tornare a un data engineering centralizzato. Le tecnologie sono penetrate nei processi, nella cultura e negli utenti, che si legano alle funzionalità e non al loro impatto. Centralizzare nuovamente su un’unica piattaforma costerebbe molto e rallenterebbe l’attività. Se è vero che i limiti dell’approccio shadow sono ormai evidenti, i vantaggi aziendali in termini di agilità e velocità sono stati preziosi e nessuno è disposto a perderli.

Di solito, le aziende tendono a salvaguardare le tecnologie maggiormente implementate, aggiungendo un layer di gestione e governance, creando hub di competenze e processi per ciascuna di esse. In genere, si cerca di costruire ex-post un livello di integrazione tra le varie piattaforme per centralizzare la catalogazione dei dati o adottare pratiche trasversali come la qualità e la riconciliazione dei dati. Questo processo è complicato perché le piattaforme/tecnologie non sono state scelte tenendo conto dell’interoperabilità.

Le varie practice saranno personalizzate per ogni specifica tecnologia, finendo per avere un basso livello di automazione, ma in ogni caso, sarà possibile ridurre il debito di dati. Tuttavia, la costruzione di questi processi di governance e umano-centrici porterà inevitabilmente a un rallentamento generale e a un aumento degli sforzi senza alcun impatto diretto sul business. Anche se sarà possibile monitorare e tracciare il movimento dei dati da un silo all’altro, seguito da processi di audit e discendenza, l’isolamento informativo dei diversi silos persisterà.

Data Engineering decentralizzato

La decentralizzazione del data engineering passa attraverso una profonda standardizzazione, che deve essere indipendente dalla tecnologia sottostante (practice over technology). La selezione della tecnologia avverrà con chiari driver non appena si darà priorità alla pratica. Adattare la tecnologia alla pratica significa spesso depotenziare la prima e costruire componenti personalizzati, utilizzando solo alcune funzionalità, escludendone altre.

C’è un’enorme differenza tra adattare una pratica a un insieme di tecnologie e relative funzionalità e adattare e selezionare le tecnologie per adeguarle a una pratica. Un chiaro insieme di principi deve essere alla base della definizione di una pratica.

Nel data engineering decentralizzato, si vuole consentire a molti team dati indipendenti di raggiungere un buon time to market e una buona velocità senza generare debito di dati e ottenendo alti livelli di governance. Ecco una serie di principi alla base di questo approccio:

Le migliori practice senza sforzi

Trasformare in codice linee guida orientate ai documenti è estremamente difficile e genera un impegno non trascurabile. Quando altre priorità si aggiungeranno alle attività del team dati, questo percepirà meno essenziale l’aderenza alle policy e le abbandonerà quando si presenteranno problemi di time-to-market critici per l’azienda.

Le best practice dovrebbero apportare valore aggiunto senza creare oneri. È necessario porre l’esperienza dello sviluppatore al centro, rendendo l’adozione semplice. Dovrebbero avere un impatto diretto su velocità e qualità, non diventare un ostacolo. Un modo eccellente per adottare le best practice è fornire template/basi, di gran lunga migliori dei framework perché non creano colli di bottiglia nel processo di delivery e non rappresentano un ostacolo all’agilità e all’evoluzione di ogni iniziativa sui dati.

I template hanno i seguenti obiettivi:

• Facilitare l’impostazione di un progetto e l’utilizzo di una tecnologia specifica fornendo rapido successo
• Incorporare e standardizzare best practice e pattern, facendo risparmiare tempo e fatica ai team che si occupano dei dati, grazie all’adozione incorporata.
• Includere effetti collaterali o comportamenti predefiniti all’interno di tutte le applicazioni per consentirne la standardizzazione (inferenza del data lineage, crittografia, ecc.) a prescindere dalla tecnologia
• Aumentare il riutilizzo degli asset software e dei casi d’uso tra più team senza dover costruire framework che, a lungo andare, si rivelano un collo di bottiglia operativo e un ostacolo per l’innovazione.
• Accelerare il time-to-market per passare dall’ideazione di un caso d’uso alla sua implementazione nel più breve tempo possibile, concentrandosi principalmente sulla logica di business.

I template dovrebbero raccogliere le “lezioni apprese” dai team dati ed essere sviluppati e mantenuti facendo leva su un ciclo di feedback tra il team di piattaforma e il team dati, per non creare un effetto silos tra gli abilitatori (il team di piattaforma) e gli esecutori (il team dati).
Il team dati dovrebbe essere in grado di contribuire con template al team di piattaforma; questi contributi aiuteranno a consolidare la practice dei dati sviluppata all’interno del team dati e a renderla disponibile ad altri team.

I template si concentrano sul time-to-market, aspetto fondamentale per lo sviluppo di un caso d’uso di successo che aiuterà i team dati a fornire valore al business il più rapidamente possibile.

Per poter far evolvere i casi d’uso in modo organico, i template devono offrire un percorso di aggiornamento a basso sforzo per le istanze, sfruttando:

• Riscritture automatiche del codice: i team dati non devono preoccuparsi degli aggiornamenti, che vengono fatti per loro.
• Kit di test di compatibilità: convalida della conformità del caso d’uso con i servizi condivisi della piattaforma prima e dopo l’aggiornamento.
• Estese note di rilascio: il team dati può facilmente comprendere perché dovrebbe preoccuparsi degli aggiornamenti e quali vantaggi e rischi comporta

Internal Data Engineer (Developer) Platform

Si tratta di un livello superiore alla tecnologia che consente l’automazione e la standardizzazione dei processi di gestione di configurazione, distribuzione, orchestrazione dell’infrastruttura e processi RBAC (role-based access control). Il team di piattaforma fornisce una serie di servizi (compresi i template) ai team dati:

• aumentare la loro produttività e felicità
• ridurre il boilerplate
• aumentare il loro livello di responsabilità e coinvolgimento, in quanto possono passare dall’ideazione alla produzione senza coinvolgere altri team, ma seguendo un processo standard.

Se pensare alla piattaforma è fondamentale per la decentralizzazione, non stiamo parlando di una semplice piattaforma tecnologica, ma di una pratica che può aiutare a creare un flusso di lavoro comune su più tecnologie e tra più team, condividendo strutture ed esperienze sulla creazione di valore.

Policy as code

Gli elementi fondanti della practice devono essere codificati e visibili a tutti i team. L’applicazione delle policy deve essere completamente automatizzata, indipendente dalla tecnologia sottostante, parte del processo di delivery complessivo e profondamente integrata con la piattaforma interna di data engineering.

Le policy possono essere applicate a conformità, sicurezza, completezza delle informazioni, qualità dei dati, governance e molti altri aspetti rilevanti della gestione dei dati, creando un ecosistema eterogeneo ma affidabile. Quando parliamo di “come codice”, significa che fa parte del ciclo di vita dello sviluppo del software.

Indipendenza tecnologica

Dobbiamo essere in grado di applicare la practice a tutte le tecnologie che fanno parte del panorama aziendale. Inoltre, l’introduzione di nuove tecnologie e strumenti deve essere sempre possibile senza avere impatto sull’ecosistema. L’introduzione della tecnologia X non deve avere un impatto sulla tecnologia Y. Dobbiamo concentrarci sul disaccoppiamento e sulla generalizzazione dei modelli, perché le tecnologie vanno e vengono mentre le pratiche si evolvono. Quando si introduce una nuova tecnologia, il primo fattore di valore è l’interoperabilità (a livello di dati, sistema e processo).

Ogni team dati deve poter scegliere l’opzione che preferisce all’interno di un paniere di tecnologie con un elevato livello di interoperabilità abilitato dal team di piattaforma. È fondamentale scegliere servizi componibili e formati/protocolli aperti. Prestare attenzione al disaccoppiamento tra archiviazione ed elaborazione, perché consente interoperabilità tecnologica e distribuzione dei costi tra produttori e consumatori migliori.

Democratizzazione e automazione della Data Governance

Per eliminare i colli di bottiglia del processo centrale, le attività di governance (modellazione dei dati, metadati, classificazione dei dati, ecc.) devono diventare parte del ciclo di sviluppo e della “definizione di fatto” per tutti i team dati. È essenziale renderla semplice e intuitiva, ecco perché la piattaforma interna di data engineering e la policy as code giocano un ruolo cruciale nell’abbracciare questo principio. La governance dei dati dovrebbe entrare nel ciclo di vita dello sviluppo per generare metadati prima che i dati vengano messi in produzione ed essere in grado di applicare i gate di qualità. Ciò significa distribuire alcuni compiti al team dati, invece di affidarsi alle attività di quello di governance centrale, che si concentrerà maggiormente su creazione del processo e automazione e non sull’esplicito controllo e sul gate keeping.

Priorità a DevOps/DataOps

È fondamentale adottare elevati livelli di automazione in tutto il processo per consentire ai team di essere indipendenti, pur avendo il controllo della qualità della delivery. Una piattaforma interna di data engineering senza una completa automazione non crea valore sufficiente per raggiungere un’ampia adozione. L’automazione dell’infrastruttura e del provisioning delle risorse è fondamentale per fornire ai team vantaggi in termini di agilità e velocità.

DevOps è inoltre essenziale per creare un processo di sviluppo e una cultura dell’automazione adeguati, che includano anche l’inserimento di gate di qualità prima che i dati vengano messi in produzione.

• Ambienti locali riproducibili: seguendo una pratica DevOps, l’infrastruttura della piattaforma necessaria per lo sviluppo locale dovrebbe essere riproducibile su un laptop dello sviluppatore, al fine di accelerare sviluppo e diagnosi dei problemi.
• Scenari di dati riproducibili: uno sviluppatore dovrebbe essere in grado di avviare un ambiente di sviluppo locale o remoto campionando automaticamente i dati necessari per riprodurre uno scenario previsto.

Data Contract first

In una practice decentralizzata non è più possibile orchestrare tutte le pipeline di dati e organizzare la delivery di più team, perché nessuno si assume tale responsabilità. Abbiamo bisogno di contratti chiari tra produttori e consumatori di dati.

Data Contract significa innanzitutto che la definizione del contratto avviene durante il ciclo di vita dello sviluppo, in seguito automatizza la creazione delle risorse e standardizza i meccanismi di scambio dei metadati.

L’orchestrazione non è più un processo centralizzato, ma un ecosistema reattivo, modulare e guidato dagli eventi. Il principio della policy as code può aiutare a far rispettare, controllare e migliorare i data contract, in quanto principalmente dichiarativi.
Inoltre, devono essere altamente standardizzati e regolati da policy, ad esempio:

• Nessuna modifica di rottura finché un contratto di dati ha un consumatore
• Almeno sei mesi di periodo di ammortamento in caso di dismissione
• Un endpoint fisico fa parte del contratto

I dati seguono i data contract, ma spesso questi ultimi si evolvono nel tempo; nel caso in cui non vi siano modifiche di rottura, i dati dovrebbero essere automaticamente aggiornabili alla nuova definizione di schema, agganciandosi agli eventi del ciclo di vita della piattaforma tramite codice o “procedure” standard.

Un servizio per individuare e risolvere i contratti sui dati è altamente raccomandato.

Trasformazioni dichiarative dei dati

Questa è una conseguenza diretta dell’approccio che privilegia i data contract, con cui vogliamo spostare l’attenzione sul risultato che intendiamo ottenere. Ma i dati sono sempre il risultato di una trasformazione che deve essere fortemente collegata al contratto sui dati. L’unico modo per farlo è adottare una semantica dichiarativa integrata con il data contract. Altrimenti, si potrebbero avere pipeline che generano informazioni non allineate con il contratto dati dichiarato. Collegare i data contract e le successive trasformazioni garantisce la coerenza dei metadati dello schema e delle informazioni sul lineage. Non c’è tempo per mantenere un livello di documentazione allineato quando ci sono più team che lavorano con grande agilità e velocità. La documentazione deve essere generata direttamente dagli artefatti e dai relativi metadati dedotti.

In conclusione

Quindi, nella pratica del data engineering decentralizzato, il team di piattaforma deve costruire e mantenere una piattaforma interna di data engineering in cui pubblicare una serie di modelli precostituiti (scaffold) e creare policy (sotto forma di codice) per applicare il processo.

Questa piattaforma deve anche instradare il processo di distribuzione attraverso metodologie DevOps/DataOps, applicando policy e controlli di qualità e astraendo il processo da tecnologie specifiche.

Il team di piattaforma facilita il lavoro dei team dati introducendo e adottando nuove tecnologie nella piattaforma, dando loro la possibilità di innovare e di sentirsi responsabili end-to-end del progetto.

In Agile Lab, abbiamo avuto l’opportunità di capire come questa metodologia possa offrire un eccellente time to market e una significativa autonomia ai team che si occupano di dati, senza introdurre un debito di dati e tenendolo sotto controllo grazie all’elevata standardizzazione e indipendentemente dalla tecnologia.

È chiaro che la costruzione di una piattaforma interna di data engineering richiede costi e sforzi, ma questi devono essere sostenuti da una visione strategica a lungo termine. Inoltre, nel mondo dei dati nulla è realmente gratuito.

Data Engineering decentralizzato

La pratica del data engineering decentralizzato si allinea al paradigma data mesh, ma non ne copre gli aspetti organizzativi e non abbraccia la proprietà del dominio dei dati e la governance federata. Si concentra solo sulla decentralizzazione, l’automazione e l’interoperabilità delle practice dei dati. Questo modello potrebbe essere considerato un primo passo verso l’adozione del data mesh, con l’aspetto positivo che potrebbe essere guidato interamente dal dipartimento IT/dati senza coinvolgere i domini aziendali e ottenere i seguenti miglioramenti:

• Interoperabilità: è un elemento critico per abbracciare e adottare il concetto di data as a product.
• Policy as code: contribuisce all’adozione del principio della Federated Computational Governance, fornendo un modo per passare dalle linee guida all’applicazione automatica delle regole di governance a livello di codice.
• Piattaforma interna di data engineering: favorisce un pensiero legato alla piattaforma, fondamentale per abbracciare il principio della self-serve data platform, e rappresenta un passo avanti verso l’implementazione di piani di controllo per data utility e data product developer.