像架構師一樣思考
另有 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 個模組，共 7 個，屬於 Data Architect 課程的第一章像資料架構師一樣思考。每個模組都可以單獨閱讀。 上一篇：本章概覽 · 下一篇：資料模型是骨架
**本模組回答的問題：**構建和做架構有什麼區別？架構師到底做什麼？
在我職業生涯的大部分時間裡，我都是一個構建者。
我從開發人員起步。在轉向 Salesforce 之前，我用 Java 和 .NET 工作，這些年來我一直在設計系統、寫程式碼、整合平台、教架構師、評審架構。
但我一路上學到的最重要的一課是：做一個出色的構建者和做一個出色的架構師，並不總是同一回事。
構建者會問：
我該怎麼構建它？
架構師則必須問另一組問題：
我們該不該構建它？
我們為什麼要這樣構建？
還有哪些替代方案？
當它變大時會發生什麼？
當它出故障時會發生什麼？
我們今天做的哪個決定，會讓我們三年後後悔當初沒有多想想？
我記得參與過一個零售企業的專案，業務裡有預約。我問：每家門店每天有多少預約？接著問：你們有多少家門店？每週營業幾天？我很快意識到，光是第一年我們就會有幾百萬條預約。這些就是架構師在專案開始時要問的問題。
這種思維上的轉變，才是這門課真正要講的東西。
手握藍圖的人
Section titled “手握藍圖的人 ”我在教架構師時用過很多次這個類比。
想像一個建築工地。有人在澆混凝土，有人在布電線、裝水管、搭牆架，還有幾十種其他專門的工作。他們都必須非常擅長自己的活兒。
但也得有人手握藍圖。
這個人需要理解所有這些部分如何組合在一起。他們需要發現，專案某一部分正在發生的事情，什麼時候會在別處造成問題。
這就是架構。
在技術領域，我們有時會誤以為架構師就是懂得最多的那個人。其實不是這樣。瞭解平台很重要，你需要技術深度。但架構不是知識競賽。
架構師的工作是：做出好的決定（有時是在資訊不完整、需求相互衝突的情況下），並理解這些決定的後果。
這是一種完全不同的技能。
不要照單全收需求
Section titled “不要照單全收需求 ”我希望架構師最先養成的習慣之一很簡單：
多問為什麼。
有人告訴你：
我們需要再加一個物件。
為什麼？
我們需要把這個欄位複製到客戶上。
為什麼？
我們需要把所有這些資料都存到 Salesforce 裡。
為什麼？
這不是故意刁難，而是要理解真正的業務需求，而不是立刻去實現別人提出的解決方案。
需求常常偽裝成設計出現。
「我們需要一個新的自訂物件」不一定是需求。真正的需求可能是「我們需要單獨追蹤這些資訊」。這兩者不是一回事。
一旦理解了真正的需求，你就可以開始探索替代方案。也許新物件正是正確答案。也許這些資訊屬於某個已經存在的地方。也許 Salesforce 根本就不該擁有這些資料。
架構師必須把業務需要什麼和一種提議的實現方式區分開。
我們當時在做一個銷售應用，客戶有多級審批，每級都有一個審批人和一個日期。他們最初的要求是在商機上加審批人 2 和審批人 3 欄位，各帶一個日期。深入瞭解之後，我們發現審批可能不止兩三級。於是我們把審批移到了一個子物件裡。請求是加更多欄位；需求是追蹤每一次審批，不管最後有多少次。
超越需求去思考
Section titled “超越需求去思考 ”多問為什麼會帶出兩個習慣，本章後面各有一個模組專門講。
答案通常不止一個。Salesforce 給了我們很多解決問題的方法，其中有些幾乎馬上就能看出是錯的。在行得通的方法之間做選擇，就是權衡的藝術（模組 4）。
而別人交給你的需求，並不是你的全部需求。沒有人會說「確保夜間載入只成功一半時也能正常工作」，但這仍然是一項需求。我用三個視角審視每個設計：為今天構建，為明天規劃，為失敗規劃（模組 5）。
想想請建築師設計一棟樓的人。他們不會要求裝火災報警器或噴淋系統，也不會要求樓在地震中不倒。他們預設這是工作的一部分，無需開口。我們的世界也是一樣。沒有人會要求優雅的錯誤處理、日誌，或者出故障時的恢復手段。哪些系統應該放進設計裡，並把它們放進去，這是架構師的事。
讓你的推理看得見
Section titled “讓你的推理看得見 ”架構師不應該只是走進會議室宣佈：「我們就這麼做。」
你的工作還包括解釋為什麼。我希望利益相關方理解我們考慮過的替代方案和其中的權衡。這不是說要給高管一份 40 頁的設計文件，而是能把同一個架構分別講給開發人員、業務方和高管聽：圍繞同一個決定的不同對話。
做到這一點的方法，是清晰的藍圖和說明，就像建築工地上手握藍圖的人。對資料架構師來說，最重要的藍圖之一就是資料模型。
如果沒有人明白一個決定為什麼這樣做，那麼很可能遲早會有人把它推翻。而且他們這樣做可能有完全合理的理由，因為從來沒有人解釋過最初的決定。
架構師不需要親手構建一切
Section titled “架構師不需要親手構建一切 ”還有一個轉變可能很難，尤其是對那些從開發轉向架構的人來說。
你不必親手構建所有東西。
我仍然喜歡在非常技術的層面理解事物是怎麼運作的，這個基礎很重要。但作為架構師，你的責任會大於你自己的實現。你不必親手構建一切；你需要知道如何給真正做構建的人正確的方向和正確的引數。這意味著你要懂得足夠多，才能指導他們的工作，才能識別出某個提議的實現什麼時候會造成架構問題，才能在細節和全域之間來回切換。
有時這意味著深入研究一個查詢、一個 API 或一個數據模型。
有時則意味著退後一步，問一問我們到底該不該做這些事。
而且，做構建的越來越不只是人。有了 AI，架構師可能直接和生成物件、程式碼和介面的工具一起工作。這時，方向、引數和準則是交給 AI 的，而把它們給好，也越來越成為架構師的責任。我們會在模組 7再回到這一點。
這是從構建者到架構師之路的一部分。
你的工作是做決定
Section titled “你的工作是做決定 ”歸根結底，架構就是關於決定。
有些決定很容易改，有些則不然。
頁面配置可以改，標籤可以重新命名。
但如果選錯了基礎資料模型，釋出了幾十個系統開始依賴的識別符號，或者把關鍵資料的主副本放錯了地方，那麼改主意的代價就會高得多。
這些都是架構決定。而這門課集中討論的，正是這類決定。
作為資料架構師，你要決定資訊如何組織、放在哪裡、如何增長、如何流動、誰能存取，以及企業的其他部分如何理解它。
技術很重要。
但瞭解每一個 Salesforce 功能並不是目標。
目標是培養判斷力，知道該用哪個工具、什麼時候用、你放棄了什麼，以及接下來會發生什麼。
這就是像架構師一樣思考。
現在，我們可以開始像資料架構師一樣思考了。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”- 一個請求是真正的需求，還是針對需求提出的一種設計。
- 在構建任何東西之前要問哪些問題：該不該做，為什麼這樣做，還能怎麼做，當它增長或出故障時會發生什麼。
- 哪些決定由架構師來做，哪些屬於做構建的人；以及要給構建者（無論是人還是 AI）什麼樣的方向和引數。
- 如何解釋一個決定，讓開發人員、業務方和高管都能理解。