?在很多程序員的大腦中，都會有這樣一個打怪升級的路徑：

曾經，我對這個路徑深信不疑，現在想想，也許是因為初出茅廬的我所看到的江湖太小。慢慢地，在江湖中久了、視野開了，就發現自己想得太簡單了。

第一個對“架構師”的定義

十多年前，在我初入江湖的時候，首先進入了一家位于深圳的大型軟件公司，研發人員的規模上千。面試我的人據說是公司中的架構師，我當時心里真的是對這個架構師充滿了仰慕之情，以至于至今我都依稀能夠回憶起他的容貌和聲音。

當時的后端主流技術是Struts+Spring+Hibernate，也就是當時業內常說的SSH；前端的主流技術是HTML+jQuery+原生JS。那時還沒有管理jar包依賴的maven，也沒有開箱即用的SpringBoot，如果在新的項目中要將上述技術整合起來供開發人員適用，往往需要幾天甚至幾周的時間，而這些工作都是架構師的職責。

于是，我給架構師下了第一個定義：

架構師就是把各種框架整合到一個項目中，提供通用的代碼，支撐開發人員完成業務功能的開發及提供必要的技術支持的人。

后來我回到了西安，此時的我，憑借自身的不斷努力，已經將上述的幾個技術掌握的很好了。在西安的一家規模不大的軟件公司中，我也做起了架構師，同時給自己定了一個工作原則：

不參與業務功能的開發，只為程序員提供通用能力和技術支持。

在之后的幾年中，我一直堅守自己對架構是的定義，原理業務知識，一心鉆研各種炫酷的技術，也一直作為團隊中面對困難的最后一道防線為開發人員提供支持。

第二個對“架構師”的定義

現在，我已經在江湖中摸爬滾打了12年，在架構師這個崗位上也已經有8年左右，原本簡單的認為“架構師即巔峰”的我，中間有一段時間迷失了方向。在不斷地與人溝通加上多次的面試經歷后，似乎在每個人的心里，對“架構師”這個名詞的理解都是不一樣的。

有一次，在參加一個架構師訓練營的時候，培訓教材中有一幅圖給我留下了很深的印象，雖然原圖我已無法找到，但表達的思想如下圖所示：

講師將架構師類比為交響樂中的指揮家，在他的描述中，架構師的視角應該比別人高，關注點并非獨立的一個個具體問題，而應該是用全局的視角去通盤考慮、整體規劃，然后指揮別人去將規劃落到實地。如果架構師過分的深入細節，只會讓他因無法抬頭看路而迷失方向，就像“不識廬山真面目，只緣身在此山中”一樣。

于是，我對“架構師”有了第二個定義：

架構師就是一個站在比別人更高的角度上看待問題，憑借更高的視角而統領全局，不會拘泥于技術細節的人。

但這樣一個定義也讓我在之后的面試中不斷地被面試官挑戰，在大部分的面試中，面試官對架構師的要求依然是某項技術的深度，而非整體的技術廣度。

第三個對“架構師”的定義

在近幾年的工作經歷中，我又接觸到了另一類架構師，他們常常被稱作“解決方案架構師”、“行業架構師”、“交付架構師”和“售前架構師”等。

在我最初從事這類工作的時候，我將之前給架構師下的兩個定義又重新審視了一遍，似乎此時的工作內容與那兩個定義都完全的不同。

經過近2年在解決方案架構師這個崗位上的歷練，發現這類架構師實際上是作為客戶的咨詢顧問存在的。工作內容幾乎已經脫離編碼了，而是給予某一個技術和產品體系，在客戶購買前、中、后提供貼身的咨詢服務，幫助客戶規劃技術方向、產品組合以及提供實踐方案等。

此時，“架構師”的第三個定義在我的心中誕生了：

架構師就是站在戰略的層面，對企業中信息化技術提供整體解決方案、路線圖規劃以及合規性監管等工作的人。

后來我考取了有“架構師黃金證書”的TOGAF，也向我打開了“企業架構”的大門，這也讓我更加確信我對架構師下的第三個定義。

“架構師”不是這么定義的

雖然我心中對架構師有了3個定義，然而它們非但沒有讓我對架構師地認識更加清晰，反而讓我更加地迷惑。尤其是在面試架構師這個崗位時，明明自己很強，但卻總覺得自己跟面試官的對話不在一個頻道上。這也一度讓我對自己的能力產生了懷疑，開始了自我否定。

