先畫全景圖，再建 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)
Data Architect 第 4 章，第 1 部分：成為資料架構師。上一章：Salesforce 資料架構。
我教 CTA 考生時，第一天之後的作業總是一樣的。讀情景。從一張空白畫布開始畫系統全景圖。然後，只有在那之後，才嘗試畫資料模型。
大家對這個順序感到意外。我們是資料架構師，難道不該從資料模型開始嗎？我不這樣做的原因是：如果我先畫資料模型，我就已經決定了什麼屬於 Salesforce。如果我先畫全景圖，我就能看到所有應該影響這個決定的東西：擁有客戶和產品的 ERP，回答五年期問題的資料倉儲，決定誰能進來的身分提供商，每天下午發來一個檔案的合作夥伴，還有那個大家都說正在退役的遺留系統。
第 2 章和第 3 章設計了 org：模型應該是什麼樣，以及它如何在 Salesforce 上存在。本章把鏡頭拉遠，畫出**在設計 org 之前，圍繞在 org 周圍的東西。**Salesforce 只是眾多系統之一，而且很多時候，它並不是擁有資料的那一個。
圖片由 AI 生成。
本章的思想
Section titled “本章的思想 ”- **全景圖先行。**先找出系統，再找出它們之間流動的資料，然後是每一部分歸誰所有。只有在那之後，才決定 Salesforce 的職責是什麼。
- **一個箭頭依賴其他箭頭。**發往 ERP 的訂單，需要客戶、產品和價格先進來。每當我看到一個只有一條資料流的整合，我就開始擔心了。
- **資料分為不同的類型，也分為不同的工作負載。**主資料、參考資料、交易資料、後設資料、分析資料和非結構化資料，它們的變化、增長和使用方式各不相同；運營（OLTP）、分析（OLAP）和流式工作負載需要不同的歸宿。org 經營業務；資料倉儲和資料湖分析業務。
- **系統有角色，而不只是標誌。**記錄、互動、參考、洞察。「Salesforce 是我們的記錄系統」：記錄什麼？
- **分析放在哪裡，取決於資料放在哪裡。**全都在核心之上：用標準報表。資料在其他儲存裡：用分析平台，當 Salesforce 資料要與資料倉儲合併時，還要用資料倉儲。
- **Data 360 是近核心（near-core）：**在核心之上管理，在核心之外託管。使用者從不連線它，所以它和資料管道放在一起。
- **ERP 擁有的資料在本地讀取，在受控的方式下寫入，**並使用
erp_字首，讓結構顯示出每個欄位歸誰所有。 - **在全景圖上，箭頭從開啟連線的那個系統開始，**它的標籤說明移動的是什麼，以及朝哪個方向。兩條資料流就是兩個箭頭；雙向箭頭只用於聯結器。
- **每個箭頭都有一個用戶端和一個伺服器，**各自負責自己的一半。這些都不放在全景圖上，但每個箭頭都有。
- **畫箭頭之前先數一數。**零的個數寫進清單，由它們來選擇機制：批次處理、同步還是事件。
- **org 策略是全景層面的決定，**在最初的幾分鐘裡就要做出：一個 org 還是多個，以及在哪裡執行。
- **現狀圖要顯示哪裡不對。**紅色表示糟糕的流程，虛線表示手工完成，紅色點線表示缺失的東西。
Steve 的全景圖佈局
Section titled “Steve 的全景圖佈局 ”畫系統全景圖的方式有很多。這是我的方式，是我多年來不斷打磨的，它讀起來像一句話：左邊的人進入中間的 Salesforce，通過上方的系統獲得信任，通過下方的渠道獲得服務，並與右邊的後臺系統相連。
| 位置 | 放什麼 |
|---|---|
| 左邊 | 人，從上到下：內部使用者、合作夥伴、客戶 |
| 中間 | Salesforce，一個樸素的方框，它的社群在下方緊貼著它 |
| 上方 | 身分提供商在 Salesforce 上方；AppExchange 往右挪；公共網站在左上角 |
| 右邊 | 整合層，然後是內部系統：ERP、財務、資料倉儲 |
| 整合層下方 | Data 360，近核心，和資料管道放在一起 |
| 下方 | 客戶渠道：電子郵件、網頁表單、電話、訊息 |
| 右下角 | 資料進出：歸檔、資料載入、外部來源、合作夥伴 |
系統是放在淺色帶標籤區域裡的卡片，每張卡片有一個圖示，並有一個圖例說明一切的含義。圖背後有一份清單：對每個資料集或資料流，記錄它的所有者、資料量、機制和時序、認證，以及是複製、引用還是聯邦存取它。
模組 4 的全景圖，加上了箭頭。
本章的路線
Section titled “本章的路線 ”六個模組，每個都可以單獨閱讀。
- **Salesforce 只是眾多系統之一。**為什麼全景圖要在那個方框之前，我一再看到的那種整合以及它所依賴的迴流資料，一波一波到來的資料，以及核心、近核心和 Hyperforce。
- **企業資料的類型。**六種類型；建立、編輯、引用；OLTP 和 OLAP；即時、近即時和批次處理；類別背後的四個問題。
- **Salesforce 周圍的系統。**系統角色；ERP、資料倉儲和湖倉；分析跟著資料走；MDM；整合和事件；開發人員會忘記的身分提供商；Data 360 位於何處。
- **畫出系統全景圖。**我的佈局，從一張空白畫布搭建起來；先數零的個數，再畫箭頭；從發起方開始的箭頭；每個箭頭背後的用戶端和伺服器，兩個方向都有；為對話畫泳道；圖背後的清單。
- **org 策略是全景層面的決定。**從一個 org 開始；什麼情況下有理由再建一個；選擇的是區域，而不是提供商；由 GDPR 驅動拆分為 AMER 和 EMEA；第二個 org 增加了什麼。
- **Steve Trucking 的全景圖。**正式實施之前的今天，標出問題：裝貨清單落到 RouteDesk，路線被手工重新錄入 Salesforce 再錄回去，一座 GPS 資料孤島，一份餵給財務的電子表格，以及每年 108,000 個「我的貨到哪兒了？」的電話。
讀完之後，用本章學習指南檢查一下自己：一份備考清單、考試之外的習慣、必知術語，還有幾道題。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”- **哪些系統圍繞著 Salesforce，**以及每個系統扮演什麼角色。
- **哪個系統擁有每一類重要的資料，**在決定 Salesforce 保留多少之前。
- **每一個連線如何運作：**搬運什麼，朝哪個方向，如何認證，多快，以及什麼會回傳。
- **有多少個 org，在哪裡執行，**要最先決定，因為全景圖上的其他一切都依賴於它。
- 對現狀的理解是否足以設計一個目標狀態。
**考試之外：**全景圖正在變成一張代理程式地圖。在一個代理程式能回答「我的貨到哪兒了？」之前，得有人知道每個事實由哪個系統權威提供，它有多新，以及代理程式可以如何存取它。每個模組的結尾都會講 AI 為圖中的那一部分帶來了什麼改變。
- Salesforce Architects，The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)（英文），查閱日期 2026-10-14。
- 給 CTA 考生的延伸閱讀：Salesforce Architects 釋出了它自己的圖示指南，How to Build Salesforce Diagrams (opens in a new tab)（英文）。
下一章：資料品質與治理