Disegna il panorama prima della org

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)

Capitolo 4 di Data Architect, Parte 1: Diventare un architetto dei dati. Precedente: Architettura dei dati Salesforce.

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. Poi, e solo poi, provate a buttare giù il modello dati.

L’ordine sorprende. Siamo architetti dei dati; non dovremmo partire dal modello dati? Ecco perché non lo faccio. Se disegno prima il modello dati, ho già deciso cosa appartiene a Salesforce. Se disegno prima il panorama, vedo tutto ciò che dovrebbe dare forma a quella decisione: l’ERP che possiede clienti e prodotti, il data warehouse che risponde alle domande sui cinque anni, il provider di identità che decide chi entra, il partner che invia un file ogni pomeriggio, il sistema legacy che tutti dicono stia per essere dismesso.

I capitoli 2 e 3 hanno progettato la org: come dovrebbe essere il modello, e come vive su Salesforce. Questo capitolo allarga l’inquadratura e disegna ciò che circonda la org, prima che la org venga progettata. Salesforce è un sistema tra tanti, e molto spesso non è quello che possiede i dati.

Una persona a capo dell'architettura disegna su una lavagna un panorama dei sistemi intorno a Salesforce per due colleghi in una mattina di nebbia

Immagine generata con l’IA.

Le idee di questo capitolo

Prima viene il panorama. Trova i sistemi, poi i dati che si muovono tra loro, poi chi possiede ogni pezzo. Solo allora decidi qual è il compito di Salesforce.
Una freccia dipende da altre frecce. Gli ordini in uscita verso l’ERP hanno bisogno che prima arrivino clienti, prodotti e prezzi. Ogni volta che vedo un’integrazione con un solo flusso, comincio a preoccuparmi.
I dati sono di tipi diversi, e di carichi di lavoro diversi. Dati master, di riferimento, transazionali, metadati, analitici e non strutturati cambiano, crescono e vengono usati in modo diverso; i carichi di lavoro operativi (OLTP), analitici (OLAP) e di streaming vogliono sedi diverse. La org fa funzionare il business; warehouse e lake lo analizzano.
I sistemi hanno ruoli, non solo loghi. Registrazione, engagement, riferimento, insight. “Salesforce è il nostro system of record”: per cosa?
Dove vivono le analisi segue dove vivono i dati. Tutto sul core: report standard. Dati in altri archivi: una piattaforma di analisi, e il data warehouse quando vi si uniscono i dati Salesforce.
Data 360 è vicino al core (near-core): gestito sul core, ospitato fuori dal core. Gli utenti non vi si collegano mai, quindi sta con le tubature.
I dati di proprietà dell’ERP si leggono localmente e si scrivono sotto controllo, con un prefisso erp_ perché lo schema mostri chi possiede ogni campo.
In un panorama, una freccia parte dal sistema che apre la connessione, e la sua etichetta dice cosa si muove e in che direzione. Due flussi sono due frecce; una freccia a doppia punta è solo per un connettore.
Ogni freccia ha un client e un server, e ognuno possiede la sua metà. Niente di questo va nel panorama, ma ogni freccia lo ha.
Conta prima di disegnare le frecce. Gli zeri vanno nell’inventario, e scelgono il meccanismo: batch, sincrono o eventi.
La strategia delle org è una decisione di panorama, presa nei primi minuti: una org o molte, e dove gira.
Uno stato attuale mostra cosa non va. Rosso per un processo sbagliato, tratteggio per ciò che è fatto a mano, puntini rossi per ciò che manca.

Il layout del panorama di Steve

Ci sono molti modi di disegnare un panorama dei sistemi. Questo è il mio, affinato in molti anni, e si legge come una frase: le persone a sinistra raggiungono Salesforce al centro, con la fiducia garantita dai sistemi sopra, servite dai canali sotto, e collegate al back office a destra.

