フレームワークレビュープロセスレビュープロセスアーキテクチャの評価は非難せずに掘り下げることができる一貫した方法で実施される必要があります。これは何日もかけずに数時間で終わる軽いプロセスである必要があります。話し合いであり、監査ではありません。アーキテクチャレビューの目的は、対策を必要とする重大な問題や改善可能な領域を特定することです。レビュー結果は、お客様のワークロードの扱いやすさを改善する対策です。「アーキテクチャ」で説明したとおり、各チームメンバーがアーキテクチャの品質に責任を持つ必要があります。フレームワークに基づいてアーキテクチャを作成するチームメンバーは、形式ばったレビューミーティングを開催するよりも、アーキテクチャを継続してレビューすることが推奨されています。レビューを継続することで、チームメンバーはアーキテクチャの変化に応じて回答を更新したり、機能を提供しながらアーキテクチャを改善したりすることができます。システムとサービスに関する内部評価方法と合致しています。取り上げられる領域が軽視されないようにするための質問に基づきます。検討し、使用している評価プロセスを改善できるかどうかを判断します。多くの決定は取り消しが可能な双方向の扉です。した決定には簡易なプロセスを適用します。場合は、取り消しが困難または不可能であるため、決定を下す前により詳細な検証が必要です。避けるため、設計の初期段階におけるレビューを実施します。本番運用前にもレビューを行います。本稼働開始後に新しい機能を追加したり、テクノロジーの実装を変更したりするにつれて、ワークロードは変化し続けます。ワークロードのアーキテクチャは時間とともに変わります。アーキテクチャを変えるにつれてアーキテクチャの特性が劣化しないように適切な予防策を取る必要があります。レビューを含めて、予防プロセスに従う必要があります。回限りのレビューまたは単独の測定として評価を活用するには、すべての適切な関係者をその話し合いに含める必要があります。レビューが実施されたことにより、チームが実装した内容を初めて本当に理解したということはよくあります。別のチームのワークロードをレビューするときに有効な方法は、そのアーキテクチャについて何度か気軽に話し合うことです。ほとんどの質問に対する回答はそれで得られます。その後に数回の会議で曖昧な領域や気付いたリスクについて解明したり、掘り下げたりすることができます。会議を進行するために次のアイテムをお勧めします。)レビューを完了すると、問題のリストが出来上がります。ビジネスの状況に応じてその優先順位を決めることができます。それらの課題がチームの日常業務に及ぼす影響を考慮する必要もあります。課題に早く対処することによって、繰り返す課題の解決にではなく、ビジネス価値の創造に費やす時間ができます。課題に対処しながらレビューを更新することで、アーキテクチャがどのように改善しているのかを知ることができます。度やってみると明らかになるのですが、新しいチームが当初抵抗することがあります。レビューの利点をチームに知らせることで、次のような反論に対処できます。(チームが大きな仕事を始める準備をしているときによくある発言)大きな仕事を始める準備をしているならば、それが円滑に進む必要があります。レビューを実施することによって、見逃していたかもしれない問題を把握できます。製品ライフサイクルの早い段階でレビューを実施して、リスクを洗い出し、機能提供ロードマップに沿ったリスク軽減計画を立てることをお勧めします。(スーパーボウルなど動かせないイベントを目標としている場合によくある発言)そのようなイベントを動かすことはできません。アーキテクチャのリスクを把握せずに、本当に進めるつもりですか。すべての課題に対策を講じることができないとしても、問題が生じたときの対処法を準備しておくことはできます。ないことをチームは理解するでしょう。組織内の他のチームと何度かレビューを実施すると、主題となる課題が見つかるかもしれません。特定の柱または主題に関して多くの課題を抱えているチームが複数あるかもしれません。すべてのレビューを総合的に検討し、それらの主題に関する課題に対処するのに役立つメカニズム、トレーニング、またはプリンシパルエンジニアリングの説明を見つける必要があります。