Jeff Tyree 和 Art Akerman 的決策記錄範本

這是 Capital One Financial 的 Jeff Tyree 和 Art Akerman 在《架構決策:揭開架構的神秘面紗》(Architecture Decisions: Demystifying Architecture)中釋出的架構決策描述範本。

• 問題(Issue):描述你要解決的架構設計問題,不要讓人對「為什麼現在要解決這個問題」留有疑問。遵循極簡主義的做法,只處理和記錄在生命週期各個階段確實需要解決的問題。

• 決策(Decision):清楚地陳述架構的方向,也就是你所選定的立場。

• 狀態(Status):決策的狀態,例如待定、已決定或已批准。

• 分組(Group):你可以使用簡單的分組(例如整合、表現層、資料等)來幫助整理這組決策。你也可以使用更復雜的架構本體,例如 John Kyaruzi 和 Jan van Katwijk 提出的本體,其中包含事件、日曆和地點等更抽象的類別。例如,使用該本體時,你會把涉及系統需要資訊的各種事件的決策歸入「事件」類別。

• 假設(Assumptions):清楚地描述你做出決策時所處環境中的基本假設,例如成本、進度、技術等。請注意,環境約束(例如公認的技術標準、企業架構、常用模式等)可能會限制你所考慮的備選方案。

• 約束(Constraints):記錄所選備選方案(即該決策)可能給環境帶來的任何額外約束。

• 立場(Positions):列出你考慮過的立場(可行的選項或備選方案)。這些往往需要冗長的解釋,有時甚至需要模型和圖表。這並不是一份詳盡無遺的清單。不過,你不會希望在最終評審時聽到「你有沒有想過……?」這樣的問題;這會導致失去信譽,並讓人質疑其他架構決策。本節也有助於確保你聽取了他人的意見;明確陳述其他意見有助於爭取這些意見的支持者加入你的決策。

• 論證(Argument):概述你選擇某個立場的原因,包括實施成本、總擁有成本、上市時間以及所需開發資源的可用性等事項。這可能與決策本身同樣重要。

• 影響(Implications):正如 REMAP 元模型所指出的,一項決策會帶來許多影響。例如,一項決策可能引入做出其他決策的需要、建立新需求或修改現有需求、給環境帶來額外約束、要求與客戶重新協商範圍或進度,或者要求額外的員工培訓。清楚地理解並陳述決策的影響,對於爭取各方支援和制定架構執行路線圖非常有效。

• 相關決策(Related decisions):顯然,許多決策是相互關聯的;你可以在此列出它們。不過,我們發現實踐中追溯矩陣、決策樹或元模型更有用。元模型適合以圖示的方式展示覆雜的關係(例如 Rose 模型)。

• 相關需求(Related requirements):決策應由業務驅動。為了體現問責,請明確地將你的決策對映到目標或需求。你可以在此列舉這些相關需求,但我們發現引用追溯矩陣更為方便。你可以評估每項架構決策對滿足每項需求的貢獻,然後評估所有決策合起來對每項需求的滿足程度。如果一項決策對滿足任何需求都沒有貢獻,就不要做出該決策。

• 相關製品(Related artifacts):列出該決策所影響的相關架構、設計或範圍文件。

• 相關原則(Related principles):如果企業有一套公認的原則,請確保決策與其中一項或多項原則保持一致。這有助於確保各領域或各系統之間的一致性。

• 備註(Notes):由於決策過程可能耗時數週,我們發現記錄團隊在溝通推廣過程中討論的備註和問題很有用。