反思架構師應該如何思考和決策

作者 | Gregor Hohpe

譯者 | 張衛濱

策劃 | 丁曉昀

核心要點

架構師並不是團隊中最聰明的人，他們是讓其他人更聰明的人。架構師是智商的放大器。

乘坐架構師電梯意味着要連接樓頂和機房，現代架構師的價值是以他們能夠覆蓋多少個樓層來衡量的。

使用隱喻可以讓觀衆更容易地進入思考。如果不邀請聽衆，那就是沒有充分利用思維資源。

最強大的模型是最簡單的。好的模型可以實現簡化和抽象，提供清晰性，而不是造成困惑。

架構師要看到更多的維度：通過擴展問題和解決方案域，架構師能夠讓其他人更聰明地解決問題。

在 QCon London 2024 上，“《軟件架構師電梯》（The Software Architect Elevator）”一書的作者 Gregor Hohpe 做了題爲“像架構師一樣思考”的演講。本文整理了他的演講內容，他首先闡述了架構師的角色和連接層次（connecting level）的概念。

隨後，演講深入介紹了隱喻的重要性，它會使複雜的技術概念更加易於理解，並瞭解了利用模型做出更好的決策的優勢。同時，我們還描述了從不同的角度處理問題、看到更多維度以及克服限制因素的重要性。

架構師的角色

架構師並不是由職稱所定義的，它涉及各種視角和維度。有些架構師並不一定會在他們的名片上印上“架構師”的字樣，而那些擁有“架構師”頭銜的人也不一定都是優秀的。架構師更多的是一種思維方式和生活方式。

不同的組織對架構師的角色會有不同的看法。有些組織的運營可能沒有正式指定的架構師，但是依然能夠維持一致的架構。

需要明確，架構師的含義是複雜和多方面的。我們可以從不同的角度來思考架構師的作用，這對我們的工作很有助益。

架構會讓其他人變得更聰明

關於架構師有一個最大的誤解，那就是他們是最終的決策者，他們通常更爲年長、收入更高，似乎也比其他人更聰明。但是，由一個人做出所有的重要決策是不現實的，因爲沒有一個人能夠比所有人聯合起來還要聰明。

架構師不能成爲整個屋子裡最聰明的人，並對別人發號施令。他們的角色是幫助其他人做出更好的決策，例如，從不同的角度看待問題、更好地理解權衡或者考慮更多的可選方案。這就是架構師作爲團隊的智商放大器所起到的作用：他們能夠讓其他人變得更聰明。

架構師連接各個層級

“《軟件架構師電梯》”一書討論了架構師在連接組織中不同層級的過程中的作用，並引出了哪個架構師對組織最有價值的問題。儘管有些人會認爲首席架構師的價值最大，但是也有一些人認爲是那些親自動手實現解決方案的人。然而，在組織內部連接不同層級的架構師的重要性是不言而喻的。

首席架構師負責創建圖表，如果這些圖表脫離現實，那麼他們的價值就會大打折扣。與之類似，經驗豐富的開發人員的工作必須與組織更廣泛的成就建立關聯。這裡的關鍵不在於開發人員所處的層次，而在於他們如何高效地駕馭和連接不同的層次。架構師電梯的概念強調了在不同的層級之間移動的重要性。

由於勞動分工、法律因素和結構化等級的原因，組織通常會劃分爲不同的層級，這往往會引發一些問題。位於“頂層”的領導層認爲 IT 部門的一切工作都非常出色，並對區塊鏈和 GenAI 技術誇誇其談。與此同時，坐在工位上的開發人員卻享受着自由的感覺，因爲管理層並不瞭解他們的實際工作。中層管理人員爲這種脫節的現象提供了便利，這個隔離層創建了一個鬆耦合的架構，但是在這種情況下，這並不是一件好事兒！

圖 1：樓層過多的危險

