ソリューション アーキテクトのチェックリスト

  • [アーティクル]

建築家の責任は、 設計と計画を提供することにあります。 アーキテクトはワークロードの実装者ではないことに注意してください。 アーキテクトは 、機能要件と非機能要件をクラウド設計パターン と目的に合わせたコンポーネントに変換します。 また、アーキテクトは、必要に応じて適応するのに十分な柔軟性を備えたワークロードを設計しますが、機能の計画された寿命を乗り切るのに十分な耐久性を備えています。

また、監視可能性やサポート可能性、ディザスター リカバリーなどの望ましくない状況を説明するなど、ワークロードの運用面も設計に含まれています。 最後に、設計は、すべてのビジネス、財務、コンプライアンス、および組織の要件によって制約される必要があります。

Azure Well-Architected Framework などのアーキテクチャ フレームワークは、アーキテクトにシステム設計に関する包括的な視点を提供するのに役立ちます。 Well-Architected Framework 成果物には、 設計原則、 チェックリスト、推奨事項などの要素 が含まれます。 ワークロードの要件をサポートするには、これらの成果物を デシジョン ツリー、 参照アーキテクチャ、 評価などの他のリソースと組み合わせて、情報に基づいた意思決定を行う必要があります。

チェック リスト

  成果物タスク
☐ 構造化パケットとして図を伴うアーキテクチャ設計仕様を開発します。 仕様は、ワークロードの機能要件と非機能要件を満たし、ルーチン、アドホック、緊急操作のプロビジョニングを含める必要があります。
☐ 広範な概要からネットワークや ID などの詳細なディメンションまで、システム設計のすべての側面を示すアーキテクチャ設計図を作成します。
☐ 設計プロセス中に行われるアーキテクチャ上の決定の正当な理由を含むアーキテクチャデシジョン レコード (ADR) を維持します。
☐ 実装中にワークロード チームと協力 して、実装シーケンスに関する明確さと推奨事項を提供します。 このコラボレーションは、学習を最大化し、最初から改善するのに役立ちます。 また、必要に応じて、利害関係者と要件を再ネゴシエーションします。
☐ ワークロードの問題に関するコンテキスト化された情報を提供するモデリング演習をサポートします。 コンテキスト化された情報は、コスト、アプリケーションの正常性、およびその他の領域をカバーできます。
☐ 使用パターンとワークロード機能またはクラウド プロバイダーの変更の変化の観察に基づいて、最適化に関する推奨事項を提供します。
☐ 監査、コンプライアンス、および信頼度のレビューに参加して、レビュー を実施する権限を持つ外部関係者に貴重な視点を提供します。
☐ 変更レビュー中にコンサルタントとして、変更 の推定コストとその実現可能性に関する分析情報を提供します。

次の手順

Well-Architected Framework の柱を使い始め、その主要な概念を理解します。

Azure Well-Architected Framework の柱