I sistemi intorno a Salesforce

🌐 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 Capire i dati aziendali, capitolo 4 del corso Data Architect. Ogni modulo si regge da solo. Precedente: I tipi di dati aziendali · Successivo: Disegna il panorama dei sistemi

La domanda a cui risponde questo modulo: Cosa circonda Salesforce, e quale ruolo svolge ciascun sistema?

Il modulo precedente ha classificato i dati. Ora voglio metterli da qualche parte, ed è qui che gli architetti Salesforce finiscono nei guai. Conosciamo Salesforce, quindi i dati dei clienti significano Account, i dati degli ordini significano Order, i documenti significano File, le analisi significano Report. Ma l’azienda non ha comprato Salesforce per sostituire tutto il resto che possiede. Potrebbe esserci un ERP che gestisce finanza ed evasione degli ordini, un data warehouse con anni di storico, una piattaforma di integrazione, un provider di identità, sistemi dei partner, una piattaforma di eventi, una piattaforma MDM, e Data 360 che ne collega diversi. Il compito non è memorizzare tecnologie. È capire quale lavoro ha ciascun sistema.

Non partire dal nome del prodotto

“Abbiamo SAP” non mi dice abbastanza. Nemmeno Snowflake, MuleSoft, Tableau o Data 360. Voglio sapere cosa fa quel sistema in questa architettura: quali dati possiede, cosa legge, cosa modifica, chi lo usa, cosa ne dipende, cosa succede quando è giù. Due aziende possono avere esattamente gli stessi prodotti e architetture completamente diverse.

Quindi etichetto i sistemi per ruolo. Quattro ruoli coprono quasi tutto:

• System of record (sistema di registrazione): dove viene mantenuta la versione autorevole di qualcosa.
• Sistema di engagement: dove le persone svolgono il lavoro.
• Sistema di riferimento: dove un sistema va a prendere informazioni di cui ha bisogno ma che non possiede.
• Sistema di insight: dove i dati si riuniscono per misurare, analizzare e prevedere.

Una piattaforma può svolgere più ruoli, e i ruoli cambiano a seconda dei dati. Salesforce può essere il system of record per i casi, il sistema di engagement per gli operatori dell’assistenza e un consumatore dei dati di prodotto che possiede l’ERP. Quindi quando qualcuno dice “Salesforce è il nostro system of record”, completa la frase: system of record per cosa?

L’ERP: il back office ha gravità

L’ERP è il sistema che troverai più spesso accanto a Salesforce, a gestire finanza, magazzino, acquisti, evasione degli ordini e fatturazione. Lo schema del modulo 1 (clienti e prodotti in entrata, ordini in uscita) significa che l’ERP possiede i prodotti, ma i commerciali ne hanno comunque bisogno in Salesforce. Va bene: portali dentro. Ma copiare i dati non trasferisce la titolarità. Una copia non è un’autorità.

La mia posizione: i dati di proprietà dell’ERP si leggono localmente e si scrivono sotto controllo. Gli utenti Salesforce hanno i dati dove lavorano, ma Salesforce non può modificare ciò che possiede l’ERP. E lo rendo visibile nello schema: i campi dell’ERP portano un prefisso erp_, come erp_Product_Number__c, così chiunque legga l’oggetto sa chi possiede ogni campo e che deve fare attenzione a modificarlo. Il prefisso non impone niente; a questo pensano le autorizzazioni, la convalida e il pattern di integrazione. Comunica un’intenzione, ed è la mappa delle autorità resa visibile.

Il data warehouse, il data lake e il lakehouse

I sistemi operativi fanno funzionare il business; i sistemi analitici aiutano a capirlo. “Mostrami le mie opportunità aperte” è un report di Salesforce. “Mostrami cinque anni di vendite, evasioni, resi, casi, magazzino e finanza su tutti i canali” è un problema diverso.

Incontrerai tre tipi di archivio analitico. Un data warehouse contiene dati strutturati preparati per l’analisi. Un data lake contiene molti più dati in più forme, spesso grezzi. Un lakehouse combina i due: archiviazione in stile lake con analisi in stile warehouse. Conoscili, perché compaiono nei panorami. Ma la mia esperienza è che lakehouse e data mesh sono ancora di nicchia nei progetti Salesforce. Il panorama tipico è CRM, ERP, un data warehouse e un livello di integrazione, con altre piattaforme dove il business ne ha davvero bisogno. Impara l’architettura; non inseguire il vocabolario.

