引子
究竟是什麼讓你在同一個位置上——例如程序員或技術負責人——工作了三年、五年或者更久，而仍然得不到任何的發展空間？你覺得自己已成爲技術圈中的大牛，並信心滿滿地去拿明天就要頒發的某某大獎，然而卻仍然停留在同樣的技術職位上，去年到今年漲的薪水甚至填不平物價升幅？於是，你開始對老闆不滿，對員工不滿，對昨天升職的那個同事不滿……你開始計劃明天就要跑單，或者準備考慮提出加薪卻又心懷忐忑。
如果技術人員有發展的軌跡，那麼他要麼“看透工具的本質，把關注點轉移到‘團隊’的圈子裏去”，要麼“順着代碼鋪就的道路，亦步亦趨地成爲良匠大師”。僅以技術方向而言，你大概可以做到架構師、總架構師甚至首席架構師；但問題是：你現在還只是一個程序員。那要如何才能踏上通往架構師之路呢？本文爲你解析一個架構師的能力模型。
你能不能做一個好的架構師？
架構師不是界定一個技術高下的職位名稱，而是一個職務。所謂職務，包括職——職位，務——工作。前者決定了你具備哪些資源，可以影響到怎樣的範圍，以及面向的機構，後者則簡單地是你需要完成的工作列表。
所以我說“架構師”不是指“一個能做架構的人”。前者是把架構師當職能，後者是當工人。能做一份工作列表中的事，並不等於就成爲相應職位上的人。在管理體系裏面，你的個人特性決定了你在哪個位置，而技術技能只是做事實施的必需。架構師這個職務，同時要求較高的個人素質和技術能力，因此它的進取之路總結起來就是：做人、做事，做架構師。
因此“模型”由“個人特性”和“技術技能”兩個方面構成，在第一張圖中，我特別說明“個人特性”既包括人際關係的能力，也包括（具體）業務能力；“技術技能”也是如此。所以個人特性主要與“做人”有關，部分地也包含“做事”的要素。
圖1 架構師能力模型
“有效溝通”以及“學會談判”與做具體的事無關，是個人能力特性的公共方面。前者是過程，後者是知道如何定目標與求結果。而“風險與防備”是做事過程控制的關鍵，與前面兩項正好構成了一個做事基本能力的完整體系。基本上，這三項個人特性都是一個“普通程序員”所不具備的，甚至在大多數情況下，普通程序員並不願意去具備這樣的個人特性，因爲在許多陷於技術泥淖的開發人員看來：溝通總是會使事情變得更加麻煩，談判則徒耗時間而無濟於事。然而事實上，在整個的架構決策過程中，架構師需要不停地溝通與談判。將“架構”變成“決策”的過程，其實就是對各個技術角色（及其思想）兼容幷包的過程，你需要不斷地協調需求、實現之間的各種問題，也需要面對各種投資者（時間、資金、人才等方面的決策者）進行談判，以確定項目的規模——沒有規模也就沒有範圍，沒有範圍如何展開設計呢？
一部分開發人員會認爲上述過程是“項目經理”的事情，但真的如此嗎？當你作爲一個更高級別的架構師，以至於要影響到多個項目的決策時，你就全然不會有這種感受了。因爲這種情況下，你的決策將先於項目的啓動，或者說你已經不單單是一個技術角色了。
設計是架構能力的一部分，但架構師不是設計師——看清楚二者之間的不同，你才真正邁出了架構師職業生涯的第一步。
抽象是思維能力、模型化是表達能力
個人特性中另一個非常重要的方面是“抽象思維”，而這是與架構師角色直接相關的一種能力。這種能力既有職業技能特徵，又是普遍性的能力。
所謂普遍性的能力，是指“抽象”在我們——作爲人這種個體的——生活中無處不在。例如我們說花、草，說桌、椅……我們用語言去指稱任何一個既已存在的（可以脫離我們的語言而自然存在的）事物時，就用到了抽象。說“桌子”的時候，既沒有描述桌子的具體形式，也沒有說明它的規格，但我們用這個名詞時，所有人都知道“桌子是什麼”。所以，名詞概念是整個抽象邏輯系統中的主體。如果失去了這些名詞定義，我們基本上不能說話，也不能描述任何東西——那便到了“只可意會不可言傳”的境地。
用現有的成熟語彙去描述你的系統時，大多數人會理解你所表達的含義，例如我們說“這個系統設計爲一個三層結構”。然而架構師面臨的系統在許多細節上並不見得能夠用成熟的語彙去描述，因此必須自已構建一個抽象系統，這就需要概念抽象能力、概念表達能力和基於概念的邏輯表達能力。
概念抽象能力是一種思維能力。簡單地說，就是“把目標分解或概括清楚”：你要麼概而言之“它是什麼”，要麼詳細地說明“它包括什麼”。必須使用大量的語彙來陳述這個“什麼”，這不單單是表達爲文字，也表達爲你在思想過程中的一個完整系統。通常用的方法是“映射系統”。例如你可以用數學中的“數軸”來映射“實數域”。將目標系統形式化爲一個概念化的、可討論的結構系統後，你的抽象過程就基本結束了。
圖2 能力模型中的個人特性
然而這個“抽象系統”可能只構建在你的思維意識裏，還必須把它描繪出來。因爲不能只是你自己思考清楚，系統就能設計完成。這個“描繪”就依賴於後面兩種表達能力，一種是描繪概念實體，一種是描繪實體上的邏輯——有趣的是，這似乎又回到了“程序＝結構＋算法”。
現在大家回過頭來看看UML，或者更多種類的ML（建模語言），他們就用於表達這兩個方面的東西：要麼是概念實體（例如用一個框表明系統邊界），要麼是實體上的邏輯（例如用箭頭表明邏輯時序）。
所以大家應該清楚，我們再如何稱讚UML，它也只是一種對模型化系統的“表達能力”，你只能把它當一種輔助表達的工具去使用，它本身既不能幫助思考，也不見得能作爲抽象過程中的或抽象思維環境中的參考。
任何一個優秀的架構師都有自己獨特的思考方式，這決定了他如何抽象系統，以及如何“創造性地”設計與構畫這個系統。這種“獨特的思考方式”貫徹他從孩童開始的整個成長過程，直至他形成獨立的社會觀、人生觀與世界觀。他認識世界的方式和接受世界的能力決定於他如何思考，也反映了他這種思考方式的“獨特性”。但這並不表明他有特立獨行的行爲特性（我們這裏只說他的思考方式），我們不應介意他是否用某種語言（例如UML或者形式化編程語言）來表達他的思考結果。
推動：設計做大，實施做小
架構師首先是把問題的真正目標確定下來，然後變成系統設計、平臺設計或架構設計。而在此之後設計輸出將會有兩個方向的發展，一是被忠實地貫徹下來，二是被變形地發展下去。兩個方向都存在致命的危險：架構最終能否被完整實現。對前者來說，可能是架構設計過度，或設計本身出現了錯誤；後者則是對架構直接的傷害。
所以架構師必須參與實施的全程——尤其是在架構被映射爲目標系統的前期。在這個階段中，架構師的任務就是推動架構實施，以保證在項目全程的設計／架構／體系的一致性。除了直接跟設計師或設計團隊溝通，以保證他們的設計在你可以控制的範圍之內以外，架構師還必須有階段化設計的能力。這種能力用於將一個原本規模宏大的架構設計，變成較小的、易於實施的、對開發團隊來說可控的關鍵點。例如在體系層次的規劃上，設計可能是獨立、異質的、可遷移的存儲框架來實現數據層，但在（前期的）實施上，這裏可能被表達爲本地數據庫，並要求前端開發人員必須通過一個清晰的數據交互層來訪問——例如一組數據存取接口，或一個獨立數據服務組件。開發人員可能在這裏遇到障礙：因爲要通過這些中間層來訪問本地數據庫，純粹是多餘的。然而，正是這“多餘的工作”提供了系統彈性，爲並行團隊開發公共存儲服務爭取了週期，也爲將來的靈活部署與數據遷移提供了可能。
這裏的關鍵就在於，無論原始系統設定有多大，實施時總是在“做小”。每一個局部的實施塊都是可控的，併爲它在整個體系空間中留下了位置和接口，這樣纔可能由“小的部分”做大。一個大系統的架構師可能同時在考慮許多個項目中的、不同位置的架構，並且清楚這些項目最終的總體規模。而這，就是平臺架構師和體系架構師所涉的領域。
圖3 架構師模型圖中的“實現能力”
架構真的是“好不好”的問題嗎？如同我對工程的理解一樣，架構問題的根本，也並不在於它是否完美或漂亮，而是在於是否合用。因此架構師必須對實施架構的團隊以及實施過程有充分了解，知道他們的能力缺陷，知道實現過程要消耗的資源，清楚每個環節可能的故障以及先兆。只有這樣，架構師才能設計一個讓這個團隊能實現，而且在實現過程中能受控的架構。
要知道，你作爲架構師被請來，不是畫幾張圖紙交給項目經理，說：你們去做吧，做不出來是你們不會做。即使你可以身體力行，在這個團隊中教大家、培養大家，那麼公司的開銷呢？風險呢？這些東西難道就不考慮了？項目的週期因爲實現的複雜程度而無法控制時，項目就死掉了。那麼，追根究底來說，是不是架構師的問題？是啊，你爲什麼會做了一份“不合用”的架構呢？——你都不知道項目如何開發、由誰實施、如何管理等等，又如何能面對這些實際環境去設計架構呢？
所以這一部分能力，是要在你的開發經驗、團隊經驗以及用人識人的經驗中去找的。參考模型圖的“實現能力”下的“設計能力→瞭解你的主要溝通對象”和“架構推行”等分支，對你或有一些可用的提示。
局部與全局
架構是一個從全局到局部的過程，而實施正好反過來，是從局部到全局。這也正是“設計做大，實施做小”的另一個層面的含義。設計大纔可以見到全局，才知道此全局對彼全局的影響；實施小纔可能關注細節，才談得上品質與控制。
事實上，大多數情況下架構是在爲“當前項目之外”去考慮，這可以看成全局關注的一個組成部分。因此我們需要界定所謂“全局”的範圍：超出公司或整個產品系列、產品線或規劃的範圍纔是多餘的。
所以當架構決策談及“全局”時，其目標並不見得是“保障當前項目”，而又必須由當前項目去完成。
一個經常被用到的例子是：如果僅爲當前項目考慮，那麼只需要做成DLL模塊；如果爲產品線考慮，可能會是“管道＋插件”的結構形式。而“管道＋插件”的形式顯然比做成DLL模塊更費時，這個時間成本（以及其它成本）就變成了當前項目的無謂開銷。
這種全局策略對局部計劃的影響是大多數公司不能忍受的，也被很多團隊所垢病。然而這卻是架構師角色對體系的“近乎必然”的影響——如果你試圖在體系中引用架構師這個角色的話。一些情況下，體系能夠容納這種影響，例如“技術架構師”試圖推動某種插件框架，而正好開發人員對這項技術感興趣，那就順其自然地花點工夫去實現了。但如果不是這樣，實施者或實施團隊看不到“多餘的部分”對他們的價值時，來自局部的抵觸就產生了。
這種情況下，平衡這些抵觸就成了架構推行的實務之一。在我看來，“平衡”是全局的藝術和局部的技術。也就是說，一方面架構師要學會遊說，另一方面也要尋求更爲簡潔的、成本更小的實現技術。只有當整個體系都意識到（你所推行的）架構的重要性，而且實施成本在他們可以接受的範圍之內時，他們纔會積極行動起來。
所以所謂平衡，其實也是折衷的過程。構架師只有眼中見大，才知道哪些折衷可以做，而哪些不能。所謂設計評估（模型圖中的實現能力->設計能力->設計評估分支）並不是去分析一個設計結果好或不好，而是從中看到原始的需求，看到體系全局的意圖，然後知道在將設計變得更爲“適當”時可以做哪些折衷。同樣的原因，架構師也必須知道自己的決策會產生的影響，才能控制它們，以防它們變成團隊的災難。有些時候，架構師甚至需要拋棄一些特性，以使得項目能夠持續下去。因爲產品的階段性產出只是整個戰略中的一個環節，而不是全部。
其它
“怎麼做一個架構師”這個問題得分成兩個部分來看，一個是“做到”，一個是“做好”。由於架構師本身不過是一個技術職位，所以時機成熟了自然會做得到。但問題是，真有一天你被放在這個位置上了，你能做得好嗎？
我瀏覽過幾套所謂培訓機構的有關架構師的教程，也翻閱過一些講架構的書。我發現他們普遍地是將架構作爲一種“職業技術”來講，就像培養程序員或者縫紉工一樣來教育。但就我的經驗來說，架構並不是一件純粹表現技術能力的工作，所以並不是翻幾本書學幾種方法就可以投入“實戰”的。更深層的問題是，架構師其實不是“戰”出來的。昨天跟同事討論這個話題，他把我們這幾年來的一些思考用了三句話來概括，非常精彩：從無到有的，是架構；從表到裏的，是抽象；從粗到細的，是設計。
那麼到底什麼是架構呢？從上面的概括中你是看不到答案的。到底如何做架構呢？從本文中你也是看不到答案的。然而我說，“你看不到答案”的根源其實是在於你的眼光與心性——後面這個詞換成現代白話，就是“思想”。真正阻礙了你成爲優秀架構師的，也許正是你既有的知識與思想方法，扔掉它們，接受一些全然有別的信息，也許正是良好的開端。
或許你現在正憤憤然：這篇文章怎麼空洞無物？——我甚至能想象到一些讀者的表情。然而請在問題面前停下來，不要急於給出答案。正如你將“?”稍微變下形，它就成爲了“!”一樣，問題的本身，就是答案。
