是企業的負擔還是救星
在企業IT環境裏，架構師的工作既令人興奮，又富有挑戰性。很多管理人員和技術人員都認爲架構師拿的報酬太高，認爲他們活在象牙塔裏，脫離實際，只知道用幻燈片和大幅海報來把自己的想法強加給公司裏的其他人。此外，他們還會追求一些無關緊要的理想，從而導致做出糟糕的決策，使項目無法按時間表進行。
儘管如此，IT架構師近年來卻變成最炙手可熱的IT專業人士之一，因爲傳統企業迫於壓力，需要將企業IT部門從單純的成本中心轉變爲業務驅動者。這是個好消息，但企業對架構師的期望很高：他們希望架構師能在上午解決突發的性能問題，下午還能繼續推動企業文化的轉型。與此形成鮮明對比的是，很多數字化企業巨頭擁有世界級的軟件和系統架構，但根本沒有架構師。IT架構師的時日屈指可數了嗎？
架構師不是什麼
有時候，和明確定義某個事物是什麼相比，定義它不是什麼更容易。通過這個方法，我發現架構師經常扮演下面4種角色，而這些角色要做的事情根本就不是架構師的職責。
消防員：很多管理人員都期望，架構師能隨時分析並解決任何突發的危機，因爲他們對當前系統有足夠全面的瞭解。然而，架構師不應該無視產品的問題，因爲這些問題很可能反映出架構上的設計缺陷。但是時刻都在忙着“救火”的架構師根本就沒有時間去做真正的架構。架構設計需要思考，只給30分鐘肯定無法完成。
資深開發人員：開發人員常常覺得他們需要把架構師這個角色作爲其職業生涯（和薪資水平）的下一個目標。但是，成爲架構師和成爲明星工程師完全是兩條不同的路線，兩者沒有高低之分。架構師需要有更廣的知識面，包括組織和戰略方面的能力，工程師則需要專攻可運行軟件的交付。理想情況下，大型組織的首席IT架構師和資深開發人員的關係都很好。
項目經理：架構師必須能夠並行處理多個不同但相關的主題，他們在做決策時也需要考慮項目時間表、人員配備以及所需技能。因此，上層管理者經常會通過架構師獲取有關項目的信息和決策，尤其是在項目經理忙於準備項目狀態報告模板的時候。這會讓架構師陷於更糟糕的境地，因爲雖然爲管理層提供項目信息和決策也是有價值的工作，但它畢竟不是架構師的主要職責。
科學家：架構師要才思敏捷，要能夠從系統和模型的角度進行思考，還需要爲具體項目和業務計劃制定決策。這常常將首席架構師的角色與首席科學家的角色區分開來，儘管這兩個角色的界限很模糊——我知道一些首席科學家就是喜歡親力親爲。我個人更喜歡首席工程師這個頭銜，它強調了架構師除了撰寫文檔外還需要做其他事情。最後，科學家常常把事物理論化和複雜化，而架構師的工作則是化繁爲簡。
衡量架構師的價值
曾經有人問我用什麼關鍵業績指標（KPI）來衡量自己作爲架構師的價值。他們覺得應該是做出決策的數量。這個提議讓我有些驚訝，我確信這不是我要尋求的KPI。做出決策固然重要，但必須要避免做出不可逆的重大決策，在這一點上我十分認同Martin Fowler的觀點：“架構師最重要的任務之一就是消除軟件設計中那些不可逆的決策。”
在別人問我作爲架構師的價值時，我有兩個“標準”答案。首先，我會解釋說，如果我們的系統在5年後還能良好運行，並且依然可以承受合理水平的變更，那麼我的工作就做得很好。如果大家希望我更具體地描述一下我的工作，我會解釋說企業裏資深架構師的工作分爲以下3個層面。
-
定義IT戰略，比如，定義系統（無論是打算自己構建還是從外部購買）的必要IT特性，或者識別爲了支撐業務戰略還需要補充到現有IT配置組合中的組件。戰略也包括“退休”系統（電影《銀翼殺手》中的特色詞語）以免你被殭屍系統包圍。
-
落實對IT藍圖的管控，以實現協調一致，降低複雜度，以及確保所有系統集成爲一個有效整體。架構評審委員會需要自始至終擔起管控的責任。
-
腳踏實地地關注項目的實際情況，從實際項目實施中獲得有關決策的反饋。否則，控制依然是假象。
架構師是變革促進者
架構師是大型企業IT轉型中至關重要的一員。爲此，他們必須具備一系列特殊的技能：
- 能夠通過乘坐架構師電梯上下，與組織中的不同層級合作；
- 具備著名電影角色的一些特點，儘管有不止一種角色模型；
- 明白自己在企業中的位置；
- 具備專業技能，但這只是架構師立足的“三條腿”之一；
- 是優秀的決策者；
- 刨根問底以找到問題的根源。
1.1 架構師電梯
在頂層套間和發動機房之間往返
高樓需要乘坐電梯上下
1.1.1 缺失的一環
架構師所扮演的承上啓下的角色非常關鍵，尤其是在大型組織裏，部門之間業務語言不同、觀點不同、目標不同甚至衝突。而很多管理層在企業內部的溝通中還大玩“電話遊戲”1，讓溝通問題變得更加嚴重。最糟糕的情況是，掌握相關信息或專業技能的人沒有權力做出決策，而決策者卻缺乏相關信息。這對於企業IT部門來說不是個好兆頭，特別是在當前這個技術已經成爲大多數業務驅動力的時代。
1 電話遊戲裏，小孩們圍成一圈，逐個向下傳遞從上個小朋友聽到的消息。當消息返回第一個說出消息的小孩時，他們會發現消息在傳遞一圈後完全改變了。
1.1.2 架構師電梯
在大型企業裏，架構師能填補一項重要的空白：他們既能在項目上和技術人員密切地工作和溝通，也能在不丟失信息本意的前提下，向上層管理者傳達和解釋技術主題。換句話說，架構師能理解公司的經營戰略，並且能將其轉化爲技術決策。
如果把組織內的不同層級看作大樓的不同樓層，架構師就能乘坐我所說的架構師電梯：在大型企業裏，他們搭乘這種電梯，在董事會會議室和負責構建軟件的發動機房（工程師團隊）之間往返。在IT快速變革和數字化顛覆的時代，這種不同層級之間的直接聯繫已經變得前所未有地重要了。
我們再用大型船舶的場景做個比喻。大家都知道，如果油輪上的艦橋發現了障礙物，爲了調轉船頭，遊輪需要反轉發動機並且盡力向右轉舵。但是，如果所有發動機實際上都在全速向前運轉，災難遲早會發生。這就是爲什麼老舊的蒸汽船也會有一個直接連接船長室和鍋爐房的管道，這樣船長就能直接發號施令並得到及時反饋。在大型企業裏，架構師就必須扮演這個管道的角色。
1.1.3 有些組織的層級比其他組織要多
回到樓層的比喻上，架構師搭乘電梯上下幾層樓取決於組織的類型。扁平的組織結構可能根本不需要電梯，只需幾階樓梯即可。這也意味着架構師這個上下溝通的角色不是很重要了：如果管理層能敏銳地瞭解必要的技術實現細節，並且技術人員能與高層管理者直接溝通，就不需要那麼多的“企業”架構師了。可以說，數字化公司就像是一座單層平房，壓根就不需要電梯。
然而，大型組織裏，典型的IT部門之上往往有很多樓層。他們位於高聳的摩天大樓裏，因此，單部架構師電梯可能無法直達所有樓層。這種情況下，技術架構師和企業架構師可以在中間的樓層會面，各自覆蓋“一半”樓層。這種場景裏，架構師的價值不應該按照他訪問的樓層高度來衡量，而應該根據他們覆蓋的樓層數目衡量。大型組織中，一個常見的錯誤是，住在頂層豪華套間裏的管理者只看見並重視位於樓層上半部分的架構師。相反，很多開發人員或者技術架構師都認爲所謂的“企業”架構師沒多大作用，因爲他們壓根就不寫代碼。在某些情況下，這可能是真的，這樣的架構師往往很享受在上半部分樓層的愜意生活，因此沒有意願再搭乘電梯前往下半部分樓層。但是，經常前往下半部分樓層和技術架構師分享戰略願景的“企業”架構師還是有重要價值的。
1.1.4 不是單行道
你肯定會遇到搭乘電梯到頂層後就再沒下來的傢伙。他們非常享受從頂層豪華套間往下看的美景，而且覺得自己辛苦工作不是爲了繼續去髒兮兮的發動機房。你經常會聽到這些傢伙說：“我過去可是搞技術的。”聽到他們這樣說，我會情不自禁地反駁：“我曾經還是經理呢！”（這是事實）或者“你們爲什麼不接着做了呢？是不是做得不好？”如果你想反駁得更委婉一些（並且更富有深度），可以參考Fritz Lang的電影《大都會》。在這部電影裏，頂層豪華套間和發動機房之間的隔閡幾乎徹底地毀滅了整個城市，後來人們才認識到“頭和手之間需要一個調停者”。任何情況下，電梯都是用來在樓層間上下往返的。頂層人士享受着山珍海味，而底層勞動者卻奄奄一息，這顯然不是企業IT轉型的正確方式。
乘坐電梯上下對架構師而言也是一個很重要的機制，他們可以獲取別人對決策的反饋，並理解這些決策的實現結果。過長的項目實現週期無法提供好的學習循環，會導致出現架構師的夙願，開發者的夢魘這樣的場景。允許架構師只在高層享受美好風光，一定會導致有權無責，這是一種遭人唾棄的反模式。只有架構師必須承受或至少觀察他們決策的後果，才能打破這種模式。爲此，他們必須不斷地搭乘電梯上下奔波。
1.1.5 高速電梯
過去，IT決策和經營戰略幾乎沒有關係：IT只被看作附加品，它的主要參數（或KPI）是成本。因此，由於新信息稀少，搭乘電梯上下並不是很關鍵。但是，如今的業務目標和技術選擇之間的聯繫已經變得越來越直接了，即使對“傳統”的業務也一樣。比如，想要通過更快地將產品投放市場來應對競爭壓力，就需要靈活的雲計算方式，而這又需要支持橫向擴展的無狀態應用程序。要獲得客戶渠道相關的內容，就需要分析模型，而優化模型則需要通過Hadoop集羣收集大量的數據，但是Hadoop適合使用本地磁盤存儲而不是共享的網絡存儲。用一兩句話，就將業務需求轉換成了應用程序和基礎設施設計，這一事實凸顯了架構師搭乘電梯上下溝通的必要性。而且，他們必須搭乘更快的電梯，這樣纔可以跟上業務和IT交織發展的節奏。
在傳統的IT部門，較低的樓層可以僅供外部顧問使用，這樣企業架構師就不必處理方案具體落地的事宜。然而，這樣只聚焦在效率上，而忽略了速度經濟2，在技術快速變革的時代，這是一種糟糕的選擇。長期處於這種環境中的架構師必須擴展其角色職責，不能只是全盤接收供應商的技術路線圖，而是要主動地定義它。爲此，他們必須要形成自己的IT世界觀。
2 速度經濟是指企業因爲快速滿足顧客的各種需求而帶來超額利潤的經濟。——譯者注
1.1.6 其他乘客
作爲成功的架構師，當你搭乘電梯上下往返時，可以能會遇到其他一些乘客與你同行。比如，你可會能遇到一些業務人員或非技術人員，他們明白深入地理解IT對業務發展至關重要。對這些人友善些，帶他們到處看看。讓他們參與到對話中，可以讓你更好地理解業務需求和目標。此外，他們還可能會帶你前往你從未去過的更高的樓層。
你還可能遇到另外一些人，他們乘坐電梯下樓只是爲了“索要”時髦用語，以便到頂層豪華套間賣弄自己的想法。我們不把這些人稱作架構師。搭乘電梯卻很少出來的人通常會被稱爲電梯服務生。受益於頂層人士的無知，這些人可以追求到一種從不真正接觸實際技術的所謂的“技術”職業生涯。你也可以嘗試去改變一些人，讓他們真的對發動機房的真實運作細節感興趣。但是，如果嘗試不成功，你最好保持沉默，比如，一直看着電梯天花板以避免和這些人發生眼神接觸。等到和高管同乘一梯時再進行“電梯遊說”，而不要和普通傳話人浪費脣舌。
1.1.7 搭乘電梯的危險
你可能以爲僱主肯定非常欣賞搭乘電梯上下忙忙碌碌的架構師。畢竟，架構師能給那些希望通過IT轉型在數字時代獲得更強競爭力的企業帶來很大的價值。令人驚訝的是，這些架構師可能會遇到意想不到的阻力。頂層豪華套間裏的決策層和底層發動機房裏的實施團隊可能都會對彼此“失聯”的現狀很滿意：公司領導層看到的是數字化轉型進展順利的假象，而發動機房裏的員工則可以不管業務需求，隨心所欲地“擺弄”新技術。這樣的情景就像是一艘巨輪全速撞向前面的冰山。當領導層意識到現狀時，很可能爲時已晚。有時候，我會把這樣的組織結構比喻爲頂層和底部並非垂直對齊的比薩斜塔，在這種傾斜的建築裏搭乘電梯上下肯定更有挑戰性。
當架構師步入這樣的環境時，必須在搭乘電梯時準備好面對來自高層和底層的雙向阻力。我就曾經被“發動機房”的員工們批評過，他們嫌我違背開發人員的意願單方面推行公司計劃，同時，企業的領導層又批評我單純爲了樂趣而嘗試新的技術方案。做一名改革者很難，特別是當系統抗拒改變的時候。一種非常好的策略是，從一開始就小心翼翼地把各個層級連接起來，然後等待合適的時機向大家分享信息。比如，你可以向管理層解釋發動機房裏的員工們的工作有多棒，這可以讓管理層進一步瞭解和認可他們，同時你也有機會獲取更詳細的技術信息。
其他對你搭乘電梯上下忙碌不滿的企業人員是中間樓層的佔有者：他們看見你總是在決策層和發動機房之間往返，感覺自己被無視了。我把這稱爲欣賞的“沙漏”曲線：高層管理者把你看作轉型的關鍵推動者，而發動機房的員工也很開心有人真的理解和欣賞他們的工作，但中間層的員工則把你視爲威脅，你害他們無法負擔子女的教育支出，無法購買山景房。這是一件很微妙的事情。有些人主動在半路上攔你：他們會在每一層攔停電梯並要求你給個解釋，如此這般，搭乘電梯還不如爬樓梯快。
1.1.8 將大樓扁平化
與其無休止地搭乘電梯上下，何不直接消除那些不必要的樓層呢？畢竟，你試圖與之競爭的數字化公司並沒有這麼多樓層。不幸的是，除非將整棟樓炸成一堆瓦礫，否則你根本無法讓這些樓層消失。無論如何，消除中間樓層的那些人也不現實，因爲他們往往是組織和IT藍圖信息的主要持有者，特別是在幕後還有一個大黑市的時候。
將大樓逐步扁平化也許是個合理的長遠戰略，但這需要改動企業文化的根基，因而會耗費太長的時間。除此之外，還需要改變或消除中間樓層員工的角色，而這勢必會遭到強烈的抵抗。所以，這不是一場架構師能打贏的仗。不過，架構師可以逐步瓦解阻力，比如，讓頂層管理者對來自發動機房的信息感興趣，提供更快的反饋迴路，以及減少中層管理者做狀態更新彙報的次數。
1.2 電影明星架構師
企業架構師的4個角色
架構師名人堂
除了搭乘電梯上下外，架構師還需要做些什麼？讓我們試着用另一個比喻來解釋：電影明星。
通常在電影正式開始播放前，你會看到一些商業廣告或短片。這裏要說的是一個有關“架構師”這個詞起源的短片：它派生自希臘語單詞ἀρχιτέκτων，簡單翻譯過來就是“首席建築師”。記住，這個單詞就是指那些建造房屋和結構的人，而不是構建IT系統的人。我們應該注意到這個單詞隱含的意思是“構建者”，而不是“設計者”——架構師應該是真正參與構建的人，而不是隻畫些漂亮圖紙的人。人們也期望架構師技藝精湛，這樣才配得上“大師”這個標籤。下面我們進入正題……
1.2.1 黑客帝國——規劃大師
如果讓技術宅給出電影中經典架構師的名字，你很可能會聽到他們提到電影《黑客帝國》三部曲。黑客帝國的架構師是一個“冷酷、毫無幽默感、身着淺灰色西裝的白髮男人”（參見維基百科），這個人實際上就是一個計算機程序。維基百科裏也描述說，這個架構師“長話連篇但頭頭是道”，這也是很多IT架構師的講話方式。所以，也許這個類比挺貼切？
黑客帝國架構師同時也有最終的決定權：他設計了黑客帝國（一個用來模擬現實的計算機程序，人類在其中被機器作爲能量源圈養）並且知曉和掌控其中的一切。企業架構師有時候也會被看成這種人——無所不知的決策者。有些架構師甚至希望自己能成爲這樣的人，因爲無所不知會讓自己的工作有條不紊，還會爲自己贏得更多的尊重。當然，這種角色模型也有一些問題：無所不知對人類來說幾乎是不可能的，這也意味着，我們會不可避免地看到一些糟糕的決策和其他各種問題。即使架構師超級聰明，他也只能基於自己瞭解的事實做出決策。在大型企業裏，這就意味着要依賴來自中間管理層的幻燈片報告或陳述，因爲無論你多麼頻繁地搭乘電梯前往發動機房，都不可能接觸到所有可用的技術。這個通往最高決策者的信息渠道往往會被某些人嚴密保護起來，因爲他們會意識到該渠道是個很有影響力的信息傳達手段，因此，架構師往往間接收到信息，而且信息經常有偏差。所以說，基於這個角色模型做決策是很危險的。
總而言之，企業IT不是電影，它的作用不是爲了給被當作能量源圈養的人類創建幻象。我們應該警惕這種角色模型。
很有意思的是，現實中的Vint Cerf，作爲互聯網的主要架構師之一，和黑客帝國架構師極其相似。考慮到Vint設計了我們所處的黑客帝國（互聯網）的很多部分，因此，這也許並不是單純的巧合。
1.2.2 剪刀手愛德華——園丁
對於企業架構師，園丁是一個更加貼合的比喻。我喜歡把企業架構師比作電影《剪刀手愛德華》（我最喜歡的電影之一）中的園丁。大型IT部門像是一個花園：各種植物按照各自的方式生長，其中雜草總是長得最快。園丁需要修剪那些長得太快或者凸出的部分，保持整個花園的平衡與和諧，同時考慮到各種植物的具體需求——比如，喜陰植物應該種植在大樹或灌木叢旁——這些都是園丁的職責。好的園丁不會一意孤行，也不會去決定像青草應該朝哪個方向生長這樣的細節——日本園丁可能是個例外。更準確地說，園丁把自己看作生態系統的守護者。有些園丁，像愛德華，已經成爲了真正的藝術家。
我之所以喜歡這個比喻，是因爲它很貼切。複雜的企業IT部門是個有機體，因此優秀的架構師都有很好的平衡意識，這也是好園丁所具備的素質。使用除草劑進行自頂而下的治理不可能產生持久的效果，而且通常弊大於利。這樣的思考是不是能使《秩序的本質》這本書得到新的應用，我還不確定。我想自己應該先讀讀這本書。
1.2.3 粉身碎骨——導遊
ThoughtWorks的歐洲技術主管Erik Dörnenburg給我介紹了另外一個非常恰當的比喻。Erik密切參與過很多的軟件項目，他非常討厭那些表面上無所不知，實際上專斷獨行又脫離實際的架構師。Erik甚至還創造了一個術語：無架構師架構。這可能會讓一些架構師擔心自己的職業生涯。
Erik把架構師比作導遊。導遊去過某個地方很多次，能講關於這個地方的好故事，還能熱心地引導遊客注意重要事項，避免無謂的風險。旅遊業有條行規是，導遊不能強迫遊客採納他們的建議，當然，那些敢把一車遊客丟在荒無人煙的黑店的導遊除外。
導遊類型的架構師必須“運用自己的影響力來引導他人”，也就是說，他們必須有真材實料才能贏得尊重。導遊需要和遊客一路同行，而不能像某些諮詢架構師那樣只給遊客提供一份地圖。但導遊類型的架構師通常依賴於管理層的強大支持，因爲沒有明確的證據能夠證明是他的指導帶來了好的結果。在純粹的“業務驅動”環境下，這會限制“導遊”架構師自身的影響力或職業生涯。
《粉身碎骨》，這部1971年上映的公路電影，也是我最喜歡的電影之一。其中的角色盲人DJ Super Soul是一個不同尋常的導遊。像很多IT項目一樣，這部電影的主角Kowalski踏上了一場死亡之旅，沿途障礙重重，他很難在約定時間內完成任務。不同的是，Kowalski要交付的不是代碼，而是要在15小時內把一輛1970年生產的道奇挑戰者R/T 440 Magnum從丹佛開到舊金山。Kowalski由Super Soul引導，後者利用警察網絡獲取關鍵信息，就好像架構師接入管理網絡一樣。一路上，Super Soul追蹤着Kowalski的進展，併爲他清除警察（即管理層）設置的各種陷阱。然而，在Super Soul向“管理層”妥協後，交付道奇車這個“項目”就變成了無頭蒼蠅，最終像很多IT項目一樣功虧一簣。
1.2.4 綠野仙蹤——魔法師
架構師有時候會被看作可以解決任何技術難題的魔法師。雖然這可以作爲一個短期的自我吹捧，但不是一個合適的工作描述，也不是一個爲之奮鬥的合理目標。這裏所說的“魔法師”並不是指那種揮動魔法棒的真正魔法師，而是電影《綠野仙蹤》裏那個“強大的奧茲”—— 一個看起來很強大的投影，但實際上只不過是由一個人類“魔法師”控制的，而人類魔法師只是通過大型機械來製造魔術效果並以此贏得尊重的普通人。
在那些“普通”開發人員很少參與管理層討論和重大決策的大型組織裏，這種精心設計的欺騙可以起到一定的作用。這種情境下，“架構師”這個頭銜可以讓開發人員顯得更加“了不起”：這種放大的投影效果能夠贏得企業普通人員的尊重，甚至可以成爲搭乘電梯前往頂層的前提條件。這是欺騙嗎？我會說“不是”，只要你不要過於迷戀這種魔幻效果而忘記自己作爲開發人員的技術根基就行。
1.2.5 超級英雄還是強力膠
和魔法師類似，對架構師的另一個期望就是超級英雄：如果你相信某些職位描述，那麼企業架構師是這樣的：能易如反掌地讓公司進入數字時代，能夠解決任何技術問題，並且總是對最新技術瞭如指掌。要達到這些期望很難，所以我要提醒所有架構師，不要對這些常見的誤解信以爲真。
英特爾公司的Amir Shenhav恰當地指出：我們需要的是“強力膠”架構師，而不是超級英雄。“強力膠”架構師既懂得架構，又瞭解技術細節，還明白業務需求，而且能將大型組織和複雜項目中的人員團結起來。我喜歡這個比喻，因爲它類似於把架構師比作催化劑。只不過，我們必須小心一些：強力膠或者催化劑，意味着你要相當瞭解要去“黏合”的東西。架構師不單單是個牽線搭橋的角色。
1.2.6 做決定
究竟要做哪種類型的架構師呢？除了上述架構師類型，還有更多的架構師類型以及可類比的電影角色。你可以像電影《盜夢空間》裏那樣，通過（危險的）意識潛入來創建架構的理想世界；或者像電影《我爲瑪麗狂》裏的兩個騙子那樣就智利建築爭辯不休；抑或像烏托邦劇《摩天大樓》中的（令人毛骨悚然的）Anthony Royal 那樣制定規則。總之，你可以選擇的架構類型有很多。
最終，大多數架構師是這些經典形象的結合體，有時是強力膠，有時是園丁，有時又是導遊，有時又展現出一種無所不知的高大形象。按照需要扮演不同的角色，就可以成爲一個優秀的架構師。
1.3 企業架構師與企業裏的架構師
象牙塔裏的上下層
出自象牙塔的架構
當我被聘爲企業架構師時——更準確的頭銜是企業架構主管（Head of Enterprise Architecture），我還不太清楚企業架構師到底需要承擔什麼責任。我也想知道，如果我是企業架構的“頭”（Head），我的團隊是不是就應該被稱爲企業架構的腳3，但團隊成員並不喜歡這個稱謂。現在，這種加上“主管”後綴的頭銜很流行。下面是我偶然在某個在線論壇看到的對這種現象的恰當解釋。
3 用來諷刺頭銜設置得不合理。——譯者注
這個頭銜通常表示候選人本想成爲總監、副總裁或者執行官，但是組織不允許再增加這些崗位的人員數量了。通過授予這種模棱兩可的頭銜，在組織外部看來，候選人已經處於較高的級別，但在組織內部，候選人並沒有獲得相應的權力配備。
我特別不喜歡“某某主管”之類的頭銜，因爲它強調的是帶領團隊，而不是實現具體的職能。我更願意用一個崗位要達成的目標來命名它，並且要體現出履行該職能需要團隊支持。幸運的是，我現在是個“首席”，不再是個“主管”了，用一個在政治上不那麼正確的比喻來說，當我還是個“主管”時，偶爾會以“打哈哈”的官僚方式和人打招呼。
拋開所有的頭銜後綴不提，當IT人員遇到企業架構師時，他們最初的反應是要把這個人放到頂層豪華套間去，在那裏，他們可以繪製漂亮卻沒什麼實際作用的架構圖。因此，要想受到IT人員的熱情歡迎，就應該慎用企業架構這樣的標籤。然而，又該如何稱呼那些完成企業級架構工作的架構師呢？
1.3.1 企業架構
“企業架構師”這個稱謂的問題是，它既可以描述一個構建整個企業架構（包括業務策略層級）的人，又可以描述一個在企業層級（比如，相對於部門的架構）構建IT架構的人。
爲了消除歧義，我們來看看書上的定義。Jeanne Ross和Peter Weill的《企業架構戰略》一書是這樣定義企業架構的：
企業架構是業務流程和IT基礎設施的組織邏輯，二者共同反映了企業運營模式的集成和標準化需求。
按照這個定義，企業架構不止包含IT職能，也需要考慮業務流程，後者是企業運營模型的一部分。實際上，這本書中最爲人熟知的是一張四象限圖，這張圖用不同水平的流程標準化（各業務線一致）和流程集成（數據共享和流程互連），描述了業務運營模型。通過給出每個象限的行業實例，該圖把每個模型映射到相應的IT架構策略。比如，如果業務運營模型是高度多樣化的業務單元之一，且共享客戶很少，那麼數據和流程集成程序可能沒有什麼價值。這種情況下，IT部門應該致力於提供公共基礎設施，然後每個部門都可以在其基礎上實現自己特有的流程。這個象限圖完美地揭示了業務和IT架構必須保持一致才能爲業務提供價值。
1.3.2 業務和IT是平等的
無論如何，我認爲把IT跟業務剝離是有問題的。我喜歡開玩笑說，在公司所有業務信息系統運行在計算機上之前，也沒看見單獨在“紙”上的部門啊。在數字化公司，IT就是業務，業務就是IT——二者不可分割。因此，我認爲企業架構應該定義如下：
企業架構是業務和IT架構之間的黏合劑。
這個定義意味着共有兩個“企業級別”的架構，一個是業務架構，另一個是IT架構。雖然兩者的側重點稍有不同，但需要緊密配合。比如，業務架構定義公司的運營模型，而IT架構則構建相應的IT能力。如果兩者能夠無縫合作、齊頭並進，就不需要其他東西了。如果它們沒能緊密聯繫，就需要企業架構部門來把兩者協調聯繫起來。這就好像新加了一部中層電梯，它可以把頂樓豪華套間的管理決策層和底部發動機房的開發人員聯繫起來，因爲已有的電梯無法直接把大樓頂部和底部連通起來。這種企業架構部門的長遠目標必須是淘汰自己，或者至少讓自己的規模變小。
我認爲這是期望的狀態，因爲它能平等對待IT架構和業務架構。雖然在企業中支持業務依然是所有職能的目標，但只把IT看作以儘可能低成本管理商品資源的簡單命令執行者的時代已經結束了。在數字時代，IT已成爲一種競爭力，並且能帶來機遇，而不是像電一樣的簡單必需品。這種改變必須要反映在架構職能的建設中：業務驅動IT，但是IT也能驅動新的業務。
這個模型需要業務架構和IT架構一樣成熟，要做到這一點是有一定難度的，因爲業務架構是一個比IT架構更新、更不明確的領域。這也體現在商界中架構化思考（比如，合理的系統化思考）的不足上，這可能是因爲相關課程在這一點上強調得不夠。因此，作爲一個成功的首席架構師，你還需要幫助組織強化業務架構。
1.3.3 企業裏的架構師
我的定義也意味着，至少某些架構師是在企業範圍內工作的。我在談到“企業架構師”或“IT架構師”時，指的就是這些人。他們通常是技術人員，已經學會搭乘電梯前往上半部樓層和管理層以及業務架構師打交道。他們就是本書的主要讀者，也是IT轉型中的關鍵元素。
那麼，“企業級架構師”和“普通的”IT架構師有什麼區別呢？首先，企業級架構師要處理的所有事項規模都更大。很多大型企業都是擁有不同業務單元和部門的企業集團，其中每個業務單元和部門都有着數十億美元級別的業務和特有的業務模型。因爲規模變大了，所以你會發現更多的遺留物——業務會隨着時間推移或通過併購增長，而這兩種情況都會產生遺留物。這種遺留物不只侷限於系統中，也存在於人們的觀念和工作方式中。因此，企業級架構師必須能夠引導組織並處理其中複雜的政治局勢。
1.3.4 哪些樓層
傳統的企業架構通常被擱置在象牙塔裏，而且被認爲沒什麼價值。導致這種情況的一個原因是反饋週期過長：評判某人是否完成了優秀的企業架構經常比評判優秀的IT架構需要更長的時間。因此，企業架構部門會成爲一些人的藏身之地，這些人只想成爲象牙塔裏的繪圖員，而不是爲公司打造業務並創造價值的真正架構師。這就是爲什麼企業架構師需要展現影響力，比如，維護一幅精準又詳細的IT世界地圖。這幅地圖不能是那種典型的“職能地圖”，它必須要包含真正有用的信息。
如果企業認真對待架構，它會爲企業的所有層級提供重大價值。這讓我想起了1977年由Charles和Ray Eames爲IBM製作的短片《10的次方》。該短片把芝加哥的一份野餐每10秒縮小一級，一直縮小到10的24次方，此時，大家看到了無數個星系。隨後，它又把同樣的野餐每10秒放大一級，一直放大到10的負18次方，此時，大家看到的是夸克的世界。有趣的是，這兩種視角看待同一個事物的結果並沒有太大的不同。我覺得在更大的企業中也是如此：從遠處看到的複雜度與從近處看到的是類似的。它幾乎就像個分形結構：你越放大或越縮小，它看起來就越相同。因此，完成重大的企業架構和修復一個Java併發缺陷的複雜度和價值是一樣的。但這需要企業架構師從頂樓象牙塔裏走出來，至少搭乘電梯下幾層樓，去完成有實際價值的工作。
1.4 架構師用三條腿立足
架構師需要橫向擴展
三腳凳不會搖晃
IT架構師是做什麼的呢？答案是，IT架構師是打造IT架構的人。這就需要定義架構是什麼。假設我們知道這個答案，那麼一個優秀的架構師在經過多年的成功後會成爲什麼？在頂樓豪華套間中佔有一席之地？希望不是。成爲首席技術官？這是個不錯的選擇。或者依然是一個（資深的）架構師？這也是很多著名的建築大師所做的。然而，我們需要明白初級和高級IT架構師的區別在哪裏。
1.4.1 技能、影響力、領導力
當被問到資深架構師具有哪些特徵時，我會使用下面這個簡單的框架，而且相信它也適於大多數高端職業。一個成功的架構師必須有“三條腿”才能立足。
(1) 技能是實踐架構的基礎。它需要知識以及應用知識的能力。
(2) 影響力用來衡量架構師在項目中應用技能後能給項目或公司帶來多大的效益。
(3) 領導力確保了架構實踐的狀態能穩步向前推進，同時培養更多的架構師。
這個分類也可以很好地應用於其他專業領域，比如醫學：醫生在學習並獲得技能後，開始實踐並治療病患，然後再通過在醫學期刊上發佈經驗成果，把自身所學傳授給下一代醫生。
技能
技能是應用相關知識的能力，比如關於特定技術（如Docker）或架構（如雲架構）的知識。知識通常可以通過上課、讀書或者研讀在線材料等方式獲取。大多數（不是所有）認證重點考覈知識，部分原因是知識點很容易以一組多選題的方式呈現在試卷上。知識就像是一組裝滿了工具的抽屜櫃，技能則意味着知道何時打開哪個抽屜以及使用哪個工具。
影響力
影響力是通過架構實踐給業務帶來的效益來度量的，通常是指增加的利潤或者降低的成本。更快地將產品推向市場，或者在產品週期的後期無須做很大改動就可以適配那些無法預見的需求，這些都能夠增加收益，因此都可以算作影響力。對於架構師而言，專注於提升影響力是個很好的鍛鍊，這樣可以避免他們陷入只有幻燈片的虛幻世界。當我和同事談論優秀架構師有什麼特點時，我們經常都把理智、自律的決策能力看作從“技能”向“影響力”轉化的一個關鍵因素。但是，這並不意味着優秀的決策者就可以成爲優秀的架構師。你依然需要具備紮實的技能基礎。
領導力
有領導力要求經驗豐富的架構師不能只侷限於做本職架構工作。比如，他們應該通過傳授知識和經驗來指導初級架構師，還應該通過出版著作、公開授課、公開演講、發佈研究成果或者撰寫博客等方式，促進所在領域的整體發展。
1.4.2 良性循環
雖然這個模型相當簡單，但就像只有兩條腿的凳子站不穩一樣，平衡技能、影響力、領導力這三方面非常重要。作爲學生或學徒的新生代架構師只具備技能卻沒有影響力，但是，他們遲早會通過實踐獲得影響力。無法產生影響的架構師在任何盈利性業務中都沒有立足之地。
早早就加入項目的方案架構師通常只具備影響力卻沒有領導力。然而，沒有領導力的架構師一定會遇到職業生涯的瓶頸，也不會成爲所在領域的思想領袖。很多公司不注意培養或者幫助他們的架構師達到這個層次，因爲這些公司害怕項目之外的任何事宜都會增加成本。反過來，這種公司裏的架構師也會始終高不成低不就，因而也無法帶領公司創新或轉型。這些公司最終會錯失機會，因小失大。相反，諸如IBM等公司有意以“回饋”的方式培養領導力：他們期望傑出的工程師和研究人員回饋公司內外的社區。
同樣，只具備領導力卻沒有影響力的架構師，很可能缺乏相應的技能基礎。這可能是一個警告信號，它表明你已經變成了一個幾乎脫離實際的象牙塔架構師。如果架構師的影響力依然停留在多年前甚至數十年前的水平，同樣會產生這種結果，因爲架構師所宣講的方法和思想在當前的技術場景下已經不適用了。雖然某些架構思想永不過時，但是其餘的都會隨着技術的發展被淘汰，比如，爲了提高處理速度而把儘可能多的邏輯以存儲子程序的方式放入數據庫，這種方法已經不再是明智的選擇了，因爲數據庫是大多數現代網絡架構中的瓶頸。此外，夜晚自動重複運行批量腳本的方法也落伍了，因爲現在的24/7實時處理根本就沒有所謂的夜晚。
資深架構師指導初級架構師時，這個良性循環就結束了。因爲（軟件）架構中的反饋週期很慢，所以這個指導的過程能讓新架構師節省很多時間，他們無須自己從實踐和錯誤中學習。10個受過良好指導的初級架構師會比1個資深架構師更有影響力。每個架構師都應該知道，縱向擴展能力（變得更聰明）到一定程度就不起作用了，而且存在單點（就是你）失敗的隱患，因此，你需要通過傳授知識和經驗給多個架構師來橫向擴展。我一直在努力招募架構師，並且意識到其他大型企業也有同樣的需求，因爲增加技能永遠都非常重要。
另外，指導的過程不僅僅對被指導者有利，對指導者同樣有益。老話說得好：只有在給其他人講解某個東西時，你才能真正地理解它。這句話同樣非常適用於架構。做一場演講或者撰寫一篇文章需要你整理和重新思考，這通常也會催生新的見解。
1.4.3 重複良性循環
經驗豐富的架構師能夠正確地解釋自20世紀80年代以來的各種技術，這意味着架構師在其職業生涯裏不只要完成一次良性循環。重複這個良性循環的一個原因是，技術和架構風格的變革永不停歇。雖然一個人很可能已經是關係型數據庫領域的思想領袖，但他依然需要學習非關係型數據庫相關的技能。在第二次循環中，獲取技能的速度通常明顯更快，因爲第一次循環提供了基礎。在經歷多次良性循環之後，我們也會慢慢理解架構大師們經常說的話：軟件架構領域裏真的沒有多少新東西，我們以前全都見過了。
重複這個良性循環的另外一個原因是，在第二次循環中，我們可能會理解得更深刻。第一次我們可能只學會瞭如何完成某件事情，但是第二次纔可能明白爲什麼要這樣做。比如，我們撰寫《企業集成模式》這本書就是體現思想領導力的一種形式，這樣說可能沒錯。然而，在書中的章節介紹裏，我們對模式圖標、決策樹和決策表等元素的選擇都是隨意的，而不是經過深思熟慮的。現在回過頭來看，我們才理解這些元素實際上就是視覺模式語言或者模式輔助的決策方法的實例。因此，重複這個良性循環總是值得的。
1.4.4 要當一輩子架構師嗎
雖然架構工作是現在最令人激動的工作之一，但有些人還是會感到悲傷，因爲作爲架構師就意味着你職業生涯的大多數時間可能會做這份工作。然而，我並沒有這樣的擔心。首先，作爲架構師，你能夠和CEO、總裁、醫生、律師以及其他高端專業人士相提並論。其次，在注重技術的組織裏，軟件工程師應該和架構師有同感：職業生涯的下一步應該是成爲資深軟件工程師或者高級工程師。因此，我們的目標就是將軟件工程師或者IT架構師這樣的職位頭銜同具體的資歷水平分離。在很多數字化組織中，軟件工程師的職業階梯可以一直到達高級副總裁級別，享有同等地位和薪酬。有些組織甚至有首席工程師這一職位，如果你思考一下，可能會覺得這個頭銜比首席架構師更好。我個人更喜歡把自己喜歡的事情做好，而不是去追求別的東西。因此，生命不息，架構不止！
1.5 決策
三思而後行
做決定
你買了一張彩票，然後中了大獎。這是一次多麼英明的決定啊！大半夜，在熱鬧的街道上，醉醺醺的你閉着眼睛闖紅燈橫穿馬路，最後竟然安全地到達了馬路對面。這個決定也很棒嗎？並不是。兩個決定都有積極的結果，但是這兩者的區別在哪裏？我們用風險來判斷第二個決定，而用結果來判斷第一個決定，忽略了票價和中獎概率。但是，你不能只通過結果來判斷決定的好壞，因爲你在做決定的時候根本就不知道結果是什麼。你需要基於當時自身的知識儲備做決策。
另外一個實驗：你面前的桌子上有一個很大的瓶子，裏面裝有100萬顆藥丸，它們看起來一樣，都無毒無味，但其中有一顆能讓你立即無痛死亡。如果有人讓你從這個瓶子中隨機拿出一顆藥丸服用，給你多少錢你纔會同意？大多數人會說100萬美元、1000萬美元，抑或直接拒絕。然而，這同一羣人卻非常願意（睜着眼睛）闖紅燈，或者滑一整天雪，而事實上，這兩種行爲和吞藥丸打賭有着同等的風險。但是，人們很難將闖紅燈之後倖存的結果和掙好幾百萬美元等同起來。
人類天生就是很糟糕的決策者，在涉及小概率事件以及死亡和金錢等問題時尤其如此。我們以爲自己是很聰明甚至是狡猾的決策者，但這並非事實。丹尼爾·卡尼曼（Daniel Kahneman）在《思考，快與慢》一書中用大量的例子展示了人類的大腦是如何被欺騙的。比如，有一種現象叫作啓動效應，它可以讓我們在面對巨大不確定性的時候，無意識地選擇一個我們最近聽到或看到的數字，即使該數字和發生的事情毫無關聯。很多人在聽到100萬顆藥丸時會脫口而出“100萬美元”，這一效應就發揮了作用。
決策是企業級架構師工作中的關鍵部分，因此，要想成爲優秀的架構師，必須首先努力成爲更好的決策者。
1.5.1 我們真的那麼容易上當嗎
面對簡單的決定或編造的例子時，我們似乎很容易分辨出其中怪誕或不合理的行爲。但是當面對現實生活或商業環境中的複雜決定時，我們的決策自制力真是出乎意料地糟糕。比如，運營週會竟然經常根據關鍵基礎設施服務中斷時間的長短來判定該周的“好壞”。任何學過統計學入門課程的人都知道，真正的判定標準應該是從長遠來看降低事故發生的次數，而不是看你在過去的一週是否足夠幸運。這就等同於企業IT部門猜測“5次黑色後肯定變紅”。另一個能突出這種思維缺陷的例子是讓人震驚的俄羅斯輪盤賭，幾輪之後就會有人中槍身亡：“扣扳機，我是個天才！——嘣。”
IT產品的採購決策通常更嚴格一些，因爲它會使用詳細的需求列表。最終，“贏家”的得分是82.1，而“輸家”的得分是79.8，這是我們經常看到的結果，然而，我們很難證明這種得分在統計學上有什麼意義。但是，這種在決策過程中引入數值計算的方式已經比流行的交通燈對比圖有所進步了，後者只是使用“紅”“黃”“綠”三色來進行粗略的等級評估。試想，某款產品因爲允許時空旅行而獲評爲“綠色”，而另一款產品因爲需要按照計劃停機而被評爲“紅色”，這種紅綠兩色的對比，會讓人以爲這兩款產品的特性是截然相反的4。其實不需要這樣對比，因爲我知道我會選擇哪個。在有些案例裏，這種對比圖的結論甚至是從想要的結果或者從不想改變的現狀反推得到的，其中的一些IT需求會被轉化爲奇怪的需求。比如，新車必須以每小時60英里5的速度搖搖晃晃地前進，而且車門也要嘎吱作響，這樣它就可以完美地替代舊車了。
4 作者這裏的例子是用來突出對兩個風馬牛不相及的特性做紅綠對比評判的不合理性。——譯者注
5 1英里約合1.6093千米。——編者注
1.5.2 小數法則
《思考，快與慢》一書裏列舉了很多示例，說明人類在決策過程中如何受影響，它會讓你覺得自己沒有爲日常生活做好準備。人類怎麼會是如此糟糕的決策者呢？我猜我們已經嘗試過很多次了。
讓我們來看一個被卡尼曼稱爲“小數法則”的現象——人們往往會根據不夠顯著的小樣本數據得出結論。比如，大型企業沒有理由把連續7天沒有中斷服務看作值得慶祝的成績。
當我還在谷歌移動廣告團隊工作時，我們爲改變廣告出現次數和設置的A/B測試實驗使用了嚴格的度量標準。儀表盤上包括瞭如點擊率（點擊率越高，收費越多）等指標，也包括了用來標識廣告是否讓用戶從搜索結果分心（谷歌是搜索引擎，而不是廣告引擎）的指標。另外一個重要的指標是置信區間，它用來表示95%的樣本集合將隨機落入的範圍。對於正態分佈，我們使用了樣本點數的平方根來縮小置信區間，這就意味着需要4倍的數據點，也就是需要4倍的時間來運行實驗，才能達到置信區間減半的效果6。如果實驗落入了當前設置的置信區間裏，你必須去爭搶額外的“實驗空間”，該空間定義了可以分配給實驗的流量佔比。整個流程的設計就是爲了克服證實性偏見，即我們傾向於將數據解釋爲支持自己的觀點。
6 置信區間（confidence interval）是指由樣本統計量所構造的總體參數的估計區間。——譯者注
1.5.3 偏見
《思考，快與慢》一書中列出了人類思維產生偏見的諸多方式。這本書真的值得一讀。這裏，爲了列舉出所有方式，我不得不對原書內容做了重新編排。其中一個衆人皆知又非常重要的偏見是前景理論：爲了換取小但有保障的收穫，人們會情願放棄獲得更多金錢（或幸福等）的機會——“一鳥在手好過百鳥在林”。然而，當涉及損失時，人們更可能徹底規避可能發生的損失，而不是抓住有保障的小收入。當我們希望規避某個負面事件時，往往會“感覺很幸運”，這種效應被稱爲損失厭惡。
研究表明，人們通常會爲了賭一個正向結果而索要1.5~2倍的合理回報。如果有人發起一個拋硬幣遊戲，硬幣正面朝上就跟你要100美元，但反面朝上的話會給你120美元，你願意參加嗎？雖然可以預見的結果是獲得10美元的收入（0.5×(-100) + 0.5×120 = 10），但是大多數人還是會友好地拒絕，當反面朝上可以得到150~200美元時，他們纔會參加這個遊戲。
1.5.4 啓動效應
當你去買毛衣時，店員幾乎肯定會先挑一件超級貴的毛衣給你看，很可能超出了你的預算。一件毛衣就要399美元？這也太貴了。但它用的可是山羊絨哦，手感柔軟舒服，很吸引人，就是價格過高。相比之下，199美元一件幾乎一樣好的毛衣似乎很便宜，你會很樂意買下它。但在隔壁，花59美元就能買件像樣的毛衣。你成了啓動效應的受害者，因爲你設定了足以影響你決定的環境。啓動效應不一定都像這個例子一樣直接。如果你是老年人的心態，那麼即便身邊沒有老年人，你也會走得更慢。7
7 參見Bargh、Chen和Burrows的文章，Automaticity of Social Behavior: Direct Effects of Trait Construct and Stereotype Activation on Action，刊載於Journal of Personality and Social Psychology，1996年8月，第71卷，第2期，第230~244頁。
William Poundstone的《無價：洞悉大衆心理玩轉價格遊戲》一書中提供了另外一個有關啓動效應的經典示例。將兩種啤酒擺在受試者面前，其中的“優質品”標價2.60美元，而旁邊的“便宜貨”標價1.80美元，大約2/3的受試者（學生）選擇了“優質品”。再增加第三種啤酒“超優品”，標價3.40美元。結果，90%的學生選擇了“優質品”，而剩餘10%的人則選擇了“超優品”。利用啓動效應，即使是沒人買的商品，也能影響人們的購買行爲。如果你想銷售一款比較便宜的啤酒，最好能放一瓶更便宜的在旁邊做襯托，即便根本沒人會買它。
1.5.5 決策分析
如果我們是非常糟糕的決策者，那麼該如何改進呢？首先，要意識到我們的確是糟糕的決策者，這是最重要的；然後，要理解爲什麼我們是糟糕的決策者，這樣才能儘量避免這些因素或者至少嘗試補救。如果想做得更好（你應該這樣做），你應該去看一本很棒的有關使用數學方法輔助決策的書，就是Ron Howard和Ali Abba撰寫的《決策分析基礎》。Ron的課是我在斯坦福大學上過的最棒的課程之一：有趣、發人深思，又充滿挑戰。不過，他的書可不便宜，標價將近200美元。你是否應該花200美元買本書來提升自己的決策水平？好好考慮一下……
1.5.6 微亡率
Ron和Ali還幫助我們思考了上面那個裝有百萬顆藥丸的瓶子的故事。他們把百萬分之一的死亡率稱爲1個微亡率（micromort）。從那個裝有百萬顆藥丸的瓶子中拿出1個藥丸服用恰好就是1個微亡率。爲了避免冒這個險，你願意付出的代價稱爲你的微亡率價值。微亡率能幫助我們推斷那些可能產生小概率但很嚴重的後果的決策，比如決定是否做手術，該手術可以消除長期病痛，但有1%的概率失敗，進而導致患者當場死亡。
校準微亡率價值有助於我們思考日常生活中的風險。滑雪一整天會有1~9個微亡率，而摩托車事故大概是每天0.5個微亡率。所以一次滑雪之旅可能會讓你承擔5個左右的微亡率風險8，等同於服用5顆從那個瓶子中取出的藥丸。那麼一天的滑雪之旅值得嗎？這時候，你就需要比較滑雪帶給你的娛樂價值和這趟滑雪之旅的花費以及要承擔的微亡率風險。
8 一整天的滑雪會有1~9個微亡率，所以微亡率的平均值是5個左右。——譯者注
那麼，讓你服用1顆那個瓶子中的藥丸需要給你多少錢？大多數人的微亡率價值在1~20美元，下面的討論中我們假設每個人都取平均值10美元。進行一次滑雪之旅，你不僅需要支付100美元的燃油費用和纜車費用，還需要承擔50美元的死亡風險。現在，你需要決定爲了在山上滑雪一天是否值得花費150美元。這也可以說明100萬美元的微亡率價值沒有多大意義，因爲你很難爲自己一天的滑雪之旅支付500萬美元，除非你富得流油！這個微亡率價值模型也能幫助你決定，花100美元買個頭盔，讓死亡風險減半是否值得。
微亡率價值會隨着收入（更準確地說是消費）增加而增加，也會隨着年齡增長而降低。它的期望值9就是你爲自己餘生定義的貨幣價值，也會隨着收入增加而增加。因此，有錢人應該會很容易決定去買個100美元的頭盔，而收入只夠維持生計的人則傾向於接受這種風險。隨着年齡的增長，你自然死亡的可能性也會不可逆轉地增加，到80歲時，你的微亡率達到每年約10萬個，即每天近300個。到那個時候，付出很大代價來降低2個微亡率已經沒有什麼意義了。
9 期望值是概率論和統計學中的一個概念，在經濟學中有應用，它是對不確定事件的所有可能結果的加權平均，但要注意，它並不等於實際值，只是用來衡量所有結果的總體趨勢。——譯者注
1.5.7 模型思維
即使是很簡單的模型，也能幫助我們成爲更好的決策者。George Box有一句名言，“所有模型都不對，但總有一些是有用的”。所以，不要僅僅因爲一個模型做了簡化的假設就放棄它。它幫助你做的決定可能比你僅僅根據直覺做的決定要好。
斯坦福大學Scott Page教授的模型思維課是我上過的最好的介紹模型及其應用的課程。決策樹是一個能幫助你做出理性決策的簡單模型。假設你要買輛車，但是有40%的概率經銷商會在下個月做1000美元的返現活動。然而你現在就需要一輛車，因此，如果你推遲購買，就需要在接下來的一個月裏花500美元來租輛車。你應該怎麼做呢？如果你現在購買，就需要支付現有的標價。爲了簡單起見，我們把這個標價定爲0美元。如果先租車，你就需要先花500美元，然後纔有40%的概率獲得1000美元的返現，那麼期望值就是負的100美元（0.4×1000 - 500 = -100），因此你應該現在就買這輛車。
假設有位內部人士能告訴你下個月是否真的有返現活動，他標價150美元來出售這個確切的消息。你應該購買這個消息嗎？有了這個消息，決策樹可以讓你在沒有返現活動時（60%的概率）決定現在就買，有返現時（40%的概率）就一個月後買。這個消息產生的期望值是正的200美元（0.6×0 + 0.4×(1000 - 500) = 200）。而這是你現在最好的選擇，因爲不購買內部消息而直接購買只會產生0美元的期望值，所以花費150美元去買這個消息是值得的。
1.5.8 避免決策
你已經看了這麼多決策背後的科學原理，那什麼纔是最好的決策呢？對了，就是那個你不需要做的決定。這就是爲什麼Martin Fowler會說“架構師最重要的任務之一就是從設計中消除那些不可逆的決策”10。這些決策是根本不需要做的，或者可以快速做的，因爲後面可以輕易改變。在良好設計的軟件系統裏，決策並不像從那個瓶子中取出致命藥丸那樣不可改變。
10 參見Fowler的文章，Who Needs an Architect?。
但是，如果你必須要做一個重大的架構決策，請務必三思而後行。
1.6 刨根問底
問則進，不問則退
愛提問題的架構師
一個很常見的誤解是，首席架構師對任何事情都比“普通”架構師精通——不然他們怎麼會是“首席架構師”呢？實際上並非如此。因此，在自我介紹時，我經常會說自己只是一個知道問正確問題的人。再次引用電影《黑客帝國》中的場景，拜訪首席架構師就有點像拜訪先知：你不會直接得到答案，但會聽到所需要的東西。
1.6.1 五問法
提問並不是一個新技能，並且已經因爲五問法而被廣泛應用。五問法是由豐田佐吉（Sakichi Toyoda）提出的，是豐田產品系統的組成部分。這是一種反覆追問某些事情爲什麼會發生以便探究根本原因的方法。如果汽車啓動不了，你應該一直追問“爲什麼”來找出根本原因：啓動器無法點火，因爲電池沒電了；電池沒電是因爲車燈一直開着；車燈一直開着，是因爲警告車燈一直開着的蜂鳴器沒有發聲；蜂鳴器沒有發聲，是因爲一個電子設備出了問題。所以，你應該做的是修復這個電子設備，而不是去嘗試通過跨接引線來啓動汽車。在日語裏，這個方法讀作“naze-naze-bunseki”（なぜなぜ分析），大致上可以翻譯爲“爲什麼，爲什麼分析”。這裏，我認爲數字“五”只是爲了提醒我們不要過早地放棄。如果你只問了四次“爲什麼”就發現了問題的根本原因，我也不會認爲你作弊了。
這種方法非常有用，但是需要自律，因爲人們往往會在答案中插入自己認同的方案或假設。我見過有人在分析產品故障的根本原因時，反覆使用“因爲我們監控得不夠”和“因爲我們沒有足夠的預算”來回答第二個和第三個爲什麼。對應汽車無法啓動的例子，這些答案就相當於反覆說“因爲車舊了”。這不是在做根本原因分析，而是典型的機會主義或藉口主義（excuseism）。藉口主義這個詞在城市詞典中有收錄，但韋氏詞典還沒有收錄它。
反覆提問會讓回答者有些惱火，所以你最好先介紹一下豐田產品系統，好讓大家明白這是一種被廣泛採用且非常有用的方法，而不是你在故意刁難他們。還有，要先提醒你的同行，你不是在質疑他們的工作或者能力，而是你需要詳細地瞭解系統和問題，只有這樣，你才能發現潛在的缺失或偏差。
1.6.2 反覆追問纔可以揭示出決策和假設
在實施架構評審時，“爲什麼”是一個非常有用的問題，它可以幫你將注意力吸引到已經做出的決策上，以及促成這些決策的假設和原則上。回答的人常常會說，這是“上帝賜予我們的”，實際上就是“從天上掉下來的”，或者從任何你認爲主宰一切的神聖造物主（真正的首席架構師！）居住的地方掉下來的。揭示出促成最終決策的假設能夠提供更多關於決策的深刻見解，還有助於提升架構評審的價值。架構評審不僅僅要驗證結果，也要驗證結果背後的思考和決策。爲了強調這個事實，評審團隊應該要求任何提交架構評審申請的團隊先提交一個架構決策記錄。
如果做出假設的環境發生改變，這些未明說的假設就會成爲很多問題的根源。比如，傳統的IT部門經常會編寫一些精緻的圖形用戶界面配置工具，但它們可以被幾行代碼和標準的軟件開發工具鏈替代。他們當時的決策是基於編寫代碼既慢又容易出錯的假設，但這已經不再是必然的了，因爲我們可以通過學習克服自己的代碼恐懼症。如果要改變組織行爲，你往往需要首先識別和解決那些過時的假設。
回到電影《黑客帝國》中，先知給出的解釋是“……你不需要來這裏做選擇，你已經做出了選擇。你來這裏只是爲了弄清楚自己爲什麼做出這樣的選擇”。這聽起來有些戲劇化，但不失爲架構評審的一個非常合適的開場白。
1.6.3 處理所有問題的研討會
在大型企業裏提問的一個顯而易見的問題就是，企業人員通常不知道、不會表達或者不願意回答。對此，他們提出的建議通常是開會，而且很可能是個冗長的、貼着“研討會”標籤、打着要“分享和記錄問題答案”旗號的會議。然而，在實際會議中，你會反覆發現答案都是“不知道”，最終就是你需要回答自己的問題。團隊還可能會從外部獲取支持來防止你問出很多他們不想聽的問題。
很快，你的日程表會被一大堆研討會的邀請塞滿，然後你會變成所有團隊口中的“瓶頸”，因爲你無法參加他們的重要會議才導致他們的進度變慢。他們甚至沒有說謊！這種組織化的抵觸行爲就是系統抗拒改變的典型例子。
如果你的目標不只是評審架構提案，還包括改變組織行爲，你就必須接受挑戰，改變系統。比如，你可以重新定義架構文檔的標準，並取得管理層對諸如提高透明度等的支持。如果團隊在會議前無法提供合格的文檔，會議就必須取消。如果團隊不能完成這種文檔，你可以爲他們提供架構師，以便幫助他們根據實際項目製作文檔。當你緩和一下，並列出一系列具體的問題時，實際的研討會將變得更加高效。把會議的時間減半還可以讓評審過程更有針對性。
從好的方面來看，組織架構文檔研討會並且給銀行劫匪畫像（參見3.5節）可以爲你提供一組寶貴的系統文檔，以便以後引用參考。我也正在計劃系統地進行這種架構評審和記錄會議，並創建一份架構手冊，收集IT領域所有系統的重要架構決策。但這需要良好的寫作技巧和足夠的人力資源，而你只有搭乘架構師電梯前往頂層，向管理層清晰闡述系統架構文檔的價值，才能獲得這些支持。比如，這種文檔可以讓員工快速瞭解系統，發現架構的不一致之處，並且可以基於事實做出理性的決策，而這反過來又能促進向和諧的IT環境方向發展。在自頂向下的組織裏，有時候你必須努力把這些信息傳遞給頂層管理者，這樣他們才能慢慢地理解並給予你相應的支持。
1.6.4 不存在自由通過
有些時候，參加架構評審會議的團隊只是想要得到你對他們完成事項的認可，他們對你問的問題根本不感興趣。他們通常就是故意等待到最後一刻才申請架構評審，對你的“爲什麼”總是回答“因爲我們沒有時間”的那批人。對於這種情況，我有一個原則，那就是“你可以避開我的評審，但你不可能自由通過評審”。如果管理層認爲架構並不重要，因此架構評審沒有必要，那我寧願完全不做評審，而不是走個形式。
我認爲這與我的職業聲譽密切相關：我們很嚴格，但也很公平，而且能出色地完成工作。我的老闆曾用一句讚美的話總結了這一點，她說，她喜歡有架構團隊參與進來，因爲“我們沒有什麼可以私下交易的，沒有人可以欺騙我們，而且我們能花時間把事情解釋得很清楚”。這對於任何架構團隊而言都是一個很好的授權聲明。