I quattro modi di 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)

Immagine generata con l'IA

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

Modulo 2 di 6 del capitolo Dati master e identità, capitolo 6 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Un’unica fonte di verità per attributo · Successivo: Corrispondenza, unione e survivorship

La domanda a cui risponde questo modulo: Come gestiscono i dati master le organizzazioni, e quale stile si adatta?

Il modulo 1 ha detto che l’autorità si assegna attributo per attributo. Ora: cosa facciamo quando quegli attributi vivono in più sistemi contemporaneamente? Informazioni sui clienti in Salesforce, nell’ERP, nella fatturazione, nell’assistenza, forse in Data 360, forse in un data warehouse, ognuno con la sua versione. È il problema che la gestione dei dati master (MDM) cerca di risolvere, e l’MDM non è un’unica architettura. Sentirai parlare di quattro schemi: registry, consolidamento, coesistenza e centralizzato. Non sono impostazioni di prodotto. Sono quattro risposte a una sola domanda: quanta autorità ha il livello di gestione dei dati master?

Parti dal problema, non dal prodotto

Le persone sentono MDM e iniziano a cercare un prodotto MDM da comprare. Io partirei dal problema. Ci basta sapere che più record sono lo stesso cliente? Ci serve una vista combinata per le analisi? Dobbiamo decidere quali valori sono autorevoli e rimandarli agli altri sistemi? O vogliamo un unico sistema centrale che crei i dati master per tutti? Requisiti molto diversi, architetture molto diverse.

Registry: dimmi chi è chi

Lo schema più leggero. Un registry non sostituisce le fonti. L’ERP tiene il suo cliente, Salesforce il suo account, la fatturazione il suo cliente, e il registry capisce che questi record rappresentano la stessa entità: l’account Salesforce 001…, il cliente ERP SAP-43821 e il cliente di fatturazione BILL-9127 appartengono a un solo cliente. Le fonti restano dove sono e non vengono sovrascritte. Ora “mostrami tutto ciò che sappiamo di questo cliente” ha una risposta.

Ma nota a cosa non risponde un registry. Salesforce dice 123 Main Street, l’ERP 125, la fatturazione “123 Main St., Suite 200”. Il registry sa che vanno insieme. Non decide quale debba cambiare. Collegare non è gestire i dati master.

Nella mia esperienza, il registry è la norma nei progetti Salesforce, poi vengono consolidamento e coesistenza; l’MDM centralizzato puro è raro. Il registry è comune perché non è invasivo. Non riprogetti ogni sistema operativo prima di ottenere valore. Salesforce continua a fare ciò che fa, l’ERP continua a fare ciò che fa, e aggiungi un livello di identità. È un cambiamento molto più piccolo che dire a ogni sistema “non controlli più i dati dei clienti; li controlla questo nuovo sistema centrale”.

Click to enlarge

Il registry risponde: quali record appartengono alla stessa entità?

Consolidamento: riunisci i dati

Il consolidamento prende i dati da più fonti e li combina in una rappresentazione centrale, per reportistica, analisi, segmentazione, conoscenza del cliente. Un data warehouse è l’esempio familiare: Salesforce invia il cliente, l’ERP i dati finanziari, la fatturazione i pagamenti, e il business può finalmente analizzare il cliente attraverso i sistemi. Le fonti esistono ancora e possono essere ancora autorevoli. La direzione conta: i dati scorrono verso il sistema consolidato, che di solito non rimanda indietro modifiche gestite come dati master. Un’immagine migliore del cliente, senza diventarne l’autorità operativa.

Registry e consolidamento si confondono facilmente. La differenza è cosa viene centralizzato: il registry centralizza l’identità (“questi vanno insieme”); il consolidamento centralizza una parte maggiore dei dati (“riuniamo gli attributi per poterli usare”). Nessuno dei due dice “questo sistema centrale ora è il master e ogni applicazione deve accettarne i valori”.

Click to enlarge

