我在阿里巴巴工作期間是一個名副其實的“刺頭”，批判中臺、批判架構師、批判技術管理者，當然，也包括自我批判。

今天來聊聊批判架構師！

Martin Fowler在他的一篇IEEE論文“Who Needs an Architect？”中提到，

能使團隊更加敏捷的架構師比只做決定的架構師要更有價值，因為只做決定的架構師會成為團隊的瓶頸（bottleneck）。顯然，一個架構師的價值和他做的決定是成反比的。

實際上，在這篇文章中，Martin甚至不認為架構師（Architect）這個名詞是合適的，他認為更合適的叫法應該是向導（Guide），即一個更有經驗的人帶領團隊走出復雜的迷霧。

尷尬的架構師

在進入阿里巴巴工作之前，我就職于eBay的支付部門。當時有一位架構師，所有的設計和方案都需要獲得他的審批才能通過，結果他成了整個團隊的瓶頸，很多事情都堆積在他那里。

工程師很難受，光是給他介紹和討論業務及系統設計就需要花費大量的時間（因為時差原因，經常要討論一周才有定論）；他也不容易，要理解每個系統的結構和業務細節也是很累的。

這里存在的主要問題是這位架構師不在執行團隊內部，不了解細節，所以很難給出有價值的建議。對于很多細節，我們認為他不懂，他的方案也無法讓我們信服，合作起來自然就很困難。

尷尬的架構部門

如果說架構師是輕量級解決方案，那么還有一個“大規模殺傷性武器”——設立一個專門的架構部門。

在阿里巴巴的B2B部門曾經就有這樣一個架構組。我記得在當年的啟動會上，負責人要求我們畫架構圖，我質問他這個架構組存在的意義是什么。如果只是畫架構圖，給老板當PPT用的話，那么我不愿意畫這個圖。

實際上，畫架構圖這種務虛任務還好，雖然用處不大，但也構不成殺傷力。真正構成殺傷力的是架構組不甘無為而挖空心思要“做事情”。可以說，在業務技術部門，架構組這種想做事的行為是很危險的，事情越大，殺傷力越大。

為什么這么說呢？我們不妨先來看一下，在業務技術部門中的架構組能做什么。

（1）業務架構？我是營銷域的、訂單域的、商品域的、供應鏈域的……如果架構組想比產品經理、運營人員、工程師更懂業務領域、業務流程和業務細節，恐怕很難。一個合格的產品經理應該能做好業務領域的抽象和業務流程的抽象，至于細節，好像沒有人比一線開發人員更懂。——架構組，卒！

（2）應用架構？需求相對清晰之后，在應用架構領域有一些影響力的團隊負責人（Team Leader，TL）在和團隊討論邊界劃分和設計方案的時候，尚且會時常爭論不休。架構組的“外人”想來指手畫腳？這是多么碾壓程序員的自尊心啊！——架構組，卒！

（3）技術架構？好吧，讓我們架構組回歸技術本身，做點純技術的事情。可是對不起，但凡有點價值的技術中間件都已經有中間件團隊在做了。——架構組，帶著整個部門一起，卒！

因此，在企業內部設立架構部門是一件要十分謹慎對待的事情。

對一個企業來說，在某個特殊階段，也許的確需要實體架構組織去保障落實架構工作。但在大部分情況下，特別是在技術體系已經相對完備的情況下，最好不要在部門（Business Unit，BU）內設立專門的架構組織。在我的職業生涯中，我看到過很多業務技術部門嘗試設立技術架構組織，基本都以失敗告終。

人人都是架構師

架構師不行，架構部門也不行。那由誰來做架構的事情呢？

看一下你左邊的同事，再看一下右邊的同事，再看一下你的主管……別看了，他們的確要做，然而你自己也要做——人人都是架構師。

