停了很久，繼續上路。計劃寫一個系列，先預告：《如何成爲架構師》，《如何做一名好開發》,《如何做系分》，《如何轉型技術管理》。
正文
拿破崙說
不想當將軍的士兵不是好士兵。
類比到IT行業
不想當架構師的程序員不是好程序員。
雖然此種類比不一定恰當。也許你就想簡簡單單、安安靜靜寫寫代碼，這種想法沒錯。國外，就有很多老程序員，與世無爭的寫代碼，把代碼寫漂亮，沒有那麼功利非要給自己掛一個架構師的頭銜。相比較而言，國內就要現實太多。工作N多年後，如果還是在一線碼農，多數時候也會被鄙視，也許還會被BOSS扣上此人發展潛力不行。還有N多人，換工作的時候，非架構師職位不來。 年前和團隊人開會，有個同事的給他的定位是漸漸可以做更多架構規劃相關的工作。他說，對於如何做架構還有很多迷茫。有些人也許不會選着這條路；有些人正在這條路上，但是很迷茫：我該如何成爲一個架構師呢？ 視野
記得有個架構師講過
“視野決定格局”
自己還是比較認同這句話，架構師首先要重構的是自己的視野。視野不是裝逼。視野可以作爲一個看問題、積累專業領域知識的內在驅動力。 僅僅說視野，未免太虛，如何把視野坐實是很重要。由內在（思維、心態、方法）驅動外在（專業知識）是需要紮紮實實去積澱。 常常聽到這樣的觀點
“做架構師，一定要有全局的視野或關注”
如何理解全局？負責幾百個應用就是全局？負責單個系統就不是全局？ 個人對全局有如下理解：
- 單點、模塊、鏈路 由點到面去積累知識，從全局和細節兩條路逼近學習；不僅僅關注自我，還超越自我。要做一個架構師，不僅僅需要知道自己能做什麼，還需要知道別人能做什麼，還需要自己不能做什麼。所以要做好，需要超越自我，積累更爲全局的知識，首先是你的上游需要理解，進一步是上游的上游需要了解。
- 過去、現在、未來 從過去看爲什麼來；從現在看缺什麼；從未來來看走向哪裏。架構師需要看的更遠，比如半年，一年，三年。預知未來的能力。
- 抽象歸納 從全局、多樣性信息中去抽象歸納。案例推演越多，越能找到本質，更能經得住推敲。分離關注點，識別關鍵內容。
視野會決定你獲取信息的寬度和廣度。
假比架構師負責的系統是一個圈，架構師的的視野，不僅僅是站在圈內看圈內，還要站在圈內看圈外。進一步，還可以站在圈外看圈內。進一步，你還可以飛起來，鳥瞰。 架構方法論
對於架構相關的工作不是無方法可循，相反對於企業級架構是有一整套方法論。 1、企業級建模方法ArchiMate
沒有聽過的可以自行搜索查看。
業務架構、應用架構、技術架構、信息架構是常見的劃分視角。技術爲業務服務，技術驅動業務。 不同層次/定位的架構師的關注點會有不同：
業務架構對接業務願景，業務架構師不一定需要完全懂技術，或者有很強的技術能力。 如果是強業務型平臺，這類平臺一般會直接面對業務場景，業務分析、建模能力需要更強；共享型平臺，這類平臺一般在各個業務平臺的下層，提供統一的業務支撐和高可用的服務支撐，此類架構師，既需要領域建模，有需要很強的技術能力，一般沒有技術功底的PD也很難規劃、掌控此類平臺；技術型平臺，諸如基礎技術平臺、中間件等架構師，需要對技術的深入度，對於技術棧的深度和廣度需要很高的要求，此類架構師對於業務的理解可能不會太強，而且此類架構師可能不喜歡關注業務。
應用架構對標業務架構，應用架構支撐業務架構。兩者關係是相互促進循環。應用架構師考慮如何基於當前的技術架構，對業務架構提出的業務模型進行系統支撐。
技術架構是企業的基礎技術棧。消息中間件，服務框架等等都可以納入這一體系。技術架構不是一味的堆砌高大上的概念。業務發展/願景，應用架構遇到的問題會驅動技術架構完善；技術架構的擴展能力確保能快速支撐業務爆發增長（比如億級訪問量），或者業務複雜度（比如服務框架或者分佈式事務框架）。
信息架構最難，此部分最容易忽略，最容易被取捨。如果要建立完全的信息架構也比較困難，第一個困難就是建設成本太高，第二就是可能當前解決還想不清楚，比如業務領域的變化性很大，在模糊階段建立信息標準存在悖論。一般前期需要業務先行，所以信息架構，信息標準會缺失；待系統發展到一定規模後，各個系統信息交互存在困難時，再來重構的成本也會很高。 2、業務建模模式 業務功能域拆分，自頂向下的分解功能域。抽象建模是每個層次都需要的能力，不同的業務複雜度級別採取的方案可能不同。 比較簡單的業務，建設初期可能就是單系統。可以採用模塊化拆分（包結構也算一種模塊化，多工程也是一種模塊化）；可以使用GoF設計模式，進行復雜功能的拆分，提供可讀性、可維護性；可以使用OOP面向對象變成進行業務建模等等。 稍微複雜一點的業務，可以使用DDD進行領域分析建模。對於業務領域進行業務實體，領域服務等合理的拆分，確定業務領域的職責範圍。 更復雜的業務綜合體，可以使用基於SOA的架構進行更大範圍的業務功能域的拆分，此部分的拆分模式其實可以理解爲更大範圍的DDD拆分，然後使用技術（SOA）的方式，讓各個業務域進行協作。本質上，建模的方式沒有太大的區別，把相同的業務服務劃分到特定職責的業務域。 3、架構與組織 一般架構師不需要關注這個點，但是架構和組織是配套對齊。只有得到組織的強有力支撐，架構實施才能得到有力實施。相對大型的業務實體會劃分爲多個一級業務域，這些域會對應架構師，同時也會配比一定的研發團隊；一級業務域可能劃分爲多個二級架構域，二級架構域也會有對應的架構師，組織一般也是配套。 有的架構師是純架構師，不帶團隊，這種架構師需要有加強的架構溝通能力，和各個TL協調資源和架構目標。有的架構師兼容TL，這類架構師得到的支撐力度會更順暢。 對於大型的架構團隊，基本上會有架構委員會。一級業務域形成公司級別的架構委員會，對於一級域的重要職責負責；二級業務域也可以形成架構師團隊，便於二級業務域內職責確定和協作。 一個好的架構師需要理解自己，同時理解周邊。一級業務域架構師，需要清楚自己負責的一級業務域，同時也需要很熟悉周邊的一級業務域。架構越大的域，信息量越大，很考驗架構師的信息接收、抽象、建模能力。 4、架構規劃閉環 架構規劃、架構實施、架構評估是一個架構閉環。
架構是動態的，在平衡、取捨、演進的架構迭代中不斷演進。 沒有完美的架構，如果你覺得當前的架構是完美的架構，那麼你的業務可能是“死業務”。充滿生命力的業務會帶來業務變化，業務願景/目標也會有調整。業務願景可以直接帶來架構目標（比如要支撐國際化）；缺失的平臺能力也帶來架構目標（比如平臺故障頻出）。 對於架構目標的內容進行合理的人員、優先級、里程碑排布，然後付諸於實施。架構實施的過程一般都是充滿挑戰，實施過程中會有對架構目標的修正，會有和你負責的上下游進行遊說、PK，會有基於當前的困難做的取捨。 達到里程碑點後對於架構目標和實施情況進行評估，反饋，進行架構治理相關工作。 架構師的價值
個人把程序員進階分爲如下幾個階段
- 任務明確型階段 多見於初入門的程序員，需要在別人指導下完成編碼工作。部分僅僅完成開發工作，不追求甚解的人可能停留在這個階段。
- 業務明確型階段 對於一個系統/業務的熟悉後，你已經可以完全掌控這個系統的職責。這個時候給你一個應該你做的需求，你會很容易進行系統的功能分解，設計，然後把這個需求完成。這個時候你知道自己該做什麼，不該做什麼。
- 業務模糊型階段 這個階段，你會遇到很多需求，這些需求可以在你這裏做，也可以不在你這裏做。會面對很多模糊領域的問題，解決模糊領域的能力，考驗架構師的能力，在信息中抽絲剝繭，歸納抽象能力。這個時候，你不僅僅知道自己不該做什麼，還能知道這個不該做的應該放到哪裏去做，比如應該放到哪個系統裏。
- 創造進階階段 這個階段更復雜，帶有更多創造性，視野可能不僅僅侷限在現狀裏，比如現狀劃分了5個功能域。但是這個階段的架構師，也許可以創造出第6個功能域。一種方式是通過業務域重組；一種方式是對未來的識別。
架構師的挑戰和價值在於處理模糊領域的問題，讓模糊的變得不模糊，清晰可觸摸。 架構師的軟能力
架構師很愛寫PPT，架構師寫PPT也很愛被一線的工程師詬病，說不幹實事。
但是，架構師很需要溝通表達能力，如何把架構目標清晰的進行表達，對架構職責進行表述，和相關關係人進行溝通，這些都很重要，關乎架構目標是否能達成。
同時，架構師對於信息的處理能力很重要，對信息的理解能力會決定架構師走的多遠，能多快、多準的找出架構關鍵點。
架構師也需要協調能力，比如架構師之間的溝通協調，架構師和實施團隊的溝通協調。
架構師該不該寫代碼
一個好的架構師應該是從實戰中的真知，從實戰和細節中走來；但是，成長爲一個架構師後，關注太多細節，會消耗較多的經歷，會影響從更宏觀看問題。技術型架構師這方面一般會好點。 架構師的工作，也是從編碼，架構規劃等工作中的取捨。如果需要關注到很細，架構師需要深入下去；如果不需要深入太細，可以從更宏觀來看問題，比如從功能層面。