Le analisi vivono dove vivono i dati

È una delle mie posizioni più ferme: dove vivono le analisi segue dove vivono i dati. Se il report ha bisogno solo di account, opportunità e commerciali, è tutto sul core: report e dashboard standard. Poi il business chiede di aggiungere le fatture dell’ERP. Poi il costo dei prodotti. Poi cinque anni di ordini dal data warehouse. Poi l’attività sul sito web. A un certo punto, trascinare tutto questo nel CRM operativo solo per farne report smette di avere senso. Quando entrano in gioco altri archivi di dati, diventa necessaria una piattaforma di analisi: Tableau (compreso Tableau Next, costruito su Data 360), oppure CRM Analytics dove è già in uso. È essenziale quando i dati Salesforce vengono uniti a un data warehouse. Il requisito non si è solo complicato; il panorama ha cambiato il posto in cui si dovrebbe rispondere alla domanda. Quindi non parto mai da “quale strumento di analisi?”. Parto da dove sono i dati?

Ai candidati CTA chiedo la stessa cosa: “Quale dei miei diagrammi risolve questo in modo splendido? Il panorama.” Se sei tutto sul core, usa i report. Se hai dati in altri repository, voglio vedere una piattaforma di analisi. Il panorama risponde alla domanda sui report prima che qualcuno apra un generatore di report. (I nomi dei prodotti cambiano; il capitolo su Data 360 spiega dove si trovano oggi le analisi di Salesforce.)

MDM: chi è davvero questo cliente?

Ora supponi che le informazioni sui clienti risiedano in Salesforce, nell’ERP, nell’e-commerce, in una piattaforma fedeltà e nel sistema di un partner, e che ognuno pensi di sapere chi è il cliente. È qui che entra in gioco la gestione dei dati master (MDM): stabilire e governare l’identità autorevole dei dati chiave tra i sistemi. Ma l’MDM non è “un database master dei clienti”. Le domande difficili sono quale sistema può creare il cliente, quali attributi possiede ciascun sistema, come si trovano i duplicati, quale identificatore sopravvive, e cosa succede quando i sistemi non sono d’accordo. Il capitolo 6 parla interamente di questo. Qui, riconosci il ruolo: se esiste una piattaforma MDM, potrebbe essere un’autorità critica tra Salesforce e il resto dell’azienda.

Il livello di integrazione e gli eventi

Collega ogni sistema direttamente a ogni altro, e il panorama diventa in fretta un piatto di spaghetti. Ecco perché le aziende hanno un livello di integrazione: un ESB (enterprise service bus) o un iPaaS (integration platform as a service). MuleSoft è quello che incontrerai più spesso nei panorami Salesforce. Fa da mediatore, così ogni applicazione non deve capire tutte le altre.

Ma un riquadro MuleSoft al centro non rende buona l’integrazione. Voglio comunque sapere cosa passa di lì e cosa no, chi trasforma i dati, chi possiede il contratto, cosa succede quando la destinazione è giù, se è sincrona o asincrona, e come sappiamo che un messaggio è andato a buon fine. Il corso Integration Architect approfondisce; qui, riconoscilo come un ruolo a sé.

E non ogni integrazione è il sistema A che chiama il sistema B. A volte succede qualcosa (viene creato un ordine, una consegna cambia stato, un camion entra in una regione), viene pubblicato un evento, e chi è interessato risponde. Anche gli eventi in movimento hanno un’infrastruttura: le funzionalità di eventi di Salesforce, un bus di eventi aziendale, altri sistemi di messaggistica. Disegna i meccanismi che trasportano i dati, non solo i database.

Il sistema che gli sviluppatori dimenticano: l’identità

C’è un riquadro che voglio sempre nel panorama e a cui gli sviluppatori pensano di rado: il provider di identità. Gli sviluppatori accedono direttamente alle loro sandbox con nome utente e password, quindi durante la costruzione l’identità è invisibile. Poi arrivano il collaudo (UAT) o la produzione, e all’improvviso c’è il single sign-on aziendale per i dipendenti, magari un secondo provider per i partner, il social sign-on per i clienti. L’identità ha sempre fatto parte dell’architettura. Lo sviluppatore semplicemente non l’aveva ancora vista.

