Collegare non è gestire i dati master

🌐 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)

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

Capitolo 6 di Data Architect, Parte 1: Diventare un architetto dei dati. Precedente: Qualità e governance dei dati.

“Ci serve un’unica fonte di verità.” È una delle frasi più ripetute in architettura, e una delle meno esaminate. Per cosa? Prendi un account. L’ERP potrebbe possedere la ragione sociale, l’indirizzo di fatturazione e il limite di credito; Salesforce l’account executive e il livello di assistenza; una piattaforma per il consenso le preferenze di marketing. Tre autorità su un solo record, ed è normale. Quindi quando qualcuno dice “Salesforce è la nostra unica fonte di verità per il cliente”, la mia domanda successiva è sempre: quale verità?

Questo capitolo parla di come rispondere a quella domanda di proposito. L’autorità si assegna attributo per attributo. Collegare i record non è gestirli come dati master. E Salesforce ti dà strumenti diversi per lavori diversi: gestione dei duplicati e unione dentro una org; la risoluzione dell’identità di Data 360 per una vista unica tra le fonti; una piattaforma MDM dedicata quando i valori devono essere decisi una volta e rimandati ovunque. Si chiude con il Checkpoint 1, in cui la Parte 1 si ricompone su Steve Trucking.

Immagine generata con l’IA.

Le posizioni di questo capitolo

• Una verità per attributo. Chiediti dove ogni dato viene creato, modificato e referenziato, e quanto in fretta cambia. Mostra l’autorità esterna nello schema con un prefisso di sistema, come sap_ o erp_.
• I potenziali clienti sono diversi. Vivono in Salesforce prima che l’ERP li conosca; l’autorità dell’ERP si applica dopo la conversione.
• Il registry è la norma nei progetti Salesforce, poi vengono consolidamento e coesistenza; l’MDM centralizzato puro è raro.
• Unisci solo quando c’è un vincitore chiaro. Tieni i duplicati che vengono da caricamenti esterni quando potresti doverli ricondurre all’origine; l’unione distrugge quello storico. E decidi cosa succede ai figli: spostarli, non caricarli, o tenerli su un record inattivo.
• Un profilo unificato è una mappa; un golden record è una decisione. Per le persone può creare confusione: la risoluzione dell’identità crea un individuo unificato, ma non un golden record.
• Quanto essere severi nella corrispondenza è una decisione sul rischio. Dove mescolare costa caro, corrispondi di meno di proposito.
• Tre strumenti per tre lavori: unione, risoluzione dell’identità, MDM.
• Le gerarchie hanno un’autorità divisa. Decidi l’autorità ramo per ramo.
• “La cosa più difficile sono i bidirezionali.” Un’integrazione a doppio senso non crea due master. Decidi quali campi viaggiano insieme come una sola transazione prima della prima collisione.
• Rendi visibili i dati master. Un campo che dice che questi sono dati master (la chiave dell’ERP o un flag) determina la modificabilità, non un tipo di record.
• Non controlliamo noi gli ERP. Controlliamo come li rappresentiamo in Salesforce: un cliente in due ERP è una gerarchia, account paritetici, o un solo account con un figlio per ogni ERP, a seconda di quanto bene il cliente mantiene sincronizzati i propri ERP.

Tre strumenti per tre lavori

Il lavoro	Lo strumento	Cosa fa alle fonti
Duplicati dentro una org, con un vincitore chiaro	Gestione dei duplicati e unione	Unisce fino a tre record; gli altri vanno nel Cestino
Un’identità e una vista unica tra le fonti	Risoluzione dell’identità di Data 360	Li collega; non ne cambia nessuno (un registry)
Un valore governato, rimandato a ogni sistema	Una piattaforma MDM dedicata	Decide il valore e lo distribuisce (coesistenza o centralizzato)

Il percorso di questo capitolo

Sei moduli e una sfida, ognuno dei quali si regge da solo.

1. Un’unica fonte di verità per attributo. La mappa delle autorità, il golden record ibrido e i segnali di fiducia.
2. I quattro modi di gestire i dati master. Registry, consolidamento, coesistenza e centralizzato, e perché un modello comune non è una verità comune.
3. Corrispondenza, unione e survivorship. Il costo di una falsa corrispondenza, cosa fa davvero un’unione in Salesforce (e cosa succede ai figli), e la survivorship come affermazione sulla fiducia.
4. Una mappa non è una decisione. Regole e metodi di corrispondenza, regole di riconciliazione, e perché un profilo unificato non è un golden record.
5. Quando l’autorità è condivisa. Richieste e aggiornamenti, loop e collisioni, gerarchie con autorità divisa, e un cliente in due ERP.
6. La sfida del Checkpoint 1, poi Checkpoint 1: Steve Trucking, cosa progetterei io. Prova prima la sfida: disegna e difendi il progetto della Parte 1, poi confrontalo con il mio, e guarda cosa cambia rispetto al panorama del capitolo 4.

Quando hai finito, mettiti alla prova con la guida allo studio del capitolo: una checklist per l’esame, le abitudini che vanno oltre, le parole da conoscere e qualche domanda. Chiude la Parte 1; la guida allo studio della Parte 1 mette insieme tutti e sei i capitoli.

Cosa decide qui un architetto

• Quale sistema è autorevole per ogni attributo importante, e come questo si vede nel modello.
• Quale stile di gestione dei dati master si adatta a ogni dominio di dati, e quanta autorità riceve il livello di gestione dei dati master.
• Quando unire, quando collegare, e chi è responsabile di ogni regola di survivorship.
• Quanto severa deve essere la corrispondenza, in base a quanto costa una falsa corrispondenza.
• Dove dati bidirezionali e gerarchie condivise hanno bisogno di confini espliciti.

Oltre l’esame: gli agenti hanno bisogno di un’identità su cui agire, e questo alza la posta in entrambe le direzioni. Corrispondere troppo diventa un incidente di privacy, e un agente che “aggiorna il cliente” deve scrivere nel system of record di ogni attributo, non nel profilo unificato. Ogni modulo si chiude con ciò che cambia l’IA.

Per approfondire

• Salesforce Architects, Data 360 Architecture (opens in a new tab) (in inglese), consultato il 2026-10-14.
• Guida di Salesforce, Considerations for Merging Duplicate Accounts (opens in a new tab), Identity Resolution Match Methods (opens in a new tab) e Identity Resolution Reconciliation Rules (opens in a new tab) (in inglese), consultato il 2026-10-14.

Successivo: la Parte 2 comincia con Progettare per la scala (coming soon).