Questo è il secondo articolo di una serie di tre parti su come sfruttare le API per massimizzare il valore dei dati in un'organizzazione digitale. Il primo articolo ha esaminato le proprietà economiche dei dati e i principi su come le organizzazioni digitali dovrebbero trattare i dati.
In "Dragon Psychology 101" - un episodio del podcast Revisionist History - Malcolm Gladwell ricorda le lotte finanziarie del Metropolitan Museum of Art di New York nel 2018. Di fronte a un potenziale deficit di 40 milioni di dollari, il Met ha iniziato a far pagare tasse d'ingresso minime e ha licenziato dozzine di lavoratori.
Come potrebbe un museo con 2 milioni di manufatti nella sua collezione, tra cui 18 Van Gogh, 20 Rembrandt e 46 Picasso, avere difficoltà finanziarie? La risposta astuta è che il museo non sopportava di separarsi da nessuno dei suoi oggetti.
La risposta economica è che la collezione del museo non è stata nemmeno conteggiata nel suo bilancio. Nella categoria "risorse", c'era letteralmente un elemento pubblicitario per la raccolta con un valore attribuito di 0$. Questo deve essere il motivo per cui l'arte di fascia alta è definita "inestimabile".
In pratica, le opere d'arte sarebbero risorse difficili da incassare per qualsiasi organizzazione durante una crisi finanziaria. Non solo ci sono variazioni repentine di valore, ma molti degli articoli del Met stavano raccogliendo polvere in un magazzino del New Jersey. In termini economici, la capacità di un'istituzione di convertire i propri asset in flussi di cassa utilizzabili è nota come "liquidità".
Con questa definizione, la raccolta del Met è bassa sulla scala della liquidità. Dall'altra parte dello spettro c'è il flusso di cassa, l'attività più liquida. Le aziende con un alto rapporto di attività liquide sono generalmente considerate più sane e agili dal punto di vista finanziario.
Riascoltando il podcast, non si può fare a meno di metterlo in relazione con il lavoro svolto ultimamente sull'economia dei dati. Chiaramente, avere la maggior parte dei dati non è la stessa cosa che avere il maggior valore dei dati.
In questo articolo, parleremo di come le organizzazioni che ottengono il massimo valore dai propri dati sono quelle con la maggiore liquidità dei dati.
"Avere la maggior parte dei dati non è la stessa cosa che avere il maggior valore dei dati".
Nell’ultimo articolo abbiamo descritto come le organizzazioni possono condividere e correlare i dati internamente per generare il massimo valore aziendale.
Rendere i dati il più possibile fruibili e protetti significa decentralizzarne la distribuzione, assottigliarli per adattarli al contesto dell’utente ed ottimizzare le prestazioni per renderli effimeri nel perimetro dell'organizzazione.
Pertanto, i principi di progettazione tra la condivisione interna dei dati e l'esposizione sicura per il consumo degli stessi sono in conflitto diretto, come illustrato nella Figura 1 di seguito.
I Mondi dei Dati si Scontreranno
Queste due controverse fonti di valore dei dati sono evidenti quando si esamina la storia dell'elaborazione dei dati. Negli ultimi decenni sono emersi due mondi di elaborazione dei dati: OLTP e OLAP.
OLTP (elaborazione delle transazioni online) è il mondo delle applicazioni in tempo reale rivolte ai clienti e agli utenti, mentre OLAP (elaborazione analitica online) è il mondo del reporting aziendale e del supporto decisionale.
OLTP genera valore dai dati attraverso il consumo e la protezione, mentre OLAP genera valore dai dati attraverso la condivisione e la correlazione.
Questi mondi si sono evoluti in modo alquanto indipendente, con ruoli, scenari di utilizzo e stack tecnologici diversi. Sebbene entrambi i mondi siano stati rivoluzionati dal cloud computing, i conseguenti cambiamenti di paradigma sono stati diversi.
OLTP è alle prese con l'architettura dei microservizi, la cultura DevOps e le tecnologie cloud-native distribuite. La fase attuale di OLAP prevede data warehouse cloud, data science e ingegneria dei dati. Entrambi i mondi coesistono efficacemente come hanno sempre fatto, ma nuove forze li stanno facendo convergere.
La migliore capacità di elaborazione e le innovative tecnologie dei dati stanno rimuovendo alcune delle barriere storiche tra OLAP e OLTP. In particolare, lo streaming dei dati, in particolare la crescente popolarità di Apache Kafka, ha consentito lo spostamento in tempo reale dei dati sia verso le pipeline analitiche di origine sia per l'integrazione basata sugli eventi dei sistemi operativi.
Il machine learning crea modelli dai dati immagazzinati che possono essere incorporati nelle applicazioni rivolte agli utenti. L'uso crescente di applicazioni SaaS significa che i data engineer devono essere fluenti nelle tecnologie web del mondo operativo.
Questo ci riporta al concetto di liquidità che abbiamo sollevato in precedenza. Possiamo considerare la liquidità dei dati come una misura dell'efficacia con cui le organizzazioni possono superare il divario tra i mondi OLAP e OLTP.
Valore dei Dati: dalla Catena al Ciclo
La Figura 2 di seguito mostra come il valore dei dati è stato storicamente generato con rispetto ai sistemi analitici e operativi:
In questo caso, esiste un processo per inserire, preparare e trasformare i dati prima che possano essere analizzati. Ciò potrebbe essere fatto estraendo dati da applicazioni e database disparati, utilizzando uno strumento ETL per raggrupparli in batch e quindi utilizzando strumenti di BI per eseguire analisi.
L’anello successivo della catena consiste nell'incorporare le informazioni sulla BI nelle applicazioni rivolte agli utenti. Spesso, questo può essere un processo manuale che richiede il completamento di un ciclo di vita di sviluppo completo. Considerando il ritmo del business nell'economia digitale, c'è un'enorme latenza in questo approccio. La liquidità dei dati è bassa.
Idealmente, le organizzazioni desiderano un ciclo del valore dei dati che riduca al minimo la latenza e chiuda il ciclo, consentendo al valore dei dati di fluire dal mondo OLAP a OLTP e viceversa.
La Figura 3 di seguito mostra come è possibile ottenere un'elevata liquidità dei dati utilizzando tecnologie innovative e approfondimenti sulle proprietà economiche dei dati.
Qui, le applicazioni rivolte all'utente forniscono dati di origine che vengono raccolti e trasmessi a sistemi analitici. Gli insight derivano dai dati, potenzialmente sotto forma di un modello di machine learning che può essere distribuito tramite pipeline al mondo operativo e contestualizzato in applicazioni rivolte all'utente.
Gli utenti che utilizzano queste applicazioni generano nuovi dati e metadati che possono essere raccolti e facilmente correlati con i dati esistenti, il che potrebbe portare a nuove informazioni o attivare la riqualificazione del modello. E così via. Il ciclo del valore dei dati continua in perpetuo. Ma come può un'organizzazione implementare una configurazione così liquida?
APIs Bloccate nel Canale Dati
La connessione dei mondi OLAP e OLTP sta guadagnando sempre più attenzione nel campo dell'ingegneria dei dati. L'approvvigionamento di dati dai sistemi operativi è sempre stato un obiettivo, ma gli approcci si stanno evolvendo.
ETL si sta trasformando in ELT, con il decollo di tecnologie leggere come DBT. I dati in batch vengono sostituiti da flussi. Le fonti locali vengono potenziate con le fonti SaaS.
La comunità di ingegneria dei dati utilizza il termine "ETL inverso" per descrivere quest'area. I Data Scientist che creano modelli di machine learning lo chiamano "distribuzione del modello".
Il mercato non è ancora arrivata a qualcosa che si avvicini a un approccio standard. Quindi qui proponiamo un approccio che permetta ai mondi OLAP e OLTP di mantenere la maggior parte della loro indipendenza, creando al contempo i giusti condotti tra di loro per far fluire il valore dei dati.
“Le API sono la forma di dati più liquida”.
L'anno scorso sul podcast pubblicato da MuleSoft, APIs Unplugged, Sanjna Verma ha condiviso la storia della creazione della piattaforma dati COVID-19 di Salesforce. È una storia fenomenale, ma vogliamo approfondire in particolare il punto di come i dati fluiscono attraverso la piattaforma dalle fonti al consumo degli utenti.
La piattaforma dati COVID-19 abbraccia entrambi i mondi dell'elaborazione dati, OLAP e OLTP. La parte OLAP presenta un approccio di pipeline di dati standard, con inserimento, preparazione, archiviazione e analisi.
SQL è la lingua madre di questo mondo. Tuttavia, “la lingua franca” utilizzata nella piattaforma per collegare OLAP a OLTP sono le API Web. Le fonti esterne di dati sul COVID-19, come il New York Times e l'ECDC, sono state normalizzate e importate tramite API.
Le entità di dati curate necessarie per il consumo sono state esposte come API. Infine, sono state fornite API a canali specifici (applicazioni Salesforce interne, soluzioni partner, sviluppatori esterni) per aiutare a contestualizzare i dati per un'esperienza utente ottimale.
Se la liquidità è la misura di come i dati fluiscono attraverso un'organizzazione, la facilità con cui i dati possono essere presentati nella forma giusta nel posto giusto al momento giusto, allora le API sono la forma di dati più liquida.
API-led Connectivity
Non sono solo le API a guidare la liquidità dei dati. Se esaminiamo l'uso delle API nella piattaforma dati COVID-19 di Salesforce, vediamo che le API sono utilizzate in tre livelli distinti all'interno dell'architettura della piattaforma.
Innanzitutto, vengono acquisiti dati grezzi dalle fonti per alimentare la pipeline di analisi. In secondo luogo, le API sono utilizzate per esporre le entità principali del data warehouse.
Infine, i dati sono contestualizzati attraverso un terzo livello di API più vicino al punto di consumo. Questo approccio a più livelli rende i dati della piattaforma componibili ed è stato il motivo per cui è stato possibile aggiungere così tante nuove fonti e utenti in un periodo di tempo così breve.
Una versione generalizzata di questa architettura API di dati a più livelli è illustrata nella Figura 4 di seguito.
È possibile reinserire nella pipeline i nuovi dati generati dal consumo di dati esistenti. Questo dettaglio ci consente di chiudere il cerchio e utilizzare questo approccio a più livelli per implementare il ciclo del valore dei dati illustrato in precedenza nell’immagine 3.
In maniera simile al modo in cui la connettività guidata da API consente di comporre le capacità aziendali di un'organizzazione in automazioni, esperienze utente e prodotti confezionati, la connettività dati basata su API (ALDC) consente alle organizzazioni di interoperare tra i loro mondi di dati disparati, consentendo allo stesso tempo a quelle parti di rimanere intatte.
ALDC fornisce i dati nel modo più efficiente possibile ai giusti utenti, fornendo allo stesso tempo modularità nell'architettura per rendere le organizzazioni più adattabili al cambiamento e consentire il riutilizzo ottimale delle risorse di dati.
La Figura 5 illustra le relazioni tra i livelli e il modo in cui vengono mappati al ciclo del valore dei dati.
Come la maggior parte dei settori dell'economia digitale, la gestione dei dati sta diventando sempre più complessa. Tuttavia, a causa del valore economico unico dei dati, le aziende che li gestiscono in modo più efficace, che ottengono la massima liquidità, saranno ben posizionate per prosperare nell'era digitale.
L’API-led Connectivity è un approccio per ottimizzare il valore dei dati e creare componibilità per le risorse di dati. Nel prossimo articolo di questa serie esamineremo come ALDC può aiutare a fornire solidi meccanismi di protezione dei dati oltre a camminare attraverso alcuni esempi di ALDC nella pratica.
Mulesoft ha consentito di sbloccare dati e ottimizzare Salesforce attraverso API e integrazione, contribuendo ad incrementare del 60% l’efficienza nel project delivery.
Se vuoi avere maggiori informazioni su MuleSoft Anypoint Platform invia una mail a cio@florence-consulting.it o chiama lo (055) 538-3250.
Visita la pagina dedicata sul nostro sito per ricevere ulteriore materiale informativo o per richiedere una demo gratuita.
In alternativa, puoi compilare il form sottostante con la tua domanda.
