アーキテクチャ上の決定

ソフトウェア工学とソフトウェアアーキテクチャ設計において、アーキテクチャ上の決定とは、アーキテクチャ的に重要な要件に対処する設計上の決定であり、決定が難しい^[1]、および/または変更にコストがかかると考えられています。^[2]

特徴

アーキテクチャ上の決定は、システムの非機能的特性に影響を与えます。各アーキテクチャ上の決定は、具体的でアーキテクチャ上重要な設計上の問題 (設計上の問題、必要な決定とも呼ばれます) を記述し、その問題には複数の潜在的な解決策 (オプション、代替案とも呼ばれます) が存在します。アーキテクチャ上の決定は、意識的で、多くの場合は共同作業によるオプション選択プロセスの結果をとらえ、たとえば、アーキテクチャ上の決定で扱われる 1 つ以上の品質属性を参照し、設計とオプションの選択に関する「なぜ」の質問に答えるなどして、意思決定結果の設計上の根拠を提供します。アーキテクチャ上の決定は、ソフトウェアシステム全体、またはそのようなシステムの 1 つ以上のコアコンポーネントに関係します。アーキテクチャ上の決定の種類には、アーキテクチャ上の戦術とパターン、統合テクノロジ、ミドルウェアの選択、および関連する実装戦略と資産 (商用製品とオープンソースプロジェクトの両方) の選択があります。^[3]

ソフトウェアアーキテクチャ設計は厄介な問題であり、^[4]アーキテクチャ上の決定を正しく行うことは困難です。多くの場合、特定のアーキテクチャ設計問題に対する単一の最適解は存在しません。アーキテクチャ上の意思決定はソフトウェアアーキテクトの中核的な責任です。^[5]ソフトウェアアーキテクチャにおける第一級の概念としてのアーキテクチャ上の決定の重要性に関する追加の動機はオンラインで見つけることができます。^[6]

歴史

理論的根拠は、Perry/Woolfによるソフトウェアアーキテクチャの初期の定義で言及されていましたが^{[7] 、2004年にオランダのフローニンゲンでアーキテクチャ上の決定とアーキテクチャ}知識管理に関するワークショップが開催されるまで、あまり研究されていませんでした。初期の出版物はこのワークショップまで遡ることができます。^[8]^[9] 2006年以降、アーキテクチャ知識管理とアーキテクチャ上の決定の研究コミュニティは勢いを増し、ヨーロッパソフトウェアアーキテクチャ会議(ECSA)、ソフトウェアアーキテクチャ品質(QoSA)、(ワーキング)国際ソフトウェアアーキテクチャ会議(ICSA)などの主要なソフトウェアアーキテクチャ会議で多くの論文が発表されました。Springerの本は2009年時点での最新技術をまとめており^[10]、2013年の体系的なマッピング研究^[11]では、ますます最近の研究結果がまとめられ、分析されています。

実際には、OpenUPなどのソフトウェア開発プロセスなどでは、正しい決定を下すことの重要性が常に認識されており、決定を文書化するためのテンプレートやプラクティスが多数存在します。これらのテンプレートのうち7つが比較されています。^[12]アーキテクチャ記述の最新の標準であるISO/IEC/IEEE 42010:2011には専用の根拠エンティティがあり、どのアーキテクチャ上の決定をキャプチャするか、およびアーキテクチャ上の決定のどのプロパティを決定ログに記録するかについて詳細な推奨事項が示されています。^[13]

意思決定管理の手順

意思決定の特定

決定を下す前に、決定の必要性を明確にする必要があります。AD はどの程度緊急で、どの程度重要なのでしょうか。今すぐ決定する必要がありますか、それとも要件や構築中のシステムについてさらに詳しく知るまで待つことができますか。個人的および集団的な経験、および認められた設計方法と実践は、決定の特定に役立ちます。アジャイルソフトウェア開発チームは、プロジェクトの製品バックログを補完する決定バックログを維持する必要があると提案されています。^[14]

意思決定

特定の決定は、AD作成の準備が整ったと定義される特定の基準が満たされた場合にのみ行うことができます。(1)利害関係者が特定されている、(2)適切な時期である、(3)代替案（オプション）がリストされている、(4)要件およびその他の基準が定義されている、(5)ADRテンプレートが選択されている。^[15]

