ソリューション アーキテクトのチェックリスト
アーキテクトの責任は、設計と計画を作成することです。 ワークロードの実装は、アーキテクトの担当ではないことに注意してください。 アーキテクトは、機能要件と非機能要件をクラウド設計パターンに変換するともに、目的に適したコンポーネントに変換します。 アーキテクトはワークロードも設計しますが、それは必要に応じて適応するのに十分な柔軟性だけでなく、その機能の予定どおりの寿命を全うするのに十分な耐久性を持つ必要があります。
他にも設計に含まれるものとして、ワークロードの運用面があります。たとえば監視やサポート可能性であり、また望ましくない状況への対処、たとえばディザスター リカバリーについても考慮する必要があります。 最後に、その設計はビジネス、財務、コンプライアンス、および組織の要件すべてに従う必要があります。
アーキテクチャ フレームワーク、たとえば Azure Well-Architected フレームワークは、アーキテクトが総合的な視点からシステム設計を行うのに役立ちます。 Well-Architected フレームワークのアーティファクトには、設計原則、チェックリスト、推奨事項などの要素が含まれます。 ワークロードの要件をサポートするには、これらのアーティファクトに他のリソース、たとえばデシジョン ツリー、参照アーキテクチャ、アセスメントを組み合わせて、十分な情報に基づいた意思決定を行う必要があります。
チェック リスト
| 成果物タスク | |
|---|---|
| ☐ | アーキテクチャ設計仕様を作成する。これには図が付属し、1 つの構造化パケットにまとめられます。 この仕様は、ワークロードの機能要件と非機能要件を満たすとともに、定型的、アドホック、および緊急の運用への備えが含まれている必要があります。 |
| ☐ | アーキテクチャ設計図を作成する。これは広範な概要からネットワークと ID などの詳細な要素まで、システム設計のあらゆる面を描いたものです。 |
| ☐ | アーキテクチャ意思決定記録 (ADR) を維持する。この内容は、設計プロセスの中で行われたアーキテクチャに関する意思決定の根拠です。 |
| ☐ | 実装時にワークロードおよびプラットフォームのチームと共同作業する。明確さを提供し、実装シーケンスに関する推奨事項を提示します。 この共同作業は、学びを最大化して改善を最初から行うのに役立ちます。 また、必要に応じて利害関係者と要件を再調整します。 |
| ☐ | モデリング演習をサポートする。ワークロードの懸念事項について、コンテキストに応じた情報を提供します。 このコンテキストに応じた情報は、コスト、アプリケーションの正常性、およびその他の領域に及びます。 |
| ☐ | 最適化の推奨事項を提示する。これは、使用パターンの観察と、ワークロードの機能またはクラウド プロバイダーの変更に基づくものです。 |
| ☐ | 監査、コンプライアンス、信頼度のレビューに参加する。レビューを実施する権限を持つ外部関係者のために、有益な観点を提供します。 |
| ☐ | 変更レビュー時のコンサルタントになる。変更の推定コストとその実現可能性に関する意見を提供します。 |
次のステップ
初めに Well-Architected フレームワークの柱について学び、その主要な概念を理解します。