在探討架構師的工作職責之前，我們先來看一下什么是架構。關于這個問題，每個人的答案可能都不一樣。我曾經看過一本技術書，其中用了一章的篇幅討論架構的定義，但是最終也沒有說得很明白。我個人比較認可的關于架構的定義是來自IEEE的定義。簡單來說，架構的定義就是要素結構+關系+指導原則。要素（Components）是指架構中的主要元素，結構是指要素之間的相互關系（Relationships），再配合指導原則（Guidelines），便構成了架構，如圖1所示。

圖1 ?架構的定義

從架構定義中，我們不難發現，架構師所要具備的架構能力實際上就是一套分析問題、解決問題的方法論。它需要你具備洞察問題本質要素、厘清要素之間的關系，以及制定相應策略的能力。

從這個角度出發，架構能力就是核心競爭力，每個工程師都應該具備一定的架構能力，人人都應該是架構師。

（1）作為技術一線的員工，如果你工作的時間并不長，架構能力相對較弱，那么沒有捷徑，只有學習學習再學習、成長成長再成長，架構能力是可以習得的，沒那么高深，但也沒那么容易，需要長期積累。

（2）作為技術團隊負責人（TL），你必須要具備一定的架構能力。不管是對于業務架構，還是應用架構，TL都應該具備發現問題的本質要素及厘清要素之間關系的能力。如果你是一名比較欠缺架構能力的TL，那么你需要盡快去補足，不足沒有關系，可怕的是停止了學習和成長。正如我比較欣賞的一位技術負責人懷素所說的，很多后勁不足的人主要是過早地停止了學習和成長，你的能力應該是圍繞著你的層級上下震蕩的，這個震蕩范圍偏差不會太大，遲早會歸于一個相對合理的區間。

（3）作為首席技術官（CTO），那么沒得選了，你必須是一個非常優秀的架構師才行。你不僅要熟悉業務架構、精通技術架構，還要通過組織架構設計去解決部門墻問題，讓生產關系適應生產力的發展。唯有如此，才能使技術穩定高效地支撐業務發展。

有一些互聯網公司沒有CTO，他們每個業務單元都有一套自己的技術棧和中間件，大家各自為政，如圖2所示。

圖2 ?各自為政的技術體系

針對上述技術體系，最好設置一名CTO。因為對于通用的技術解決方案，比如大數據處理、技術中間件，沒必要重復造輪子，顯然復用是更科學的做法。

本文節選自《程序員的底層思維》一書，想要了解更多相關內容，歡迎閱讀本書！

▊ 《程序員的底層思維》

張建飛 著

• 這是一本超越具體編程技法的技術書：職場晉升不僅需要技術能力，更重要的是思維能力。本書帶你學會用底層思維解決復雜技術問題，突破職場“天花板”。

• 這也是一本培養思維能力的通用技能書：打破認知局限，培養通用的思維能力。本書幫你跳出思維定勢，輕松解決生活及工作中遇到的問題。

本書涵蓋程序員應知應會的16種思維能力，共18章，分為三部分。

第一部分主要介紹抽象思維、邏輯思維、結構化思維、批判性思維、維度思維、分類思維、分治思維、簡單思維，以及成長型思維等解決日常問題的基礎思維能力。

第二部分結合軟件行業的特點，主要介紹解耦思維、契約思維、模型思維、工具化思維、量化思維、數據思維，以及產品思維等專業思維能力。

第三部分主要是對上述思維能力的綜合運用實踐。

粉絲專享六折優惠，掃碼即購！

如果喜歡本文 歡迎?在看丨留言丨分享至朋友圈?三連

往期推薦

成為優秀軟件工程師的三條路徑

好代碼和壞代碼

大疆再遭制裁，設計軟件Figma斷供！中國工業軟件如何應對全面封禁？

美團搜索多業務商品排序探索與實踐

史海峰：我的架構師修煉之道

一年之計：如何構建知識體系？

千萬級流量的大型分布式系統架構設計

40歲從零開始學習軟件開發，四年后我成了首席研發

一張圖看懂微服務架構路線

入行二十年的一些認知

微信支付架構為什么這么牛？

總結

以上是生活随笔為你收集整理的今天我要批判架构师的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。