意思決定技術には、一般的なものからソフトウェアやソフトウェアアーキテクチャに特有のものまで、さまざまなものがあり、例えば、対話マッピングなどがあります。^[16] グループによる意思決定は、活発な研究テーマです。

意思決定文書

意思決定を記録するためのテンプレートやツールは、アジャイルコミュニティ（M. Nygardのアーキテクチャ意思決定記録^[17]など）やソフトウェアエンジニアリングおよびアーキテクチャ設計手法（IBM UMF ^[18]やCapitalOneのTyreeとAkerman ^[19]が提案したテーブルレイアウトなど）の両方に多数存在します。G. Fairbanksは、1ページのArchitecture Haikus ^[20]に意思決定の根拠を含めました。彼の表記法は後にYステートメントに進化しました。動機、例、比較については ^{[21]を参照してください。}

決定の制定（執行）

アーキテクチャ上の決定はソフトウェア設計で使用されるため、資金提供、開発、運用を行うシステムの利害関係者に伝えられ、受け入れられる必要があります。アーキテクチャ上の懸念と決定に焦点を当てた、アーキテクチャ的に明らかなコーディングスタイル ^[22]とコードレビューは、2つの関連するプラクティスです。

ソフトウェアの進化においてソフトウェアシステムを最新化する場合、アーキテクチャ上の決定も考慮する必要があります。

意思決定の共有（オプションのステップ）

多くのアーキテクチャ上の決定はプロジェクト間で繰り返されるため、過去の決定に関する経験は、良いものも悪いものも、明示的な知識管理戦略を採用する際に貴重な再利用可能な資産となり得ます。^[23]

単一のアーキテクチャ上の決定が完了したとみなせる時期を知ることは重要です。完了の定義には、証拠、基準、合意、文書化、実現/レビューの5つの要素が提案されています。^[24]

例

大規模プロジェクトでは、次のようなアーキテクチャ上の決定事項が 100 を超えることがあります。

^{アーキテクチャの階層化スキームの選択と個々のレイヤーの役割（ [25]}のレイヤーパターンを採用する場合）
レイヤー、コンポーネント、コネクタごとの実装テクノロジの選択 (例: プログラミング言語、インターフェース契約形式、統合インターフェースとメッセージ交換を設計する際の XML と JSON)
クライアント側（JavaScript フレームワークなど）とサーバー側（Java および PHP フレームワークなど）のプレゼンテーション層フレームワークの選択

さらなる例については、属性駆動設計3.0 ^[26]の設計コンセプトカタログとドメイン固有の意思決定ガイダンスモデル^[27]を参照してください。

これは、以下のYステートメントテンプレートに従ってフォーマットされた意思決定の例です。^[28]

「Webショップサービスのコンテキストでは、ショップインスタンス間でユーザーセッションデータの一貫性と最新性を維持する必要性に直面し、セッションデータベースを設計、実装、複製する必要があることを受け入れ、クラウドの弾力性を実現するためにデータベースセッション状態パターン（クライアントセッション状態やサーバーセッション状態ではなく）^[29]を選択しました。」

テンプレート

多くのテンプレートは、現役の建築家やソフトウェアアーキテクチャの研究者によって提案されています。「アーキテクチャ決定記録（ADR）」^[30]や「Markdownアーキテクチャ決定記録」^[31]などのGitHubリポジトリには、それらの多くと、ツールへのリンク、執筆のヒントが収集されています。

ソフトウェアアーキテクチャグループの意思決定

実務家と研究者はともに、ソフトウェアアーキテクチャの意思決定は、複数の利害関係者がアーキテクチャ上の決定について議論し、評価し、絞り込むグループプロセスであることを認識しています。実務家を対象とした研究^[32]^[33]では、グループの規模は理想的であるものの、意思決定に対する構造化されたアプローチが大きく欠如していることがわかりました。具体的には、

意思決定には非構造化アプローチが主流です。これにより、グループメンバーの参加が制限されます。
建築家の意思決定プロセスを支援するコラボレーションツールのサポートが不足しています。
建築家は、構造化されたアプローチの欠如により、意思決定プロセスで遅延や省略を経験することが多い。
設計チームは集団思考や集団分極化などの課題を経験する

