I tipi di dati aziendali

🌐 Disponibile anche in 28 lingue

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Immagine generata con l'IA

Tradotto con l'IA. Non ancora rivisto dalla comunità. Leggi in inglese

Modulo 2 di 6 del capitolo Capire i dati aziendali, capitolo 4 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Salesforce è un sistema tra tanti · Successivo: I sistemi intorno a Salesforce

La domanda a cui risponde questo modulo: Quali tipi di dati detiene un’azienda, e perché stanno in posti diversi?

Un record cliente. Un elenco di paesi. Un ordine. La definizione di un campo. Cinque anni di totali di vendita. Quattro milioni di foto delle consegne. Sono tutti dati, ma dal punto di vista architetturale non sono la stessa cosa. Cambiano in modo diverso, crescono in modo diverso, vengono usati in modo diverso e sono di proprietà di persone diverse, e non dovrebbero automaticamente risiedere nello stesso posto. Quindi quando qualcuno dice “ci servono questi dati in Salesforce”, la mia domanda successiva è: che tipo di dati sono? La risposta comincia a dirmi cosa farne.

Parti dal tipo, non dall’oggetto

Come persone di Salesforce, traduciamo i requisiti in strutture quasi all’istante: cliente, Account; foto, File; stato, elenco di selezione. Prima o poi è utile. A livello aziendale voglio prima sapere con che tipo di informazione ho a che fare. Ci sono molti modi di classificarla (il DAMA body of knowledge è il riferimento standard), e io trovo utili sei tipi: master, di riferimento, transazionali, metadati, analitici e non strutturati. Le categorie non sono l’architettura. Sono un modo per porre domande migliori.

Dati master: le cose che il business conosce

I dati master descrivono le cose durature intorno a cui gira un business: clienti, prodotti, prezzi, dipendenti, fornitori, sedi, asset. In una org Salesforce per le vendite, sono i tuoi Account e Contatti, i tuoi prodotti e i tuoi listini prezzi. In Steve Trucking, un Partner retail è un dato master. Keystone non è un evento; è un’organizzazione con cui Steve Trucking ha una relazione continuativa. Anche i nove centri di distribuzione sono dati master.

I dati master sopravvivono alle transazioni che li usano: un Partner retail può avere milioni di consegne. Quindi la prima domanda su di essi è sempre chi li possiede? Potrebbe non essere Salesforce. L’ERP potrebbe possedere i prodotti. Salesforce potrebbe possedere i potenziali clienti mentre l’ERP diventa autorevole quando diventano clienti. Una piattaforma MDM potrebbe possedere l’identità aziendale di un cliente costruita a partire da diversi sistemi. Il capitolo 6, Dati master e identità, approfondisce. Per ora, riconosci la forma.

Dati di riferimento: il vocabolario condiviso del business

I dati di riferimento sono il vocabolario controllato usato per classificare altri dati: codici dei paesi, valute, categorie di prodotto, codici motivo, stati. Gli stati delle consegne di Steve Trucking (pianificata, caricata, in consegna, in arrivo, consegnata, installata, eccezione, resa) sono dati di riferimento. Non sono consegne; sono le parole usate per descrivere le consegne.

Sembrano piccoli e innocui, spesso un elenco di selezione con otto valori. Non confondere piccolo con poco importante. Se Salesforce dice Delivered, l’ERP dice Complete e un Partner retail invia D, qualcuno deve definire cosa significa ciascuno e come si corrispondono. È nei dati di riferimento che si nascondono le ipotesi di integrazione.

Dati transazionali: ciò che è successo

I dati transazionali registrano attività: un ordine effettuato, un pagamento eseguito, una consegna completata, un caso aperto. Nella stessa org per le vendite, sono i preventivi e le righe dei preventivi, gli ordini e le voci d’ordine, i pagamenti: ognuno rimanda a un cliente e a un prodotto. Il milione di consegne all’anno di Steve Trucking sono dati transazionali, e lo sono anche i loro aggiornamenti di stato: circa otto per consegna, quindi otto milioni di cambi di stato all’anno, in un business che cresce del 30% l’anno.

È una curva di crescita completamente diversa da quella dei dati master. Tre Partner retail in cima; milioni di righe sotto. È qui che conta il Numero di Zeri di Steve: non puoi guardare Partner retail → Consegna → Stato e dare a ogni riquadro lo stesso peso. Con i dati transazionali penso subito a volume, velocità, conservazione, storico, archiviazione, integrazione, e a come le persone hanno davvero bisogno di trovarli. La Parte 2 ci dedica molto tempo.

Metadati: dati sui dati

