Architecture Decision RecordJeff 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 メタモデルが示すように、決定は多くの影響を伴います。たとえば、決定によって他の決定を行う必要が生じたり、新しい要件が生じたり、既存の要件が変更されたり、環境にさらなる制約が課されたり、顧客とスコープやスケジュールを再交渉する必要が生じたり、追加のスタッフトレーニングが必要になったりすることがあります。決定の影響を明確に理解し、述べることは、賛同を得て、アーキテクチャ実行のロードマップを作成するのに非常に効果的です。
関連する決定: 多くの決定が関連していることは明らかです。ここに列挙できます。ただし、実際にはトレーサビリティマトリックス、決定木、またはメタモデルの方が有用であることが分かっています。メタモデルは、複雑な関係を図で示すのに役立ちます(Rose モデルなど)。
関連する要件: 決定はビジネス主導であるべきです。説明責任を示すために、決定を目標や要件に明示的にマッピングします。ここでこれらの関連要件を列挙することもできますが、トレーサビリティマトリックスを参照する方が便利であることが分かっています。各アーキテクチャ上の決定が各要件の充足にどれだけ貢献しているかを評価し、さらにすべての決定を通じて要件がどれだけ満たされているかを評価できます。ある決定が要件の充足に貢献しない場合は、その決定を行わないでください。
関連する成果物: この決定が影響を与える、関連するアーキテクチャ、設計、またはスコープの文書を列挙します。
関連する原則: 企業が合意した原則のセットを持っている場合は、決定がそれらの 1 つ以上と一貫していることを確認します。これは、ドメインやシステム間の整合性を確保するのに役立ちます。
メモ: 意思決定プロセスには数週間かかることがあるため、社内への周知の過程でチームが議論したメモや課題を記録しておくと便利であることが分かっています。