1. 程式人生 > >閒話如何成為一個架構師

閒話如何成為一個架構師

拿破崙說

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

類比到IT行業

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


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

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

視野


記得有個架構師講過

“視野決定格局”


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

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

常常聽到這樣的觀點

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


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

  • 單點、模組、鏈路

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

  • 過去、現在、未來

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

  • 抽象歸納

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

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

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

架構方法論


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

1、企業級建模方法ArchiMate

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

架構師的價值


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

  • 任務明確型階段

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

  • 業務明確型階段

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

  • 業務模糊型階段

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

  • 創造進階階段

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

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

架構師的軟能力


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

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

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

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


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

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