Hai lavorato con i metadati per tutto il corso: la definizione di un oggetto, il tipo di un campo, la sua descrizione, le sue relazioni. Tutta l’azienda ne ha: schemi dei data warehouse, mappature di integrazione, cataloghi di dati, contratti delle API, e per ogni campo un responsabile, un livello di sensibilità, una definizione, una lineage e una regola di conservazione. I valori sono dati; la descrizione di cosa significano è un metadato. Come diceva il capitolo 3, Flag2__c non dice niente a nessuno, e conta di più ora che l’IA legge i metadati per capire cosa significano i dati.

Dati analitici: dati ricavati da altri dati

“Qual è il nostro tasso di puntualità per Partner retail negli ultimi cinque anni?” non è una transazione. È una domanda analitica, a cui si risponde ricavando nuovi dati da milioni di consegne: percentuale di puntualità, tasso di danni, ricavi per partner, qualità delle installazioni, tendenze delle squadre. Ed è un lavoro diverso. Chi fa dispatch e chiede “qual è la prossima tappa del camion 217?” non ha bisogno di scorrere cinque anni di storico. La direzione che confronta cinque anni di puntualità per regione sì. Ecco perché i dati analitici di solito risiedono in un data warehouse, un lakehouse o una piattaforma di analisi costruita per quel lavoro. Che Salesforce possa memorizzare qualcosa non fa della piattaforma operativa il posto in cui eseguire ogni analisi su di esso.

Dati non strutturati: ciò che non entra nelle righe

Documenti, PDF, immagini, audio, video, email, trascrizioni, articoli della knowledge base. In Steve Trucking, le foto delle consegne: circa quattro per consegna, di più con le installazioni, da quattro a cinque milioni all’anno. Una foto non è solo un altro campo. È grande, può mostrare l’interno della casa di qualcuno, ha le sue regole di conservazione, e si cerca in modo diverso, se si cerca.

Questo tipo conta di più ogni anno, perché l’IA ora può fare cose utili con informazioni che prima stavano fuori dal modello strutturato. Una trascrizione è un dato. Un manuale in PDF è un dato. Una foto di installazione è un dato. Non significa che appartenga al core di Salesforce. Significa che appartiene al panorama.

Click to enlarge

Sei tipi, quattro domande ciascuno. Le risposte cambiano da tipo a tipo, ed è proprio questo il punto.

Il tipo è solo metà della domanda: il carico di lavoro

Sapere che tipo di dati abbiamo non basta. Voglio anche sapere cosa ne stiamo facendo. Qui contano tre carichi di lavoro, e confonderli produce cattiva architettura.

Operativo: far funzionare il business. Chi fa dispatch aggiorna una consegna, una squadra completa una tappa, un operatore apre un caso. Tante piccole letture e scritture: trova questo, aggiorna quello, mostrami le tappe di oggi. Questo è l’OLTP, l’elaborazione transazionale online (online transaction processing), e Salesforce è bravissima in questo; è il mondo in cui vivono amministratori e sviluppatori.

Analitico: capire il business. Ogni consegna degli ultimi cinque anni, raggruppata per partner e CD, confrontata anno su anno, unita ai dati finanziari. Ora stiamo scorrendo e aggregando. Questo è l’OLAP, l’elaborazione analitica online (online analytical processing), ed è ciò per cui sono costruiti i warehouse, i lakehouse e le piattaforme di analisi. Detto semplicemente: la org fa funzionare il business; warehouse e lake lo analizzano. Un errore classico è mettere quel carico di lavoro sulla piattaforma operativa e sorprendersi quando gli zeri crescono. Se qualcuno vuole scorrere ripetutamente enormi quantità di storico, non trattarlo come “solo un altro report”. Chiediti se è la piattaforma giusta. La Parte 2 ci torna in Progettare per la scala (coming soon) (non fare del core il tuo warehouse), e la Parte 3 mostra come si costruiscono le strutture analitiche in Oltre il relazionale (coming soon).

Streaming: dati in movimento. Eventi, telemetria, cambi di stato, letture dei sensori. I camion di Steve Trucking inviano circa 200.000 letture GPS al giorno. Chi fa dispatch vuole sapere dov’è il camion 217 adesso. Salesforce ha bisogno di conservare ogni lettura minuto per minuto di ogni camion? Forse no. “Dov’è adesso?” e “quali erano le tendenze di efficienza dei percorsi nell’ultimo trimestre?” vengono dalla stessa fonte e portano a decisioni di archiviazione completamente diverse.

Quanto in fretta deve muoversi?

