La struttura organizzativa ideale per le DataOps

Le comunicazioni esterne di un'organizzazione tendono a riflettere quelle interne. Questo è ciò che ci ha insegnato Melvin Conway e si applica al data engineering. Se non si dispone di un team dedicato alle operazioni sui dati o "DataOps" chiaramente definito, le output della propria azienda saranno tanto disordinate quanto gli input.

Le operazioni dati sono il processo di assemblaggio dell'infrastruttura per generare e elaborare dati, oltre a mantenerli. È anche il nome del team che svolge (o dovrebbe fare) questo lavoro: data operazioni o DataOps. Cosa fa DataOps? Ebbene, se la sua azienda gestisce delle pipeline di dati, il lancio di un team con questo nome per gestire tali pipeline può apportare un elemento di organizzazione e controllo che altrimenti manca.

DataOps non è destinato solo alle aziende che vendono i propri dati. La storia recente ha dimostrato che è necessario un team per le operazioni sui dati, a prescindere dalla provenienza o dall'utilizzo dei dati stessi. Cliente interno o cliente esterno, è la stessa cosa. È necessario un team per costruire (o, per essere più precisi, ereditare e poi ricostruire) le pipeline. Dovrebbero essere le stesse persone (o, per molte organizzazioni, le stesse persone) che implementano strumenti diobservability e tracciamento e monitorano la qualità dei dati attraverso i suoi quattro attributi.

E, naturalmente, le persone che hanno costruito la pipeline dovrebbero essere le stesse che ricevono il temuto avviso PagerDuty quando un dashboard è inattivo, non perché sia punitivo, ma perché è educativo. Quando hanno qualcosa in gioco, le persone costruiscono in modo diverso. È un buon incentivo e consente una migliore risoluzione dei problemi e una risoluzione più rapida.

Infine, ma non meno importante, il team addetto alle operazioni sui dati ha bisogno di una missione, che trascenda il semplice "spostamento dei dati" dal punto A al punto B. Ed è per questo che la parte "operazioni" del titolo è così importante.

Le operazioni sui dati stanno costruendo processi resilienti per spostare i dati per il loro scopo previsto. Tutti i dati dovrebbero essere spostati per una ragione. Spesso il motivo è il fatturato. Se il tuo team di operazioni non riesce a tracciare una linea chiara tra quell'obiettivo finale, ad esempio i team di vendita che hanno previsioni migliori e guadagnano di più, e le loro attività di gestione delle pipeline, c'è un problema.

Senza operazioni, emergeranno problemi man mano che si aumenta la scalabilità:

• Duplicazione dei dati
• Collaborazione problematica
• In attesa dei dati
• Soluzioni cerotto che lasciano una cicatrice
• Problemi di rilevamento
• Strumenti scollegati
• Incongruenze nella registrazione
• Mancanza di processo
• Mancanza di proprietà e SLA

Se c'è una disconnessione, si sta semplicemente praticando la vecchia gestione dei dati. La gestione dei dati è l'aspetto di manutenzione ordinaria delle operazioni sui dati. Il che, pur essendo cruciale, non è strategico. Quando sei in modalità manutenzione, stai cercando la causa di una colonna mancante o di un errore della pipeline e stai riparando il problema, ma non hai tempo per pianificare e migliorare.

Il tuo lavoro diventa davvero "operazioni" quando trasformi i ticket di assistenza in correzioni ripetibili. Poniamo ad esempio che trovi un errore di trasformazione proveniente da un partner e gli mandi un e-mail per farlo risolvere prima che arrivi nella tua pipeline. Oppure puoi implementare un banner di "avvisi" sulla dashboard dei tuoi dirigenti che li informi quando qualcosa non va, in modo che sappiano di attendere l'aggiornamento. Le operazioni dati, proprio come le operazioni di sviluppo, mirano a mettere in atto sistemi ripetibili, testabili, spiegabili e intuitivi che alla fine riducano lo sforzo per tutti.

