Salesforce è un sistema tra tanti

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

La domanda a cui risponde questo modulo: Perché un architetto dei dati disegna ciò che circonda la org prima di progettare la org?

Quando preparo i candidati CTA, il compito dopo il primo giorno è sempre lo stesso. Leggete lo scenario. Iniziate il panorama dei sistemi da una tela bianca. Solo allora provate a buttare giù il modello dati. Non gli oggetti, non le integrazioni nel dettaglio: il panorama. Voglio vedere cosa circonda Salesforce prima di decidere cosa ci va dentro.

Per molti professionisti Salesforce è un cambio di prospettiva. Se hai passato la carriera da amministratore o da sviluppatore, Salesforce è naturalmente il centro del tuo mondo. Apri Imposta, crei oggetti, costruisci flow, scrivi Apex e integri altri sistemi dentro Salesforce. Tutto sembra cominciare dalla org. Un architetto deve allargare l’inquadratura, perché in un’azienda Salesforce è un sistema tra tanti, e molto spesso non è quello che possiede i dati.

Disegna prima il panorama

Il capitolo 2 ha costruito il modello logico, e il capitolo 3 si è chiesto come vive su Salesforce. Ora renderò il problema più grande. Prima di decidere cosa dovrebbe possedere Salesforce, voglio capire l’azienda intorno. Quali sistemi esistono già? Dove vengono creati i clienti, definiti i prodotti, avviati gli ordini, generate le fatture? Dove risiede l’identità? Dove si fanno le analisi, dove si tengono i documenti, dove sta lo storico? Quali sistemi hanno bisogno dei dati di Salesforce, e da quali dipende Salesforce?

Queste domande cambiano l’architettura. Quindi parto da una tela bianca, metto Salesforce al centro e disegno tutto intorno. Il modulo 4 mostra esattamente come lo dispongo. Per ora la lezione è semplicemente: non progettare la org prima di aver capito il mondo in cui deve vivere.

Spesso Salesforce non è il system of record

Prendi un’azienda molto comune: Salesforce più un ERP, un sistema di pianificazione delle risorse d’impresa come SAP o Oracle, che gestisce finanza, prodotti, magazzino, acquisti ed evasione degli ordini. Ora fai una domanda semplice: dove risiede il cliente?

Potrebbe essere Salesforce, l’ERP o entrambi, ed è lì che si fa interessante. I commerciali possono lavorare i potenziali clienti come Account in Salesforce, mentre l’ERP emette il numero cliente ufficiale quando diventano clienti paganti. Prodotti e prezzi? Probabilmente l’ERP. Il magazzino? Quasi mai Salesforce. Gli ordini potrebbero essere acquisiti in Salesforce ed evasi nell’ERP; le fatture vengono dall’ERP; l’assistenza vive in Salesforce; le analisi sono divise tra i report di Salesforce e un data warehouse. All’improvviso il nostro bel modello dati Salesforce non è il modello dati aziendale. Ne è una parte.

L’integrazione che vedo di continuo

L’integrazione più comune che vedo funziona così: clienti, prodotti e prezzi arrivano in Salesforce dall’ERP, e gli ordini escono. Metti al suo posto SAP, Oracle o qualsiasi altro ERP; la forma è la stessa. L’ERP possiede il golden record del cliente e del prodotto, quindi quei flussi arrivano da destra, verso Salesforce. Le vendite chiudono l’affare in Salesforce, quindi l’ordine nasce lì e torna all’ERP per essere evaso, fatturato e contabilizzato.

Quei flussi non sono solo integrazioni. Mi dicono dove l’azienda crede che risieda la verità.

Le frecce a senso unico mi rendono nervoso

Ogni volta che vedo un’integrazione con un solo flusso, comincio a preoccuparmi. Ad alto livello, qualcuno disegna una sola freccia: ordini da Salesforce all’ERP. Va bene. Ora guarda più a fondo. Come posso inviare un ordine all’ERP se non conosco i suoi clienti, i suoi prodotti o i suoi prezzi? L’ordine deve essere legato a un cliente che l’ERP ha già, e ogni riga deve essere uno SKU che l’ERP vende già. Non posso inviare una voce d’ordine per un prodotto che dall’altra parte non esiste. Quindi, perché quella freccia degli ordini funzioni, devono esistere dei flussi di ritorno, che vanno nell’altro senso.

È la domanda che faccio a ogni freccia: da cosa dipende questo flusso? La freccia ad alto livello che vedi di solito ha bisogno di flussi di ritorno che non hai ancora disegnato.

