為什麼要評估架構？#

架構評估（Architecture Evaluation）的本質是一種風險管理手段。如同保險策略，投入多少資源於評估取決於你承受「不適當架構」的風險程度與容忍度：

• 若系統耗資數百萬或數十億美元，或具備重大**安全關鍵（safety-critical）**意涵，風險事件的衝擊巨大，評估就更為關鍵
• 若團隊在該領域擁有深厚經驗，產生不良架構的機率較低；反之，若是首次嘗試，機率則大幅提升
• 評估可在開發過程的不同階段進行，由不同的評估者、以不同方式執行

評估建立在已學過的核心概念之上：系統為滿足**商業目標（business goals）而建構，商業目標以品質屬性場景（quality attribute scenarios）具體化，品質屬性目標則透過策略（tactics）與模式（patterns）**的應用來達成。

架構評估的關鍵活動#

無論由誰執行、何時進行，評估都基於架構驅動因素（architectural drivers），主要是以品質屬性場景表達的架構重要需求（ASRs）。每次評估至少應包含以下步驟：

1. 理解架構現況 — 評審者透過共享文件或架構師的簡報來確認理解
2. 確定評估驅動因素 — 通常以高優先級品質屬性場景為主（而非單純的功能性用例）
3. 逐一評估場景 — 判斷場景是否被滿足，同時檢查當前設計決策是否會使其他場景無法實現；必要時提出替代方案並進行同等分析
4. 記錄潛在問題 — 形成後續追蹤的基礎，若為真實問題則須修復或明確接受風險

分析深度的考量#

• 決策的重要性 — 越重要的決策，越需要仔細評估
• 替代方案的數量 — 替代方案越多，評估時間可能越長
• 夠好就好（Good enough） — 當兩個替代方案後果差異不大時，做出選擇並繼續前進比追求完美更重要

誰可以執行評估？#

架構師自我評估#

每當架構師做出關鍵設計決策以回應 ASR 或完成設計里程碑時，評估便隱含或明確地進行。這是架構設計過程的內建環節。

同儕審查（Peer Review）#

架構設計可像程式碼審查一樣進行同儕審查。通常分配數小時到半天的固定時間。若使用 ADD 流程，可在每次 ADD 迭代的第 7 步結束後進行，並搭配各章（Chapters 4-13）介紹的策略導向問卷（tactics-based questionnaires）。

外部評估者#

外部評估者能以更客觀的視角審視架構。「外部」是相對概念：可以是開發專案之外、業務單位之外但同公司、或完全來自公司外部。外部評估者的優勢：

• 較不懼於揭露敏感問題或因組織文化忽略的問題
• 通常具備特定專業知識，例如特定品質屬性或技術的經驗
• 管理層往往更願意重視外部團隊（儘管內部團隊可能早已提出相同問題）

情境因素（Contextual Factors）#

進行同儕審查或外部分析時，需考量以下情境因素：

• 可用的產出物 — 必須有描述架構的文件。若系統已上線，可使用架構恢復（recovery）與分析工具
• 誰可以看到結果 — 部分評估由所有利害關係人參與並知悉，部分則較私密
• 哪些利害關係人將參與 — 需識別關鍵個體並確保其參與
• 商業目標為何 — 若事先未明確捕獲並排序商業目標，應在評估中安排專門階段處理

Architecture Tradeoff Analysis Method（ATAM）#

ATAM 是一套形式化的架構評估流程，已被使用超過二十年，應用於從汽車、金融到國防等領域的大型系統。ATAM 的設計使得評估者不需事先熟悉架構或商業目標，且系統不需已經建構完成。

ATAM 的三方參與者#

• 評估團隊（Evaluation Team） — 3 至 5 人的外部團隊，成員各有特定角色，須被認可為客觀且無隱藏議程的外部人員
• 專案決策者（Project Decision Makers） — 有權代表專案發言或授權變更的人，必定包含架構師（架構師必須自願參與是基本原則）
• 架構利害關係人（Stakeholders） — 對架構表現有切身利益的人，包括開發者、測試者、整合者、維護者、效能工程師、使用者等；大型企業關鍵架構的評估，經驗法則是 10 至 25 位利害關係人

