Capire i dati aziendali

🌐 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

Guida allo studio del capitolo 4 del corso Data Architect. Leggi prima i sei moduli; questa pagina ti aiuta a verificare cosa ti è rimasto.

Su questa guida allo studio. È costruita solo con i contenuti di questo corso e con l’elenco degli obiettivi della guida all’esame pubblicata da Salesforce. Non si basa mai su domande reali d’esame, e non pretende di sapere cosa c’è nell’esame. Se hai sostenuto l’esame, per favore non mandarmi domande: l’accordo di certificazione vieta di condividerle, e memorizzare le risposte è comunque il modo sbagliato per diventare architetto.

La guida all’esame dice che non verifica concetti di database non Salesforce, e gran parte di questo capitolo parla dell’azienda intorno a Salesforce. Quindi, come per il capitolo 1, questa checklist indica quali obiettivi sostiene ciascun punto. Ma non saltarla: molti scenari d’esame iniziano con un ERP, un data warehouse o una seconda org, e la risposta dipende da chi possiede i dati.

Per l’esame

Spuntali man mano. Ognuno rimanda al punto in cui è spiegato.

Chi possiede i dati (sostiene SDM-2, SDM-3 e il capitolo sui dati master)

• So dire quale sistema è il system of record per ogni tipo di dati, e completo la frase: system of record per cosa? (Spesso Salesforce non è il system of record, Non partire dal nome del prodotto)
• Conosco lo schema comune: clienti, prodotti e prezzi in entrata dall’ERP, ordini in uscita, e so che la freccia degli ordini dipende dalle altre; poi chiedo del viaggio di ritorno. (L’integrazione che vedo di continuo, Le frecce a senso unico mi rendono nervoso)
• Pongo tre domande sui dati master: dove vengono creati, dove vengono modificati, e dove vengono referenziati? (Le quattro domande dietro le categorie)
• So che una copia non è un’autorità: i dati di proprietà dell’ERP si leggono localmente e si scrivono sotto controllo, con l’identificatore dell’ERP conservato come ID esterno. (L’ERP: il back office ha gravità, Il panorama cambia il modello dati)

I tipi di dati e i loro carichi di lavoro (sostiene DM-1, LDV-1 e MDM-4)

• So distinguere i dati master, di riferimento, transazionali, metadati, analitici e non strutturati, e cosa significa ciascuno per il posto in cui risiedono. (Parti dal tipo, non dall’oggetto)
• So che i dati di riferimento sono piccoli ma sono il posto in cui si nascondono le ipotesi di integrazione (Delivered, Complete, D). (Dati di riferimento)
• So distinguere i carichi di lavoro operativi (OLTP), analitici (OLAP) e di streaming: la org fa funzionare il business, warehouse e lake lo analizzano. (Il tipo è solo metà della domanda)
• So distinguere sincrono (aspettare alla porta), asincrono (andare avanti e occuparsene quando torna) e batch (ogni ora, ogni qualche ora, ogni giorno), so quando il batch basta, e so che il tempo reale ha un costo. (Quanto in fretta deve muoversi?)
• Pongo le quattro domande su ogni insieme di dati: chi lo possiede, quanto in fretta cambia, quanto diventa grande e qual è il suo ciclo di vita. (Le quattro domande dietro le categorie)

I sistemi intorno a Salesforce (sostiene SDM-3, LDV-3 e i capitoli sull’integrazione)

• Conosco i quattro ruoli dei sistemi: registrazione, engagement, riferimento e insight. (Non partire dal nome del prodotto)
• So che dove vivono le analisi segue dove vivono i dati: i report del core quando è tutto in Salesforce; una piattaforma di analisi (Tableau, compreso Tableau Next, o CRM Analytics dove è in uso) o il data warehouse quando entrano in gioco altri archivi. (Le analisi vivono dove vivono i dati)
• So cosa sono un data warehouse, un data lake e un lakehouse, e il ruolo dell’MDM, di un ESB o iPaaS e degli eventi. (Il data warehouse, il data lake e il lakehouse, Il livello di integrazione e gli eventi)
• Metto il provider di identità nel panorama fin dal primo giorno, e so che la configurazione SSO si distribuisce ma segreti e certificati non viaggiano con essa; nel panorama è un certificato condiviso (fiducia), non una chiamata, perché l’accesso passa dal browser. (Il sistema che gli sviluppatori dimenticano: l’identità)
• So che Data 360 è vicino al core (near-core) (gestito sul core, ospitato fuori dal core), e che il suo zero copy permette di interrogare i dati senza copiarli. (Dove si colloca Data 360?, Core, fuori dal core e Hyperforce)

Org e hosting (sostiene SDM-4)