這種脫節的危險性顯而易見，因爲項目與戰略目標並不一致，戰略家已經脫離了現實。最有價值的架構師就是那些能夠彌合這個鴻溝的人。

如今，高速變化的環境需要我們識別出組織和技術之間的相似性。在與高層管理人員交流時，架構師應該避免過度簡化，因爲高層管理人員是知識淵博的領導者，儘管他們可能不瞭解像 Helm Charts 這樣的技術細節，但是我們鼓勵架構師提供有意義的細節信息，以幫助領導者做出更好的決策。架構師電梯理念的提出是爲了統一組織中各個層級的理解，而不是自說自話。

儘管討論高水平的自動化、雲基礎設施和 DevOps 這樣的話題會讓技術團隊興奮不已，但是 CIO 和 IT 主管更關心的是避免安全漏洞、確保高可用性和維持成本收益。Hohpe 概述瞭如何彌合這些差異：技術創新直接解決了 CIO 層級的優先事項，但是架構師要乘坐電梯將位於不同層級的點聯繫起來。例如，自動化可以確保一致的補丁級別，這進而又提高了安全性。

使用隱喻

架構師有一個連接這些點的強大工具，也就是隱喻。選擇與行業相關的隱喻，比如，當在金融服務業工作時，使用金融相關的隱喻可以使複雜的技術概念更加貼近現實，從而吸引領導者參與決策。隱喻有助於消除隔閡，建立信任，而不要使用高深的技術術語去轟炸他們。這樣就能讓領導者參與深思熟慮的決策，而不是簡單地去尋去他們的批准。使用隱喻可以讓他們參與決策過程。

圖 2：跨層連接不同的點

類似的，在與關注成本效益的管理者討論交付速度時，提到頻繁發佈軟件可能會讓他們覺得不安。對他們來說，速度可以意味着忙中出錯。爲了消除這種隔閡，架構師應該闡明延遲成本的概念：部署延遲六個月可能會造成數百萬的損失。這種方式將時間轉換成了貨幣，克服了他們的心理障礙，更有助於理解。

架構師使用模型做出更好的決策

我們所處的世界並不簡單。如今，我們所構建的應用之所以這麼複雜，是因爲它們是基於分佈式系統、事件驅動架構、異步處理或橫向擴展和自動擴展等能力的。雖然這些功能看上去非常高端，但是它們卻增加了複雜性。

模型是架構師應對複雜性的最佳工具。模型的強大之處就在於它塑造了人們的思維方式。Dave Farley 用一個例子闡明瞭這一點：很久以前，人們認爲地球位於宇宙的中心，這種觀點會讓人覺得行星的運動是不穩定的，而且非常複雜。真正的問題不是行星的運動，而是採用了不正確的模型。當你把太陽放到太陽系的中心時，一切就變得合理了。

當架構師向不同領域的人解釋問題時，可能會認爲別人不理解他，但實際上是因爲他們使用了不同的心智模型。

George Box 有一句名言：“所有的模型都是錯誤的，但有些模型是有用的”。但是，我們經常忽略了這句話的後半部分：

在架構中，圖表和複雜的產出物（如數據庫模式和系統架構）是很常見的。不過，這些模型並不一定總能提供太多的抽象性。最強大的模型就是最簡單的模型。好的模型可以簡化和抽象，提供清晰度，而不是帶來混亂。

當有人說，“但是，這個模型並不完全符合現實”的時候，我們的回答應該是這樣的：“模型本來就不是完全符合現實，它只是一個模型。它能夠讓我們的思維更清晰，讓我們更聰明，幫助我們做出更好的決策。它能提高我們的智商”。當架構師試圖捕獲現實中的每個細節時，他們就陷入了 George Box 所說的過於複雜的陷阱了。

我們該如何簡化模型呢？以地球爲例，我們有四個不同的模型。哪一個是最好的呢？它們都很好，這取決於問題是什麼。

圖 3：最好的模型是由問題決定的

