拿破崙說

不想當將軍的士兵不是好士兵。

類比到IT行業

不想當架構師的程式設計師不是好程式設計師。

雖然此種類比不一定恰當。也許你就想簡簡單單、安安靜靜寫寫程式碼，這種想法沒錯。國外，就有很多老程式設計師，與世無爭的寫程式碼，把程式碼寫漂亮，沒有那麼功利非要給自己掛一個架構師的頭銜。相比較而言，國內就要現實太多。工作N多年後，如果還是在一線碼農，多數時候也會被鄙視，也許還會被BOSS扣上此人發展潛力不行。還有N多人，換工作的時候，非架構師職位不來。

年前和團隊人開會，有個同事的給他的定位是漸漸可以做更多架構規劃相關的工作。他說，對於如何做架構還有很多迷茫。有些人也許不會選著這條路；有些人正在這條路上，但是很迷茫：我該如何成為一個架構師呢？

視野

記得有個架構師講過

“視野決定格局”

自己還是比較認同這句話，架構師首先要重構的是自己的視野。視野不是裝逼。視野可以作為一個看問題、積累專業領域知識的內在驅動力。

僅僅說視野，未免太虛，如何把視野坐實是很重要。由內在（思維、心態、方法）驅動外在（專業知識）是需要紮紮實實去積澱。

常常聽到這樣的觀點

“做架構師，一定要有全域性的視野或關注”

如何理解全域性？負責幾百個應用就是全域性？負責單個系統就不是全域性？
個人對全域性有如下理解：

• 單點、模組、鏈路

  由點到面去積累知識，從全域性和細節兩條路逼近學習；不僅僅關注自我，還超越自我。要做一個架構師，不僅僅需要知道自己能做什麼，還需要知道別人能做什麼，還需要自己不能做什麼。所以要做好，需要超越自我，積累更為全域性的知識，首先是你的上游需要理解，進一步是上游的上游需要了解。

• 過去、現在、未來

  從過去看為什麼來；從現在看缺什麼；從未來來看走向哪裡。架構師需要看的更遠，比如半年，一年，三年。預知未來的能力。

• 抽象歸納

  從全域性、多樣性資訊中去抽象歸納。案例推演越多，越能找到本質，更能經得住推敲。分離關注點，識別關鍵內容。

視野會決定你獲取資訊的寬度和廣度。

假比架構師負責的系統是一個圈，架構師的的視野，不僅僅是站在圈內看圈內，還要站在圈內看圈外。進一步，還可以站在圈外看圈內。進一步，你還可以飛起來，鳥瞰。

架構方法論

對於架構相關的工作不是無方法可循，相反對於企業級架構是有一整套方法論。

1、企業級建模方法ArchiMate

沒有聽過的可以自行搜尋檢視。

業務架構、應用架構、技術架構、資訊架構是常見的劃分視角。技術為業務服務，技術驅動業務。
不同層次/定位的架構師的關注點會有不同：
業務架構對接業務願景，業務架構師不一定需要完全懂技術，或者有很強的技術能力。 如果是強業務型平臺，這類平臺一般會直接面對業務場景，業務分析、建模能力需要更強；共享型平臺，這類平臺一般在各個業務平臺的下層，提供統一的業務支撐和高可用的服務支撐，此類架構師，既需要領域建模，有需要很強的技術能力，一般沒有技術功底的PD也很難規劃、掌控此類平臺；技術型平臺，諸如基礎技術平臺、中介軟體等架構師，需要對技術的深入度，對於技術棧的深度和廣度需要很高的要求，此類架構師對於業務的理解可能不會太強，而且此類架構師可能不喜歡關注業務。

應用架構對標業務架構，應用架構支撐業務架構。兩者關係是相互促進迴圈。應用架構師考慮如何基於當前的技術架構，對業務架構提出的業務模型進行系統支撐。

技術架構是企業的基礎技術棧。訊息中介軟體，服務框架等等都可以納入這一體系。技術架構不是一味的堆砌高大上的概念。業務發展/願景，應用架構遇到的問題會驅動技術架構完善；技術架構的擴充套件能力確保能快速支撐業務爆發增長（比如億級訪問量），或者業務複雜度（比如服務框架或者分散式事務框架）。

資訊架構最難，此部分最容易忽略，最容易被取捨。如果要建立完全的資訊架構也比較困難，第一個困難就是建設成本太高，第二就是可能當前解決還想不清楚，比如業務領域的變化性很大，在模糊階段建立資訊標準存在悖論。一般前期需要業務先行，所以資訊架構，資訊標準會缺失；待系統發展到一定規模後，各個系統資訊互動存在困難時，再來重構的成本也會很高。

2、業務建模模式
業務功能域拆分，自頂向下的分解功能域。抽象建模是每個層次都需要的能力，不同的業務複雜度級別採取的方案可能不同。

比較簡單的業務，建設初期可能就是單系統。可以採用模組化拆分（包結構也算一種模組化，多工程也是一種模組化）；可以使用GoF設計模式，進行復雜功能的拆分，提供可讀性、可維護性；可以使用OOP面向物件變成進行業務建模等等。

