Org 策略是全景層面的決定

🌐 另有 28 種語言版本

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 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)

圖片由 AI 生成

由 AI 翻譯，尚未經過社群審閱。 閱讀英文版

第 5 個模組，共 6 個，屬於 Data Architect 課程第 4 章理解企業資料。每個模組都可以單獨閱讀。 上一篇：畫出系統全景圖 · 下一篇：Steve Trucking 的全景圖

**本模組回答的問題：**一個 org 還是多個，它在哪裡執行？

我教 CTA 考生時會告訴他們，一個情景中最大的決定出現在最初的五到十分鐘：**我們面對的是多少個 Salesforce org？**一個大 org？北美、EMEA 和亞太各一個區域 org？不同業務部門各用一個 org？為一個有自己規則的國家單獨建一個 org？緊接著與之相關的是：這些 org 在哪裡執行？

這些不是管理員層面的細節。它們會改變資料放在哪裡、整合、報表、身分，以及世界各地的人如何存取系統。這就是為什麼我把 org 策略當作全景層面的決定，也是為什麼我最先做這個決定。

從一個 org 開始

我的出發點很簡單：**從一個 org 開始。**不是因為一個 org 總是對的，而是因為我需要一個理由才會再加一個。一個 org 給了我一個存放共用客戶資料的地方，一個安全模型，一個部署的地方，一套整合，一個做報表的地方。而一個 org 仍然可以支援不同的業務部門、國家、流程、記錄類型、應用、共用模型和體驗。

所以我不會因為歐洲的做法有點不同、某個事業部有自己的銷售流程，或者業務部門之間互相看不順眼，就加一個 org。這些是需求，不是 org 的邊界。問題是：什麼力量強大到足以證明需要另一個 org？

多個 org 是有代價的

把一個 org 拆成三個（北美、歐洲、亞太），你畫出的並不是三個整齊的方框；你製造了新的問題。一個全球客戶放在哪裡？如果它在兩個區域都有業務：兩份副本，哪一份擁有它？怎麼做全球報表？ERP 要和三個 org 都整合嗎？資料倉儲要接收三個資料來源嗎？身分提供商要連線三個 org 嗎？我們要把同樣的功能部署三次，並讓三個資料模型保持一致嗎？如果一個代理程式需要一個客戶的全球檢視，它該問哪個 org？

回到模組 4 的全景圖。一個 Salesforce 方框變成三個，每一個箭頭都要重畫。多 org 並沒有錯。但它從來都不是免費的。

尋找真正的邊界

什麼能證明需要另一個 org？足以塑造架構的真實邊界：資料駐留、監管、法律上的隔離、真正不同的運營模式、尚未整合的收購、區域託管約束、截然不同的治理方式，有時還有規模或隔離的需要。這份清單並不完整。重點是區分**「這些群體不一樣」和「這些群體需要一條架構邊界」**。後者的門檻要高得多。

地理位置並不自動構成 org 策略

「我們在 30 個國家運營，所以需要 30 個 org。」不對。地理位置只有在帶來架構需求時才重要。一家公司可以讓全世界的使用者使用同一套通用架構。所以我不數國家；我問的是隨之而來的是什麼。資料可以儲存在哪裡？可以在哪裡處理？跨境傳輸個人資料有沒有限制？有沒有關於資料駐留的合同承諾？某個區域是否需要不同的 Salesforce 服務或託管方？「在德國有一個辦公室」本身是不夠的。

託管是圖的一部分

在這裡，現代平台讓全景圖變得更有意思。Hyperforce 在世界各地區域的公有雲基礎設施上執行 Salesforce，讓客戶對資料駐留在哪裡有更多選擇和控制（Salesforce Hyperforce: General Information and FAQ (opens in a new tab)，英文）。所以當我給一個方框標上「Salesforce，歐洲」時，這個位置是可能重要的。

但要說得準確。選擇一個 org 放在哪裡，並不是承諾每一項服務的每一個位元組都留在那裡。Salesforce 提醒客戶查閱 Hyperforce 的信任與合規文件，包括他們所購買服務的額外子處理方（同一來源）。所以不要說「我們在 X 國的 Hyperforce 上，所以一切都留在 X 國」。要知道你實際在用哪些服務，以及你在滿足哪項需求。還要注意你選擇的是什麼：是區域，而不是它下面的雲。Hyperforce 執行在 AWS 上，從 2026 年底起也執行在 Google Cloud 上，由 Salesforce 決定一個 org 放在哪家提供商上；如果客戶有書面的監管理由需要避開某一家，就要和它的客戶團隊溝通（同一來源）。

不要扮演律師

這也是架構師需要清楚自己角色的地方。如果有人說「歐洲的隱私法要求單獨一個 org」，我不會盲目接受。我也不會自封為公司的律師，宣佈它並不要求。我會問：**我們要滿足的具體需求是什麼？**資料儲存在哪裡、在哪裡處理、跨境傳輸、誰可以為了支援而存取它、一份合同、內部政策？然後我和隱私、安全、合規及法務團隊一起，把這項需求轉化為架構。不要編造法律要求，也不要忽視它們。把它們翻譯出來。

當歐洲有了自己的 org

這是我在真實情景中看到的一條邊界。一家公司在美國有大量業務，在歐洲也有大量業務：兩大客戶群，兩套銷售和服務運營，以及一個圍繞 GDPR 建立的歐洲隱私計劃。GDPR 並沒有說「你需要一個單獨的 Salesforce org」。它為個人資料制定規則，包括個人資料何時可以被傳輸到歐盟以外（GDPR, Chapter V (opens in a new tab)，英文）。但這家公司與它的隱私和法務團隊一起決定，它的歐洲客戶的個人資料應該放在一個託管在歐洲的 org 裡，由它的歐洲團隊運營，受它的歐洲治理約束。這是一個真實的需求，而且是他們的需求，不是我的。

