Un'unica fonte di verità per attributo

🌐 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 1 di 6 del capitolo Dati master e identità, capitolo 6 del corso Data Architect. Ogni modulo si regge da solo. Successivo: I quattro modi di gestire i dati master

La domanda a cui risponde questo modulo: Cosa significa davvero “unica fonte di verità”?

C’è una frase che sento di continuo: “Ci serve un’unica fonte di verità.” Bene. Per cosa? Il cliente? Non è abbastanza specifico. Prendi un account. Chi possiede il nome del cliente, l’indirizzo di fatturazione, il limite di credito, l’account executive, il livello di assistenza, le preferenze di marketing? Quelle risposte non indicano lo stesso sistema. L’ERP potrebbe controllare la ragione sociale, l’indirizzo di fatturazione e lo stato del credito; Salesforce il titolare della relazione e gli attributi di vendita; un’altra piattaforma il consenso. Quindi quando qualcuno mi dice “Salesforce è la nostra unica fonte di verità per il cliente”, la mia domanda successiva è: quale verità?

La verità appartiene a un attributo

Il primo principio dei dati master è questo: l’autorità si assegna per attributo, non per record. Un account può risiedere in Salesforce senza che Salesforce sia autorevole per ogni suo campo. Sette campi su un solo record, due autorità:

Attributo	Sistema autorevole
Ragione sociale, indirizzo di fatturazione, ID cliente ERP, limite di credito	ERP
Account executive, flag di account strategico, livello di customer success	Salesforce

Un solo record; la verità è distribuita. È normale. “System of record = Salesforce” non lo descrive. Un modello delle autorità sì.

Creato, modificato, referenziato, e con quale velocità?

Quando insegno i dati master, torno sempre alle stesse domande per ogni dato importante: dove viene creato, dove viene modificato, dove viene referenziato, e qual è la sua latenza di cambiamento? Fanno emergere l’architettura in fretta. (Le prime tre le hai incontrate nel capitolo 4, quando abbiamo classificato i tipi di dati; è qui che fanno il loro vero lavoro.)

Prendi un asset. Un cliente ordina tre biciclette. Salesforce ha l’opportunità e le sue voci, e l’ordine va all’ERP. L’ERP lo evade, ed è lì che gli asset vengono creati: tre biciclette, tre numeri di serie, rimandati a Salesforce. Mesi dopo il cliente chiama per una di loro, e l’assistenza referenzia l’asset in un caso. Ora qualcuno deve correggere un attributo. Quali può modificare Salesforce, e quali appartengono all’ERP che li ha creati? E quando l’ERP ne cambia uno, con quale velocità deve saperlo Salesforce? Un asset, quattro domande, e le risposte non sono le stesse per ogni campo.

Diciamo che la ragione sociale viene creata nell’ERP e referenziata in Salesforce, e un commerciale si accorge che è sbagliata. Dovrebbe correggerla in Salesforce? Se il campo è dell’ERP, cambiare la copia non corregge niente. Nel migliore dei casi la sincronizzazione successiva la sovrascrive; nel peggiore i due sistemi ora non sono d’accordo e nessuno sa di quale fidarsi. Se il business vuole che il commerciale avvii la correzione, è diverso: Salesforce fornisce l’esperienza, invia una richiesta all’ERP, l’ERP fa o approva la modifica, e il valore autorevole torna indietro. È un’architettura molto diversa dal lasciare che Salesforce modifichi il campo per conto suo.

Anche la latenza fa parte della verità. L’ERP cambia lo stato del credito di un cliente alle 10; Salesforce si sincronizza ogni notte; alle 15 un commerciale guarda Salesforce. Il valore è sbagliato? È vecchio. Se il valore cambia una volta all’anno e un giorno di ritardo non costa nulla, la notte va bene. Se decide se accetti oggi un ordine da un milione di dollari, no. L’autorità dice da dove viene la verità; la latenza dice quanto in fretta gli altri devono sapere che è cambiata. Due decisioni separate.

System of record, di engagement, di riferimento

