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)
第 1 個模組，共 6 個，屬於 Data Architect 課程第 4 章理解企業資料。每個模組都可以單獨閱讀。 下一篇：企業資料的類型
**本模組回答的問題：**為什麼資料架構師要在設計 org 之前，先畫出圍繞 org 的東西？
我教 CTA 考生時，第一天之後的作業總是一樣的。讀情景。從一張空白畫布開始畫系統全景圖。然後才嘗試畫資料模型。不是物件，也不是詳細的整合：是全景圖。在我們決定什麼屬於 Salesforce 內部之前，我想先看到圍繞著 Salesforce 的是什麼。
對很多 Salesforce 從業者來說，這是一次視角的轉變。如果你的職業生涯一直是管理員或開發人員，Salesforce 自然就是你世界的中心。你開啟設定，建立物件，構建 Flow，寫 Apex，把其他系統整合進 Salesforce。一切似乎都從 org 開始。架構師必須把鏡頭拉遠，因為在企業中，**Salesforce 只是眾多系統之一，**而且很多時候，它並不是擁有資料的那一個。
先畫全景圖
Section titled “先畫全景圖 ”第 2 章構建了邏輯模型，第 3 章問了它如何在 Salesforce 上存在。現在我要把問題放大。在決定 Salesforce 應該擁有什麼之前，我想先理解它周圍的企業。已經有哪些系統？客戶在哪裡建立，產品在哪裡定義，訂單從哪裡開始，發票在哪裡生成？身分在哪裡？分析在哪裡進行，文件存放在哪裡，歷史放在哪裡？哪些系統需要 Salesforce 的資料，Salesforce 又依賴哪些系統？
這些問題會改變架構。所以我從一張空白畫布開始，把 Salesforce 放在中間，再畫出它周圍的一切。模組 4 會準確展示我是如何佈局的。現在，教訓很簡單：在理解 org 必須生存其中的世界之前，不要設計 org。
Salesforce 常常不是記錄系統
Section titled “Salesforce 常常不是記錄系統 ”拿一個非常常見的企業來說：Salesforce 加上一個 ERP，也就是 SAP 或 Oracle 這樣的企業資源計劃系統，負責財務、產品、庫存、採購和履約。現在問一個簡單的問題：客戶在哪裡？
可能在 Salesforce，可能在 ERP，也可能兩邊都有，而事情正是從這裡開始變得有趣。銷售人員可能在 Salesforce 中把潛在客戶作為客戶來跟進，而一旦他們成為付費客戶，ERP 才簽發正式的客戶編號。產品和價格？多半在 ERP。庫存？幾乎從不在 Salesforce。訂單可能在 Salesforce 中錄入、在 ERP 中履約；發票來自 ERP；服務在 Salesforce；分析則分散在 Salesforce 報表和資料倉儲之間。突然之間，我們漂亮的 Salesforce 資料模型就不是企業資料模型了。它只是其中的一部分。
我一再看到的那種整合
Section titled “我一再看到的那種整合 ”我看到最多的整合是這樣的：**客戶、產品和價格從 ERP 流入 Salesforce，訂單流出。**換成 SAP、Oracle 或任何其他 ERP，形狀都一樣。ERP 擁有客戶和產品的黃金記錄，所以這些資料流從右邊來，流入 Salesforce。銷售在 Salesforce 中成交，所以訂單從那裡開始，再回到 ERP 去履約、開票和記賬。
這些資料流不只是整合。它們告訴我，企業認為真相在哪裡。
單向箭頭讓我不安
Section titled “單向箭頭讓我不安 ”每當我看到一個只有一條資料流的整合，我就開始擔心了。在高層檢視上，有人畫了一個箭頭：訂單從 Salesforce 到 ERP。好的。現在往深裡看。如果我不知道 ERP 的客戶、產品或價格，我怎麼把訂單發給它？訂單必須關聯到 ERP 已有的客戶，每一行都必須是 ERP 已經在賣的 SKU。我不能為對面不存在的產品傳送一個明細項目。所以在這個訂單箭頭能工作之前，必須先有反方向的迴流資料。
這就是我對每個箭頭都會問的問題：**這條資料流依賴什麼？**你能看到的高層箭頭，通常需要你還沒畫出來的迴流資料。
再往深裡看，你會發現回程。Salesforce 發出一個訂單。然後呢？它被接受了還是被拒絕了？發貨了嗎，部分發貨了嗎，被取消了嗎？開票了嗎？Salesforce 裡有人需要知道嗎？也許不需要。但總該有人問過。如果什麼都不回傳，好的。告訴我為什麼。
企業不是一下子建成的
Section titled “企業不是一下子建成的 ”全景圖之所以複雜，部分原因是沒有人一次性把它們全建好。資料是一波一波到來的。先是檔案：固定格式的記錄，然後是 CSV 這樣的分隔檔案。然後是用於運營資料的關聯式資料庫。然後是把資料彙集起來做分析的資料倉儲。然後是 NoSQL 資料庫，用於不適合整齊放進表裡的文件、鍵值對和圖。然後是用於海量原始和半結構化資料的資料湖，以及把兩者結合起來的湖倉。事件流，比如 Kafka 或 Salesforce 事件匯流排，在資料發生時就移動它，而不是在夜間批次處理中。而現在是聯邦存取，資料不必先複製到一個地方，另一個平台就能使用它。
現在重點還不在技術，而在這一點：**新的一波很少會讓舊的一波消失。**走進一家大企業，你會同時發現所有這些：關聯式資料庫、ERP、Salesforce、資料倉儲、資料湖、SFTP 投遞、API、事件流、某人每週五仍在用郵件傳送的電子表格，還有那個人人都不敢碰的系統，因為構建它的人六年前就退休了。這才是你要做架構的企業，而不是產品手冊裡的那一個。
不同的系統因不同的原因而存在
Section titled “不同的系統因不同的原因而存在 ”這也是為什麼我從不從「我們怎麼把所有資料都弄進 Salesforce？」開始。我為什麼要讓所有資料都在那裡？Salesforce 也許是銷售和服務人員與客戶打交道的最佳場所。但這並不讓它成為財務系統、企業資料倉儲、遙測資料儲存、文件檔案庫，或者公司產生過的每一次點選、每一個 GPS 讀數和每一筆歷史交易的歸宿。
第 3 章針對一個 org 問的是**這些資料應該放在哪裡？**在企業層面，同樣的問題變得更大：有時 Salesforce 擁有資料，有時它保留一份副本，有時只是一個引用，有時它根本就不該有這些資料。
核心、核心之外與 Hyperforce
Section titled “核心、核心之外與 Hyperforce ”還有另一條邊界需要理解：即使是「Salesforce」，也不是一個執行時加一個資料庫。在第 3 章，核心之上指的是資料放在哪裡：在你的桌上，在 org 自己的物件裡。這裡同樣的詞描述的是一個產品執行在哪裡。你會聽到架構師兩種用法都用。
歷史上，Core 執行時承載了平台的大部分。今天，Salesforce 把平台描述為由數百個獨立的、後設資料驅動的服務組成，而 Core 仍然是應用後設資料唯一的記錄系統（The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)，英文）。這就是為什麼你會聽到架構師說某項能力執行在核心之上或核心之外。
早在平台拆分成服務之前，這一點就很重要。我在課上問大家，為什麼 Salesforce 收購 SteelBrick 來做報價，而不是 Apttus，我想要的答案很簡單：SteelBrick 是 100% 構建在核心之上的。Flow 和觸發器都在核心裡，所以構建在那裡的產品會隨之獲得平台的後設資料、定製和自動化。那個報價產品後來讓位給了 Revenue Cloud，但這個教訓沒有過時。然後是近核心（near-core），我用的例子是 Data 360。Data 360 不是核心。它的租戶在核心之外：資料和處理資料的機制執行在它自己的湖倉裡，在 org 的關聯式資料庫旁邊，而不是在裡面（The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)，英文）。但你用來設定和控制它的介面顯示在核心之上，在 org 裡。所以我能給出的最精確的說法是：**在核心之上管理，在核心之外託管。**資料和處理都不在 Core 裡執行；Core 上的介面控制著核心之外的租戶。當然，還有那些因為根本不是 Salesforce 而在核心之外的一切。
我不太在意記住今年哪個產品執行在哪裡，因為這會變；我在意的是這個習慣：一條邊界可能影響資料流動、延遲、身分、整合和資料駐留。所以不要因為一個產品叫 Salesforce，就認為它的資料就挨著你的客戶記錄。去看實際的架構。
然後是 Hyperforce：Salesforce 為公有雲構建、以程式碼定義的基礎設施，而不是它傳統的自建資料中心，讓客戶對資料駐留在哪裡有更多選擇（Salesforce Hyperforce: General Information and FAQ (opens in a new tab)，英文）。這很重要，模組 5 會再回到它。但基礎設施架構不是企業資料架構。把一個 org 遷到公有雲，並不能告訴你誰擁有客戶、庫存在哪裡、分析在哪裡執行，或者哪些資料可以跨境。Hyperforce 可以影響其中一些決定，尤其是資料駐留。它不能代替對全景的瞭解。
全景圖要在那個方框之前
Section titled “全景圖要在那個方框之前 ”所以這是一個習慣。有人交給你一個情景。不要開始構建 Salesforce 解決方案。先找出系統：ERP、身分提供商、資料倉儲、整合平台、合作夥伴系統、客戶渠道、文件儲存。然後找出它們之間流動的資料：客戶、產品、訂單、發票、文件、事件、身分。然後問每一樣歸誰所有。只有在那之後，才決定什麼屬於 Salesforce。否則你就是在不知道一個方框連線著什麼的情況下設計它。
第 1 步（共 3 步）：我們設計的 org，單獨來看。從這裡看，它就像整個世界。
第 2 步（共 3 步）：拉遠鏡頭。Salesforce 是眾多系統中的一個（第 4 模組會講這種佈局）。
第 3 步（共 3 步）：第一批箭頭。客戶、產品和價格從 ERP 進來，訂單發出去：它們說明了企業認為真相存放在哪裡。
全景圖會改變資料模型
Section titled “全景圖會改變資料模型 ”這就是它對資料架構師之所以重要的原因。第 2 章說客戶是一個重要的實體。好的。然後全景圖說 ERP 對客戶是權威的。這就改變了物理模型。Salesforce 也許仍然會保留一個本地的客戶記錄，因為人們每天都在用它，但現在我們需要把 ERP 的識別符號作為外部 ID；我們需要知道 Salesforce 可以修改哪些欄位（我會用 erp_ 字首標記 ERP 的欄位，模組 3 會講到）；ERP 的變更多快到達；Salesforce 能否在 ERP 知道之前就建立一個客戶；以及兩者不一致時會怎樣。這些不是留給以後的整合問題，而是資料架構問題，是全景圖把它們暴露了出來。
其中一個是這樣咬人的。銷售人員為一家大型飲料公司轉換了潛在客戶，建立了客戶，贏下了這筆交易，然後這個客戶被送到了 ERP。但公司和這家飲料公司已經做了多年生意，ERP 裡早就有它了。現在有兩個了。銷售人員當初真的應該能建立這個客戶嗎？第 5 章和第 6 章會回到這個問題；全景圖是你提前看到它到來的地方。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”- 哪些系統圍繞著 Salesforce，以及每個系統扮演什麼角色。
- 哪個系統擁有每一類重要的資料，在決定 Salesforce 保留多少之前。
- 什麼流入 Salesforce，什麼流出，以及什麼會回傳。
- Salesforce 應該擁有、複製、引用、聯邦存取、歸檔還是不碰哪些資料。
- 哪些平台和基礎設施的邊界是重要的，而不是假設所有帶 Salesforce 品牌的東西都在同一個地方。
從開發人員到架構師的轉變，往往不是再學一項功能，而是學會什麼時候不再盯著 Salesforce：把鏡頭拉遠，跟著資料走，找到誰擁有真相，然後回來決定 Salesforce 的職責應該是什麼。
- Salesforce Architects，The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)（英文），查閱日期 2026-10-14。
- Salesforce Help，Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab)（英文），查閱日期 2026-10-14。