La strategia delle org è una decisione di panorama

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

La domanda a cui risponde questo modulo: Una org o molte, e dove gira?

Quando preparo i candidati CTA, dico loro che la decisione più grande di uno scenario arriva nei primi cinque o dieci minuti: con quante org Salesforce abbiamo a che fare? Una grande org? Org regionali per Nord America, EMEA e APAC? Org separate per business unit separate? Una org speciale per un paese con regole proprie? E strettamente legata a questa: dove girano quelle org?

Non sono dettagli da amministratore. Cambiano dove risiedono i dati, le integrazioni, la reportistica, l’identità, e il modo in cui le persone nel mondo raggiungono il sistema. Ecco perché tratto la strategia delle org come una decisione di panorama, e perché la prendo per prima.

Parti da una sola org

La mia posizione di partenza è semplice: parti da una sola org. Non perché una sola org sia sempre giusta, ma perché ho bisogno di una ragione per aggiungerne un’altra. Una sola org mi dà un unico posto per i dati condivisi dei clienti, un unico modello di sicurezza, un unico posto in cui distribuire, un unico insieme di integrazioni, un unico posto per la reportistica. E una sola org può comunque sostenere business unit, paesi, processi, tipi di record, app, modelli di condivisione ed esperienze diversi.

Quindi non aggiungo una org perché l’Europa fa le cose in modo un po’ diverso, o una divisione ha il suo processo di vendita, o le business unit non si sopportano. Sono requisiti, non confini tra org. La domanda è: quale forza è abbastanza forte da giustificare un’altra org?

Più org hanno un costo

Dividi una org in tre (Nord America, Europa, Asia-Pacifico) e non hai disegnato tre riquadri ordinati; hai creato nuove domande. Dove risiede un cliente globale? E se opera in due regioni: due copie, e quale lo possiede? Come si fa reportistica globale? L’ERP si integra con tutte e tre, il data warehouse riceve tre flussi, il provider di identità si collega a tutte e tre? Distribuiamo la stessa funzionalità tre volte e teniamo allineati tre modelli dati? Se un agente ha bisogno di una vista globale di un cliente, a quale org chiede?

Torna al panorama del modulo 4. Un riquadro Salesforce ne diventa tre, e ogni freccia va ridisegnata. Le org multiple non sono sbagliate. Non sono mai gratis.

Cerca confini reali

Cosa può giustificare un’altra org? Confini abbastanza reali da dare forma all’architettura: residenza dei dati, regolamentazione, separazione legale, modelli operativi davvero diversi, un’acquisizione non ancora integrata, un vincolo di hosting regionale, una governance molto diversa, a volte la scala o l’isolamento. L’elenco non è completo. Il punto è distinguere “questi gruppi sono diversi” da “questi gruppi hanno bisogno di un confine architetturale”. La seconda asticella è molto più alta.

La geografia non è automaticamente una strategia delle org

“Operiamo in 30 paesi, quindi ci servono 30 org.” No. La geografia conta quando porta con sé un requisito architetturale. Un’azienda può avere utenti in tutto il mondo su un’unica architettura comune. Quindi non conto i paesi; mi chiedo cosa portano con sé. Dove possono essere memorizzati i dati? Dove possono essere elaborati? Ci sono limiti al trasferimento dei dati personali oltre confine? Promesse contrattuali sulla residenza? Una regione ha bisogno di un servizio o di un hosting Salesforce diverso? “C’è un ufficio in Germania” da solo non basta.

L’hosting fa parte del disegno

Qui la piattaforma moderna rende il panorama più interessante. Hyperforce fa girare Salesforce su infrastrutture cloud pubbliche in regioni di tutto il mondo, dando ai clienti più scelta e controllo su dove risiedono i loro dati (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). Quindi quando etichetto un riquadro “Salesforce, Europa”, quel luogo può contare.

