方法論設計的四個步驟

前一篇文章「微服務設計的十個步驟」，其實是我的一個技術架構方法論（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 的意義，它是用來設計方法論的方法論。