これらの課題は、ソフトウェアアーキテクチャコミュニティにとって実験と研究のための優れた機会を提供します。

参照

参考文献

^ Fowler, M. (2003). 「デザイン – 建築家は誰に必要か?」 IEEE ソフトウェア. 20 (5): 11–44. doi:10.1109/MS.2003.1231144
^ Booch, G.、未知の抽象化、SATURN 2016 基調講演
^ O. Zimmermann「再利用可能な設計資産としてのアーキテクチャ上の決定」の 64 ページ。IEEE Software、第 28 巻、第 1 号、64 ～ 69 ページ、2011 年 1 月/2 月。
^ Conklin, Jeffrey (2006). ダイアログマッピング：困難な問題に対する共通理解の構築。イギリス、チチェスター：Wiley Publishing。ISBN 0470017686。
^ Kruchten, P., ソフトウェアアーキテクトは実際何をしているのか? システムとソフトウェアジャーナル 81 (2008) 2413–2416
^ Hohpe, G.、「これはアーキテクチャですか? 決定を探してください!」
^ Perry, DE; Wolf, AL (1992). 「ソフトウェアアーキテクチャの研究の基礎」(PDF). ACM SIGSOFT ソフトウェアエンジニアリングノート. 17 (4): 40. doi:10.1145/141874.141884
^ Jansen, A.; Bosch, J. (2005). 「ソフトウェアアーキテクチャはアーキテクチャ設計上の決定事項の集合である」。第 5 回 IEEE/IFIP ソフトウェアアーキテクチャワーキングカンファレンス (WICSA'05)
^ Kruchten, Philippe、Patricia Lago、Hans Van Vliet。「アーキテクチャ知識の構築と推論」ソフトウェアアーキテクチャの品質。Springer Berlin Heidelberg、2006年。43-58。
^ Babar, MA; Dingsøyr, T.; Lago, P.; Vliet, H. van (2009). ソフトウェアアーキテクチャ知識管理: 理論と実践 (編)、第 1 版。Springer。
^ Li, Z.、Liang, P.、Avgeriou, P.、「ソフトウェアアーキテクチャにおける知識ベースアプローチの応用：体系的なマッピング研究」、Information and Software Technology、第55巻、第5号、2013年5月、777-794ページ、Elsevier。
^ Zimmermann, O.、Wegmann, L.、Koziolek, H.、Goldschmidt, T.、「プロジェクト間のアーキテクチャ決定ガイダンス」、IEEE/IFIP WICSA 2015 論文集
^ ISO/IEC/IEEE 42010:標準を使用するためのテンプレート。
^ Hofmeister, C.、Kruchten, P.、Nord, R.、Obbink, H.、Ran, A.、America, P. (2007)、「5 つの産業的アプローチから派生したソフトウェアアーキテクチャ設計の一般モデル」。
^ O. Zimmermann (2023). 建築上の決定に対する準備の定義、https://medium.com/olzzio/a-definition-of-ready-for-architectural-decisions-ads-2814e399b09b
^ Conklin, Jeffrey (2006). ダイアログマッピング：厄介な問題に対する共通理解の構築。イギリス、チチェスター：Wiley Publishing。ISBN 0470017686。
^ M. Nygard、アーキテクチャ決定の文書化
^ Zimmermann, O.、「SOA およびクラウド設計のためのアーキテクチャ決定モデリングフレームワーク」、SEI SATURN 2010 プレゼンテーション。
^ Tyree, J.、Akerman, A.、アーキテクチャの決定：アーキテクチャの神秘性を解き明かす
^ G. フェアバンクス、建築俳句、http://www.slideshare.net/matthewmccullough/architecture-haiku
^ T. van Lessen、「ADR の簡単な紹介」、https://speakerdeck.com/vanto/a-brief-introduction-to-architectural-decision-records
^ Fairbanks, G.、「アーキテクチャ的に明らかなコーディングスタイル: コード内でデザインを可視化する」、Proc. of OOPSLA 2010
^ Babar, MA; Dingsøyr, T.; Lago, P.; Vliet, H. van (2009). ソフトウェアアーキテクチャ知識管理:理論と実践 (編)、第1版。Springer。
^ O. Zimmermann (2020). アーキテクチャ上の決定における完了の定義、https://medium.com/olzzio/a-definition-of-done-for-architectural-decisions-426cf5a952b9
^ フランク・ブッシュマン;ムニエ、レジーヌ。ローナート、ハンス。サマーラッド、ピーター (1996)。パターン指向ソフトウェアアーキテクチャ、第 1 巻: パターンのシステム。ジョン・ワイリー＆サンズ。ISBN 0-471-95869-7。
^ H. Cervantes、R. Kazman、「ソフトウェアアーキテクチャの設計：実践的アプローチ」、Addison-Wesley、2016年。
^ Zimmermann, O.、「SOA、クラウド、アウトソーシングソリューション設計のためのガイダンスモデルと意思決定ツール」の 21 ページ、http://resources.sei.cmu.edu/asset_files/Presentation/2011_017_001_24654.pdf
^ Uwe Zdun 他「持続可能な建築設計の決定」、IEEE Software、第 30 巻、第 6 号 (2013)、http://www.infoq.com/articles/sustainable-architectural-design-decisions で入手可能
^ M. Fowler、エンタープライズアプリケーションアーキテクチャのパターン
^ J. Parker-Hernderson、アーキテクチャ決定記録 (ADR)、https://github.com/joelparkerhenderson/architecture_decision_record
^ ADR組織、Markdownアーキテクチャ決定記録
^ Rekhav, V. Smrithi; Muccini, Henry ( 2014年 4 月)。「ソフトウェアアーキテクチャにおけるグループ意思決定に関する研究」。2014 IEEE/IFIP ソフトウェアアーキテクチャ会議。pp. 185– 194。doi :10.1109/ WICSA.2014.15。ISBN 978-1-4799-3412-6.S2CID 17362075 。
^ V, Smrithi Rekha; Muccini, Henry (2018 年 9 月 1 日). 「ソフトウェアアーキテクチャにおけるグループ意思決定: 産業慣行に関する研究」.情報およびソフトウェア技術. 101 : 51–63 . doi :10.1016/j.infsof.2018.04.009. ISSN 0950-5849. S2CID 49384683.

[1] Fowler, M. (2003). 「デザイン – 建築家は誰に必要か?」 IEEE ソフトウェア. 20 (5): 11–44. doi:10.1109/MS.2003.1231144

[2] Booch, G.、未知の抽象化、SATURN 2016 基調講演

[3] O. Zimmermann「再利用可能な設計資産としてのアーキテクチャ上の決定」の 64 ページ。IEEE Software、第 28 巻、第 1 号、64 ～ 69 ページ、2011 年 1 月/2 月。

[4] Conklin, Jeffrey (2006). ダイアログマッピング：困難な問題に対する共通理解の構築。イギリス、チチェスター：Wiley Publishing。ISBN 0470017686。

[5] Kruchten, P., ソフトウェアアーキテクトは実際何をしているのか? システムとソフトウェアジャーナル 81 (2008) 2413–2416

[6] Hohpe, G.、「これはアーキテクチャですか? 決定を探してください!」

[7] Perry, DE; Wolf, AL (1992). 「ソフトウェアアーキテクチャの研究の基礎」(PDF). ACM SIGSOFT ソフトウェアエンジニアリングノート. 17 (4): 40. doi:10.1145/141874.141884

[8] Jansen, A.; Bosch, J. (2005). 「ソフトウェアアーキテクチャはアーキテクチャ設計上の決定事項の集合である」。第 5 回 IEEE/IFIP ソフトウェアアーキテクチャワーキングカンファレンス (WICSA'05)

[9] Kruchten, Philippe、Patricia Lago、Hans Van Vliet。「アーキテクチャ知識の構築と推論」ソフトウェアアーキテクチャの品質。Springer Berlin Heidelberg、2006年。43-58。

[10] Babar, MA; Dingsøyr, T.; Lago, P.; Vliet, H. van (2009). ソフトウェアアーキテクチャ知識管理: 理論と実践 (編)、第 1 版。Springer。

[11] Li, Z.、Liang, P.、Avgeriou, P.、「ソフトウェアアーキテクチャにおける知識ベースアプローチの応用：体系的なマッピング研究」、Information and Software Technology、第55巻、第5号、2013年5月、777-794ページ、Elsevier。

[12] Zimmermann, O.、Wegmann, L.、Koziolek, H.、Goldschmidt, T.、「プロジェクト間のアーキテクチャ決定ガイダンス」、IEEE/IFIP WICSA 2015 論文集

[13] ISO/IEC/IEEE 42010:標準を使用するためのテンプレート。

[14] Hofmeister, C.、Kruchten, P.、Nord, R.、Obbink, H.、Ran, A.、America, P. (2007)、「5 つの産業的アプローチから派生したソフトウェアアーキテクチャ設計の一般モデル」。

[15] O. Zimmermann (2023). 建築上の決定に対する準備の定義、https://medium.com/olzzio/a-definition-of-ready-for-architectural-decisions-ads-2814e399b09b

[16] Conklin, Jeffrey (2006). ダイアログマッピング：厄介な問題に対する共通理解の構築。イギリス、チチェスター：Wiley Publishing。ISBN 0470017686。

[17] M. Nygard、アーキテクチャ決定の文書化

[18] Zimmermann, O.、「SOA およびクラウド設計のためのアーキテクチャ決定モデリングフレームワーク」、SEI SATURN 2010 プレゼンテーション。

[19] Tyree, J.、Akerman, A.、アーキテクチャの決定：アーキテクチャの神秘性を解き明かす

[20] G. フェアバンクス、建築俳句、http://www.slideshare.net/matthewmccullough/architecture-haiku

[21] T. van Lessen、「ADR の簡単な紹介」、https://speakerdeck.com/vanto/a-brief-introduction-to-architectural-decision-records

[22] Fairbanks, G.、「アーキテクチャ的に明らかなコーディングスタイル: コード内でデザインを可視化する」、Proc. of OOPSLA 2010

[23] Babar, MA; Dingsøyr, T.; Lago, P.; Vliet, H. van (2009). ソフトウェアアーキテクチャ知識管理:理論と実践 (編)、第1版。Springer。

[24] O. Zimmermann (2020). アーキテクチャ上の決定における完了の定義、https://medium.com/olzzio/a-definition-of-done-for-architectural-decisions-426cf5a952b9

[25] フランク・ブッシュマン;ムニエ、レジーヌ。ローナート、ハンス。サマーラッド、ピーター (1996)。パターン指向ソフトウェアアーキテクチャ、第 1 巻: パターンのシステム。ジョン・ワイリー＆サンズ。ISBN 0-471-95869-7。

[26] H. Cervantes、R. Kazman、「ソフトウェアアーキテクチャの設計：実践的アプローチ」、Addison-Wesley、2016年。

[27] Zimmermann, O.、「SOA、クラウド、アウトソーシングソリューション設計のためのガイダンスモデルと意思決定ツール」の 21 ページ、http://resources.sei.cmu.edu/asset_files/Presentation/2011_017_001_24654.pdf

[28] Uwe Zdun 他「持続可能な建築設計の決定」、IEEE Software、第 30 巻、第 6 号 (2013)、http://www.infoq.com/articles/sustainable-architectural-design-decisions で入手可能

[29] M. Fowler、エンタープライズアプリケーションアーキテクチャのパターン

[30] J. Parker-Hernderson、アーキテクチャ決定記録 (ADR)、https://github.com/joelparkerhenderson/architecture_decision_record

[31] ADR組織、Markdownアーキテクチャ決定記録

[32] ^ Rekhav, V. Smrithi; Muccini, Henry ( 2014年 4 月)。「ソフトウェアアーキテクチャにおけるグループ意思決定に関する研究」。2014 IEEE/IFIP ソフトウェアアーキテクチャ会議。pp. 185– 194。doi :10.1109/ WICSA.2014.15。ISBN 978-1-4799-3412-6.S2CID 17362075 。

[33] V, Smrithi Rekha; Muccini, Henry (2018 年 9 月 1 日). 「ソフトウェアアーキテクチャにおけるグループ意思決定: 産業慣行に関する研究」.情報およびソフトウェア技術. 101 : 51–63 . doi :10.1016/j.infsof.2018.04.009. ISSN 0950-5849. S2CID 49384683.