Dove	Cosa ci va
Sinistra	Le persone, dall’alto in basso: utenti interni, partner, clienti
Centro	Salesforce, un semplice riquadro, con le sue community che lo toccano da sotto
In alto	Provider di identità sopra Salesforce; AppExchange spostato a destra; siti web pubblici in alto a sinistra
Destra	Il livello di integrazione, poi i sistemi interni: ERP, finanza, data warehouse
Sotto il livello di integrazione	Data 360, vicino al core, con le tubature
In basso	I canali verso i clienti: email, moduli web, telefono, messaggistica
In basso a destra	Dati in entrata e in uscita: archivi, caricamenti di dati, fonti esterne, partner

I sistemi sono schede in zone tenui con un’etichetta, ognuna con un’icona, e una legenda dice cosa significa tutto. Dietro l’immagine c’è un inventario: per ogni insieme di dati o flusso, il responsabile, il volume, il meccanismo e i tempi, l’autenticazione, e se copiarlo, referenziarlo o federarlo.

Click to enlarge

Il panorama del modulo 4, con le sue frecce.

Il percorso di questo capitolo

Sei moduli, ognuno dei quali si regge da solo.

Salesforce è un sistema tra tanti. Perché il panorama viene prima del riquadro, l’integrazione che vedo di continuo e i flussi di ritorno da cui dipende, i dati a ondate, e core, vicino al core e Hyperforce.
I tipi di dati aziendali. Sei tipi; creato, modificato, referenziato; OLTP e OLAP; tempo reale, quasi tempo reale e batch; le quattro domande dietro le categorie.
I sistemi intorno a Salesforce. I ruoli dei sistemi; l’ERP, il data warehouse e il lakehouse; le analisi seguono i dati; l’MDM; integrazione ed eventi; il provider di identità che gli sviluppatori dimenticano; dove si colloca Data 360.
Disegna il panorama dei sistemi. Il mio layout, costruito partendo da una tela bianca; gli zeri prima delle frecce; frecce che partono da chi avvia la connessione; il client e il server dietro ogni freccia, in entrambe le direzioni; corsie per le conversazioni; l’inventario dietro l’immagine.
La strategia delle org è una decisione di panorama. Parti da una sola org; cosa ne giustifica un’altra; la regione, non il provider; una divisione in AMER ed EMEA dettata dal GDPR; cosa aggiunge la seconda org.
Il panorama di Steve Trucking. Oggi, prima di un’implementazione fatta come si deve, con i problemi segnati: manifesti che arrivano in RouteDesk, percorsi ridigitati a mano in Salesforce e all’indietro, un’isola di dati GPS, un foglio di calcolo che alimenta la contabilità, e 108.000 chiamate “dov’è la mia consegna?” all’anno.

Quando hai finito, mettiti alla prova con la guida allo studio del capitolo: una checklist per l’esame, le abitudini che vanno oltre, le parole da conoscere e qualche domanda.

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.
Come funziona ogni collegamento: cosa si muove, in quale direzione, come si autentica, quanto in fretta, e cosa torna indietro.
Quante org, e dove girano, deciso per primo, perché tutto il resto del panorama ne dipende.
Se lo stato attuale è compreso abbastanza bene da progettare uno stato futuro.

Oltre l’esame: il panorama sta diventando una mappa per gli agenti. Prima che un agente possa rispondere a “dov’è la mia consegna?”, qualcuno deve sapere quale sistema è autorevole per ogni fatto, quanto è aggiornato e come l’agente può raggiungerlo. Ogni modulo si chiude con ciò che l’IA cambia per la sua parte del quadro.

Per approfondire

Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (in inglese), consultato il 2026-10-14.
Per approfondire, per chi si prepara al CTA: Salesforce Architects pubblica le proprie indicazioni sui diagrammi, How to Build Salesforce Diagrams (opens in a new tab) (in inglese).

Successivo: Qualità e governance dei dati