Ma sii preciso. Scegliere dove risiede una org non è la promessa che ogni byte di ogni servizio resti lì. Salesforce dice ai clienti di rivedere la documentazione su fiducia e conformità di Hyperforce, compresi i sub-responsabili aggiuntivi per i servizi che acquistano (stessa fonte). Quindi non dire “siamo su Hyperforce nel paese X, quindi tutto resta nel paese X”. Sappi quali servizi stai davvero usando, e quale requisito stai soddisfacendo. E nota cosa scegli: la regione, non il cloud che c’è sotto. Hyperforce gira su AWS, con Google Cloud a partire dalla fine del 2026, ed è Salesforce a decidere su quale provider si trova una org; un cliente con una ragione normativa documentata per evitarne uno ne parla con il proprio team commerciale (stessa fonte).

Non giocare all’avvocato

È anche il punto in cui gli architetti devono conoscere il proprio ruolo. Se qualcuno dice “la legge europea sulla privacy richiede una org separata”, non lo accetterò a occhi chiusi. Ma non mi nominerò nemmeno avvocato dell’azienda per dichiarare che non è così. Chiederò: quale requisito specifico stiamo soddisfacendo? Dove vengono memorizzati i dati, dove vengono elaborati, il trasferimento transfrontaliero, chi può accedervi per l’assistenza, un contratto, una politica interna? Poi lavoro con privacy, sicurezza, conformità e ufficio legale per trasformare quel requisito in architettura. Non inventare requisiti legali, e non ignorarli. Traducili.

Quando l’Europa ha la sua org

Ecco un confine che vedo in scenari reali. Un’azienda ha una forte presenza negli Stati Uniti e una forte presenza in Europa: due grandi basi di clienti, due operazioni di vendita e assistenza, e un programma europeo per la privacy costruito intorno al GDPR. Il GDPR non dice “ti serve una org Salesforce separata”. Stabilisce regole per i dati personali, compreso quando possono essere trasferiti fuori dall’UE (GDPR, capo V (opens in a new tab)). Ma questa azienda, lavorando con i suoi team privacy e legale, decide che i dati personali dei suoi clienti europei debbano vivere in una org ospitata in Europa, gestita dal suo team europeo, sotto la sua governance europea. È un requisito reale, ed è loro, non mio.

Ora “una grande org globale” non è più una preferenza. C’è un confine nel panorama, Salesforce AMER e Salesforce EMEA, e devo disegnarlo. E la seconda org non è mai solo un riquadro in più.

Click to enlarge

Due org, AMER ed EMEA. L’ambra è ciò che la seconda org aggiunge: non un riquadro in più, ma di nuovo ogni freccia.

Percorri di nuovo le frecce

Con più di una org, percorri di nuovo il panorama. L’ERP invia i prodotti a ogni org? Ognuna rimanda gli ordini? Dove sono gestiti i clienti come dati master, e i loro dati possono attraversare le regioni? Il livello di integrazione è globale o regionale? Quale provider di identità autentica quali utenti? Dove vanno i dati analitici?

Tre punti mostrano il costo più in fretta:

Reportistica. L’amministratore delegato vuole una pipeline globale. In una sola org è un report di Salesforce. In tre è un problema di reportistica aziendale: replicare, inviare al data warehouse, federare? Quanto deve essere aggiornata, e le org definiscono “pipeline” allo stesso modo? Dove vivono le analisi segue dove vivono i dati, e se dividi di proposito i dati operativi, devi progettare come le informazioni si ricompongono.

Dati master. Un cliente globale compra negli Stati Uniti, in Germania e in Giappone. Tre org, quindi probabilmente tre Account. Come sai che sono la stessa azienda? Qual è l’identificatore globale, e chi lo possiede? Se una regione cambia l’indirizzo, la modifica deve propagarsi? Quali attributi sono globali e quali regionali? La strategia delle org non risolve l’identità; cambia il problema dell’identità. È il capitolo 6.

