架構是一種能力，它不是職位。 換句話說，我們需要具備架構師的能力，但不一定要成爲架構師。就像鄧公，他被稱爲改革開放的總設計師，但他不是設計師。
既然這樣，那我們還需要架構師嗎？還需要架構部門嗎？
我給出的答案是：我們不需要架構師，因爲每個人都應該是“架構師”。
爲什麼架構師不work
在來阿里之前，我是在eBay的payments部門工作，當時有一個架構師叫Scott，所有的設計和方案都需要獲得他的approve才能通過，結果他成了整個團隊的bottleneck，很多事情都block在他那個地方。
工程師很難受，光是給他介紹業務和系統設計，就需要花費了大量的時間討論（因爲時差原因，經常一個討論要一個星期纔會有定論）。他也不容易，要去理解每個系統的結構和業務細節，已經累成狗。
效率低下尚且不說，這樣的折騰最後帶來了什麼益處呢？說實話，我現在回想起來，除了幾個變量命名我覺得Scott說的比較有道理以外，其它還真沒什麼更有價值的東西了。
這裏我想主要問題是因爲Scott不在執行團隊內部，他不瞭解細節，所以也很難給出有價值的輸入。很多東西，我們認爲“他不懂”，也就是他的方案不能讓我們信服，自然，合作起來就很困難。
很多人喜歡拿建築架構和軟件架構做類比，認爲既然建築需要建造師，那麼軟件也應該需要架構師。Too simple, too naive!
其實，二者除了都需要有圖紙，都有藝術的成分之外，並沒有多少共同之處。
首先，建築和軟件不同。建築的標準性、確定性要比軟件高的多，而軟件的靈活性簡直是沒有邊界的，任何一個function都可以有無數的實現方式，沒有定式。因此，軟件架構圖的約束力，要遠遠低於建築圖紙的約束力。建築如果不按照設計來，你就不能實現其功能。而軟件設計文檔和代碼，完全可以是兩個平行宇宙。
其次，建築工人和程序員不同。程序員的工作絕對不僅僅是“搬磚”這麼簡單，軟件設計是一個充滿挑戰的創造性工作。它需要對各種微妙之處進行權衡，只有深入其中，hands-on coding，才能真正的發現問題。因此，飄在開發團隊之上，指手畫腳的PPT架構師，註定是很難成功的。
爲什麼架構部門不work
如果說架構師是輕量級解決方案的話，那麼，還有一個“大規模殺傷性武器”就是設立一個專門的架構組織。
幾年前的B2B就有一個這樣的架構組織。我記得在當年的“架構圖”KO會議上，當時的負責人要求我們畫架構圖，我就質問他這個架構組存在的意義是什麼？如果只是畫架構圖，給老闆當ppt用的話，這個圖我不願意畫。我還說KO不一定要Kick Off，也可以是Kick Out。不止於此，而後我又“上書”到當時B2B的CTO，再然後… 隨着CTO的調離，架構負責人的離職，也就沒有然後了…
實際上，“架構圖”這種務虛活動還好，雖然無用，但也構不成殺傷。真正構成殺傷的是架構組織不甘無爲，挖空心思要“做事情”。
可以說，在業務技術部門，架構組這種“想做事”的行爲是很危險的，事情越大，殺傷力越大。何出此言？
不着急，我們不妨先來看一下，在業務技術部門，架構組織能做什麼。
-
業務架構？我是營銷域的，是訂單域的，是商品域的，是供應鏈域的… 你架構組告訴我，你對業務領域，業務流程，業務細節的理解比PD、運營、工程師更懂？恐怕難，一個合格的PD應該能做好業務領域的抽象和業務流程的抽象，至於細節，沒有人比一線開發更懂。架構組，卒！
-
應用架構？需求相對清晰之後，我一個在應用架構領域尚且有一些影響力的TL在和團隊討論邊界劃分，設計方案的時候，時常會爭論不休。你一個架構組的“外人”想來指手畫腳？呵呵，你這是有多低估程序員的自尊心啊。架構組，卒！
-
技術架構？好吧，那我們架構組迴歸技術本身，做點純技術的事情總可以吧。對不起，但凡有點價值的技術中間件，已經有中間件團隊在做了。還記得，ICBU架構組搞的Hilton容器和AE架構組（中間件團隊）的“我行我素”使用SpringBoot嗎。這種重複造輪子完全沒有必要。在雲原生成熟之前，PandoraBoot就是最好的解決方案。架構組，帶着整個BU一起——卒！
在此我想稍微提一下支付寶的中間件團隊（架構部門？），我不知道歷史，也許TecFin的確是有其特殊性。但是，從整個集團角度來說，我認爲統一的技術中臺，應該是更好的做法。
支付寶的發展歷程我不是很瞭解，也許在某個特殊階段，的確需要實體架構組織去保障落實架構工作。
但大部分情況下，特別是在技術體系已經相對完備的情況下。比如在阿里，業務技術部門，最好是不要在BU內設立專門的架構組織，相信我，在我的職業生涯中，看到過很多業務技術部門設立的技術架構組織案例，基本都是以失敗而告終。
人人都是架構師
架構師不行，架構部門也不行。那架構的事情誰來做呢？看一下你座位左邊的，再看一下你座位右邊的，再看一下你主管… 別看了，他們是要做，你自己也要做，人人都是架構師。
首先，讓我們來看一下什麼是架構能力，我認爲廣義的架構能力，應該是一套分析問題、解決問題的方法論。它需要你具備洞察問題本質要素，理清要素之間的關係，以及制定相應策略的能力。
從這個視角出發，我認爲架構能力就是核心競爭力，每個工程師都應該具備一定的架構能力，人人都應該是架構師。 怎麼理解？
-
作爲技術一線員工，也許你的工作時間並不長，架構能力相對較弱，沒有捷徑，學習學習再學習，成長成長再成長，架構作爲能力是可以習得的，沒那麼高深。
-
作爲技術團隊Leader，你必須要具備一定的架構能力了，不管是業務架構還是應用架構。TL都應該具備能發現問題裏的本質要素，以及理清要素之間關係的能力。如果你已經是一名TL，然而架構能力還比較欠缺，則需要儘快去補足。不足沒有關係，有關係的是停止了學習和成長。就像懷素說的，很多後勁不足的人主要是過早的停止了學習和成長，你的能力應該是圍繞着你的層級震盪的，這個震盪範圍偏差不會太大，遲早會歸於一個相對合理的區間。
-
作爲CTO（沒喫過豬肉，但看過豬跑），CTO沒得選了，必須是一個非常、非常優秀的架構師纔行。你不僅要熟悉業務架構，精通技術架構。更重要的是因爲屁股問題（康威定律），你還要去設計組織架構，讓生產關係適應生產力的發展。唯有如此，技術才能穩定高效的支撐業務發展。
聽說，騰訊沒有CTO，所以他們每個BU都有一套自己的技術棧和中間件，大家各自爲政。
如果上圖對騰訊的架構描述屬實的話，我覺得最好他們還是要有一個CTO比較好。因爲很明顯，對於通用的技術解決方案，比如大數據處理，技術中間件。沒必要重複造輪子，複用很明顯是更加科學的做法。
在這一點上，如下圖所示，我認爲阿里無疑是走在騰訊前面的。其中，數據中臺和技術中臺，我認爲是阿里做的最好，也是最NB的地方。至於業務中臺爲什麼旁邊飄着一朵小烏雲呢，這是因爲業務的抽象複用要比技術的抽象複用難的多的多的多，不同業務面臨的業務問題的差異是巨大的，而不同業務面臨的技術問題相對業務問題，要穩定的多。我想，這也是爲什麼技術中臺已經成功，業務中臺還在探索的原因吧。
如何踐行
最後，分享一下我是如何在團隊做“架構師”的。
一方面，我會不遺餘力的培養團隊成員的架構能力，我會不斷的和他們探討系統的邊界是否合理，模型抽象是否合理，流程抽象是否合理，模塊設計是否合理。並要求他們說清楚設計背後的思考和理念是什麼，然後用我自己的方法論、思考和他們去碰撞，這樣反覆進行，我和團隊都會有所成長。
另一方面，我會hands-on coding，參與核心業務邏輯的編碼工作，這點很重要。一定要深入代碼細節中去做架構，因爲很多問題只有在coding的過程中才會暴露出來。另外，無謂的討論是低效的，驗證架構是否合理的方式，就是結合業務場景，寫代碼去驗證。設計是否合理，是否優雅，在coding的過程中，便能獲得很好的反饋。我不止一次，在寫代碼的過程中，去重構原來的設計，甚至是完全推翻重來。
總而言之，架構作爲一種能力，作爲我們工程師的核心成長目標，值得我們去孜孜不倦的追求。而架構師作爲一個職位，在大部分情況下，它就是個“呵呵”。