架構是一種能力，它不是頭銜。換句話說，我們需要具備架構能力，但不一定要成為架構師。

?[[331339]]?

圖片來自 Pexels

既然這樣，那我們還需要架構師嗎?還需要架構部門嗎?我給出的答案是：不需要，因為每個人都應該是架構師。

為什么架構師不 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 架構組(中間件團隊)的“我行我素”使用 Spring Boot 嗎?

這種重復造輪子完全沒有必要。在云原生成熟之前，PandoraBoot 就是最好的解決方案。架構組，帶著整個 BU 一起——卒!

在此我想稍微提一下支付寶的中間件團隊(架構部門?)，我不知道歷史，也許 TecFin 的確是有其特殊性。

但是，從整個集團角度來說，我認為統一的技術中臺，應該是更好的做法。

對一個企業來說，也許在某個特殊階段，的確需要實體架構組織去保障落實架構工作。

但大部分情況下，特別是在技術體系已經相對完備的情況下。比如在阿里，業務技術部門，最好是不要在 BU 內設立專門的架構組織。

相信我，在我的職業生涯中，看到過很多業務技術部門設立的技術架構組織案例，基本都是以失敗而告終。

人人都是架構師

架構師不行，架構部門也不行。那架構的事情誰來做呢?看一下你座位左邊的，再看一下你座位右邊的，再看一下你主管.... 別看了，他們是要做，你自己也要做，人人都是架構師。

首先，讓我們來看一下什么是架構能力，我認為廣義的架構能力，應該是一套分析問題、解決問題的方法論。

它需要你具備洞察問題本質要素，理清要素之間的關系，以及制定相應策略的能力。

??

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

怎么理解?我認為有如下三點：

①作為技術一線員工，也許你的工作時間并不長，架構能力相對較弱，沒有捷徑，學習學習再學習，成長成長再成長，架構作為能力是可以習得的，沒那么高深。

②作為技術團隊 Leader，你必須要具備一定的架構能力了，不管是業務架構還是應用架構。

TL 都應該具備能發現問題里的本質要素，以及理清要素之間關系的能力。如果你已經是一名 TL，然而架構能力還比較欠缺，則需要盡快去補足。

不足沒有關系，有關系的是停止了學習和成長。就像懷素說的，很多后勁不足的人主要是過早的停止了學習和成長，你的能力應該是圍繞著你的層級震蕩的，這個震蕩范圍偏差不會太大，遲早會歸于一個相對合理的區間。

③作為 CTO(沒吃過豬肉，但看過豬跑)，CTO 沒得選了，必須是一個非常、非常優秀的架構師才行。你不僅要熟悉業務架構，精通技術架構。

更重要的是因為屁股問題(康威定律)，你還要去設計組織架構，讓生產關系適應生產力的發展。唯有如此，技術才能穩定高效的支撐業務發展。

聽說，騰訊沒有 CTO，所以他們每個 BU 都有一套自己的技術棧和中間件，大家各自為政。

??

如果上圖對騰訊的架構描述屬實的話，我覺得最好他們還是要有一個 CTO 比較好。

因為很明顯，對于通用的技術解決方案，比如大數據處理，技術中間件。沒必要重復造輪子，復用很明顯是更加科學的做法。

在這一點上，如下圖所示，我認為阿里無疑是走在騰訊前面的。其中，數據中臺和技術中臺，我認為是阿里做的最好，也是最 NB 的地方。

至于業務中臺為什么旁邊飄著一朵小烏云呢，這是因為業務的抽象復用要比技術的抽象復用難的多的多的多，不同業務面臨的業務問題的差異是巨大的，而不同業務面臨的技術問題相對業務問題，要穩定的多。

我想，這也是為什么技術中臺已經成功，業務中臺還在探索的原因吧。

??

如何踐行

最后，分享一下我是如何在團隊做“架構師”的。

一方面，我會不遺余力的培養團隊成員的架構能力，我會不斷的和他們探討系統的邊界是否合理，模型抽象是否合理，流程抽象是否合理，模塊設計是否合理。

并要求他們說清楚設計背后的思考和理念是什么，然后用我自己的方法論、思考和他們去碰撞，這樣反復進行，我和團隊都會有所成長。

另一方面，我會 hands-on coding，參與核心業務邏輯的編碼工作，這點很重要。

一定要深入代碼細節中去做架構，因為很多問題只有在 Coding 的過程中才會暴露出來。

另外，無謂的討論是低效的，驗證架構是否合理的方式，就是結合業務場景，寫代碼去驗證。

設計是否合理，是否優雅，在 Coding 的過程中，便能獲得很好的反饋。我不止一次，在寫代碼的過程中，去重構原來的設計，甚至是完全推翻重來。

總而言之，架構作為一種能力，作為我們工程師的核心成長目標，值得我們去孜孜不倦的追求。而架構師作為一個職位，在大部分情況下，它就是個“呵呵”。

作者：從碼農到工匠

編輯：陶家龍

出處：轉載自微信公眾號從碼農到工匠(ID：craftsman_frank)

??