模型只有在能夠幫助我們回答問題時纔有其價值。需要徒步？那請使用地形圖。想要參加選舉？那請使用政治地圖。想以最快的速度從 A 到達 B？請使用路線圖。想了解物流密度？請使用人口地圖。不同的問題需要使用不同的地圖。當被問到，“給我看一下架構”的時候，你應該反問，“你的問題是什麼？”——不同的問題需要不同的模型。

架構師能夠看到更多的維度

架構師可以從多個維度看問題，從而讓其他人更加聰明。通過擴展問題和解決方案空間，架構師可以讓其他人更聰明地處理問題。通常，當雙方從不同的角度看待問題時，就會產生分歧，這就像下圖這樣圍繞正方形和三角形爭論不休，毫無進展。

圖 4：架構師能夠看到更多的維度

架構師可以引入第三個維度，向大家展示對象其實是一個金字塔結構。例如，當團隊在加快交付速度和保持質量之間爭論不休時，架構師可以提出自動化測試或提前集成測試的方案，從而提升集體解決問題的能力，跳出非此即彼的辯論。

在 IT 戰略領域，許多領導者都在面臨“左右爲難”的困境。一方面是標準化和降低成本以實現統一和規模經濟的壓力，但這會限制靈活性，因爲開發人員可能更喜歡其他創新性的解決方案。另一方面，企業需要敏捷性和創新性來保持競爭力。這就形成了一種線性、不和諧的現象，雙方都不滿意。架構師如果能夠識別出更多的維度，那麼就可以更有效地應對這些挑戰。

平臺可以實現協調和標準化，但不會扼殺創新，反而能夠促進創新。這一概念已經不再侷限於 IT 領域，而是延伸到了其他行業，比如，20 世紀 70 年代大衆汽車採用平臺模式時的汽車製造業。通過在一個通用平臺上實現底層工程的標準化，他們能夠通過多種模型實現車型的多樣化和創新。這種方式不僅沒有減少多樣性，反而大大增加了汽車的品種。寶馬從最初的三種車型發展到瞭如今的 30 多種車型。

擺脫單向思維至關重要：汽車公司通過平臺標準化擴展了產品多樣性，軟件架構師也應如此。通過採用多維方式，可以在質量和速度之間取得平衡，並通過平臺實現標準化和創新。對於尋求效率和創造力最大化的架構師來說，擺脫這種二元選擇的思維方式非常重要。

圖 5：克服制約因素

另外一個增加思考維度的樣例就是供應商鎖定和切換成本的問題，這是雲供應商之間不太受歡迎的話題。通常情況下，對話會圍繞在不同的雲供應商之間切換工作負載所面臨的挑戰而展開，這在傳統上會被視爲一個單向思維的問題：決策通常會在兩害相權之間做出選擇，而無法找到一箇中間點。更好的方式是在討論中引入更多的維度。

例如，供應商鎖定和切換成本可以視爲潛在的負債，考慮到這種遷移的概率和規模，可以對成本進行量化。另一方面，無服務器架構和託管服務所帶來的好處也能降低運營的複雜性。

通過考慮收益與切換的成本，可以更有效地權衡利弊，提供決策模型，而不是直接給出答案。這種方式可以讓客戶更好地瞭解其獨特的限制因素和目標，使他們能夠做出明智的決策。

客戶說：我被鎖定了。這聽上去是一個非此即彼的狀態：要麼被鎖定，要麼沒有被鎖定。但實際上並非如此，這應該是一個可高可低的成本問題，它有不同的維度。

圖 6：鎖定的多個維度

鎖定不僅侷限於切換供應商。AWS 在其託管的 Kubernetes 服務上 EKS 上提供了擴展版本的支持。作爲一名架構師，你希望每個人都使用最新版本，對吧？那爲什麼需要這樣的服務呢？答案很簡單：版本升級也是有成本的，由於切換成本的原因，你會被鎖定到開源項目的某個特定版本上。架構師應該瞭解這些細微的差別，並考慮如何升級能夠更具成本效益。

