Dizionario, lineage e classificazione

🌐 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 3 di 6 del capitolo Qualità e governance dei dati, capitolo 5 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Tenere fuori i dati cattivi · Successivo: Le leggi sulla privacy danno forma al progetto

La domanda a cui risponde questo modulo: Come registri cosa significano i dati, da dove vengono e quanto sono sensibili?

Hai ereditato una org. Account ha 900 campi, tra cui Customer_Type__c, Customer_Class__c, Customer_Category__c, Customer_Status__c, ERP_Status__c e Account_Status__c. Quale ti dice se qualcuno è davvero un cliente? Apri le descrizioni. Tre sono vuote. Una dice “Customer Type”. Grazie tante. Una dice che viene dall’ERP; un’altra è stata creata sei anni fa da qualcuno che se n’è andato da tempo. Ora immagina di non essere l’architetto ma un’integrazione, un team di reportistica o un agente. L’organizzazione ha moltissimi dati. Non significa che sappia cosa significano.

È qui che i metadati diventano architettura, attraverso tre domande collegate ma non uguali:

• Dizionario: cosa significano questi dati?
• Lineage (provenienza dei dati): da dove vengono?
• Classificazione: come vanno trattati?

Due tipi di metadati

I metadati sono di due tipi, e ti servono entrambi. I metadati di business sono ciò che i dati significano per il business: la definizione, il responsabile, le regole d’uso, quanto sono sensibili. I metadati tecnici sono il modo in cui i dati sono costruiti e si muovono: l’oggetto e il campo, il tipo e la lunghezza, il nome API, lo schema, la mappatura da un sistema all’altro, la lineage dall’origine alla destinazione. Il nome API e il tipo di un campo dicono a uno sviluppatore come usarlo; la sua definizione e il suo responsabile dicono a tutti gli altri se usarlo. Quando non vanno d’accordo, o uno dei due manca, è lì che integrazioni e report vanno storti.

Da sapere per l’esame. Distingui i metadati di business (significato, definizioni, responsabile, regole, sensibilità: il dizionario di business e la classificazione) dai metadati tecnici (oggetti, campi, tipi, nomi API, schemi, mappature e lineage).

Parti dal significato

Il capitolo 3 ha fissato la regola: ogni campo riceve una descrizione. Non “Customer Status” per un campo chiamato Customer Status, ma qualcosa come “L’attuale relazione commerciale del partner con Steve Trucking. Impostata dall’ERP dopo l’attivazione. Non usare per la qualificazione dei potenziali clienti.” Ora so cosa significa, da dove viene e per cosa non usarlo. È l’inizio di un dizionario di business: definizioni comuni per i dati che contano. Cos’è un cliente? Un cliente attivo? Cosa significa Consegnata? Cosa conta come puntuale? Sembrano ovvie finché non metti cinque reparti in una stanza: la Finanza ha una definizione, le Vendite un’altra, le Operazioni una terza, il data warehouse una quarta, e qualcuno ha costruito un dashboard su una quinta. Il problema non è che nessuno parli la stessa lingua. È che l’azienda non si è accordata sul significato.

Un dizionario può vivere in un foglio di calcolo o in uno strumento di documentazione, ma le sue definizioni importanti devono stare vicino a dove le persone usano i dati. Sulla piattaforma sono le descrizioni dei campi, il testo della guida e i metadati di classificazione. Nelle analisi conta ancora di più: “ricavi” non può significare una cosa nel dashboard della direzione e un’altra nella query di un analista. È a questo che serve un livello semantico, e i modelli semantici di Data 360 contengono definizioni governate come metriche, dimensioni e relazioni al di sopra dei dati fisici (Create a Semantic Model in Data 360 (opens in a new tab)). La tecnologia cambia; il requisito no: i dati importanti hanno bisogno di un significato condiviso.

E parti dal significato, non dalla tecnologia. Un dizionario che comincia con oggetto, campo, tipo e nome API documenta l’implementazione. Uno che comincia con i termini di business documenta l’azienda:

Termine di business	Significato	Dove è rappresentato
Partner retail	Un retailer per cui Steve Trucking consegna, sotto contratto	Account Salesforce; cliente nell’ERP finanziario
Consegna	Una consegna a un Destinatario, a un indirizzo, in un giorno	Oggi RouteDesk; un ordine di lavoro quando le consegne passeranno in Salesforce
Destinatario	La persona che riceve una consegna	Dati del Destinatario sulla consegna
Consegnata	Completata secondo la definizione operativa concordata	Stato della consegna
Consegna puntuale	Completata entro la fascia di consegna concordata	Metrica derivata

Click to enlarge

Un significato, molte rappresentazioni tecniche.