Integrazione. Una org: Salesforce, il livello di integrazione, l’ERP. Tre org: tre collegamenti al livello di integrazione, magari uno con un suo hosting e una sua connettività, alcuni flussi condivisi, alcuni regionali, alcuni dati autorizzati ad attraversare e altri no. Perfino la rete può cambiare: se l’azienda ha bisogno di connettività privata dedicata verso Hyperforce (su AWS, Salesforce consiglia AWS Direct Connect; stessa FAQ su Hyperforce), ogni org e ogni hosting nel disegno è un altro collegamento da pianificare. Dove gira una org può cambiare il modo in cui il resto dell’azienda la raggiunge.

Una org o tante è una decisione che prendi ora, all’inizio, sul panorama. Il modo in cui le org condividono poi i dati (Salesforce Connect tra org, integrazione tra di esse, Data 360) è la meccanica, e lo tratta il capitolo 14, Una org o tante? (coming soon).

Se progetti l’intero modello dati e l’architettura di integrazione e solo dopo senti “a proposito, devono essere tre org”, non hai fatto un piccolo aggiustamento. Hai cambiato l’architettura. Ecco perché la decisione viene per prima.

Non dividere solo per rimpicciolire i riquadri

Una grande org sembra complicata: tante unità, oggetti, utenti, integrazioni. Qualcuno dice: “Non sarebbe più pulito se ognuno avesse la sua org?”. Il disegno potrebbe diventare più pulito. L’azienda forse no. Hai scambiato la complessità interna con una complessità distribuita: sincronizzazione, dati duplicati, identità tra org, reportistica globale, più pipeline di rilascio, integrazioni e automazioni duplicate, e la governance su tutto questo. A volte è comunque lo scambio giusto. Ma separato non è lo stesso che semplice.

E nemmeno una sola org è gratis. La governance condivisa conta di più, i team possono influenzarsi a vicenda, i confini di sicurezza vanno progettati con cura, il modello dati deve servire molti gruppi, i rilasci richiedono coordinamento, e le regole regionali possono vincolare tutti. Quindi non è “Steve dice sempre una sola org”. La mia propensione di partenza è una sola org; poi cerco il requisito abbastanza forte da spostarmi.

Rendi visibile la decisione

Se la strategia delle org conta, non disegnare una generica nuvola Salesforce. Disegna le org e dai loro un’etichetta (AMER, EMEA, qualunque cosa sia reale), annota il requisito di hosting o di residenza dietro ciascuna, e percorri i collegamenti. Un altro architetto dovrebbe poter vedere perché esiste ogni confine. Se non so spiegare perché ci sono tre riquadri Salesforce, non ho finito di prendere la decisione.

Steve Trucking ha una sola org, negli Stati Uniti, e niente nel suo brief ne richiede un’altra. Ma tieni a mente questo modulo per il capstone: un’acquisizione che arriva con la propria org è esattamente il tipo di confine che mette alla prova queste domande.

Oltre l’esame: cosa cambia l’IA. Un agente può rendere invisibile all’utente il confine tra org. Sotto, l’architettura deve comunque decidere a quale org o sistema l’agente può chiedere, quali dati possono attraversare le regioni, e quale risposta è autorevole. L’IA può nascondere la complessità nell’esperienza; non elimina la governance né il confine.

Cosa decide qui un architetto

• Se c’è una vera ragione architetturale per avere più di una org, invece di risolvere le differenze all’interno di una sola.
• Dove gira ogni org, e quale requisito di residenza, normativo, contrattuale o di business la mette lì.
• Quali dati possono attraversare i confini tra org e tra regioni, dove i dati master sono autorevoli, e come funziona l’identità globale.
• Come cambiano integrazione, identità, analisi e reportistica quando un riquadro Salesforce ne diventa diversi.
• Se il beneficio della separazione vale l’architettura distribuita che crea.

Quando leggo uno scenario, cerco per prima questa decisione: una org o molte, con hosting dove, e imposte da cosa? Rispondi a queste domande, e il resto del panorama comincia a prendere forma.

Per approfondire

• 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.
• EUR-Lex, Regolamento (UE) 2016/679, regolamento generale sulla protezione dei dati (opens in a new tab), capo V (trasferimenti di dati personali verso paesi terzi), consultato il 2026-10-14.