畫出系統全景圖
另有 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)
第 4 個模組，共 6 個，屬於 Data Architect 課程第 4 章理解企業資料。每個模組都可以單獨閱讀。 上一篇：Salesforce 周圍的系統 · 下一篇：org 策略是全景層面的決定
**本模組回答的問題：**我如何畫一張能顯示資料去向的全景圖？
給我一個新情景和一塊空白的白板，我最先畫的東西之一就是系統全景圖。不求漂亮，不畫每一個 API，也還不畫資料模型。我想看到整個企業：使用者是誰，涉及哪些系統，Salesforce 位於何處，它周圍有什麼，資料從哪裡來、到哪裡去。然後我要逐一走查那些箭頭。一張好的全景圖不是一幅方框的圖畫。它是一種暴露架構決定的方式。
從一張空白畫布開始
Section titled “從一張空白畫布開始 ”我會讓 CTA 考生練習這個。讀情景，然後開始畫。不要等到在腦子裡全部解決了再畫；畫圖本身會幫你解決問題。這就是為什麼第一天之後的作業是先開始畫全景圖，再嘗試畫資料模型。先畫資料模型，你就已經假設了什麼屬於 Salesforce。先畫全景圖，你就能看到應該影響這個決定的那些系統。
從高處開始，然後逐層深入：先是整個企業，再在重要的地方看細節。
第 1 步，共 6 步：一張空白畫布。只有區域。
Steve 的全景圖佈局
Section titled “Steve 的全景圖佈局 ”畫系統全景圖的方式有很多。這只是我的方式，是我多年來不斷打磨的，我分享它，是為了讓你看到如何快速搭起一張全景圖。我在每一張 Salesforce 全景圖上都用它，它讀起來像一句話：左邊的人進入中間的 Salesforce，通過上方的系統獲得信任，通過下方的渠道獲得服務，並與右邊的後臺系統相連。
**人在左邊，從上到下：內部使用者、合作夥伴、客戶。還不需要每一個使用者畫像；足夠回答誰在試圖接觸這個架構？**就行。每個群體都指向自己的入口：內部使用者指向 Salesforce，合作夥伴指向合作夥伴社群，客戶指向客戶社群。系統不會獨自存在。總有某個人或某樣東西在試圖使用它們。
第 2 步，共 6 步：誰在試圖接觸這個架構？
**Salesforce 在中間。**一個樸素的方框。不是因為 Salesforce 是企業的中心（我們剛花了三個模組說它不是），而是因為它是我圍繞著做設計的那個系統。它是錨點。
**社群緊貼在它正下方。**合作夥伴社群和客戶社群是獨立的端點，所以它們有自己的方框。但它們緊貼著 Salesforce，因為要接觸它們不需要任何整合：它們執行在同一個 org 裡。
第 3 步，共 6 步：Salesforce 在中間，社群緊貼在它正下方。
**身分在上方。**身分提供商放在頂部，也就是開發人員會忘記的那些：一個給內部使用者，也許另一個給合作夥伴。AppExchange 軟體包也放在上面，往右挪一點，因為它們是被引入 org 的能力，而不是與它交換資料的後臺系統。公共網站放在左上角。
第 4 步，共 6 步：身分在上方，這是開發人員會忘記的方框。
**整合在右邊，再往右是後臺。**整合層，即 ESB 或 iPaaS（如果點名了，就是 MuleSoft），是緊挨在 Salesforce 右邊的一根高高的豎條。內部系統在它後面：各個 ERP、財務、訂單管理、遺留系統、資料倉儲。現在整頁從左往右讀：人、Salesforce、整合、後臺。
第 5 步，共 6 步：先是整合，然後是後臺。
**渠道在下方。**凡是與客戶有直接聯絡的：郵件轉案例（email-to-case）、網頁轉潛在客戶（web-to-lead）、電話、訊息。
**資料進出，在右下角。**外部資料來源、歸檔、資料載入。
**Data 360 在右邊，整合層的下方。**使用者從不連線它，而它的租戶會連線很多後端系統，所以它和資料管道放在一起，在那裡這些連線保持很短：挨著內部系統、資料倉儲和右下角的資料。資料團隊確實會開啟它的介面，但這些介面在 org 裡：Data 360 是近核心，在核心之上管理，在核心之外託管（模組 1）。一條連回 Salesforce 的線表明誰在管理它。方框放在哪裡，應該講出它做什麼的故事。
這些幾何佈局都不是神聖不可改變的。約定的價值在於，我不用每次都重新發明一套視覺語言，而看過我一張圖的人，讀下一張會更快。
第 6 步，共 6 步：整個佈局，還沒有箭頭。之後的每一張全景圖都保持這些位置。
區域裡的卡片
Section titled “區域裡的卡片 ”讓表示法保持簡單。每個系統都是一張卡片：它的名稱、它的角色，以及一個說明它是什麼東西的小圖示：ERP、資料庫、身分提供商、一群人。我剛才描述的那些區域畫成淺色的帶標籤區域，這樣佈局本身就是可見的。底部的圖例說明每個圖示和每種線的含義。
不要在一個方框裡塞太多東西。只有在非常複雜的全景圖上，我才會把 Salesforce 拆開成幾個部分（org 裡的 Sales Cloud 和 Service Cloud，它們之間有箭頭）。也不要發明十五種形狀，除非每一種都在告訴讀者一些東西。我希望有人看全景圖三十秒，就開始理解這個架構。花哨幫不上忙。清楚才行。
把零的個數寫進清單
Section titled “把零的個數寫進清單 ”不要等到詳細設計時才考慮資料量。一個每晚搬運 500 個產品的箭頭，和一個每天搬運 200,000 條 GPS 讀數的箭頭，在全景圖上看起來可能一模一樣。它們不是同一個問題。所以在畫任何一個箭頭之前，先數一數移動的是什麼。從數量開始建立圖背後的清單：每個重要的資料集一行，寫上它的資料量。零的個數也許永遠不會出現在箭頭上，但你需要知道什麼時候進入了大數字：一小時幾千或幾百萬，幾十萬筆交易，甚至每秒幾十到幾百筆交易。
這些數字決定機制。每晚幾百條記錄是批次處理。有人在等待的呼叫可以是同步的，如果資料量允許的話。每秒幾十到幾百條可能需要事件，比如平台事件，而不是每條記錄一次呼叫。箭頭看起來是一樣的；由資料量決定用什麼來承載它，所以把它記在清單裡，也就是選擇機制的地方。
機制甚至可以改變箭頭的方向。每分鐘傳送幾條記錄，Salesforce 可以直接向外呼叫：箭頭從 Salesforce 開始。傳送多得多的記錄，Salesforce 可能改為在事件總線上釋出事件；外部系統訂閱，並呼叫進來取走它們，於是現在箭頭從另一端開始。再大一些，比如每晚同步幾百萬條記錄，那就是批次處理過程。所以在開始設計機制時就要儘早知道你的數量，因為數量可能會重畫箭頭。
資料量在兩個地方重要，原因各不相同。在資料模型上，我需要它來留意大數據量並規劃歸檔；第 2 部分會深入討論這一點。在系統全景圖上，清單裡的大數字決定整合模式和機制的選擇。模組 6 會把真實的零的個數放到 Steve Trucking 的全景圖和清單上。有了這些數量，再畫箭頭。
現在畫出箭頭
Section titled “現在畫出箭頭 ”系統就位後，把它們連起來，全景圖就變成了架構。**方框是一個系統；箭頭表示誰發起連線。**它從開啟連線的那個系統開始，指向被它呼叫的那個系統：從用戶端到伺服器。標籤說明移動的是什麼，以及朝哪個方向。
這條規則是給系統全景圖用的，在那裡是系統在和系統對話。在資料流圖上，箭頭跟著資料走，正如你所預期的。不要把全景圖的規則帶到其他圖裡；那隻會增加混亂。
箭頭放進來了。每個方框都在原來的位置；每個箭頭都從開啟連線的系統開始，它的標籤說明移動的是什麼以及朝哪個方向。
所以，如果整合層把產品推送進 Salesforce，箭頭就從整合層指向 Salesforce，標註產品進入。如果是 Salesforce 向外呼叫去取產品，箭頭就從 Salesforce 開始，標籤仍然是產品進入。同樣的資料，不同的對話，而這個區別告訴我誰需要憑據，誰必須處理失敗。Salesforce 通過整合層傳送訂單：訂單發出。ERP 的履約資訊回傳：訂單狀態進入。現在我能看到每段對話由誰發起，資料從哪裡進入 Salesforce、從哪裡離開，哪些資料流跨越了邊界，所有權大概在哪裡，以及我需要在哪裡多問一些。
還要記住模組 1：每當我只看到一條資料流，我就會擔心。在高層檢視上，一個訂單發出箭頭依賴迴流資料：客戶進入、產品進入、價格。再往深裡看，還有回程：接受、拒絕、狀態、發票號、取消。箭頭給了我可以質疑的具體東西。
每一個箭頭都需要一個機制
Section titled “每一個箭頭都需要一個機制 ”在這裡，全景圖不再是 PowerPoint 裡的裝飾畫。在評審會上，任何一個箭頭都可能引來三個問題，我希望你都有答案：
- **它如何認證？**OAuth、憑證、命名憑據，還是別的什麼？
- **它是同步還是非同步？**Salesforce 是等待 ERP，還是釋出後繼續做別的？業務需要多快拿到結果？
- **機制是什麼？**REST 呼叫、事件、檔案、訊息佇列，經過 MuleSoft 還是直連？
然後：另一端宕機時會怎樣？**每一個箭頭都需要一個機制。**如果你解釋不了它，這條線就是裝飾。
而「fire and forget」（發出即不管）不是答案。它通常意味著「我還沒設計發出之後會發生什麼」。它到達了嗎？被接受了嗎？失敗了嗎？會重試嗎？誰知道它卡住了？同一條訊息到達兩次會怎樣？這些都不放在全景圖上，否則全景圖就沒法讀了。但箭頭應該讓你知道這些問題是存在的。
把任何一個箭頭放大，都有一個用戶端和一個伺服器，各自負責自己的一半。用戶端開啟連線：它需要端點和埠，先從認證伺服器獲取權杖，呼叫伺服器定義的協議和契約，並選擇是否等待。只有用戶端能看到整個往返過程，所以只有用戶端能重試。伺服器負責監聽，定義協議、契約和資料載荷，驗證進來的東西，並且只看到它自己那一部分。當我畫一個箭頭時，我已經知道哪端是哪端，這就告訴了我每個問題歸誰負責。
放大的一個箭頭：用戶端負責處理，伺服器負責定義。這些都不放在全景圖上，但每個箭頭都有。
現在把箭頭反過來。當 ERP 呼叫 Salesforce 時，Salesforce 就是伺服器：它定義 API，執行自己的授權伺服器，並通過一個 External Client App（外部用戶端應用）和一個整合使用者來決定呼叫方可以做什麼。同樣的問題，另一邊。
Salesforce 作為伺服器：同樣的問題，由 Salesforce 回答伺服器那一半。
箭頭畫在全景圖上，對話畫在泳道裡
Section titled “箭頭畫在全景圖上，對話畫在泳道裡 ”架構師毀掉一張好圖的方式是：讓一個產出物回答所有問題。全景圖上加了 API 名稱、資料載荷、重試、錯誤佇列、轉換、每一個回撥，很快就沒人看得懂了。不要這樣。全景圖是大圖景：系統以及它們之間重要的資料流。
當我需要解釋一次互動時，我會畫第二張圖，但不是為每個整合都畫。如果系統 A 給 B 發了點東西，甚至問了一個問題並得到了答案，帶標籤的箭頭就夠了。當流程變成一場對話時，我才需要泳道：A 呼叫 B，B 向 C 核實，C 回答，B 建立了某樣東西並回調 A，一個人審批，另一個系統接著處理。我的經驗法則是：**超過一兩次往返互動，這個順序就要有自己的泳道。**箭頭畫在全景圖上；對話畫在泳道裡。
還要注意，箭頭在那裡的含義不同。在全景圖上，箭頭是一個連線：誰開啟它，移動的是什麼。在泳道裡，每個箭頭是一段對話中的一條訊息，按順序讀：一個請求往一個方向去，一個回覆從另一個方向回來，然後是下一步。
全景圖上三個箭頭；泳道裡六個步驟。在全景圖上，箭頭是一個連線；在泳道裡，每個箭頭是一條訊息，按順序排列。
逐一走查每個箭頭
Section titled “逐一走查每個箭頭 ”當全景圖看起來基本完成時，逐個箭頭地走查一遍。ERP 到 Salesforce：搬運的是什麼，誰擁有它，如何認證，機制是什麼，同步還是非同步，必須多新？然後是下一個箭頭，再下一個。缺口就是在這裡出現的。「哦，我們從來沒弄清楚那個合作夥伴到底是怎麼傳送的。」「我們把訂單發給了 ERP，但還沒設計被拒絕的訂單怎麼回來。」很好。你是在白板上發現了它，而不是在生產環境裡。
在圖的背後放一份清單
Section titled “在圖的背後放一份清單 ”圖必須保持可讀，所以細節放進它背後的清單裡。你已經用數量開了個頭；現在把它補完，每個重要的資料集或資料流一行：
| 列 | 我想知道什麼 |
|---|---|
| 資料集 | 客戶、產品、訂單、配送、發票 |
| 類型 | 主資料、參考資料、交易資料、分析資料、非結構化資料 |
| 所有者 | 誰擁有它的含義和生命週期？ |
| 記錄系統 | 權威版本在哪裡？ |
| 工作負載 | 運營、分析、流式 |
| 資料量 | 零的個數 |
| org | 如果有多個，是哪個 Salesforce org？ |
| 認證 | 連線如何建立信任？ |
| 機制和時序 | API、事件、檔案、聯邦存取；同步、非同步、批次處理 |
| 方式 | 複製它、引用它，還是聯邦存取它？ |
現在有了兩個產出物：全景圖讓我看到架構，清單讓我追問架構。
ED-D42 背後的清單。箭頭在全景圖上看起來都差不多；由資料量決定用什麼來承載每一個箭頭。
全景圖能回答問題
Section titled “全景圖能回答問題 ”這就是我喜歡這個產出物的原因：它幫助我思考。「我們如何跨 Salesforce 和 ERP 做報表？」這是模組 3 裡的問題：**我的哪張圖能漂亮地解決這個問題？**全景圖。如果一切都在核心之上，就用標準報表。如果資料在 ERP 和資料倉儲裡，你立刻就能看出來。「這個客戶屬性應該在哪裡主控？」看看哪些系統用它，哪個系統已經擁有客戶。「Salesforce 需要每一條 GPS 讀數嗎？」誰產生它，誰消費它，工作負載是什麼？也許 Salesforce 需要的是當前位置，而由另一個平台保留歷史。全景圖不會直接交給你答案。它給你的是看待問題的正確視角。
在修復之前先畫出現狀
Section titled “在修復之前先畫出現狀 ”還有一條紀律。在一個已有的企業裡，畫出存在的東西，而不是你希望存在的東西。每週五用郵件傳送的那份電子表格：畫出來。合作夥伴放在 SFTP 伺服器上的 CSV：畫出來。因為歷史原因繞過 ESB 的那個整合：畫出來。在兩個系統之間重新錄入資料的人：標出來。不要在記錄現實的同時把它美化。在設計目標全景圖之前，你需要當前的全景圖，而這正是我們在模組 6 中為 Steve Trucking 做的事。
**考試之外：AI 改變了什麼。**全景圖正在變成一張代理程式地圖。如果一個代理程式要回答「我的貨到哪兒了？」，全景圖就必須說明答案來自 Salesforce、某個合作夥伴系統、車載遠端資訊、ERP，還是它們的組合。代理程式不會消除系統邊界；它們讓知道哪個系統是權威的、以及如何安全地存取它，變得更加重要。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”- 哪些系統和使用者群體屬於全景圖，以及它們的位置如何體現其角色。
- 哪些資料流跨越系統邊界，朝哪個方向，以及什麼會回傳。
- 每一個連線如何認證，由什麼機制承載，以及它是同步、非同步、批次處理還是聯邦存取。
- 什麼時候一個帶標籤的箭頭就夠了，什麼時候一次互動需要自己的泳道。
- 圖背後的清單要記錄什麼：所有者、工作負載、資料量、org、時序、認證，以及複製、引用還是聯邦存取。
全景圖不是我在架構完成之後才畫的東西。它是我發現架構的方式。當你覺得它完成了時，不要欣賞它，去走查它。每一個你還解釋不了的箭頭，都在告訴你工作在哪裡。
- 延伸閱讀：Salesforce Architects 釋出了它自己的圖示指南，How to Build Salesforce Diagrams (opens in a new tab) 和 System Landscape (opens in a new tab)（英文），如果你準備參加 CTA 評審會，值得了解。