在深入的思索及閱讀相關的資料后，我發現，問題的根源在于對“架構師”這個名詞的濫用。

Martin Fowler（微服務架構提出者之一）在其一篇談論架構師的文章中說到：

不管架構是什么，它都包含了重要的事物，而架構師就是關注這些重要事物的人。

我認為，“架構師”這個名詞的濫用，也正是因為這個崗位關注的是重要的事物，因此，行業中在招聘時，只要涉及重要的事物，就會稱其為“架構師”。

架構師的分類

其實，架構師是分很多種類的，每一類架構師都有自己的成長路徑——這與打怪升級是不同的。

首先，我將“關注竟要的事物的人”拆分為三類，如下圖所示：

• 常見的技術專家有：數據庫架構師、緩存架構師、框架架構師、工作流架構師”、大數據架構師等，這些架構師專注于對應領域的技術細節。
• 常見的產品、行業專家有：售前架構師、解決方案架構師、交付架構師、某某行業架構師等，這些架構師的關注點不在于研發和技術，而在于某個產品體系或某個行業的通用訴求。

對于上圖中的“架構師”而言，還可以繼續拆分，如下圖所示：

• 研發類架構師：為一個IT項目或產品負責，責該IT系統的技術規劃、研發和運維等工作。常見的崗位名稱有：系統架構師、軟件架構師、技術架構師等。
• 業務類架構師：普遍存在于各行各業，負責規劃其所在企業的業務邏輯。常見的崗位名稱有：領域專家、業務架構師、總設計師等。
• 企業架構師：普遍存在于各行各業，負責企業內外IT系統的規劃和建設。在非IT企業中時，主要負責企業內部IT的建設，為業務部門提供信息化的支撐；在軟件或互聯網等IT企業中時，則可僅負責企業內部系統也可內外系統均負責。

架構師的工作方式

這里所說的工作方式主要分為兩類：集權型和連接型。

（1）集權型架構師

集權型架構師通常在某一領域內擁有出眾的能力，是以“問題終結者”的角色出現在團隊之中的，當出現其他團隊成員無法處理的問題時，集權型架構師會成為團隊的最后一道防線。

集權型的優點有：

• 作為決策的唯一制定者，可以高效地統一團隊內的思想，保證了團隊內的一致性。
• 作為團隊內的經驗和技術方面的專家，會為其他成員帶來安全感。

集權型的缺點有：

• 集權型架構師作為唯一的決策者可以高效地統一思想，但在實際工作中，架構師往往并非距離問題最近的人，架構師的誤判也是比較常見的，由于集權型架構師是唯一的決策者，其他成員只能跟隨，因此極有可能做出錯誤的決策。
• 集權型架構師自身強大的個人能力在為其他成員帶來安全感的同時，會讓其他成員對集權型架構師形成依賴，導致其他成員的積極性和主動性降低，集權型架構師自身的工作強度隨之上升。

（2）連接型

連接型架構師就像黏合劑，他們更善于與他人合作。這類架構師可能不具備出眾的個人技術能力，但他們擁有豐富的經驗和溝通能力，通過和不同職能團隊之間深度合作，協助團隊解決問題，必要時可為團隊提供相應的資源和授權。另外，連接型架構師會成為技術人員和非技術人員之間的橋梁，將業務部門和技術部門連接在一起。

在我工作的早期一段時間，我都非常支持集權型，因為我覺得這樣的溝通成本最少、效率最高，但現在來看，其缺點也是不容忽視的，并且，系統越龐大缺點也就約明顯。因此我目前的推薦方式是以連接型為主，集權型為輔。

總結

筆者結合自己在軟件研發行業12年的工作經歷，提出了在不同階段對架構師這個崗位的3種定義。在與各類人群針對架構師的討論過程中，得出“架構師”一詞在行業中被廣泛的“濫用”這一結論。

在對架構師這一崗位深入的思索后，提出了架構師的分類體系。筆者認為，被濫用的“架構師”一詞實際上表達了包括技術專家、架構師和產品、行業專家在內的不同方向，并對架構師這個方向繼續分類為：研發類架構師、業務類架構師和企業架構師三類。

總之，架構師關注重要的事物，視角應該更高，避免陷入細節；系統越龐大，越是需要連接型的架構師，當團隊躊躇不前時，需要集權型架構師快速地決斷。?