稍微複雜一點的業務，可以使用DDD進行領域分析建模。對於業務領域進行業務實體，領域服務等合理的拆分，確定業務領域的職責範圍。

更復雜的業務綜合體，可以使用基於SOA的架構進行更大範圍的業務功能域的拆分，此部分的拆分模式其實可以理解為更大範圍的DDD拆分，然後使用技術（SOA）的方式，讓各個業務域進行協作。本質上，建模的方式沒有太大的區別，把相同的業務服務劃分到特定職責的業務域。

3、架構與組織
一般架構師不需要關注這個點，但是架構和組織是配套對齊。只有得到組織的強有力支撐，架構實施才能得到有力實施。相對大型的業務實體會劃分為多個一級業務域，這些域會對應架構師，同時也會配比一定的研發團隊；一級業務域可能劃分為多個二級架構域，二級架構域也會有對應的架構師，組織一般也是配套。

有的架構師是純架構師，不帶團隊，這種架構師需要有加強的架構溝通能力，和各個TL協調資源和架構目標。有的架構師相容TL，這類架構師得到的支撐力度會更順暢。

對於大型的架構團隊，基本上會有架構委員會。一級業務域形成公司級別的架構委員會，對於一級域的重要職責負責；二級業務域也可以形成架構師團隊，便於二級業務域內職責確定和協作。

一個好的架構師需要理解自己，同時理解周邊。一級業務域架構師，需要清楚自己負責的一級業務域，同時也需要很熟悉周邊的一級業務域。架構越大的域，資訊量越大，很考驗架構師的資訊接收、抽象、建模能力。

4、架構規劃閉環
架構規劃、架構實施、架構評估是一個架構閉環。

架構是動態的，在平衡、取捨、演進的架構迭代中不斷演進。

沒有完美的架構，如果你覺得當前的架構是完美的架構，那麼你的業務可能是“死業務”。充滿生命力的業務會帶來業務變化，業務願景/目標也會有調整。業務願景可以直接帶來架構目標（比如要支撐國際化）；缺失的平臺能力也帶來架構目標（比如平臺故障頻出）。

對於架構目標的內容進行合理的人員、優先順序、里程碑排布，然後付諸於實施。架構實施的過程一般都是充滿挑戰，實施過程中會有對架構目標的修正，會有和你負責的上下游進行遊說、PK，會有基於當前的困難做的取捨。

達到里程碑點後對於架構目標和實施情況進行評估，反饋，進行架構治理相關工作。

架構師的價值

個人把程式設計師進階分為如下幾個階段

• 任務明確型階段

  多見於初入門的程式設計師，需要在別人指導下完成編碼工作。部分僅僅完成開發工作，不追求甚解的人可能停留在這個階段。

• 業務明確型階段

  對於一個系統/業務的熟悉後，你已經可以完全掌控這個系統的職責。這個時候給你一個應該你做的需求，你會很容易進行系統的功能分解，設計，然後把這個需求完成。這個時候你知道自己該做什麼，不該做什麼。

• 業務模糊型階段

  這個階段，你會遇到很多需求，這些需求可以在你這裡做，也可以不在你這裡做。會面對很多模糊領域的問題，解決模糊領域的能力，考驗架構師的能力，在資訊中抽絲剝繭，歸納抽象能力。這個時候，你不僅僅知道自己不該做什麼，還能知道這個不該做的應該放到哪裡去做，比如應該放到哪個系統裡。

• 創造進階階段

  這個階段更復雜，帶有更多創造性，視野可能不僅僅侷限在現狀裡，比如現狀劃分了5個功能域。但是這個階段的架構師，也許可以創造出第6個功能域。一種方式是通過業務域重組；一種方式是對未來的識別。

架構師的挑戰和價值在於處理模糊領域的問題，讓模糊的變得不模糊，清晰可觸控。

架構師的軟能力

架構師很愛寫PPT，架構師寫PPT也很愛被一線的工程師詬病，說不幹實事。

但是，架構師很需要溝通表達能力，如何把架構目標清晰的進行表達，對架構職責進行表述，和相關關係人進行溝通，這些都很重要，關乎架構目標是否能達成。

同時，架構師對於資訊的處理能力很重要，對資訊的理解能力會決定架構師走的多遠，能多快、多準的找出架構關鍵點。

架構師也需要協調能力，比如架構師之間的溝通協調，架構師和實施團隊的溝通協調。
架構師該不該寫程式碼

一個好的架構師應該是從實戰中的真知，從實戰和細節中走來；但是，成長為一個架構師後，關注太多細節，會消耗較多的經歷，會影響從更巨集觀看問題。技術型架構師這方面一般會好點。

架構師的工作，也是從編碼，架構規劃等工作中的取捨。如果需要關注到很細，架構師需要深入下去；如果不需要深入太細，可以從更巨集觀來看問題，比如從功能層面。