Questa è la differenza fra operazioni sui dati e gestione dei dati. La domanda quindi diventa: come dovrebbe essere strutturato il team addetto alle operazioni sui dati?

Torniamo quindi al punto di partenza: parliamo di come gli output del tuo sistema riflettono la tua struttura organizzativa. Se il tuo team di operazioni sui dati è un team di "operazioni" solo a livello di nome, e per lo più si occupa solo di manutenzione, probabilmente accumulerà un arretrato di richieste sempre crescente. Raramente avrai il tempo di riprendere fiato per apportare modifiche di manutenzione a lungo termine, come la sostituzione di un sistema o la modifica di un processo. Rimarrai bloccato nell'inferno delle risposte di Jira o ServiceNow.

Se, invece, hai fondato (o rilanciato) il tuo team di operazioni dati con principi e una struttura solide, produci dati che riflettono la tua struttura interna di alta qualità. Buone strutture di team per le operazioni dati producono dati validi.

Riunisci un data engineer, un data scientist e un analista in un gruppo, o "pod", e chiedi loro di affrontare insieme argomenti che avrebbero affrontato separatamente. Invariabilmente, queste tre prospettive portano a decisioni migliori, a meno scosse e a una maggiore lungimiranza. Ad esempio, invece di avere il data scientist che scrive un notebook che non ha senso per poi passarlo al data engineer solo per creare un ciclo di avanti e indietro, lui e l'analista possono discutere di ciò di cui hanno bisogno e l'ingegnere potr spiegare come dovrebbe essere fatto.
Molti team di operazioni dati già lavorano così. "I team dovrebbero puntare a essere formati come 'full-stack', così da avere a disposizione le competenze necessarie nell'ingegneria dei dati per avere una visione a lungo termine dell'intero ciclo di vita dei dati", affermano Krishna Puttaswamy e Suresh Srinivas di Uber. E sul sito di viaggio Agoda, il team di ingegneria usa i pod per lo stesso motivo.

Fatelo anche se siete una sola persona. Ogni ruolo è un "cappello" che qualcuno deve indossare. Per avere un team operativo sui dati altamente efficiente, è utile sapere dove si trova il cappello e chi è il proprietario dei dati e per quale aspetto. È inoltre necessario ridurre l'intervallo di controllo di ogni individuo a un livello gestibile. Forse disegnarlo in questo modo ti aiuta a sostenere l'assunzione.

Cos'è la gestione del team di operazioni dati? Uno strato di coordinazione sopra le strutture del tuo pod che svolge il ruolo di leader dei servitori. Gestiscono progetti, li allenano e li sbloccano. Idealmente, sono le persone più competenti del team.

Abbiamo trovato la nostra struttura ideale, illustrata nell'immagine, anche se è un work in progress. Ciò che è importante notare è che c'è una sola persona che guida con una visione per i dati (il vicepresidente). Sotto di loro ci sono diversi leader che guidano varie discipline dei dati verso quella visione (i Direttori), e sotto di loro, team interdisciplinari che garantiscono che l'organizzazione dei dati e le caratteristiche dei dati funzionino insieme. (Ringraziamo il nostro Data Solution Architect, Michael Harper, per queste idee.)

Scegliere una metrica come faro guida aiuta tutti i coinvolti a capire per cosa dovrebbero ottimizzare. Senza un simile accordo, si generano controversie. Forse i tuoi "clienti" interni si lamentano della lentezza dei dati. Ma il motivo per cui sono lenti è perché sai che il loro desiderio inespresso è quello di ottimizzare prima di tutto la qualità.