Un provider di identità (IdP) è il sistema che autentica un utente e stabilisce l’identità di cui Salesforce si fida. Appartiene al panorama fin dal primo giorno, anche se viene configurato più avanti nella pipeline di rilascio, perché chi può entrare decide chi può arrivare ai dati.

C’è anche una complicazione pratica: la configurazione dell’identità è distribuibile, ma non del tutto. La configurazione del single sign-on SAML e i provider di autenticazione sono tipi della Metadata API, quindi viaggiano nella pipeline (SamlSsoConfig (opens in a new tab)). Ma i consumer secret dei provider di autenticazione non vengono più restituiti nelle risposte della Metadata API (Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab)), e i certificati di solito cambiano da un ambiente all’altro. Pianifica per le parti che viaggiano e per quelle che non viaggiano.

Click to enlarge

Leggi il panorama per ruoli, non per loghi: cosa possiede, legge o decide ogni sistema.

Dove si colloca Data 360?

Data 360 solleva una bella questione di disegno. Lo metto a destra, sotto l’ESB o MuleSoft. La ragione sono i suoi collegamenti: gli utenti non vi si collegano mai direttamente, mentre lui si collega direttamente a molti sistemi di back-end. Quindi appartiene alle tubature dei dati, dove quelle linee restano corte, non va fuori con gli utenti. Disegnalo come un’altra schermata a cui le persone accedono, e stai raccontando la storia sbagliata.

Gli amministratori e i team dei dati aprono sì le schermate di Data 360, ma quelle schermate sono nella org, sul core. Il tenant che fa il lavoro, i suoi dati e la sua elaborazione, gira fuori dal core. Ecco perché lo chiamo vicino al core (near-core): gestito sul core, ospitato fuori dal core (il modulo 1 spiega i termini). Il disegno segue il tenant: sta con le tubature, con una sola linea che torna alla org che lo gestisce.

Ciò che fa, con le parole di Salesforce, include lo zero copy: una tecnologia di federazione dei dati che permette a un’azienda di accedere ai dati e interrogarli senza copiarli (Zero Copy (opens in a new tab)). Le funzionalità e i connettori cambiano in fretta, quindi è il capitolo su Data 360 a trattarli come si deve, invece di trasformare questo modulo in un tour del prodotto.

Leggi il panorama come responsabilità

Quando guardi un panorama, non leggere i loghi; leggi le responsabilità. L’ERP: cosa possiede? Il data warehouse: a quali domande risponde? La piattaforma di integrazione: cosa sposta? L’IdP: chi autentica? L’MDM: quale identità governa? Data 360: cosa collega, e per cosa? Salesforce: di cosa è davvero responsabile? Una volta che sai rispondere, i riquadri significano qualcosa, e le frecce tra loro diventano molto più interessanti. Nel prossimo modulo le disegniamo deliberatamente.

Cosa decide qui un architetto

• Quale ruolo svolge ciascun sistema, oltre il nome del prodotto.
• Quale sistema è autorevole per ogni insieme di dati importante, e dove Salesforce tiene solo una copia locale.
• Se i dati di proprietà dell’ERP sono disponibili in Salesforce con le scritture controllate, e come quella titolarità si vede nello schema.
• Dove stanno le analisi, in base a dove risiedono i dati.
• Dove si collocano nel panorama identità, integrazione, eventi e autorità sui dati master.

Un panorama con dieci rettangoli non è architettura; è un inventario. L’architettura comincia quando sai indicare ogni rettangolo e dire perché è lì, cosa possiede, chi lo usa, di cosa ha bisogno Salesforce da esso, e cosa si rompe se ne fraintendi il ruolo.

Per approfondire

• Salesforce Developers, Metadata API Developer Guide, SamlSsoConfig (opens in a new tab) (in inglese), consultato il 2026-10-14.
• Guida di Salesforce, Winter ‘23 Release Notes, Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab) (in inglese), consultato il 2026-10-14.
• Salesforce, Zero Copy (opens in a new tab) (pagina prodotto, in inglese), consultato il 2026-10-14.
• Zhamak Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (opens in a new tab), martinfowler.com (in inglese), 2019.