Poi chiediti da dove vengono

Una volta che so cosa significa un valore, voglio sapere da dove viene. È la lineage. La ragione sociale di un partner in Salesforce: l’ha digitata un commerciale, l’ha inviata l’ERP, l’ha trasformata un’integrazione, l’ha unificata Data 360, è stata calcolata, l’ha generata l’IA? Queste cose incidono su quanto mi fido del valore e su cosa posso farci. Ricorda i record provvisori del modulo 2: due account possono dire entrambi “Keystone”, uno creato ieri da un commerciale, l’altro dall’ERP con un identificatore autorevole. Stesso testo, lineage diversa, trattamento diverso.

La lineage non è solo il diagramma di un data engineer con mille tabelle. Per i dati importanti voglio rispondere a domande pratiche: dove è nato, quale sistema è autorevole, cosa lo ha trasformato, quali sistemi ne hanno ricevuto copie, cosa lo ha modificato per ultimo, e posso ricondurre un valore derivato alle sue fonti? Il panorama del capitolo 4 dice che i sistemi sono collegati. La lineage dice cosa è successo ai dati lungo il percorso.

Una parte della lineage arriva gratis: l’ID ERP sull’account, Creato da e Ultima modifica di, i log delle integrazioni, i documenti di mappatura. Data 360 aggiunge ai suoi oggetti dati dei campi di lineage che registrano l’origine dei dati e l’oggetto di origine di ogni record (Data Lineage Fields (opens in a new tab)). Ma non dare per scontato che la lineage compaia perché i sistemi sono integrati. A volte la lineage più utile è un solo campo: Sistema di origine = Keystone. E se l’origine conta per la governance, rendila meccanicamente affidabile, impostata dall’integrazione, non digitata da una persona.

I dati derivati hanno più di tutti bisogno di lineage. Diciamo che Steve Trucking calcola un rischio di consegna in ritardo a partire dalla posizione del camion, dalla fascia di consegna e dallo storico del percorso, e il dispatch lo usa per stabilire le priorità. Da dove è venuto “alto”? Aggiungi un agente che dice a un Destinatario “la tua consegna è in ritardo”, e devi sapere cosa ha fondato quella risposta, e quanto era aggiornato. Più ti allontani dai valori memorizzati verso quelli calcolati, unificati, previsti e generati, più la lineage conta.

La classificazione risponde a un’altra domanda

Ora: come andrebbero trattati? Nome del Destinatario, indirizzo di consegna, numero di telefono, note di consegna, stato della consegna, numero del camion, centro di distribuzione, Partner retail, foto: non sono ugualmente sensibili. “In consegna” non è un numero di telefono, e il codice di un CD non è la foto dell’interno della casa di qualcuno. Salesforce ti permette di registrarlo su ogni campo, standard o personalizzato: Data Owner, Field Usage, Data Sensitivity Level e Compliance Categorization (Data Classification Metadata Fields (opens in a new tab)). Il capitolo 3 li chiamava i campi della tassonomia, e spiegava perché contano: segnala un campo come PII o GDPR e i processi possono trovarlo, dagli strumenti di mascheramento al trust layer di Salesforce per l’IA, che può impedire ai valori segnalati di raggiungere un modello linguistico di grandi dimensioni. Una cautela dal capitolo 3: Salesforce ora disattiva quel mascheramento verso l’LLM per gli agenti, perché può togliere il contesto di cui un agente ha bisogno (Classifica ciò che conta: i campi della tassonomia). Quindi la classificazione deve comunque guidare gli altri controlli.

Qui la mia posizione è deliberata: classifica i campi sensibili, non ogni campo. Non voglio tre mesi passati a classificare migliaia di campi perché qualcuno possa riferire “classificato al 100%” e nessuno lo usi. Il numero di telefono del Destinatario: sì. L’indirizzo di casa: sì. Le note di consegna che possono contenere codici del cancello e “cane in giardino”: sì. Le foto che possono mostrare persone o una casa: assolutamente. Un’etichetta di visualizzazione interna? Non è lì che dovrebbe andare l’energia della governance. Non significa che i campi non documentati siano accettabili. Due lavori diversi: la documentazione è ampia; la classificazione è deliberata. È questo che mantiene significativa la classificazione.

Una tassonomia che le persone possano usare

La classificazione ha bisogno di un vocabolario, una tassonomia. Quella predefinita di Salesforce va da Public, Internal, Confidential, Restricted a MissionCritical; la tua organizzazione può volere etichette proprie. Non le prescrivo. Mantienile comprensibili: se ci sono 47 categorie e nessuno fuori dal team privacy sa distinguere la categoria 31 dalla 32, non sta aiutando. Una buona tassonomia collega un’etichetta a un comportamento. Se un campo è un dato personale sensibile, chi può vederlo, può andare in una sandbox, uscire dalla regione, comparire nelle analisi, per quanto tempo viene conservato, può usarlo un agente? Ora la classificazione sta lavorando.