ATAM 評估團隊角色#

ATAM 的七大產出#

1. 精簡的架構呈現 — 要求在一小時內完成，通常既精簡又可理解
2. 商業目標的闡明 — 往往讓部分參與者首次看到這些目標
3. 優先化的品質屬性需求 — 以品質屬性場景（Chapter 3 格式）表達
4. 風險與非風險清單 — 風險是可能導致不良後果的架構決策；非風險是經分析後被認為安全的決策
5. 風險主題（Risk Themes） — 從完整風險集合中歸納出系統性弱點的概括性主題
6. 架構決策到品質需求的映射 — 為決策提供理據說明
7. 敏感點與權衡點（Sensitivity & Tradeoff Points） — 敏感點是對品質屬性回應有顯著影響的決策；權衡點是同一決策使某品質改善但另一品質惡化

ATAM 也會產生無形成果：利害關係人之間的社群感、架構師與利害關係人之間開放的溝通管道，以及所有參與者對架構優缺點的更深入理解。

ATAM 的四個階段#

ATAM 九個步驟詳解#

Phase 1（步驟 1-6）：評估團隊與專案決策者

步驟 1：呈現 ATAM 方法 — 評估領導者向所有參與者說明流程、回答問題、設定背景與期望。

步驟 2：呈現商業目標 — 專案決策者從商業角度做系統概覽，包含：

• 系統最重要的功能
• 相關的技術、管理、經濟或政治限制
• 商業目標及其與專案的關聯
• 主要利害關係人
• 架構驅動因素（強調 ASRs）

步驟 3：呈現架構 — 首席架構師在適當的詳細程度下展示架構，包括技術限制、使用的架構方法（architectural approaches），以及各種架構視圖（views），如 context diagrams、C&C views、module decomposition 或 layered views、deployment view 等。

步驟 4：識別架構方法 — ATAM 透過理解架構方法來進行分析。每種架構模式和策略都有已知的品質屬性影響方式（例如，分層模式帶來可攜性與可維護性但可能犧牲效能）。

步驟 5：產生品質屬性效用樹（Utility Tree） — 由架構師與專案決策者共同建構。架構師評估場景的技術難度／風險（H, M, L），專案決策者評估其商業重要性。

步驟 6：分析架構方法 — 評估團隊逐一檢視最高排名的場景，架構師解釋架構如何支援每個場景。

此步驟的分析並非追求全面性，而是引出足夠的架構資訊來建立架構決策與品質屬性需求之間的連結。場景走查會引出風險、非風險與權衡的討論，例如：

• 心跳頻率影響故障偵測時間，某些設定可能導致不可接受的回應值（風險）
• 較高頻率改善可用性，但消耗更多處理時間與通訊頻寬（權衡）

Phase 2（步驟 7-9）：加入利害關係人

Phase 1 類似於自己測試自己的程式；Phase 2 則類似於交給獨立品保團隊，以更廣泛的測試和環境來驗證。

步驟 7：腦力激盪與排序場景 — 利害關係人針對各自角色提出具操作意義的品質屬性場景。場景收集後進行合併與投票排序：每人獲得場景總數 30% 的票數（無條件進位），可自由分配。

將排序後的清單與效用樹比對：若一致，表示架構師與利害關係人的認知良好對齊；若出現重大差異，本身就是一個風險。

步驟 8：分析架構方法 — 針對步驟 7 中最高排名的新場景，執行與步驟 6 相同的分析活動，通常涵蓋前 5 至 10 個場景。

步驟 9：呈現結果 — 評估團隊將風險歸類為風險主題，並關聯到步驟 2 中的商業目標，使「技術議題」被明確識別為對管理層在意之事的威脅。最終呈現包含：

• 記錄的架構方法
• 場景及其排序
• 效用樹
• 風險與非風險
• 敏感點與權衡點
• 風險主題及其威脅的商業目標

