前一篇文章「微服務設計的十個步驟」,其實是我的一個技術架構方法論(methodology)再經過特定化和簡化的結果。方法論是指為了達到某目標的一套做事情的邏輯。有了方法論,其他人就有了可以依循的規矩和流程,降低事情的難度。

關於「如何設計方法論」,我自己又有一套方法論(又抽象了一層),在這篇文章中分享給 iThome 的讀者。既然這是「用來設計方法論的方法論」,這篇文章介紹的其實是 meta-methodology。

設計方法論,首先你必須要有一個參考模型(reference model)。請注意,參考模型本身就是模型,並不是 meta-model。

以我的微服務設計方法論來說,我先設計出了三維技術模型,這是一個「通用」的技術架構參考模型。這個模型是我多年來演化的結果,使用了三個維度,第一個維度是業務(Business)維度,第二個維度是技術(Tech)維度,第三個維度是維運(DevOp)維度。每個維度又分成數個層次,這三個維度以「笛卡兒乘積」,看起來就像是個魔術方塊。

一個好的參考模型必須做到:1 盡可能通用於許多領域 2. 容易用程式碼實現 3. 功能需求容易設計 4 不會阻礙非功能需求的設計 5. 可以降低後續調整的難度

參考模型和框架(framework)非常類似,但參考模型是虛的設計規範,而框架是實際的程式碼系統半成品。也就是說,一旦你有了參考模型,你接下來就可以往實現框架的目標邁進。請參考本專欄的第六篇「架構能力的四個階段」。

參考模型就像是一個樣板(template),裡面有許多格子,每個格子的分工以及格子之間的通道都已經提前設計好了,大家根據每個格子的描述,往格子裡面填入東西。這就是設計方法論的第二個階段:找出「填入格子」的方法。這個方法的關鍵在於:能夠配合敏捷開發流程,通過迭代的方式遞增式地設計和開發。

我看過的所有架構設計方法,都沒有考慮到和敏捷的相容,這使得這些架構方法都太「笨重」,不太可行。現在的商業環境變化如此快速,除非你是壟斷性質的產業,否則沒人能夠花一年兩年的時間做詳細設計,然後才去實現。只有敏捷才能夠降低風險,敏捷是必須的。沒有敏捷的技術架構,就沒有敏捷的開發,就沒有敏捷的業務,就沒有敏捷的企業。

架構和敏捷真的不相容嗎?我不認為,而且我試圖證明這一點。在「微服務設計的十個步驟」方法,是以「場景」(scenario)作為驅動的,這符合敏捷以功能點或特徵驅動的作法,且場景更全面,更關心用戶的目的,尤其場景也是我的「技術建模」和「商業建模」之間的一個銜接點。

設計方法論的第三個階段是:建立自我優化的機制。比擬董事會(執行)、監事會(監察)、股東會(決議)的關係,我希望系統本身就像一個公司,也具備執行、分析、調整的循環,提供這樣的機制來持續優化自己,甚至為未來的自動化和智慧化提供可能性。所以「微服務設計的十個步驟」中的第八和第十步驟,分別對業務和維運提供執行、分析、調整的機制。

設計方法論的第四個階段是:降低難度。以「微服務設計的十個步驟」為例,我一開始只要求分解前端和後端這兩層,接下來才繼續分解前端和後端為五層,接下來才把這五層根據技術來分解,接下來才又把分解的結果根據運維來分解。這個過程大大地把難度降低了。

這篇文章介紹的是設計方法論的方法論,也就是所謂的 meta-methodology。「微服務設計的十個步驟」是實踐這個方法論的結果,而我還有另一個方法論,是用來設計商業的,也是實踐這個 meta-methodology 的結果。這兩個例子的存在,解釋了meta-methodology 的意義,它是用來設計方法論的方法論。

專欄作者

熱門新聞

Advertisement