La classificazione senza applicazione è decorazione

Segna come sensibile il numero di telefono del Destinatario senza cambiare nient’altro, e hai scritto della documentazione. Utile, ma la governance va oltre: la classificazione dovrebbe guidare autorizzazioni, mascheramento, crittografia, conservazione, consenso, movimento dei dati, uso nelle sandbox, audit e accesso dell’IA. In parte è una decisione di progettazione dell’architetto; in parte alcune piattaforme ora applicano tag e classificazioni direttamente nelle policy, come fa la governance di Data 360 (Data Governance in Data 360 (opens in a new tab)). E segnare un campo come Restricted non impedisce a nessuno di leggerlo. La classificazione dice come un campo andrebbe trattato; la sicurezza fa sì che lo sia. La sequenza è: identifica i dati, capiscili, classifica ciò che conta, poi applica i controlli che quella classificazione richiede.

Click to enlarge

Tre domande sui tuoi dati, e la terza deve guidare qualcosa.

Anche i dati di riferimento hanno bisogno di metadati

Codici dei paesi, stati delle consegne, codici dei CD, identificatori dei partner, motivi di annullamento: sembrano semplici finché due sistemi non sono d’accordo. Uno dice CANCELLED, un altro CANCELED, un terzo CNCL, un quarto 9. I dati di riferimento hanno bisogno di definizioni, un responsabile, un’origine, un ciclo di vita quando i valori cambiano, e mappature quando i sistemi li rappresentano in modo diverso. Valori piccoli possono guidare processi molto grandi. Il capitolo 6 va oltre.

Tutte e tre insieme

Prendi il numero di telefono del Destinatario. Dizionario: il numero usato per raggiungere la persona che riceve una consegna specifica. Lineage: dal manifesto di carico del Partner retail. Classificazione: dato personale. Ora le domande di architettura sono possibili: la squadra può vederlo, e per quanto tempo (il brief dice solo per le proprie tappe, solo quel giorno); può andare in una sandbox; Snowflake ne ha bisogno; può usarlo un agente; cosa succede quando la consegna è completata?

Ora prendi lo stato della consegna. Dizionario: lo stato operativo attuale della consegna. Lineage: impostato dal processo di consegna di Steve Trucking e rimandato a ogni partner attraverso la sua integrazione. Classificazione: operativo, non sensibile. Dati diversi, trattamento diverso. È proprio questo il punto.

Non tratto i metadati come documentazione prodotta dopo che la vera architettura è finita. Se non so dire cosa significa un campo, non capisco il modello dati. Se non so da dove viene un valore, non capisco le integrazioni. Se non so se è sensibile, non capisco la sicurezza. I metadati descrivono l’architettura, e a volte la guidano.

Oltre l’esame: cosa cambia l’IA. La classificazione sta diventando l’interruttore di ciò che un agente può recuperare o ripetere, e la lineage deve arrivare fino alla risposta o all’azione dell’agente. Se un agente dice a un Destinatario che la consegna è in ritardo, l’architettura dovrebbe saper dire cosa ha fondato quella risposta, da dove viene, e se l’agente era autorizzato a usarlo. “Da qualche parte in Salesforce” non è lineage, e “dati dei clienti” non è una classificazione.

Cosa decide qui un architetto

• Quali termini di business hanno bisogno di definizioni governate, perché sistemi e team non diano significati diversi alla stessa parola.
• Come i valori importanti conservano abbastanza lineage da mostrare origine, autorità e trasformazioni.
• Quali campi hanno un significato di sensibilità o di conformità e ricevono quindi una classificazione esplicita.
• Quale tassonomia usa l’organizzazione, e se le persone riescono ad applicarla in modo coerente.
• Come la classificazione guida controlli reali invece di restare inutilizzata.

Prima di governare i dati, sappi cosa hai: cosa significano, da dove vengono, come vanno trattati. Documenta in modo ampio, classifica in modo deliberato, conserva la lineage dove conta. Altrimenti non governi i dati. Semplicemente li hai.

Per approfondire

• Guida di Salesforce, Data Classification Metadata Fields (opens in a new tab) (in inglese), consultato il 2026-10-14.
• Guida di Salesforce, Data 360: Data Lineage Fields (opens in a new tab), Data Governance in Data 360 (opens in a new tab) e Create a Semantic Model in Data 360 (opens in a new tab) (in inglese), consultato il 2026-10-14.