Salesforce 周圍的系統
另有 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)
第 3 個模組，共 6 個，屬於 Data Architect 課程第 4 章理解企業資料。每個模組都可以單獨閱讀。 上一篇：企業資料的類型 · 下一篇：畫出系統全景圖
**本模組回答的問題：**Salesforce 周圍有什麼，每個系統扮演什麼角色？
上一個模組給資料分了類。現在我想把它放到某個地方，而這正是 Salesforce 架構師容易陷入麻煩的地方。我們瞭解 Salesforce，所以客戶資料就意味著客戶物件，訂單資料就意味著訂單，文件就意味著檔案，分析就意味著報表。但企業買 Salesforce 並不是為了取代它擁有的其他一切。可能有一個負責財務和履約的 ERP，一個存著多年曆史的資料倉儲，一個整合平台，一個身分提供商，合作夥伴的系統，一個事件平台，一個 MDM 平台，以及連線其中幾個的 Data 360。這份工作不是記住各種技術，而是理解每個系統承擔什麼職責。
不要從產品名稱開始
Section titled “不要從產品名稱開始 ”「我們有 SAP」告訴我的資訊不夠。Snowflake、MuleSoft、Tableau 或 Data 360 也一樣。我想知道那個系統在這個架構中做什麼：它擁有什麼資料，讀取什麼，修改什麼，誰在用它，什麼依賴它，它宕機時會怎樣。兩家公司可以擁有完全相同的產品，架構卻完全不同。
所以我按角色給系統貼標籤。四種角色就能涵蓋大部分情況：
- **記錄系統：**維護某樣東西權威版本的地方。
- **互動系統：**人們做事的地方。
- **參考系統：**一個系統去獲取它需要但並不擁有的資訊的地方。
- **洞察系統：**資料匯聚起來用於度量、分析和預測的地方。
一個平台可以扮演好幾種角色，而且角色因資料而異。Salesforce 可能是案例的記錄系統，是服務人員的互動系統，同時也是 ERP 所擁有的產品資料的消費者。所以當有人說「Salesforce 是我們的記錄系統」時，把這句話說完：記錄什麼的系統？
ERP：後臺有引力
Section titled “ERP：後臺有引力 ”ERP 是你最常在 Salesforce 旁邊看到的系統，負責財務、庫存、採購、履約和計費。模組 1 的模式（客戶和產品流入，訂單流出）意味著 ERP 擁有產品，但銷售人員仍然需要在 Salesforce 中用到它們。好的：把它們引進來。但複製資料並不會轉移所有權。副本不是權威。
我的立場是：**ERP 擁有的資料在本地讀取，在受控的方式下寫入。**Salesforce 使用者在他們工作的地方拿到資料，但 Salesforce 不能修改 ERP 擁有的東西。而且我會讓這一點在結構中可見：ERP 的欄位帶有 erp_ 字首，比如 erp_Product_Number__c，這樣任何閱讀這個物件的人都知道每個欄位歸誰所有、修改時要小心。字首本身不執行任何東西；執行靠的是權限、驗證和整合模式。它傳達的是意圖，是讓權威系統圖變得可見。
資料倉儲、資料湖和湖倉
Section titled “資料倉儲、資料湖和湖倉 ”運營系統經營業務；分析系統幫助理解業務。「給我看我未完成的商機」是一份 Salesforce 報表。「給我看所有渠道五年的銷售、履約、退貨、案例、庫存和財務」則是另一個問題。
你會遇到三種分析儲存。資料倉儲存放為分析而準備的結構化資料。資料湖存放多得多、形式也更多樣的資料，往往是原始資料。湖倉把兩者結合起來：資料湖式的儲存，資料倉儲式的分析。要了解它們，因為它們會出現在全景圖上。但我的經驗是，**湖倉和資料網格在 Salesforce 專案中仍然比較小眾。**典型的全景圖是 CRM、ERP、一個數據倉庫和一個整合層，再加上業務確實需要的其他平台。學習架構，而不是追逐術語。
分析放在資料所在的地方
Section titled “分析放在資料所在的地方 ”這是我最堅定的立場之一：**分析放在哪裡，取決於資料放在哪裡。**如果報表只需要客戶、商機和銷售人員，那全都在核心之上：用標準報表和儀表板。然後業務方要求加上 ERP 的發票。然後是產品成本。然後是資料倉儲裡五年的訂單。然後是網站活動。到了某個時候，為了做報表把所有這些都拖進運營 CRM 就不再說得通了。一旦涉及其他資料儲存，分析平台就變得必要：Tableau（包括構建在 Data 360 之上的 Tableau Next），或者在已經使用它的地方用 CRM Analytics。當 Salesforce 資料要與資料倉儲合併時，它就必不可少。需求並不只是變複雜了；**是全景改變了這個問題應該在哪裡回答。所以我從不以「用哪個分析工具？」開始。我以資料在哪裡？**開始。
我也問 CTA 考生同樣的問題：「我的哪張圖能漂亮地解決這個問題？全景圖。」如果你全都在核心之上，就用報表。如果你在其他儲存庫裡有資料，我希望看到一個分析平台。在任何人開啟報表構建器之前，全景圖就回答了報表的問題。（產品名稱會變；Salesforce 的分析如今處於什麼位置，由 Data 360 那一章來講。）
MDM：這個客戶到底是誰？
Section titled “MDM：這個客戶到底是誰？ ”現在假設客戶資訊分散在 Salesforce、ERP、電商、會員平台和一個合作夥伴系統裡，而每一個都認為自己知道客戶是誰。這就是主資料管理登場的地方：在各個系統之間建立並治理關鍵資料的權威身分。但 MDM 不是「一個主客戶資料庫」。難的問題是：哪個系統可以建立客戶，每個系統擁有哪些屬性，如何發現重複，哪個識別符號存活下來，以及系統之間不一致時怎麼辦。第 6 章講的全是這個。在這裡，先認出這個角色：如果存在一個 MDM 平台，它可能是 Salesforce 與企業其餘部分之間一個關鍵的權威。
整合層與事件
Section titled “整合層與事件 ”把每個系統都和其他每個系統直接相連，全景圖很快就會變成一盤義大利麵。這就是為什麼企業要有一個整合層：一個 ESB（企業服務匯流排）或 iPaaS（整合平台即服務）。MuleSoft 是你在 Salesforce 全景圖中最常遇到的。它充當中介，這樣每個應用就不必去理解其他每一個應用。
但中間放一個 MuleSoft 方框，並不會讓整合變好。我仍然想知道什麼經過它、什麼不經過，誰來轉換資料，誰擁有契約，目標宕機時會怎樣，它是同步還是非同步，以及我們如何知道一條訊息成功了。Integration Architect 課程會深入討論；在這裡，先把它認作一個獨立的角色。
而且並非每個整合都是系統 A 呼叫系統 B。有時某件事發生了（一個訂單被建立，一次配送改變了狀態，一輛卡車駛入了某個區域），一個事件被髮布出來，感興趣的各方各自響應。流動中的事件也有基礎設施：Salesforce 自己的事件能力、企業事件匯流排、其他訊息機制。要畫出承載資料的機制，而不只是資料庫。
開發人員會忘記的系統：身分
Section titled “開發人員會忘記的系統：身分 ”有一個方框我總希望出現在全景圖上，而開發人員卻很少想到它：**身分提供商。**開發人員用使用者名稱和密碼直接登入他們的沙箱，所以在構建期間身分是看不見的。然後到了 UAT 或生產環境，突然就有了公司給員工用的單點登入，也許還有給合作夥伴的第二個提供商，給客戶的社交登入。身分一直都是架構的一部分。只是開發人員還沒看到它。
身分提供商（IdP）是認證使用者並建立 Salesforce 所信任的身分的系統。它從第一天起就應該出現在全景圖上，即使它要在釋出流水線的後期才配置，因為誰能進來，決定了誰能接觸到資料。
還有一個實際的問題：身分配置**可以部署，但不能完全部署。**SAML 單點登入配置和認證提供商都是 Metadata API 類型，所以它們可以隨流水線遷移（SamlSsoConfig (opens in a new tab)，英文）。但認證提供商的使用者金鑰不再在 Metadata API 的響應中返回（Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab)，英文），而憑證通常因環境而異。要為能遷移的部分和不能遷移的部分都做好計劃。
按角色而不是標誌來讀全景圖：每個系統擁有什麼、讀取什麼、決定什麼。
Data 360 放在哪裡？
Section titled “Data 360 放在哪裡？ ”Data 360 提出了一個很好的畫圖問題。我把它放在**右邊、ESB 或 MuleSoft 的下方。**原因在於它的連線：使用者從不直接連線它，而它會直接連線很多後端系統。所以它屬於資料管道那一邊，在那裡這些連線保持很短，而不是和使用者放在一起。把它畫成又一個人們登入的介面，你講的就是一個錯誤的故事。
管理員和資料團隊確實會開啟 Data 360 的介面，但這些介面在 org 裡，在核心之上。真正幹活的租戶，它的資料和處理，執行在核心之外。這就是為什麼我把它叫作近核心（near-core）：在核心之上管理，在核心之外託管（模組 1 解釋了這些術語）。圖跟著租戶走：它和資料管道放在一起，有一條線連回管理它的 org。
用 Salesforce 自己的話說，它的功能包括零複製：一種資料聯邦技術，讓企業無需複製就能存取和查詢資料（Zero Copy (opens in a new tab)，英文）。它的能力和聯結器變化很快，所以由 Data 360 那一章來好好講，而不是把這個模組變成一次產品導覽。
把全景圖當作職責來讀
Section titled “把全景圖當作職責來讀 ”看一張全景圖時，不要讀標誌，要讀職責。ERP：它擁有什麼？資料倉儲：它回答什麼問題？整合平台：它搬運什麼？IdP：它認證誰？MDM：它治理什麼身分？Data 360：它連線什麼，為了什麼？Salesforce：它實際上負責什麼？一旦你能回答這些，方框就有了意義，而它們之間的箭頭也會變得有趣得多。接下來，我們有意識地把它們畫出來。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”- 每個系統扮演什麼角色，超越它的產品名稱。
- 對每一個重要的資料集，哪個系統是權威的，以及 Salesforce 在哪裡只保留一份本地副本。
- ERP 擁有的資料是否在 Salesforce 中可用、寫入受控，以及這種所有權如何在結構中體現出來。
- 根據資料所在的位置，分析應該放在哪裡。
- 身分、整合、事件和主資料權威在全景圖上位於何處。
一張有十個矩形的全景圖還不是架構，只是一份清單。當你能指著每一個矩形說出它為什麼在那裡、它擁有什麼、誰在用它、Salesforce 需要從它那裡得到什麼，以及誤解它的角色會讓什麼出問題時，架構才開始。
- Salesforce Developers，Metadata API Developer Guide，SamlSsoConfig (opens in a new tab)（英文），查閱日期 2026-10-14。
- Salesforce Help，Winter ‘23 Release Notes，Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab)（英文），查閱日期 2026-10-14。
- Salesforce，Zero Copy (opens in a new tab)（產品頁面，英文），查閱日期 2026-10-14。
- Zhamak Dehghani，How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (opens in a new tab)，martinfowler.com，2019（英文）。