Qui aiuta il vocabolario del capitolo 4. Un system of record mantiene la versione autorevole. Un sistema di engagement è dove le persone ci lavorano. Un sistema di riferimento fornisce dati che un altro sistema usa ma non possiede. Salesforce può essere il sistema di engagement per la relazione con il cliente mentre l’ERP resta il system of record per i suoi attributi legali e finanziari. Non è una debolezza dell’architettura; è l’architettura. L’errore è fingere che un solo sistema debba possedere tutto perché il diagramma sembri più semplice.

Il golden record ibrido

Questo cambia il significato di “golden record”. Il capitolo 5 ha introdotto l’idea parlando di come tenere fuori i dati sbagliati; qui è il cuore del progetto. Le persone immaginano un record magico con ogni campo gestito come dato master in un solo posto. A volte il progetto è quello. Su Salesforce, più spesso vedo un ibrido: parte dell’account gestita altrove e copiata dentro (ragione sociale, numero cliente ERP, indirizzo di fatturazione, stato del credito), e parte che esiste solo perché serve a Salesforce (account executive, strategia sulle opportunità, livello di customer success, note sulla relazione). I campi dell’ERP entrano perché le persone possano usarli. I campi di Salesforce non tornano mai indietro, perché all’ERP non interessano. Perfettamente ragionevole, purché tutti sappiano quali sono gli uni e quali gli altri.

Rendi visibile l’autorità

Quindi rendo evidente nello schema l’autorità esterna. Se SAP controlla un campo, riceve un prefisso: sap_Customer_Number, sap_Credit_Status, sap_Legal_Name. È la stessa idea del prefisso erp_ del capitolo 4. Usa il nome del sistema quando quell’autorità è specifica e stabile, e un prefisso generico quando conta più il significato del fornitore di oggi. Il punto è che sei mesi dopo, chi legge il modello possa vedere: questo non è solo un altro campo Salesforce; questo valore lo possiede un altro sistema. Non costringere le persone a riscoprire l’autorità ricostruendo a ritroso le integrazioni.

Costruisci una mappa delle autorità

Per i dati master importanti voglio una mappa delle autorità: per ogni attributo chiave, chi lo crea, chi è responsabile della decisione di business, quale sistema è autorevole, e chi o cosa può modificarlo. Quattro domande diverse:

Attributo	Creato da	Responsabile di business	Sistema autorevole	Può modificarlo
Ragione sociale	Finanza	Finanza	ERP	Il processo della finanza
Limite di credito	Finanza	Finanza	ERP	Il team crediti
Account executive	Sales operations	Vendite	Salesforce	La direzione vendite
Livello di assistenza	Service operations	Assistenza	Salesforce	La direzione assistenza
Consenso	Il cliente	Privacy	Piattaforma per il consenso	Il cliente, un processo approvato

Nota che il responsabile di business e il sistema autorevole non sono la stessa cosa. Un sistema non è responsabile delle politiche; le persone sì. Il sistema memorizza e fa rispettare il risultato. È di nuovo il capitolo 5: i responsabili fissano le politiche; gli architetti le fanno rispettare.

Click to enlarge

Un cliente. Molti attributi. Un’autorità per ciascuno.

L’autorità cambia nel corso del ciclo di vita

Un commerciale incontra un potenziale cliente di cui l’ERP non ha mai sentito parlare e crea l’account in Salesforce. In quel momento Salesforce è autorevole per nome, indirizzo, contatti e qualificazione. Il potenziale cliente diventa cliente; l’ERP crea il cliente ufficiale e assegna numero cliente, ragione sociale, indirizzo di fatturazione e credito. L’autorità si è spostata. Salesforce non sbagliava prima; è cambiato il ciclo di vita. È lo schema da provvisorio a governato del capitolo 5: prima della conversione, Salesforce possiede il potenziale cliente; dopo, l’ERP possiede gli attributi governati, e Salesforce continua a possedere i propri. Quindi “quale sistema possiede l’account?” è una domanda debole. Chiediti: quale sistema possiede questo attributo, in questo momento del ciclo di vita?

Una copia non è un’autorità

