我把架構的能力分為四個階段,分別是架構原則(Principles)、架構模式(Patterns)、架構建模(Modeling)、架構框架(Frameworks)。

第一階段「架構原則」,這是最基礎的架構知識。架構原則是在架構設計領域中基本要遵守的原則,通常不會有太多條,且每一條都很簡單、用處很廣泛、彼此獨立。你可以在工作中或者從別人的經驗分享中,整理出你的架構原則。我自己目前就建立了十幾條的技術架構設計指導原則,例如:兩個系統不能共用一個資料庫。

第二階段「架構模式」,這是「設計模式」的一種,設計模式是一些經常被使用、已經確定有效的「招式」可以用來「套招」。這方面的書非常多,有的描述安全架構模式、有的描述基礎架構(Infrastructure)模式,有的描述應用架構模式。只要去閱讀這些書,可以快速得到這方面的能力。架構模式比架構原則更「實」,因為它會描述具體要解決的問題是什麼、具體的設計是什麼、會產生什麼效果。例如,面對可能的DDoS網路攻擊,系統要如何設計以為因應,這麼做有什麼優缺點。

第三階段「架構建模」,這是指建模所需要的語言和能力。不要把模型(Model)和模式(Pattern)搞混了,模型是某件事物的化身,而模式是一種套招;模型是一種整體觀,但模式是零散的常用招式。

第四階段「架構框架」,這是指模型已經被抽象成為一個更通用的框架,這個框架只要透過簡單的設定或配合一些小工作量的開發,就可以產生新的模型,把大部分的事情都處理完。新的需求一來,就可以快速搞定。

上面說的這四個階段,同時適合技術架構和業務架構領域。在技術架構領域,多數的技術架構師可能是在第二階段。在業務架構領域,業務架構師本來就不多,他們可能一部分在第一階段,一部分在第二階段。

透過這些階段的區分,我希望其他架構師也能夠據以判斷自己的能力在什麼位置,並因此有了努力前進的方向。我之所以把架構能力分為這四個階段,因為這正是我走過的路。既然這四階段是我的經驗,我就藉這個機會順便說說我的架構師成長之路吧!

在生活中和工作中,我們很容易從他人的身上看到許多他們的行事風格(例如上床睡覺前先洗澡),我們也可能發展出我們自己的行事風格,一旦我們發現某些行事風格對我們有好處,我們可能會持續採用,最後變成我們的原則。我在軟體開發行業這麼多年,自然會培養出一些我認為好的原則,例如系統之間一定要避免循環依賴。

慢慢培養出這些原則固然好,但後來我發現了一種快速進步的方法:學習「設計模式」。於是我把架構領域的設計模式的書全都買回家。我身為架構師團隊的負責人,我也讓我的團隊成員去學習這些設計模式。

儘管這些設計模式對團隊有幫助,但設計模式還是太零散。我希望能夠有一個比較全面的架構設計方法論,來讓團隊成員能夠依循,在方法論的指導下,即使比較菜鳥的架構師也能夠做出水準以上的架構。所以這些年來,我一直在研究架構建模的方法論。

後來我確實整理出一套架構建模的方法論,但漸漸地我開始有了重複的感覺,這表示需要更高層次的抽象。我試圖把抽象的結果實現為框架。這是我現在努力的目標。

同時我又發現一個問題:光是技術架構還不夠,因為如果沒有好的業務架構,技術架構就不容易做好,或者技術架構的價值體現不出來。於是我開始走向業務架構,接下來是商業模型方法的研究。到頭來我發現,每一個目的地都只是另一個旅程的起點。只有回首前塵,看以前走過的那些路,才理解這一切的脈絡。

專欄作者

熱門新聞

Advertisement