架構是權衡的藝術
另有 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 個模組，共 7 個，屬於 Data Architect 課程的第一章像資料架構師一樣思考。每個模組都可以單獨閱讀。 上一篇：可逆性測試 · 下一篇：為今天構建。為明天規劃。為失敗規劃。
**本模組回答的問題：**當好幾種方案都可能行得通時，架構師如何選擇，又如何解釋這個選擇？
如果架構只是找出正確答案，事情就簡單多了。學會平台，學會模式，學會限制，選出對的那個，完事。
真實的架構不是這樣運作的。艱難的決定通常不是在一個明顯好的方案和一個明顯壞的方案之間做選擇，而是在好幾個都可能行得通的方案之間做選擇，每個都有優點和缺點，每個都會把架構推向略微不同的方向。架構師正是在這裡贏得自己在會議桌上的一席之地。
解決問題的方法有很多
Section titled “解決問題的方法有很多 ”我在教架構師時，用過很多次這個例子的各種版本。
在 Salesforce 裡，解決一個問題可能有很多種方法。我有時會給它一個數字，比如十種，但那只是個比喻，不是實際數量。很多選項一開始就有問題：它們碰上了平台限制，漏掉了關鍵需求，或者帶來我們無法接受的安全或效能問題。這些可以很快放到一邊。另一些今天行得通，但在資料增長時會出問題。它們在技術上能用，卻撐不住我們已經知道即將到來的增長。
剩下的是少數幾個能支撐你未來需求的選項，事情從這裡開始變得有趣。它們中的每一個都可能行得通、能擴充套件、能滿足需求。那麼哪個是正確的？也許全都是。架構師的工作是理解它們之間的差別。
即便是挑選清單這樣簡單的東西，也是今天行得通、資料增長時可能出問題。挑選清單對使用者來說很方便。但要問一問這些值從哪裡來，最多會有多少個。挑選清單在大約 20 個值以內效果最好。偶爾我們會用到 50 個，比如美國各州，極少超過 100 個，比如國家，而那樣就已經很難用了。所以每個挑選清單都要知道它的上限。而且修改挑選清單的值是後設資料變更，不是資料變更。
改用查閱關係，使用者介面會稍微複雜一點。但清單可以無上限地持續增長，新值也可以通過整合進來。這是在與可用性做權衡。這就是平衡。
最優不等於完美
Section titled “最優不等於完美 ”我用最優這個詞是很謹慎的。最優的架構並不是每個單獨決定都完美的架構，那樣的架構多半不存在。最優的架構是整體方案達到平衡的架構。
假設方案 A 效能最好，但昂貴且難以維護。方案 B 成本更低、更容易運維，但犧牲了一些效能。方案 C 對未來更靈活，但今天就增加了複雜度。哪個是最優的？僅憑這些事實我無法回答。我需要了解業務、需求和優先順序，以及哪些約束是真實的，哪些只是偏好。架構取決於具體情境。這就是為什麼對一個客戶正確的模式，換到下一個客戶可能完全錯誤。
作為資料架構師，你的工作就是平衡這些決定。你會自己或者和團隊一起做出幾十個這樣的決定。要知道是哪些決定，也要知道某個決定什麼時候會在成本、時間或功能上產生更大的影響，需要上報給關鍵決策者。
次優的決定可以是最優架構的一部分
Section titled “次優的決定可以是最優架構的一部分 ”這是本章最重要的思想之一。有時我會有意在架構的某一部分做出次優的決定，因為它讓整個方案變得更好。
也許我會重複儲存少量資料，因為消除這種重複會帶來不必要的整合複雜度。也許我會選一個更簡單的資料模型，因為理論上更乾淨的那個會讓報表和日常使用難得多。也許我會接受一點效能損失，因為另一種做法會增加組織還沒準備好運維的基礎設施。
單獨看其中任何一個，你都會說它不是最優的。沒錯。但架構不是逐個最佳化每個元件，而是最佳化整個系統。區域性次優的決定可以是全域最優架構的一部分，只要我們理解自己在做的權衡。危險的是在不知情的情況下做出權衡。
知道你放棄了什麼
Section titled “知道你放棄了什麼 ”每當有人對我說「這是最好的方案」，我接下來的問題就是**「在什麼方面最好？」**最快？最便宜？最簡單？最能擴充套件、最安全、最靈活？最容易運維、交付最快、最不依賴專門技能？幾乎總有另一個維度上的答案不是「最好」。那就是權衡。我想知道我們得到了什麼，也想知道我們放棄了什麼。
拿處理一大批企業資料的兩個選項來說。一個是把資料複製到 Salesforce，這樣更容易使用 Salesforce 原生能力，但我們就要負責搬運它、儲存它、同步它、保護又一份副本，還要處理延遲。另一個是把資料留在原處，需要時再存取。我們消除了一些重複，但可用性、查詢效能、網路依賴和遠端系統的能力就變得更重要了。兩種描述都沒有告訴我們該選哪個，它們告訴我們的是該問哪些問題。
需求並非同等重要
Section titled “需求並非同等重要 ”權衡還迫使我們看清：並不是每項需求的分量都一樣。
有人說：「資料需要即時可用。」好的，即時是什麼意思？一秒、十秒、一分鐘？為什麼？也許是欺詐檢測，那裡每一秒都很關鍵。也許只是有人不喜歡等夜間載入。這是截然不同的需求，架構師會一直追問，直到我們知道手上是哪一種。
我喜歡經得起追問的需求：多少、多少個、多快、多頻繁、給誰用，以及如果做不到會怎樣？「快」不是架構需求。「95% 的客戶更新必須在 30 秒內對服務人員可見」就接近得多了。現在我們可以評估權衡了。
約束會改變答案
Section titled “約束會改變答案 ”有時架構根本不受技術的約束，而是受金錢、人手、時間、許可或組織成熟度的約束。
一個技術上出色、卻需要公司並不具備的運維團隊的架構，不是好架構。一項能優雅解決問題、卻需要客戶不願購買的許可的能力，也不是解決方案。而完美的三年轉型計劃，幫不了一家八週後就必須上線的公司。
這些都不意味著我們因為截止日期就放棄好的架構。它意味著我們要理解自己在妥協什麼、為什麼妥協、接受哪些後果，最好還知道如何從今天的妥協走到明天的架構。
架構師心裡要有一幅「最優」的圖景
Section titled “架構師心裡要有一幅「最優」的圖景 ”這裡有一種有意思的張力。我一邊告訴你通常沒有唯一完美的答案，一邊又希望你在腦子裡裝著一幅最優方案的圖景。兩者並不矛盾。你需要一個參照點。
看一個數據模型時，我想知道：如果能在沒有不必要約束的情況下針對需求做最佳化，我會構建什麼。然後，當真實的約束把我們推離那個設計時（我們把模型的一部分做扁平、重複一些資料、推遲某個整合、接受一個臨時的手工流程），我不是在隨意妥協。我知道自己正朝哪個方向偏離最優，以及為什麼。這就是架構的藝術，而這種直覺需要練習。
把它畫出來
Section titled “把它畫出來 ”理解一個權衡最好的方法之一，就是把它畫出來。架構圖不是幻燈片上的裝飾，而是思考的工具。如果要在兩種做法之間做選擇，就把兩種都畫出來。資料在哪裡，往哪裡流動？誰擁有它？邊界在哪裡，在哪裡執行安全？出故障時會發生什麼，資料量增長時什麼會變化？
圖會把模糊之處逼到明處，也給每個人一張可以共同指著討論的圖。
我是在一家公用事業公司的專案上體會到這有多重要的。一次又一次評審，我發現自己總在重新解釋同樣的概念，把討論拉回最初的設計。於是我改變了開會的方式：每次評審一開始，螢幕上都先放資料模型。不是包含每個欄位的詳細模型，而是一個概要模型：一個客戶有若干連絡人，這條記錄有子記錄，工作掛在這裡。會議室裡大多是高管，這隻用了幾分鐘。
因為每次開會都是同一批人，這張圖成了我們的共同語言。大家開始用圖上的名字。重複的問題少了，會議也順利多了。我把它叫作讓會議落地：一張簡單的圖，每次都展示，它帶來的價值遠遠超過製作它的成本。
目標不是藝術上的完美。有時是給工程師看的詳細圖，有時是給高管看的五個方框六個箭頭。目標是清晰。
好的架構師會按順序擺出來：這是我們考慮過的選項，這是每個選項帶給我們的，這是每個選項的代價，這是我推薦的選項，這是原因。
注意，推薦是放在權衡之後的。我不希望架構變成「我以前做過，相信我」。經驗極其重要，它幫你更快地識別模式、更早地發現問題。但你的經驗應該讓推理更好，而不是取代推理。我們的工作不只是理解架構，還要幫助組織理解這個決定，尤其是當最後拍板的人不是架構師的時候。
Think Correct. Think Fast.
Section titled “Think Correct. Think Fast.”你不會總有三週時間去分析每個選項。有時你只有三分鐘。會上某項需求變了，有人提出一個你不知道的約束，或者某位高管問：「如果明年我們在歐洲也需要這個呢？」
我一直用一句話：Think Correct. Think Fast.（想得對，想得快。）速度不是來自跳過思考，而是來自在那一刻到來之前已經做了足夠的思考：你學過各種模式，瞭解平台，見過失敗，知道該問哪些問題，知道哪些決定難以逆轉。這就是為什麼我們在整門課裡都會演練各種場景。你分析過的決定越多，就越快認出下一個決定的樣子。
我有一個客戶需要表單錄入。但表單很多，問題還會隨時間變化。我很快意識到需要一個調查問卷資料模型，這個模式我們在課程後面還會講到。因為我認出了這個模式和解決方案，我才能帶來一個更完整的資料模型，它能應對尚未到來的需求，而不只是眼前的那些。
架構關乎平衡
Section titled “架構關乎平衡 ”隨著我們深入資料架構，你會遇到一些選擇，我會刻意不給你簡單的規則。規範化還是扁平化？複製資料還是聯邦存取？同步還是非同步？標準物件還是自訂物件？歸檔還是保持線上？
有原則、有模式、有限制，有時也有明顯錯誤的答案。但很多時候，架構師的工作是為這個系統、這項業務、這個時刻找到恰當的平衡。
知道最優是什麼樣子。理解約束。找出可行的選項。讓權衡看得見。然後做出決定。
這不是優柔寡斷。這就是架構。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”- 哪些選項可行，哪些現在就錯了或者一年後會變糟。
- 每個可行選項得到什麼、放棄什麼，以經得起追問的需求來衡量。
- 哪些約束是真實的，哪些只是偏好。
- 在擺出權衡之後推薦哪個選項，以及如何解釋它。