Copiamo i dati dell’ERP in Salesforce perché le persone ne hanno bisogno di continuo. Questo fa di Salesforce una comoda copia locale, non il master, e l’architettura dovrebbe comportarsi di conseguenza: sola lettura per gli utenti, aggiornata dall’integrazione, etichettata con la sua origine, modificata solo tramite una richiesta, verificata dalla riconciliazione quando la copia si discosta. La copia è utile. L’autorità non si è spostata.

La fiducia ha bisogno di più di un valore

“Indirizzo di fatturazione: 123 Main Street.” Dovresti fidarti? Voglio dei segnali di fiducia: da dove viene, quando è stato confermato l’ultima volta, quale sistema l’ha fornito, e chi o cosa l’ha modificato per ultimo: una persona, un’integrazione, un agente? Ora l’ERP dice 123 Main Street, Salesforce dice 125, e il file di un partner dice “123 Main St., Suite 200”. Quale è giusto? Non rispondere “usa il più recente”. Forse. Ma “il più recente” è a sua volta una regola che presuppone che chi l’ha modificato per ultimo meriti di vincere. Potrebbe essere vero, o terribile. Il modulo 3 affronta questo tema. La fiducia viene dall’autorità e dalla provenienza, non dal trovare un campo compilato.

Steve Trucking: di chi è la verità?

Un Partner retail invia una consegna, e in quell’unica transazione si nascondono diverse verità. Il riferimento d’ordine del partner è del partner; Steve Trucking lo conserva per abbinare gli aggiornamenti, ma non ne diventa il master. Lo stato della consegna (arrivata, consegnata, installata, un’eccezione) è di Steve Trucking; il partner lo riceve, ma ricevere uno stato non rende il partner autorevole su ciò che è successo sul camion. E il Destinatario è il cliente del partner. Il partner fornisce nome, indirizzo, telefono e note di consegna perché a Steve Trucking servono per consegnare. Questo non fa di Steve Trucking il master dell’identità di quella persona, e quella distinzione decide il progetto del Destinatario al checkpoint.

Click to enlarge

Una consegna, due autorità.

Dove risiedono i dati e chi possiede la loro verità sono domande diverse. Salesforce può contenere il numero cliente dell’ERP senza possederlo; Snowflake può contenere lo stato delle consegne senza esserne il master operativo; una piattaforma dei dati dei clienti può unificare le identità senza possedere ogni attributo. Un agente può leggerli tutti e tre, e questo di certo non permette all’agente di decidere quale sia vero.

Oltre l’esame: cosa cambia l’IA. Gli agenti trasformano l’autorità sugli attributi in una regola di esecuzione. Una persona vede un indirizzo di fatturazione sbagliato e sa che “viene da SAP; non dovrei cambiarlo qui”. Un agente a cui si dice di “aggiornare l’indirizzo di fatturazione del cliente” non lo saprà, a meno che non lo progettiamo. Ha bisogno della stessa mappa delle autorità che ha l’architetto: avere accesso a un campo non fa di quel campo il posto giusto in cui scrivere.

Cosa decide qui un architetto

• Quale sistema è autorevole per ogni attributo importante, invece di un solo sistema per un intero record.
• Dove ogni attributo viene creato, modificato e referenziato, e quanto in fretta devono viaggiare le sue modifiche.
• Chi fissa la politica per ogni attributo, e quali persone, integrazioni o agenti possono modificarlo.
• Come l’autorità esterna si vede nel modello: prefissi nei nomi, autorizzazioni, comportamento delle integrazioni.
• Come l’autorità si sposta nel corso del ciclo di vita, per esempio quando un potenziale cliente diventa un cliente governato dall’ERP.

Un’unica fonte di verità non significa una sola org, un solo ERP, una sola piattaforma MDM o un solo record gigante. Significa che per ogni informazione governata l’architettura sa dire dov’è il valore autorevole, e ogni altro sistema sa come comportarsi di conseguenza. Non è un’unica fonte di verità. È un’architettura della verità.

Per approfondire

• Salesforce Architects, Data 360 Architecture (opens in a new tab) (in inglese), consultato il 2026-10-14.