Jeff Tyree 同 Art Akerman 嘅決策記錄範本

呢個係喺 "Architecture Decisions: Demystifying Architecture"（作者 Jeff Tyree 同 Art Akerman，Capital One Financial） 發表嘅架構決策描述範本。

• 問題（Issue）：描述你正處理嘅架構設計問題，要令人完全清楚點解你而家要處理呢個問題。採用極簡做法，只處理同記錄喺生命週期各個階段真正需要處理嘅問題。

• 決策（Decision）：清楚講明架構嘅方向，即係你揀選嘅立場。

• 狀態（Status）：決策嘅狀態，例如待定（pending）、已決定（decided）或者已批准（approved）。

• 組別（Group）：你可以用簡單嘅分組（例如整合、展示、數據等）去幫助整理決策集合。你亦可以用更精密嘅架構本體論，例如 John Kyaruzi 同 Jan van Katwijk 提出嘅本體論，當中包含更抽象嘅類別，例如事件、日曆同位置。舉例說，用呢個本體論，你會將處理系統需要資料嘅事件嘅決策，歸入事件組別。

• 假設（Assumptions）：清楚描述你做決策時所處環境嘅基本假設，例如成本、時間表、技術等等。留意環境限制（例如獲接受嘅技術標準、企業架構、常用模式等）可能會限制你考慮嘅方案。

• 限制（Constraints）：記錄所揀選嘅方案（即決策）可能對環境造成嘅任何額外限制。

• 立場（Positions）：列出你考慮過嘅立場（可行嘅選項或者方案）。呢啲往往需要長篇解釋，有時甚至要模型同圖表。呢個唔係詳盡無遺嘅清單。不過，你唔想喺最後審閱嗰陣聽到「你有冇諗過……？」呢個問題，因為咁樣會令你失去公信力，亦會令人質疑其他架構決策。呢個部分亦有助確保你有聽過其他人嘅意見；明確寫出其他意見，有助爭取佢哋嘅支持者加入你嘅決策。

• 論據（Argument）：概述你點解揀選某個立場，包括實施成本、總擁有成本、上市時間，以及所需開發資源嘅可用性等項目。呢部分可能同決策本身一樣重要。

• 影響（Implications）：正如 REMAP 元模型所指，一個決策會帶來好多影響。例如，一個決策可能引致需要作出其他決策、產生新需求或者修改現有需求；對環境施加額外限制；需要同客戶重新磋商範圍或者時間表；或者需要額外員工培訓。清楚理解同講明決策嘅影響，對於爭取認同同建立架構執行路線圖可以非常有效。

• 相關決策（Related decisions）：好明顯，好多決策係相關嘅；你可以喺呢度列出。不過，我哋發現實際上，追溯矩陣、決策樹或者元模型更加有用。元模型有助以圖表方式展示複雜關係（例如 Rose 模型）。

• 相關需求（Related requirements）：決策應該由業務驅動。為咗展示問責，要明確將你嘅決策對應到目標或者需求。你可以喺呢度逐一列出相關需求，不過我哋發現參照追溯矩陣更方便。你可以評估每個架構決策對滿足每項需求嘅貢獻，然後評估所有決策合起上嚟對需求滿足嘅程度。如果一個決策對滿足需求冇貢獻，就唔好做嗰個決策。

• 相關工件（Related artifacts）：列出受呢個決策影響嘅相關架構、設計或者範圍文件。

• 相關原則（Related principles）：如果企業有一套共同認可嘅原則，要確保決策同其中一項或者多項一致。咁樣有助確保各領域或者系統之間保持一致。

• 備註（Notes）：由於決策過程可能需時數星期，我哋發現記錄團隊喺諮詢過程中討論嘅備註同問題好有用。