Il consolidamento riunisce i dati senza togliere la titolarità alle fonti.

Coesistenza: decidi, e rimandalo indietro

Nella coesistenza, il livello di gestione dei dati master riceve un’autorità reale. I dati vivono ancora in più sistemi operativi, ma il processo MDM decide il valore master e lo pubblica di ritorno. Salesforce, l’ERP e la fatturazione hanno ciascuno una ragione sociale diversa; il processo MDM determina quella governata e la distribuisce a tutti e tre. I sistemi coesistono, ma convergono sul valore master.

È una forma di MDM molto più forte. Non sta dicendo “questi vanno insieme”; sta dicendo “per questo attributo, questo è il valore che usa l’azienda”. Serve più della corrispondenza: regole di business, responsabilità, survivorship, integrazione bidirezionale, gestione degli errori e governance, perché qualcuno deve decidere perché un valore vince.

Click to enlarge

La coesistenza non si limita a collegare i record. Decide i valori master e li rimanda indietro.

Centralizzato: il master crea la verità

Lo schema più forte. Nell’MDM centralizzato, i dati master governati vengono creati e mantenuti nel master centrale e distribuiti a tutti gli altri. Invece di far creare a ogni sistema il proprio cliente per poi farli riconciliare dall’MDM, crei il cliente governato nel master, poi lo invii a Salesforce, all’ERP e alla fatturazione. Una governance molto forte, e un cambiamento molto significativo: i processi esistenti creano i propri clienti, gli utenti hanno i loro flussi di lavoro, le integrazioni presuppongono la creazione locale, e le business unit potrebbero non essere nemmeno d’accordo su cosa sia un cliente. Ecco perché è raro nei panorami Salesforce che vedo. Può essere la scelta giusta. È una decisione molto più grande che installare uno strumento.

Click to enlarge

L’MDM centralizzato sposta la creazione e l’autorità nel master.

I quattro a confronto

Stile	Cosa viene centralizzato	Le fonti restano?	Rimanda indietro i valori governati?
Registry	Identità e collegamenti	Sì	Di solito no
Consolidamento	Identità più dati combinati	Sì	Di solito no
Coesistenza	Identità, dati e decisioni sui dati master	Sì	Sì
Centralizzato	Creazione e autorità	Sì, come consumatori	Sì

Scendendo nella tabella, il livello di gestione dei dati master riceve più autorità, e di solito l’organizzazione deve cambiare di più.

Da sapere per l’esame. Conosci i quattro stili di implementazione dell’MDM: registry (collega le identità; le fonti mantengono i propri dati), consolidamento (riunisce i dati, di solito per l’analisi), coesistenza (decide i valori master e li ripubblica verso le fonti) e centralizzato (il master crea i dati; le fonti li consumano).

Quindi non esiste un “il centralizzato è il più maturo, quindi tutti dovrebbero arrivarci”. Scegli lo schema più leggero che risolve il problema. Ti serve sapere che dei record vanno insieme? Pensa al registry. Una vista combinata per le analisi? Consolidamento. Valori governati sincronizzati di ritorno su più sistemi operativi? Coesistenza. Un unico processo che crea e controlla i dati master per tutti? Centralizzato.

Dove si colloca Data 360?

Data 360 costruisce profili unificati a partire da molte fonti, il che somiglia molto all’MDM, e risolve effettivamente una parte del problema. La sua risoluzione dell’identità fa corrispondere i profili di origine in un’identità unificata e conserva i collegamenti ai record di origine (Data 360 Architecture (opens in a new tab)). Questo lo rende più vicino a un registry. Può anche mostrare valori riconciliati sul profilo unificato. Ma non ne fa un sistema centralizzato di golden record che riscrive le fonti. Una vista unificata non è automaticamente un record aziendale gestito come dato master. Il modulo 4 parla interamente di questa differenza.

Un modello comune non è una verità comune

