Steve Trucking 的全景圖
另有 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)
第 6 個模組，共 6 個，屬於 Data Architect 課程第 4 章理解企業資料。每個模組都可以單獨閱讀。 上一篇：org 策略是全景層面的決定 · 下一篇：下一章資料品質與治理
**本模組回答的問題：**在我們設計任何東西之前，一張真實的全景圖能告訴我們什麼？
這一章一直在把鏡頭拉遠：Salesforce 只是眾多系統之一，資料的類型，Salesforce 周圍的系統，如何畫全景圖，以及 org 策略。現在我們在 Steve Trucking 上把它們串起來。但我們還不打算修復任何東西。這就是紀律：畫出存在的東西，走查每一個箭頭，看看全景圖告訴了我們什麼。
從我們知道的開始
Section titled “從我們知道的開始 ”Steve Trucking 有一個 Salesforce org，在美國。Service Cloud 處理來自收貨人和零售合作夥伴的案例；Field Service 管理預約、配送小組和移動應用；Experience Cloud 給零售合作夥伴提供了一個入口網站，目前只用於索賠和報表；Sales Cloud 追蹤合作夥伴合同和新配送中心的投標。所以 Salesforce 放在中間。
左邊是人：在零售合作夥伴的配送中心裡工作的 45 名排程協調員，330 輛卡車上大約 700 名配送小組成員，60 名客戶服務人員，40 名運營、財務和銷售人員，以及大約 300 名零售合作夥伴使用者。這已經告訴了我們一些東西：這不是一個部門級的 CRM。它是覆蓋大部分業務的運營平台。但它仍然是一個方框。現在我們來看看它周圍有什麼。
正式實施之前的 Steve Trucking 現狀。每一份裝貨清單都落到 RouteDesk；協調員手工把路線重新錄入 Salesforce，再把完成的停靠點錄回去；FleetLink 缺少它的連線。
標出哪裡不對
Section titled “標出哪裡不對 ”這是一個現狀，在正式實施之前，我會在圖上寫明這一點。然後我把調色盤開啟。在一個已完成系統的全景圖上，我不用紅色；在現狀圖上我會用。紅色標出糟糕或不當的流程，虛線標出手工完成的事情，紅色點線標出缺失的連線。不畫某個箭頭本身也說明了一些東西。這些都不是裝飾：每一條紅線都是一條等著被寫下來的需求。
三個合作夥伴，三種整合
Section titled “三個合作夥伴，三種整合 ”三個零售合作夥伴用三種不同的方式傳送裝貨清單，所以要把每一個分開畫。
Keystone 每天下午把一份 CSV 裝貨清單放到一臺 SFTP 伺服器上，用於兩天後的配送，並希望每晚收到一份回傳的狀態檔案。兩個箭頭：裝貨清單以檔案方式進來，由 Keystone 發起；狀態以檔案方式出去，由 RouteDesk 發起。非同步，時間視窗很寬。
Redrock 通過一個 REST API 傳送裝貨清單，並期望狀態一發生變化就通過 webhook 收到更新。兩個箭頭，兩種機制：Redrock 通過 API 呼叫進來送裝貨清單，RouteDesk 通過 webhook 向外呼叫送狀態。近即時。
Brightwave 通過一個第三方網路傳送 EDI 檔案，並期望收到回傳的 EDI 狀態報文。又一種格式，又一種機制。
同樣的業務概念（裝貨清單、配送、狀態），三種完全不同的整合。不要因為你希望它們一致就把圖簡化。它們不一致。這就是現狀。
然後走查它們。Keystone：SFTP 連線如何認證，檔案落在哪裡，什麼去拾取它，我們怎麼知道整個檔案都被處理了，壞的一行會怎樣，Keystone 如何在今晚的檔案之前得知一個變更？Redrock：API 如何認證，任何一方宕機時會怎樣，什麼算一次成功的 webhook，同一個狀態到達兩次會怎樣？Brightwave：誰運營 EDI 網路，轉換在哪裡做，會回傳什麼確認？我們沒有重新設計任何東西。我們在發現問題。這正是全景圖的工作。
RouteDesk 仍然在那裡
Section titled “RouteDesk 仍然在那裡 ”RouteDesk 是遺留的桌面排程和路線規劃工具，各個配送中心的協調員用它把裝貨清單變成路線。它存著八年的配送歷史，而且已經計劃退役。照樣把它畫出來。一個常見的錯誤是漏掉那個「我們正在淘汰的」系統。什麼時候淘汰？假設答案是十八個月。那麼它至少在十八個月裡都是架構的一部分，而它八年的歷史，大約五百萬次配送，不會隨著應用消失而消失。再看看全景圖暴露了什麼：RouteDesk 和 Salesforce 並沒有連起來。配送小組在 Salesforce 的 Field Service 應用裡處理他們的停靠點，但路線是在 RouteDesk 裡建的，所以協調員每天晚上把路線重新錄入 Salesforce，然後再把完成的停靠點錄回 RouteDesk，好讓它向合作夥伴傳送狀態。每天大約 3,300 個停靠點，錄兩遍，全靠手工。這在圖上是紅色虛線。它還告訴你，Redrock 那個「一發生變化就傳送」的 webhook 其實並不是一發生變化就傳送。RouteDesk 今天擁有什麼？什麼依賴它？哪些歷史必須在它之後存續下來，存到哪裡：Salesforce、資料倉儲、某個檔案庫？我們還不回答。全景圖只是把問題暴露了出來。
FleetLink 是一座孤島
Section titled “FleetLink 是一座孤島 ”車載遠端資訊平台 FleetLink 接收每輛卡車的 GPS：每天大約 20 萬條讀數，每輛卡車，行駛中的每一分鐘。而它沒有和任何東西相連。協調員在一塊單獨的螢幕上看它。所以把 FleetLink 畫出來，不帶任何箭頭。不要因為我們覺得應該有一條整合線，就憑空畫一條。
然後數一數零：每天 20 萬條，一年就超過 7,000 萬條。這不是「我們有 GPS 資料」。這是一個有很多零的流式資料來源，位於 Salesforce 體驗之外。Salesforce 需要每年 7,000 萬條讀數嗎？多半不需要全部。這是一個留給以後的設計問題。
財務有它自己的真相
Section titled “財務有它自己的真相 ”財務 ERP 按每次配送、安裝和拉走舊貨向每個零售合作夥伴開票，並支付配送小組的激勵。而配送數量是通過一份月度電子表格到達它那裡的。把這份電子表格畫出來。不要因為我們是架構師、懂得更多，就把它換成一個整潔的 API 箭頭；它是當前架構的一部分。一旦畫出來，問題就來了：誰製作它，從哪個系統來，誰核對它，如果一次配送在表格發出後發生了變化會怎樣，以誰的數字為準？答案關係到錢。
Snowflake 每週收到一次匯出
Section titled “Snowflake 每週收到一次匯出 ”Snowflake 存放運營和財務分析資料，由每週一次的匯出供數。Snowflake 自己做不到這一點；是中間的某樣東西在做：一個執行在 Salesforce 之外的計劃匯出作業，通過 Bulk API 拉取資料並載入到 Snowflake。分析放在哪裡，取決於資料放在哪裡，而 Snowflake 已經是分析的歸宿了。但時序也告訴了我們一些東西。「上個月發生了什麼？」每週一次的資料完全夠用。「這次配送現在在哪裡？」Snowflake 就不是我會開始找的地方。同一個企業，不同的工作負載，不同的新鮮度，不同的答案。
身分並非以同樣的方式覆蓋每個人
Section titled “身分並非以同樣的方式覆蓋每個人 ”企業身分提供商放在 Salesforce 上方。辦公室員工用單點登入。但協調員和配送小組用 Salesforce 憑據登入。所以從 IdP 到 Salesforce 只畫一條信任線，會把一半的故事藏起來。真正的問題是哪些使用者通過哪條路徑登入，而這屬於全景圖。
收貨人體驗有一個缺口
Section titled “收貨人體驗有一個缺口 ”簡訊和電子郵件服務商從 RouteDesk 給收貨人傳送一條通用的「您的貨明天送到」訊息。沒有追蹤連結。與此同時，每年大約有 18 萬個案例，其中大約 60% 是「我的貨到哪兒了？」：**每年大約 108,000 個案例在問同一個問題。**現在把它和 FleetLink 放在一起。公司知道它的卡車在哪裡。它的收貨人卻不停地打電話來問。而知道答案的系統，和回答問題的系統，並沒有連起來。我還不需要設計解決方案。全景圖已經在講這個故事了。
把零的個數寫進清單
Section titled “把零的個數寫進清單 ”現在數一數移動的是什麼。和模組 4 一樣，零的個數不放在箭頭上；它們放進圖背後的清單裡，等我們做設計時，它們會決定機制。每年大約一百萬次配送，每天大約 3,300 次，每年增長 30%；每次配送大約 1.6 個明細項目；每次大約八次狀態更新，所以今天是每年八百萬次狀態更新；每年四五百萬張照片，目前存在配送小組成員自己的手機上；每天大約 20 萬條 GPS 讀數；每年大約 18 萬個案例。一個標註「配送狀態」的箭頭不是偶爾才有的一條訊息。方框告訴你存在什麼。箭頭告訴你什麼在移動。零的個數告訴你，你的假設能否經得起現實的考驗。
Steve Trucking 全景圖背後的清單：資料量就寫在它將決定的機制旁邊。
還沒有目標架構，而我已經能看到重要的資料在哪裡，它是哪類資料，它流動得多快，以及各個系統如何交換它。
**考試之外：AI 改變了什麼。**假設 Steve Trucking 構建了一個代理程式，來回答收貨人的「我的貨到哪兒了？」。它應該問哪個系統？Salesforce 知道預約，FleetLink 知道卡車在哪裡，合作夥伴的裝貨清單定義了這次配送。當前的全景圖就是代理程式的地圖，而在代理程式能安全地回答之前，架構師必須知道每個事實由哪個系統權威提供，以及它有多新。把代理程式指向錯誤的來源，過時的資料就會變成一個自信的答案。
讀懂痛點，先別急著修
Section titled “讀懂痛點，先別急著修 ”退後一步看。三個合作夥伴，三種整合風格。一個存著八年曆史的遺留排程工具，協調員每天把 3,300 個停靠點重新錄入 Salesforce，再錄回去。一個每天 20 萬條讀數、卻沒連起來的車載遠端資訊平台。財務根據一份月度電子表格來統計配送。分析資料落後一週。有些使用者用單點登入，有些不用。沒有追蹤連結，每年 108,000 個案例在問貨到哪兒了。而這一切每年都在增長 30%。
一張圖裡有這麼多架構資訊。誘惑是開始修復它。不要。還不要。我希望你能坦然地讓一張現狀圖保持難看，因為有時現狀就是難看的。重點不是用乾淨的圖讓誰刮目相看，而是對現實形成共同的理解。邊記錄邊重新設計，你就會失去基線。之後我希望能說：這是當時存在的，這是我們解決的問題，這是我們改變的東西，以及為什麼。第 6 章開始就所有權和身分做出決定，檢查點 1 則把第 1 部分串起來。Integration Architect 課程會深入設計合作夥伴的資料流。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”在這個階段，架構師並不是在決定目標架構。要決定的是對現狀的理解是否足以設計一個目標架構：
- 今天實際存在哪些系統、使用者群體、資料儲存和外部合作夥伴。
- 什麼資料跨越每一條重要的邊界，朝哪個方向，多頻繁，通過什麼機制。
- 運營、分析、流式、歷史和非結構化資料現在放在哪裡。
- 哪些資料流承載的資料量最大，值得儘早關注。
- 哪些缺口、手工步驟、孤立的系統、不清晰的權威和不一致的模式，要變成明確的設計問題。
這一章從一個想法開始：**在設計 org 之前先畫全景圖。**如果我從 Steve Trucking 的資料模型開始，我可能會在物件和關係上花好幾個小時，而與此同時，FleetLink 帶著每天 20 萬條讀數待在外面，RouteDesk 存著八年的歷史，三個合作夥伴說著三種語言，財務在用一份電子表格，每年十萬個案例在問貨到哪兒了。這些不是物件模型的問題，而是企業資料的問題。把難看的整合、那份電子表格、那個據說正在退役的系統都畫出來。寫下零的個數。走查每一個箭頭。然後你才準備好去改變它。
- Steve Trucking 的簡介，第 2–4 節，以及它的全景圖。