架構師兜售的是選擇

很多人認爲多樣性和協調性是相互對立的。試想，開發人員對編程語言有不同的偏好。爲了協調這些偏好，作爲 IT 和軟件架構師，我們使用像 OAuth 和 JSON 這樣的協議創建標準 API 和接口。這種方式在微服務架構中很常見。

這裡的關鍵在於，要將特定的元素標準化，如接口、授權協議、傳輸方法和數據表述格式。通過鎖定這些元素，架構師犧牲了一些選擇，卻獲得了另外一些選擇，從而能夠使開發人員使用各種語言進行編碼。Hohpe 強調了協調性和靈活性之間的平衡，以便於同時實現創新和標準化。

圖 7：放棄某些選擇，從而獲取另外的一些選擇

爲了解釋這種權衡，我們可以使用一些隱喻，尤其是來自金融領域的隱喻。將某些元素標準化以實現多樣性類似於期權交易：軟件從業人員放棄了一些選擇，但是獲得了另外一些選擇。這些選擇，比如使用不同的編程語言、將工作負載轉移至另外的供應商、擴展系統和添加硬件容量，都是非常有價值的。

對於金融從業者來說，這個概念就像 Kubernetes 和 Helm Charts 對於 IT 專業人員一樣清晰。期權定價（Black-Scholes 模型曾獲得諾貝爾獎）表明，擁有期權總是有價值的。推遲決策，例如以後再利用雲的彈性基礎設施和擴展架構來增加容量，就是一種有價值的選擇。

該公式的一個重要啓示涉及到易變性：隨着不可預測性的增加，期權會變得更有價值。例如，如果用戶數量穩定，就不需要彈性硬件。相反，如果在用戶數量不確定的情況下推出移動應用或電子商務站點，那麼擴展相關的選擇就變得至關重要。不確定性越大，選擇就越有價值。這個比喻說明，在架構領域，就像在金融領域一樣，不確定性會增加選擇的價值。使用這樣的隱喻可以使複雜的想法更加清晰，更有說服力。

敏捷架構：是友非敵

架構和敏捷方法論都是在處理不確定性和易變性的基礎上發展起來的。如果一切都是可預測的、一成不變的，那麼就不需要敏捷性了。敏捷在變化中不斷成長起來，就像架構一樣：它們都能應對不確定性，是互相補充的。用汽車來類比的話，敏捷就是方向盤，用來指引方向，而架構則是發動機，確保汽車能夠動起來。兩者缺一不可，相互配合。在不斷變化的世界中，要想取得成功，兩者均不可或缺。架構和敏捷是盟友。

結 論

在本文中，我們深入探討了軟件架構師的角色，反思了架構師是如何思考和決策的。我們討論了架構師是誰以及要做什麼的話題，重點闡述了使用模型和隱喻找到合適抽象的重要性。

我們還討論了架構師作爲智商放大器的概念，以及理解權衡和駕馭不同選擇的重要性。

作者介紹

Gregor Hohpe 負責幫助技術領導者轉型他們的組織和技術平臺。你會發現他不斷乘坐架構師電梯在機房到頂樓之間穿梭，也許上午他在設計自動化無服務器的解決方案，下午又在準備董事會的報告。Gregor 曾擔任 AWS 和 Google Cloud 的 CTO 辦公室負責人、新加坡政府的智能國家研究員以及 Allianz SE 的首席架構師。在 Allianz SE，他負責全球數據中心的整合架構，並部署了首個私有云的軟件交付平臺。Gregor 是開創性著作《企業級集成模式》（Enterprise Integration Patterns）的合著者，該書爲所有現代 ESB 提供了參考。他的著作《軟件架構師電梯》講述了來自一線的 IT 轉型的故事。

Thinking Like an Architect (https://www.infoq.com/articles/thinking-like-architect/)

聲明：本文爲 InfoQ 翻譯，未經許可禁止轉載。