Sentirai anche parlare di modello dati canonico. L’Account di Salesforce, il business partner dell’ERP e il cliente della fatturazione corrispondono tutti a un unico concetto aziendale concordato, Cliente, con identificatori e attributi concordati, così ogni integrazione non deve capire la forma di ogni altro sistema. Il modello dati di Data 360 è un esempio di armonizzazione delle fonti in concetti comuni. Ma un modello canonico risponde a come lo rappresentiamo in modo coerente? L’MDM risponde a come lo identifichiamo, governiamo e gestiamo come dato master tra i sistemi? Fai corrispondere perfettamente tutti e tre i sistemi a un’unica forma di Cliente, e Salesforce dirà ancora 123 Main Street mentre l’ERP dice 125. Hai risolto la struttura, non l’autorità. Armonizzare e gestire i dati master non sono intercambiabili.

Un solo business, diversi schemi

Quindi “Steve Trucking ha bisogno di MDM” non è un requisito. Per cosa? Partner retail, centri di distribuzione, squadre, camion, Destinatari sono domini diversi con autorità diverse: i Partner retail governati in Salesforce e nell’ERP finanziario, l’identità dei camion da FleetLink, ogni Destinatario fornito da un partner per ogni consegna. Domini diversi possono adottare schemi diversi, e dentro un dominio gli attributi possono avere autorità diverse. Quindi non disegnare un riquadro con l’etichetta MDM al centro del diagramma per poi considerare il problema risolto. Chiediti cosa fa quel riquadro.

Lo stile cambia anche l’integrazione. Il registry ha bisogno di collegamenti di identità; il consolidamento, di flussi in entrata affidabili; la coesistenza, di dati in entrambe le direzioni; il centralizzato, della distribuzione dal master più controlli che impediscano ad altri sistemi di creare verità rivali. Man mano che l’autorità cresce, cresce il coordinamento, e cresce la gestione dei guasti: e se l’MDM cambia la ragione sociale e l’ERP la rifiuta? Ecco perché coesistenza e centralizzato non sono “un registry con più funzionalità”. Portano responsabilità operative diverse.

L’MDM è una decisione di business

Il punto più importante: l’MDM non è fondamentalmente una decisione tecnologica. È una decisione sull’autorità. Chi crea il cliente, chi può modificarlo, chi decide quale valore vince, quali sistemi devono accettarlo, cosa succede quando non sono d’accordo. Uno strumento può implementare quelle decisioni; non può far sì che l’organizzazione le condivida. Ecco perché un progetto MDM può avere una tecnologia eccellente e fallire comunque: il team tecnico ha risolto la corrispondenza, e il business non ha mai risolto la responsabilità.

La lezione generale che ho imparato a mie spese: quando più sistemi gestiscono come master gli stessi dati, Salesforce non può riconciliare ciò su cui loro non sono d’accordo. Quando un’azienda usa due ERP, chiedo come li mantiene sincronizzati. Se non ci riesce lei, non ci riesce nemmeno Salesforce. Il modulo 5 racconta questa storia (Un cliente, due ERP).

Cosa decide qui un architetto

• Se il problema richiede collegamenti di identità, dati combinati, valori master rimandati indietro, o una creazione centrale.
• Quale schema si adatta a ogni dominio di dati, invece di un solo schema per l’intera azienda.
• Quanta autorità riceve il livello di gestione dei dati master, e quali sistemi devono accettarne le decisioni.
• Se serve un modello canonico, senza confondere l’armonizzazione con l’autorità.
• Come lo schema scelto cambia direzione dell’integrazione, responsabilità e gestione dei guasti.

Quando qualcuno mette un riquadro MDM in un diagramma, chiediti cosa fa. Sa quali record vanno insieme? Ne combina i dati? Decide quali valori vincono? Rimanda indietro quelle decisioni? Crea i dati fin dall’inizio? Le risposte ti dicono quale architettura hai davvero, e dove risiede l’autorità.

Per approfondire

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