• Parto da una sola org e cerco un confine reale (residenza, regolamentazione, separazione legale, un modello operativo diverso, un’acquisizione) prima di aggiungerne un’altra. (Parti da una sola org, Cerca confini reali)
• So quanto costano più org: reportistica globale, dati master, integrazione, identità e deployment, ciascuno moltiplicato. (Percorri di nuovo le frecce)
• So che Hyperforce dà la scelta della regione in cui risiedono i dati di una org (non del provider cloud), ma non promette che ogni servizio resti lì; e che il GDPR da solo non richiede una org separata: stabilisce regole per i dati personali che escono dall’UE, e un’azienda può scegliere una org europea per rispettarle. (L’hosting fa parte del disegno, Quando l’Europa ha la sua org)

Disegnare e leggere un panorama (sostiene ogni scenario)

• So disegnare un panorama: le persone a sinistra, Salesforce al centro con le sue community che lo toccano da sotto, l’identità sopra, integrazione e back office a destra, Data 360 sotto il livello di integrazione, i canali sotto, i dati in entrata e in uscita in basso a destra. (Il layout del panorama di Steve)
• In un panorama, una freccia parte dal sistema che apre la connessione e la sua etichetta dice cosa si muove e in che direzione; in un diagramma di flusso dei dati, le frecce seguono i dati. Due flussi sono due frecce. (Ora disegna le frecce)
• Per ogni freccia so cosa gestisce il client e cosa definisce il server: dove, autenticazione, protocollo e contratto, payload, tempi, traccia, errori. Una Credenziale denominata e la sua Credenziale esterna quando Salesforce chiama in uscita; un’App client esterna e un utente di integrazione solo API quando qualcosa chiama Salesforce. (Ogni freccia ha bisogno di un meccanismo)
• Conto prima di disegnare le frecce: il volume va nell’inventario e guida il meccanismo, e può persino cambiare la direzione della freccia. (Metti gli zeri nell’inventario)
• Disegno una corsia (swim lane) solo quando un processo ha più di uno o due scambi avanti e indietro. (Frecce nel panorama, conversazioni in una corsia)

Oltre l’esame

L’esame è il pavimento, non il soffitto. Queste sono le abitudini di questo capitolo di cui un architetto ha bisogno, che una domanda le chieda o no.

• Disegna il panorama prima di progettare la org. Parti da una tela bianca.
• Allarga l’inquadratura. Salesforce è un sistema tra tanti.
• La nuova ondata raramente fa sparire la vecchia. Progetta l’azienda che esiste, non quella della brochure.
• Leggi il panorama come responsabilità, non come loghi.
• Le frecce a senso unico mi rendono nervoso. Da cosa dipende questo flusso, e cosa torna indietro?
• Ogni freccia ha bisogno di un meccanismo. “Fire and forget” non è una risposta.
• Frecce nel panorama, conversazioni in una corsia.
• Conta prima di disegnare le frecce. Gli zeri vanno nell’inventario, e scelgono il meccanismo.
• Disegna lo stato attuale prima di aggiustarlo: il foglio di calcolo, il deposito SFTP, il sistema “che stiamo dismettendo”.
• Segna con onestà uno stato attuale: rosso per un processo sbagliato, tratteggio per ciò che è fatto a mano, puntini rossi per ciò che manca. Ogni linea rossa è un requisito che aspetta di essere scritto.
• Due flussi, due frecce. Una freccia a doppia punta è solo per un connettore.
• Non giocare all’avvocato. Chiediti quale requisito specifico stai soddisfacendo, e traducilo con le persone che ne sono responsabili.
• Separato non è lo stesso che semplice.

Parole da conoscere

Termine	In una riga
Panorama dei sistemi	I sistemi intorno a Salesforce, le persone che li usano e i flussi importanti tra loro
System of record	Dove si conserva la versione autorevole di un tipo di dati
Sistema di engagement	Dove le persone svolgono il lavoro
Sistema di riferimento	Dove un sistema consulta informazioni di cui ha bisogno ma che non possiede
Sistema di insight	Dove i dati si riuniscono per misurare, analizzare e prevedere
ERP	Il sistema di back office per finanza, prodotti, magazzino, acquisti ed evasione degli ordini
Dati master	Le cose durature intorno a cui gira un business: clienti, prodotti, sedi
Dati di riferimento	Il vocabolario condiviso che classifica altri dati: codici, stati, categorie
Dati transazionali	Registrazioni di ciò che è successo: ordini, consegne, pagamenti, casi
Dati analitici	Dati ricavati da altri dati per misurare e confrontare
Dati non strutturati	Documenti, immagini, audio, video, trascrizioni
Data warehouse / data lake / lakehouse	Archivio analitico strutturato / archivio grezzo su larga scala / un misto dei due
ESB / iPaaS	Un livello di integrazione che fa da mediatore tra i sistemi
OLTP / OLAP	Lavoro operativo su pochi record alla volta / analisi su molti record
Vicino al core (near-core)	Gestito sul core, ospitato fuori dal core: Data 360
Credenziale denominata / Credenziale esterna	Dove Salesforce conserva un endpoint in uscita / la sua autenticazione
App client esterna	Come un sistema esterno viene autorizzato a chiamare Salesforce
Stato attuale	Il panorama com’è oggi, prima della progettazione; con segnato ciò che non va
Provider di identità (IdP)	Il sistema che autentica gli utenti e stabilisce l’identità di cui Salesforce si fida
Sincrono / asincrono / batch	Aspettare la risposta / andare avanti e gestirla quando arriva / spostare i dati in gruppo secondo una pianificazione
Hyperforce	Salesforce su infrastruttura cloud pubblica, con la scelta della regione
Zero copy	Interrogare i dati dove risiedono, senza copiarli