形式化流程的價值#

將評估流程形式化有幾個關鍵好處：

• 使流程更具可重複性
• 幫助利害關係人理解評估將需要與交付的內容
• 訓練新的評估者使用流程
• 理解執行評估所需的投資

ATAM 實務經驗：脫稿的藝術#

書中作者分享了二十多年來 ATAM 評估的實務經驗，歸納出三個評估成功的核心原因：

1. 參與者的意願 — 委託架構評估的人和參與的架構師、開發者、利害關係人都希望評估成功，這股集體力量推動評估朝向架構洞察的目標前進
2. 誠實 — 當評估有脫軌之虞時，應暫停並與團隊及客戶商議。少量的勇氣可能派上用場，但絕不應該虛張聲勢。參與者能本能地察覺虛假的音符，評估團隊絕不能失去其他參與者的信任
3. 方法的共識建構 — 方法設計為在整個練習中建立並維持穩定的共識，最終結果不會有意外

來自作者的實戰經驗：曾遇到開發組織根本沒有可評估的架構、架構師在評估途中離職、以及評估進行到一半才發現架構已被替換等狀況。但只要盡力而為、保持誠實、信任方法、信任參與者的善意，最終都能取得成功。甚至有一次，專案經理精心策劃讓架構師在評估中途離開，真正目的是培養初級設計團隊的能力 — 而評估成功達成了這個隱藏目標。

輕量級架構評估（Lightweight Architecture Evaluation）#

LAE 方法設計用於專案內部情境，由同儕定期執行。它沿用 ATAM 的概念，但因為範圍有限，許多步驟可以省略或縮短。

LAE 的特點#

• 時長取決於場景數量，可短至數小時，長至一整天
• 完全由組織內部成員執行
• 通常由專案架構師召集並主持
• 可聚焦於上次審查以來的變更，或檢視先前未審查的架構部分

LAE 典型議程#

LAE 無正式報告，但由記錄員（scribe）負責記錄結果，可作為風險補救的基礎。LAE 的評估團隊為內部成員，客觀性可能不如外部團隊，但其優點是成本低、易於召集、儀式感低，可隨時部署進行架構品質保證的健全性檢查。

策略導向問卷（Tactics-Based Questionnaires）#

這是一種更輕量的評估方法，一次聚焦於單一品質屬性。可由架構師用於自我反思，或用於結構化的問答環節。

• 典型時長：每個品質屬性約一小時
• 將每個策略（tactic）轉化為問題（如「系統是否支援入侵偵測？」「系統是否支援訊息完整性驗證？」）
• 能快速揭露設計決策中隱藏的風險

策略導向問卷可在極短時間內揭露令人驚訝的結果。書中舉例：一個管理醫療資料的系統要求資料不得以「明文」傳輸，團隊選擇對所有資料做 XOR 運算。雖然嚴格來說滿足了需求，但這種「加密」演算法一個具備基礎能力的高中生就能破解。

評估方法的比較與選擇#

三種評估方法形成一個從輕量到全面的評估光譜：

選擇哪種評估方法取決於系統的重要性、風險容忍度、可用的資源與時間，以及架構的成熟度。這些方法並非互斥 — 可以在開發過程中組合使用，例如日常使用策略導向問卷、每次迭代後執行 LAE、在重大里程碑安排 ATAM。

本章總結#

• 若系統重要到需要明確設計其架構，該架構就應該被評估
• 評估的次數與範圍因專案而異；設計者在做出重要決策時就應進行評估
• ATAM 是全面性的架構評估方法，透過讓決策者和利害關係人闡明精確的品質屬性需求，並照亮與每個高優先場景分析相關的架構決策，找出風險或非風險
• LAE 提供輕量級的內部同儕審查選項，成本低且易於定期執行
• 策略導向問卷提供最輕量的單一品質屬性評估途徑，能在極短時間內揭露關鍵風險
• 所有評估方法都遵循相同的核心邏輯：以品質屬性場景為基礎，檢視架構決策是否充分回應需求