I fari guida comuni di DataOps: qualità dei dati, automazione (processi ripetibili) e decentralizzazione dei processi (alias autosufficienza dell'utente finale).

Una volta individuato un faro guida, è possibile anche stabilire delle metriche o dei principi secondari che puntano a quel faro guida, che è quasi sempre un indicatore ritardato.

Organizza il team in modo che i diversi gruppi interagiscano frequentemente e chiedi ad altri gruppi di informazioni. Queste interazioni possono rivelarsi inestimabili. "Quando i data scientist e i data engineer imparano a vicenda come lavorano, questi team si muovono più velocemente e producono di più", afferma Amir Arad, Senior Engineering Manager di Agoda.

Amir dice di scoprire che uno dei valori nascosti di una leggera ridondanza interfunzionale è quando si pongono domande che nessuno in quel team aveva pensato di porre.

"Il divario nelle conoscenze ingegneristiche è in realtà piuttosto interessante. Può indurre a chiederci di semplificare", afferma Amir. "Ci potrebbero dire: 'Ma perché non possiamo farlo? ' Allora a volte torniamo indietro e ci rendiamo conto che non abbiamo bisogno di quel codice o di quel server specifico. A volte sono i non esperti a proporre le vere novità."

Proprio come per DevOps, i migliori team di operazioni dati sono invisibili e lavorano costantemente per rendersi ridondanti. Piuttosto che interpretare l'eroe che ama intervenire per salvare tutti, ma che alla fine rende fragile il sistema, diventa il leader servitore. Come disse Lao Tzu, l'obiettivo è guidare le persone alla soluzione in modo che pensino: "Ce l'abbiamo fatta da soli".

Tratta il tuo team di operazioni dati come un team di prodotto. Studia il tuo cliente. Conserva un backlog di correzioni. L'obiettivo è rendere lo strumento abbastanza utile da consentire l'effettivo utilizzo dei dati.

Per il monitoraggio e l'osservabilità dei dati, non esiste il concetto di "troppo presto". L'analogia che viene spesso utilizzata per giustificare il rinvio del monitoraggio è: "Stiamo costruendo l'aereo mentre è in volo". Pensa a questa immagine. Non ti dice tutto quello che c'è da sapere sulla tua sopravvivenza a lungo termine? Un'analogia molto migliore è la vecchia architettura. Più aspetti per mettere insieme una fondazione, più costosa sarà da installare e più problemi creerà la mancanza di una base.

Leggi: Cos'è l'osservabilità dei dati?

Le decisioni che prendi ora con la sua infrastruttura di dati, come dice il Gladiatore, "riecheggiano nell'eternità". La scorciatoia della crescita di oggi sarà il gargantuesco incubo del sistema interno che trasforma i dati. Devi ottenere il supporto della dirigenza per prendere decisioni scomode ma corrette, come dire a tutti che devono mettere in pausa le richieste perché ti servirà un trimestre per sistemare le cose.

CASE sta per "copy and steal everything" (copia e ruba tutto), un modo ironico per dire: non costruire tutto da zero. Oggi sono disponibili tanti microservizi utili e offerte open source. Sali sulle spalle dei giganti e concentrati sulla costruzione del 40% della sua pipeline che deve effettivamente essere personalizzato, e farlo bene.

Dai un'occhiata ai ticket nel tuo backlog. Quanto spesso reagisci ai problemi anziché anticiparli? Quanti dei problemi che hai affrontato avevano una causa principale chiaramente identificabile? Quanti ne avete corretti in modo permanente? Più agisci in anticipo, più assomiglierai a un vero team di gestione dei dati. E più sarà utile uno strumento per l'osservabilità dei dati. Una visibilità completa può aiutarti a passare dal semplice mantenimento al miglioramento attivo.

I team che migliorano attivamente la loro struttura migliorano attivamente i loro dati. L'armonia interna porta all'armonia esterna, in una connessione che renderebbe orgoglioso Melvin Conway.

Scopri di più sulla piattaforma di osservabilità continua dei dati di IBM Databand e su come aiuta a rilevare prima gli incidenti che coinvolgono i dati, risolverli più rapidamente e fornire all'azienda dati più affidabili. Se desideri approfondire ulteriormente l'argomento, prenota subito una demo.