Mettiti alla prova

Brevi scenari nello stile del corso. Decidi la tua risposta prima di aprirla.

1. I commerciali lavorano gli account in Salesforce, ma l'ERP emette il numero cliente ufficiale quando acquistano. Salesforce invia gli ordini all'ERP. Cosa devi progettare?

Chi possiede il cliente in ogni fase; il numero dell’ERP come ID esterno sull’Account; quali campi Salesforce può modificare; quanto in fretta arrivano le modifiche dall’ERP; e cosa torna indietro dopo l’invio di un ordine (accettato, rifiutato, spedito, fatturato). Rileggi Il panorama cambia il modello dati.

2. La direzione vuole cinque anni di puntualità per regione, uniti ai dati finanziari. Lo costruisci con i report di Salesforce?

Probabilmente no. È un carico di lavoro analitico su più archivi, quindi appartiene al posto in cui i dati si riuniscono: il data warehouse, con sopra CRM Analytics o Tableau. Dove vivono le analisi segue dove vivono i dati. Rileggi Le analisi vivono dove vivono i dati.

3. Un'azienda opera in 30 paesi e chiede una org per paese. Cosa chiedi?

Quale requisito porta con sé ogni paese: archiviazione, elaborazione, trasferimento transfrontaliero, contratti, un hosting diverso. Senza un confine reale, parti da una sola org, perché ogni org in più moltiplica reportistica, dati master, integrazione, identità e deployment. Rileggi La geografia non è automaticamente una strategia delle org.

4. I camion inviano 200.000 letture GPS al giorno. Salesforce dovrebbe memorizzarle tutte?

Probabilmente no. Sono dati di streaming: chi fa dispatch ha bisogno della posizione attuale, mentre storico e tendenze appartengono a una piattaforma costruita per quel volume. Conta gli zeri (oltre 70 milioni all’anno) e separa “dov’è adesso?” da “cosa è successo lo scorso trimestre?”. Rileggi Il tipo è solo metà della domanda.

5. Le squadre lavorano le loro tappe in Salesforce, ma i percorsi si costruiscono in un vecchio strumento di dispatch, e niente collega i due. Come disegni la situazione di oggi?

Così com’è, indicata come stato attuale: i percorsi ridigitati in Salesforce e le tappe completate ridigitate all’indietro, tratteggiati perché lo fanno le persone e rossi perché è sbagliato. Non disegnare l’integrazione che vorresti esistesse; ogni linea rossa diventa un requisito per la progettazione. Rileggi Segna ciò che non va e RouteDesk è ancora lì.

6. Qualcuno dice che la legge europea sulla privacy richiede una org separata. Come rispondi?

Né accettarlo a occhi chiusi né scavalcarlo. Il GDPR da solo non richiede una org separata; stabilisce regole per i dati personali, compresi i trasferimenti fuori dall’UE. Chiedi quale requisito specifico soddisfa (archiviazione, elaborazione, trasferimento, accesso per l’assistenza, un contratto, una politica), poi lavora con privacy, ufficio legale e sicurezza per trasformarlo in architettura. Rileggi Non giocare all’avvocato e Quando l’Europa ha la sua org.

7. Salesforce invia ordini all'API dell'ERP. Quale parte gestisce i nuovi tentativi, e dove conserva Salesforce il segreto?

Salesforce è il client: apre la connessione, vede l’intero viaggio di andata e ritorno ed è l’unica parte che può riprovare. Una Credenziale denominata contiene l’endpoint, e la sua Credenziale esterna l’autenticazione. L’ERP, il server, definisce il contratto e convalida ciò che arriva. Rileggi Ogni freccia ha bisogno di un meccanismo.

8. Un'integrazione oggi invia un paio di record al minuto, e il business se ne aspetta decine di migliaia all'ora l'anno prossimo. La freccia cambia?

Forse il suo meccanismo e persino la sua direzione. Pochi record al minuto possono essere una callout da Salesforce; molti di più possono significare pubblicare eventi a cui l’altro sistema si iscrive, così la freccia parte dall’altra estremità; milioni durante la notte sono un batch. Conosci i conteggi prima di scegliere. Rileggi Metti gli zeri nell’inventario.

Per approfondire

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Guida di Salesforce (in inglese, consultato il 2026-09-25): l’elenco ufficiale degli obiettivi e dei loro pesi. Controlla sempre la versione attuale prima di prenotare l’esame.