Poi la latenza. In aula la metto così: il tempo reale è aspettare alla porta che qualcuno torni. Lo mandi fuori e resti lì, perché non puoi andare avanti finché non ritorna. È sincrono. Il quasi tempo reale è guardarlo uscire e fare nel frattempo altro; quando torna poco dopo, te ne occupi. È asincrono. E poi c’è il batch: nessuno esce dalla porta uno alla volta. I dati aspettano e si spostano in gruppo, secondo una pianificazione: ogni ora, ogni qualche ora, o una volta al giorno. Ci sono molte situazioni in cui il batch basta, e alcune in cui non basta. Sapere distinguere le une dalle altre è il lavoro. Questi tre non sono solo termini di integrazione; sono scelte architetturali.

Prendi la comune integrazione con l’ERP. Un nuovo prodotto viene creato nell’ERP alle 11 del mattino. Le vendite hanno davvero bisogno di venderlo entro mezzogiorno? Ho visto entrambe le risposte. Alcuni clienti lo vogliono il prima possibile; altri dicono: se non ti abbiamo ancora spedito quello SKU, non possiamo aspettarci che tu lo venda già. Quindi i prodotti di solito vanno una volta al giorno, a volte più spesso. I clienti, come minimo una volta al giorno; ho visto ogni ora e, in casi estremi, quasi in tempo reale. Gli ordini sono diversi: l’evasione deve partire, quindi quasi in tempo reale. Il venditore chiude l’affare e passa oltre, e l’ordine arriva nell’ERP in un tempo che va da qualche secondo a un paio di minuti. Non esiste un’unica latenza giusta per “i dati aziendali”. Chiediti di cosa ha davvero bisogno il business, e non rendere tutto in tempo reale perché suona impressionante. Il tempo reale ha un costo.

Le quattro domande dietro le categorie

Non devi andare in giro ad annunciare “questi sono dati transazionali!”. La classificazione serve a far scattare quattro domande su ogni insieme di dati importante:

• Chi lo possiede? Quale sistema è autorevole? Io lo divido in tre: dove viene creato, dove viene modificato, e dove viene referenziato? Il capitolo 6 li approfondisce (Creato, modificato, referenziato, e con quale velocità?).
• Quanto in fretta cambia? Una volta all’anno, ogni giorno, da decine a centinaia di volte al secondo?
• Quanto diventa grande? Dieci record, diecimila, dieci milioni, dieci miliardi?
• Qual è il suo ciclo di vita? Vive per sempre, viene archiviato, deve essere eliminato, perde valore nel tempo?

Quelle quattro mi dicono molto più di “Salesforce può memorizzarlo?”. E tengono insieme ciò che abbiamo già imparato: titolarità, ciclo di vita, il Numero di Zeri, dove risiedono i dati.

Un solo business produce tutti i tipi

In Steve Trucking, il Partner retail è un dato master; il vocabolario degli stati è un dato di riferimento; ogni consegna è transazionale; le definizioni dei suoi campi sono metadati; la scheda di puntualità su cinque anni è analitica; la foto di installazione è non strutturata; e il flusso GPS è streaming. Sono tutti “dati di Steve Trucking”. Niente di tutto questo significa che appartengano allo stesso database. È questo il cambio di prospettiva.

Oltre l’esame: cosa cambia l’IA. Per rispondere a una sola domanda, un agente può aver bisogno di un record cliente strutturato, di una transazione recente, di un manuale in PDF, della trascrizione di un’assistenza e della telemetria in tempo reale. I dati non strutturati e di streaming diventano parti a pieno titolo dell’architettura anche quando non appartengono al database del CRM, e l’architetto deve comunque sapere chi possiede ogni fonte, quanto è aggiornata e se l’agente dovrebbe fidarsene.

Cosa decide qui un architetto

• Che tipo di dati è ogni insieme di dati importante, e chi lo possiede.
• Se il suo carico di lavoro è operativo, analitico, di streaming o un misto.
• Quanto in fretta cambia, e quanto in fretta gli altri sistemi hanno davvero bisogno di vedere il cambiamento.
• Come volume e ciclo di vita decidono dove risiede e per quanto tempo.
• Se Salesforce dovrebbe possederlo, tenerne una copia, referenziarlo, o lasciarlo in un posto più adatto al carico di lavoro.

Quando qualcuno ti consegna un requisito, non saltare a quale oggetto, quale campo, quale API. Prima chiediti che tipo di dati è, chi lo possiede, quanto in fretta cambia, quanto diventa grande, quanto a lungo vive, e cosa stiamo cercando di farne. Un Account, un evento di consegna, un aggregato su cinque anni e una fotografia possono contare tutti per lo stesso business senza essere lo stesso problema architetturale.

Per approfondire

• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, 2ª edizione (2017, in inglese): il riferimento standard per le categorie di dati e la gestione dei dati.
• Il brief di Steve Trucking, sezione 4 (volumi).