現在，「一個大的全球 org」就不再是一種偏好了。全景圖上有了一條邊界，Salesforce AMER 和 Salesforce EMEA，我必須把它畫出來。而第二個 org 從來不只是多一個方框。

Click to enlarge

兩個 org，AMER 和 EMEA。琥珀色是第二個 org 所增加的：不是多一個方框，而是每個箭頭都要再來一遍。

再走查一遍箭頭

有了不止一個 org，就再走查一遍全景圖。ERP 要把產品發給每個 org 嗎？每個 org 都要把訂單發回去嗎？客戶在哪裡主控，他們的資料可以跨區域嗎？整合層是全球的還是區域的？哪個身分提供商為哪些使用者登入？分析資料去哪裡？

有三個地方最快暴露出代價：

**報表。**CEO 想要一份全球銷售管道。在一個 org 裡，那是一份 Salesforce 報表。在三個 org 裡，那就是一個企業報表問題：複製、傳送到資料倉儲，還是聯邦存取？它必須多新？這幾個 org 對「銷售管道」的定義是否一致？**分析放在哪裡，取決於資料放在哪裡，**如果你有意把運營資料拆開了，就必須設計洞察如何重新匯聚起來。

**主資料。**一個全球客戶在美國、德國和日本都有採購。三個 org，所以很可能有三個客戶記錄。你怎麼知道它們是同一家公司？全球識別符號是什麼，歸誰所有？如果一個區域改了地址，這個修改應該傳播出去嗎？哪些屬性是全球的，哪些是區域的？org 策略解決不了身分問題；它改變的是身分問題本身。那是第 6 章的內容。

**整合。**一個 org：Salesforce、整合層、ERP。三個 org：三條連入整合層的連線，其中一條可能有自己的託管方和網路連線，有些資料流是共用的，有些是區域的，有些資料允許跨越，有些不允許。甚至網路也可能變化：如果企業需要通往 Hyperforce 的專用私有連線（在 AWS 上，Salesforce 推薦 AWS Direct Connect；見同一份 Hyperforce 常見問題），圖上的每一個 org 和託管方都是又一條需要規劃的連線。一個 org 在哪裡執行，可能會改變企業其餘部分存取它的方式。

**一個 org 還是多個，是你現在就要做的決定，**在一開始，在全景圖上。之後這些 org 如何共用資料（跨 org 的 Salesforce Connect、它們之間的整合、Data 360）屬於機制層面，由第 14 章一個 org 還是多個？ *(coming soon)*來講。

如果你設計完整個資料模型和整合架構之後才聽到「順便說一下，這得是三個 org」，你做的就不是一次小調整。你改變了架構。這就是為什麼這個決定要最先做。

不要只為了讓方框變小而拆分

一個大 org 感覺很複雜：很多部門、物件、使用者、整合。有人說：「如果每個人都有自己的 org，不是更乾淨嗎？」圖也許會更乾淨。企業卻未必。你用內部的複雜度換來了分散式的複雜度：同步、重複資料、跨 org 身分、全球報表、好幾條釋出流水線、重複的整合和自動化，以及對這一切的治理。有時這仍然是正確的交換。但分開不等於簡單。

而一個 org 也不是免費的。共用治理變得更重要，團隊之間會互相影響，安全邊界需要仔細設計，資料模型必須服務很多群體，釋出需要協調，區域性的規則可能會約束所有人。所以這不是「Steve 說永遠只用一個 org」。我的出發傾向是一個 org；然後我去尋找足以讓我偏離它的強有力的需求。

讓決定看得見

如果 org 策略很重要，就不要畫一朵籠統的 Salesforce 雲。把各個 org 畫出來並標上名字（AMER、EMEA，無論實際是什麼），註明每個 org 背後的託管或駐留需求，並走查各個連線。另一位架構師應該能看出每條邊界為什麼存在。如果我解釋不了為什麼有三個 Salesforce 方框，我就還沒做完這個決定。

Steve Trucking 只有一個 org，在美國，它的簡介裡也沒有任何需要另一個 org 的東西。但在綜合專案中記住這個模組：一次帶著自己 org 到來的收購，正是檢驗這些問題的那種邊界。

**考試之外：AI 改變了什麼。**代理程式可以讓 org 邊界對使用者不可見。但在底層，架構仍然必須決定代理程式可以問哪個 org 或系統，哪些資料可以跨區域，以及哪個答案是權威的。AI 可以在體驗中隱藏複雜度；它不會消除治理或邊界。

架構師在這裡決定什麼

• 是否有真正的架構理由需要不止一個 org，而不是在一個 org 內部解決這些差異。
• 每個 org 在哪裡執行，以及是哪項駐留、監管、合同或業務需求讓它放在那裡。
• 哪些資料可以跨越 org 和區域的邊界，主資料在哪裡是權威的，以及全球身分如何運作。
• 當一個 Salesforce 方框變成好幾個時，整合、身分、分析和報表會如何變化。
• 分開帶來的好處是否值得它所製造的分散式架構。

讀一個情景時，我首先尋找這個決定：一個 org 還是多個，託管在哪裡，被什麼所迫？回答了這些，全景圖的其餘部分就開始成形了。

延伸探索

• Salesforce Help，Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab)（英文），查閱日期 2026-10-14。
• EUR-Lex，Regulation (EU) 2016/679, the General Data Protection Regulation (opens in a new tab)（英文），第五章（向第三國傳輸個人資料），查閱日期 2026-10-14。