Sempre più aziende hanno iniziato a utilizzare la metodologia DataOps. Vediamo di capire perché, di cosa si tratta e come adottarla. Come si può intuire dal nome, DataOps è la contrazione dei termini “Data” e “Operations” e nasce, estendendola e adattandola alle problematiche tipiche dei processi di analisi dei dati, dalla disciplina DevOps (Development Operations). Da quest’ultima eredita le prassi legate all’automazione dei processi e la modalità “iterativa” di implementazione dei processi.
DataOps, un po’ di storia
Si tratta di un termine abbastanza recente, la sua prima comparsa è riconducibile al 2014 a opera di Lenny Liebmann, editorialista di InformationWeek. anche se la sua popolarità esplode nel 2017 grazie agli articoli e le conferenze di Andy Palmer (Tamr). Gartner ha inserito DataOps nell’Hype Cycle per il Data Management nel 2018.
Il DataOps Manifesto
Uno dei modi migliori per approcciare la cultura DataOps è sicuramente la lettura del “DataOps Manifesto”, la cui prima massima recita:
1.Continually satisfy your customer
“Our highest priority is to satisfy the customer through the early and continuous delivery of valuable analytic insights from a couple of minutes to weeks”.
Tale affermazione enfatizza l’importanza deila collaborazione, tramite scambio di feedback continui degli stakeholders, e di rilasci frequenti in pieno stile agile.
Ma fin qui potremmo pensare a una indicazione di massima quasi esclusivamente di buon senso. Da un punto di vista pratico l’impatto arriva forte andando avanti con i punti:
9. Analytics is code
“Analytic teams use a variety of individual tools to access, integrate, model and visualize data. Fundamentally, each of these tools generates code and configuration which describes the actions taken upon data to deliver insight”.
10. Orchestrate
“The beginning-to-end orchestration of data, tools, code, environments and the analytic teams work is a key driver of analytic success”.
11. Make it reproducible
“Reproducible results are required and therefore we version everything: data, low-level hardware and software configurations, and the code and configuration specific to each tool in the toolchain”.
Utilizzo di versioning e strumenti di Continuous Integration e Continuous Delivery (CI/CD), e qui siamo sulla pratica DevOps, utilizzati per automatizzare il processo e fornire un flusso continuo di informazioni necessario ad alimentare procedura analitiche anche in near realtime.
Probabilmente per capire l’impatto di business di tale approccio è necessario fare lo sforzo di calarsi nei panni di realtà estremamente innovative. Ad esempio immaginiamo per un attimo di essere Amazon che modifica il prezzo degli articoli a catalogo circa 2,5 milioni di volte al giorno o un broker che vende biglietti di voli low-cost. Solo automatizzando l’intero processo è possibile rendere disponibili in tempi rapidi al sistema analitico dati come, ad esempio, le ultime interazioni dell’utente con la piattaforma.
Verrebbe da pensare che tale modalità operativa potrebbe fornire risultati in tempi rapidi a scapito dei risultati nel medio e lungo termine. Non è così.
Andando avanti nel manifesto leggiamo infatti:
14. Analytics is manufacturing
“Analytic pipelines are analogous to lean manufacturing lines. We believe a fundamental concept of DataOps is a focus on process-thinking aimed at achieving continuous efficiencies in the manufacture of analytic insight”.
15. Quality is paramount
“Analytic pipelines should be built with a foundation capable of automated detection of abnormalities (jidoka) and security issues in code, configuration, and data, and should provide continuous feedback to operators for error avoidance (poka yoke)”.
16. Monitor quality and performance
“Our goal is to have performance, security and quality measures that are monitored continuously to detect unexpected variation and generate operational statistics”.
L’utilizzo di tecniche di controllo statistico ereditate dal mondo della produzione industriale e il monitoraggio continuo, utilizzando anche metriche specifiche di dominio che grazie all’approccio collaborativo di base sono disponibili anche ai Data engineer che fisicamente si occuperanno della realizzazione delle pipeline, consentiranno di ottenere risultati di qualità nel tempo. Le iterazioni continue di migliorare costantemente il processo.
Ostacoli e opportunità della DataOps e relazione con il cloud computing
“I dati sono il nuovo petrolio” è la celebre frase coniata nel 2006 dal matematico e imprenditore (data scientist della prima ora) Clive Robert Humby, l’inventore delle fidelity card. Risale infatti al 1995 la sua prima campagna personalizzata creata per Tesco.
Che i dati, diventati “big”, siano un asset aziendale di primaria importanza è oggi un concetto abbastanza consolidato anche nelle organizzazioni più tradizionali. Mettere in atto processi che riescano a trasformare il loro potenziale in reale valore è tuttavia ancora appannaggio di pochi. Gli ostacoli principali, secondo un report di NewVantage Partners del 2018, sono riconducibili a una “mancanza di cultura dei dati” e a impedimenti di natura organizzativa. Non a una mancanza di know-how e tecnologie come si potrebbe pensare. Centrali, ai fini della trasformazione, diventano quindi azioni per la diffusione della data-culture e, a livello direzionale, una data-strategy di medio e lungo termine.
Le moderne piattaforme analitiche, basate su architetture distribuite, unite alla elevata disponibilità di risorse computazionali fornita dal cloud computing, consentono di analizzare senza eccessivi sforzi volumi di dati dell’ordine di grandezza del Petabyte (1015 byte), tipici di contesti quali il mondo IoT. Governare correttamente tali quantità di dati, peraltro tipicamente molto variegati e spesso poco strutturati, è cosa ben diversa.
Mettere a disposizione dei data analyst e dei data scientist set aggiornati sui quali poter condurre analisi o sviluppare modelli predittivi, ad esempio, comporta in contesto Big data l’onboarding nel team di figure con competenze di Big data engineering. Il maggior numero di passaggi, rispetto a quelli necessari al recupero dei dati da un tradizionale RDBMS o DWH, e lo skill-gap relativamente alla conoscenza del dato delle differenti figure, potrebbero generare colli di bottiglia e allungamento dei tempi di rilascio dei risultati delle analisi, con conseguente perdita di valore delle stesse (ricordate la “v” di velocity, insieme a volume e variety, nel celebre 3V’s model di Gartner?).
Per concludere, “i dati sono il nuovo petrolio” ma ottenere da essi valore necessita le competenze per la messa a punto di processi di estrazione efficienti.