Guarda ancora più a fondo e trovi il viaggio di ritorno. Salesforce invia un ordine. E poi? È stato accettato o rifiutato? È stato spedito, spedito in parte, annullato? È stato fatturato? Qualcuno in Salesforce ha bisogno di saperlo? Forse no. Ma qualcuno avrebbe dovuto chiederlo. Se non torna indietro niente, va bene. Dimmi perché.

L’azienda non è arrivata tutta in una volta

I panorami si complicano anche perché nessuno li ha costruiti tutti in una volta. I dati sono arrivati a ondate. Prima i file: record a formato fisso, poi file delimitati come i CSV. Poi i database relazionali per i dati operativi. Poi i data warehouse per riunirli a fini di analisi. Poi i database NoSQL per documenti, coppie chiave-valore e grafi che non stanno bene in tabelle. Poi i data lake per enormi quantità di dati grezzi e semi-strutturati, e i lakehouse che combinano le due cose. I flussi di eventi, come Kafka o l’event bus di Salesforce, spostano i dati nel momento in cui accadono invece che in batch notturni. E ora la federazione, in cui i dati non devono essere copiati in un unico posto prima che un’altra piattaforma possa usarli.

La tecnologia non è ancora il punto. Il punto è questo: la nuova ondata raramente fa sparire la vecchia. Entra in una grande azienda e le troverai tutte insieme: database relazionali, l’ERP, Salesforce, un data warehouse, un data lake, depositi SFTP, API, flussi di eventi, il foglio di calcolo che qualcuno manda ancora per email ogni venerdì, e quell’unico sistema che tutti hanno paura di toccare perché la persona che l’ha costruito è andata in pensione sei anni fa. È questa l’azienda di cui stai progettando l’architettura, non quella della brochure di prodotto.

Sistemi diversi esistono per ragioni diverse

È anche per questo che non parto mai da “come mettiamo tutti i dati in Salesforce?”. Perché dovrei volerli tutti lì? Salesforce può essere il posto migliore in cui chi fa vendita e assistenza lavora con i clienti. Non ne fa il sistema finanziario, il data warehouse aziendale, l’archivio della telemetria, l’archivio dei documenti, o la sede di ogni clic, lettura GPS e transazione storica che l’azienda abbia mai prodotto.

Il capitolo 3 si chiedeva dove dovrebbero risiedere questi dati? per una sola org. A livello aziendale la stessa domanda diventa più grande: a volte Salesforce possiede i dati, a volte ne tiene una copia, a volte solo un riferimento, e a volte non dovrebbe averli affatto.

Core, fuori dal core e Hyperforce

C’è un altro confine da capire: nemmeno “Salesforce” è un unico runtime e un unico database. Nel capitolo 3, sul core indicava dove stanno i dati: sulla tua scrivania, negli oggetti della org stessa. Qui le stesse parole descrivono dove gira un prodotto. Sentirai gli architetti usarle in entrambi i sensi.

Storicamente il runtime Core ospitava gran parte della piattaforma. Oggi Salesforce descrive una piattaforma di centinaia di servizi indipendenti guidati dai metadati, con Core che resta l’unico system of record per i metadati delle applicazioni (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). Ecco perché sentirai gli architetti dire che una funzionalità gira sul core o fuori dal core.

Contava molto prima che la piattaforma si dividesse in servizi. Quando chiedo a una classe perché Salesforce abbia comprato SteelBrick per i preventivi invece di Apttus, la risposta che cerco è semplice: SteelBrick era costruito al 100% sul core. Flow e trigger vivono nel core, quindi un prodotto costruito lì si porta dietro i metadati, le personalizzazioni e l’automazione della piattaforma. Quel prodotto per i preventivi ha poi lasciato il posto a Revenue Cloud, ma la lezione no. Poi c’è il vicino al core (near-core), e Data 360 è l’esempio che uso. Data 360 non è core. Il suo tenant è fuori dal core: i dati e i meccanismi che li elaborano girano nel loro lakehouse, accanto al database relazionale della org e non al suo interno (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). Ma le schermate che usi per configurarlo e controllarlo sono visualizzate sul core, nella org. Quindi il modo più preciso in cui posso dirlo è: gestito sul core, ospitato fuori dal core. Nessuno dei dati né dell’elaborazione gira davvero in Core; l’interfaccia su Core controlla il tenant fuori dal core. E poi, naturalmente, c’è tutto ciò che è fuori dal core perché non è affatto Salesforce.

