如今但凡提到軟件工程，必言軟件架構。軟件架構對於軟件界來雖說是舶來之詞，它對於軟件工程的發展意義非凡。對於一般的架構師而言，他們或多或少會面臨着這樣的困惑：
1. 如何將系統劃分爲模塊
2. 大系統架構設計該如何起步
3. 總覺得需求很糟糕，影響了架構設計
4. 非功能需求很重要，但是如何發現這些新功能需求並應用到設計當中去
等等。
雖然就目前而言，軟件架構遠沒有我們所期望的和建築上的架構那樣完善，但也出現不少的方法論來試圖幫我們解決上面提到的一些普遍性問題，如ADD指導如何劃分系統爲模塊、ZAEMAN Framework爲大系統特別是大的信息系統的架構提供參考、TOGAF是目前比較流行的用於信息系統的架構方法論等。這篇文章要說的就是ADMES，是Architectural Design Method has been Extended to Method System的縮寫。ADMEMS方法不是單一方法，而是由多個各具特點的方法組成的方法體系，它不同於其他的方法論，它試圖提供一種方法體系來供我們的架構師參考來解決上面的這些問題。
ADMENS方法通過3個階段和1個貫穿環節，來覆蓋“需求進，架構出”的架構設計完整工作內容。3個階段分別是：Pre-architecture、Conceptual Architecture、Refined Architecture。PA階段是架構實踐中常見的短板，CA階段是大型系統成敗的關鍵，RA階段是大規模開發的基礎。總體說來，PA階段的工作就是運用ADMEMS矩陣將需求結構化，建立二維的需求，並視圖找出系統的重大的功能需求和質量屬性；CA階段的工作就是根據PA階段的結果運用分析圖、目標-場景-決策表來構建出一個儘量合理的架構；RA階段的工作就是運用UML、目標-場景-決策表等方法來構建出系統的5個視圖（實踐中不是5個視圖都需要）。
PA階段強調重大需求的獲取和質量屬性的確定，分爲四個階段：
1. 需求結構化（需求分類）
2. 分析約束影響（ADMEMS矩陣方法）
3. 確定關鍵質量（安全性、高性能、高可用、互操作等）
4. 確定關鍵功能（核心功能、必做功能、高風險功能、獨特功能等）
我們一般認爲需求分爲三個層次，分別是業務需求、用戶需求和功能需求（RUP的分類法則分爲Need、Feature和軟件需求）。不同的需求從層面去影響架構。
1. 功能需求是發現職責的依據，是CA階段進行的基礎
2. 質量需求是架構的驅動力
3. 約束是架構必須考慮的因素
（功能需求但並不一定是劃分模塊的唯一依據，劃分模塊需要綜合三者，往往質量需求是劃分模塊最首先要考慮的因素）
ADMEMS方法提供了ADMEMS矩陣方法來進行需求的分析和推導，藉助這個方法，把多而雜的架構影響因素梳理清楚，建立全面有序的理解。
架構新手和有經驗的架構師的區別之一在於是否懂得並能有效地進行概念架構設計。有經驗的架構師不會一上來就關注如何定義結構，他們在典型系統架構設計的早期比較注重識別重大需求、特色需求、高風險需求並識別質量屬性來設計概念架構。CA強調重大需求塑造架構，這裏的需求既包括功能、約束、質量屬性。概念架構界定系統的高層組件，以及他們之間的關係。概念性架構意在對系統進行適當分解，而不陷入細節。藉此，可以與管理人員、市場人員、用戶等非技術人員交流架構。概念性架構規定了每個組件的非正式規約和架構圖，但不涉及接口細節。進行CA，首先及需要構建出自己的架構場景（即一部分業務用例）從而發現不同的系統組件。CA可分爲三個步驟：
1. 初步設計（通過業務用例和序列圖發現職責，得到系統分析設計圖，包括實體、控制對象、界面對象、接口等）
2. 高層分割（切割/聚合初步設計得到的系統爲多個層次【可按照不同的維度來劃分，如技術、業務等】或/和多個子系統【一般按照業務來劃分】）
3. 考慮非功能需求（如可按照ADD方法）
RA關注的是具體的接口、模塊和連接件了，當然還有其它很多的工作，如進程、線程設計、接口定義、系統選型、數據架構等等。ADMEMS推薦使用5視圖方法來進行架構設計，這5個視圖分別是運行視圖、邏輯視圖、物理視圖、開發視圖、數據視圖。每個視圖描述系統的一個側面。
（如邏輯架構的目標就是劃分模塊，定義接口，其實踐方法包括細化分層、提取機制、劃分垂直子系統，可採用職責分離、通用專用分離、技能分離、工作量均衡等策略進行設計）。
總而言之，ADMEMS爲我們提供了一個很好的思路來進行指導我們的架構。
參考資料
1. 軟件架構實踐
2. 軟件架構設計
3. 架構之美
4. 一線架構師指南