Mi interessa meno memorizzare quale prodotto gira dove quest’anno, perché cambia, che l’abitudine: un confine può influire su movimento dei dati, latenza, identità, integrazione e residenza. Quindi non dare per scontato che, siccome un prodotto dice Salesforce, i suoi dati stiano proprio accanto ai tuoi record Account. Guarda l’architettura reale.

Poi c’è Hyperforce: l’infrastruttura di Salesforce costruita per il cloud pubblico e definita come codice, invece dei tradizionali data center di proprietà, che dà ai clienti più scelta su dove risiedono i loro dati (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). Conta, e il modulo 5 ci torna. Ma l’architettura dell’infrastruttura non è l’architettura dei dati aziendali. Spostare una org sul cloud pubblico non ti dice chi possiede il cliente, dove risiede il magazzino, dove girano le analisi, o quali dati possono attraversare un confine. Hyperforce può dare forma ad alcune di queste decisioni, soprattutto la residenza. Non sostituisce la conoscenza del panorama.

Il panorama viene prima del riquadro

Quindi ecco l’abitudine. Qualcuno ti consegna uno scenario. Non iniziare a costruire la soluzione Salesforce. Prima trova i sistemi: l’ERP, il provider di identità, il data warehouse, la piattaforma di integrazione, i sistemi dei partner, i canali verso i clienti, gli archivi dei documenti. Poi trova i dati che si muovono tra loro: clienti, prodotti, ordini, fatture, documenti, eventi, identità. Poi chiediti chi possiede ciascuno. Solo allora decidi cosa appartiene a Salesforce. Altrimenti stai progettando un riquadro senza sapere a cosa si collega.

Click to enlarge

Passo 1 di 3: la org che progettiamo, da sola. Da qui sembra il mondo intero.

Click to enlarge

Passo 2 di 3: allarga lo sguardo. Salesforce è un sistema tra tanti (il modulo 4 insegna questo layout).

Click to enlarge

Passo 3 di 3: le prime frecce. Clienti, prodotti e prezzi in entrata dall’ERP, ordini in uscita: dicono dove l’azienda crede che stia la verità.

Il panorama cambia il modello dati

Ecco perché conta per un architetto dei dati. Il capitolo 2 dice che il cliente è un’entità importante. Bene. Poi il panorama dice che l’ERP è autorevole per il cliente. Questo cambia il modello fisico. Salesforce può comunque tenere un Account locale, perché le persone lo usano ogni giorno, ma ora ci serve l’identificatore dell’ERP come ID esterno; dobbiamo sapere quali campi Salesforce può modificare (segno i campi dell’ERP con un prefisso erp_, come vedremo nel modulo 3); quanto in fretta arrivano le modifiche dall’ERP; se Salesforce può creare un cliente prima che l’ERP ne sappia qualcosa; e cosa succede quando i due non sono d’accordo. Non sono domande di integrazione per dopo. Sono domande di architettura dei dati, e le ha fatte emergere il panorama.

Ecco come uno di questi morde. Un venditore converte un lead per una grande azienda di bevande, crea l’Account, vince l’affare, e il cliente passa all’ERP. Ma l’azienda lavora con quella società di bevande da anni, e l’ERP ce l’ha già. Ora ce ne sono due. Il venditore avrebbe dovuto poter creare quell’Account? I capitoli 5 e 6 ci tornano; il panorama è dove lo vedi arrivare.

Cosa decide qui un architetto

• Quali sistemi circondano Salesforce, e quale ruolo svolge ciascuno.
• Quale sistema possiede ogni tipo importante di dati, prima di decidere quanta parte ne conserva Salesforce.
• Cosa entra in Salesforce, cosa esce, e cosa torna indietro.
• Quali dati Salesforce dovrebbe possedere, copiare, referenziare, federare, archiviare o lasciare stare.
• Quali confini di piattaforma e di infrastruttura contano, invece di dare per scontato che tutto ciò che porta il marchio Salesforce risieda in un unico posto.

Il passaggio da sviluppatore ad architetto spesso non consiste nell’imparare un’altra funzionalità. Consiste nell’imparare quando smettere di guardare Salesforce: allargare l’inquadratura, seguire i dati, trovare chi possiede la verità, poi tornare e decidere quale dovrebbe essere il compito di Salesforce.

Per approfondire

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (in inglese), consultato il 2026-10-14.
• Guida di Salesforce, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (in inglese), consultato il 2026-10-14.