ワークロード アーキテクチャ設計仕様
ワークロード アーキテクチャ設計仕様は、設計の選択肢を説明し、図を伴う詳細な仕様です。 設計の選択肢は、機能要件と非機能要件を満たしている必要があり、日常、アドホック、緊急の運用に対するプロビジョニングが含まれている必要があります。
図の詳細については、「アーキテクチャ設計図」を参照してください。
ワークロード アーキテクチャの設計は、通常、広範囲にわたり、アプリケーションの設計から始まり、クラウド サービスの選択に進みます。 これらのフェーズは相互に情報を提供し合います。 アプリケーションとインフラストラクチャを組み合わせた設計は、すべての要件を満たす必要があります。
すべての要件を満たすソリューションを実現するには、利害関係者、開発者、テスト担当者、運用チーム、製品所有者間の共同作業が必要です。 設計プロセスでは、要件を明確にし、ネゴシエーションを行いながら洗練させていく必要があります。 このプロセスは反復的であり、多くの場合、複数のレビューが必要になります。
設計原則と推奨事項ガイドを含む Azure Well-Architected フレームワークの基本的なガイダンスに合わせて設計を行い、トレードオフを確認することをお勧めします。
最終的に、ワークロード アーキテクチャの設計仕様はワークロード開発チームによって実装されるため、明確かつあいまいさがないものである必要があります。 仕様はすぐに利用できて、ワークロードのドキュメントと共に保存する必要があります。
機能仕様
ワークロードの機能仕様には、開発中のシステムまたは機能の "内容" と "理由" が詳しく記載されますが、実装についてはされません。 このドキュメントでは、現在の存在する問題と、この機能またはシステムがそのエクスペリエンスをどのように改善するかを説明する必要があります。 このドキュメントには、ほとんどのビジネス要件が取り上げられます。
アーキテクトはこのドキュメントの作成を支援できますが、それは主に製品の当事者意識によるものです。 アーキテクトは、この仕様に取り込まれるデータの設計を支援する必要があります。 この関与により、機能仕様が効果的かつ効率的な技術設計を確実に推進します。
この仕様で取り上げるべきいくつかのトピックの例を次に示します。
この設計の "スコープ内" の内容を詳しく説明するだけでなく、"スコープ外" である隣接する懸念事項についても明確にします。 明確なスコープを設定すると、機能の周囲の境界が定義されるため、スコープの収まりの悪さが軽減されます。
この変更をどのように測定するかについての詳細を含めると役立ちます。 どのような測定値を収集する必要があるか、またそれらの測定値がどのようなビジネス目標をサポートするのか、です。
ユーザー フローを明確に記述する必要があります。 忠実度が低いモックアップも役立つ場合があります。 エラー処理の状況がこれらのフローにとって重要である場合、想定される動作を必ず記述します。
アクセシビリティ、コンプライアンス、パフォーマンス、プライバシー、またはセキュリティに関する特定の要件を常に含めます。
計画されているロールアウト戦略を含めます。 たとえば、"この機能は、完全リリースを決定するまでの 2 か月間、ベータ版ユーザーに提供されます" などです。
この仕様では、特定の技術的な実装の詳細は避けてください。 これらの機能仕様により、アーキテクトが作成する技術仕様が促進されます。
技術仕様
技術仕様では、機能仕様に記載されているスコープと目標に基づいて、"方法" が説明されます。 この仕様は、エンジニアリング チームが実装中に POR (plan-of-record) として使用できるように設計されています。
この仕様には次のような項目が含まれます。
- 購入、構築、再利用、拡張、使用停止などのテクノロジに関する決定。
- API およびデータ コントラクト (スキーマ) (下位互換性の実装戦略を含む)
- ロールアウトとロールバックの実装の詳細
- 独自のセキュリティで保護された開発ライフサイクル (SDL) とプライバシーの実装
- テスト計画
- 主要な監視とアラート シグナルのソース
- 検討された代替設計
技術仕様により、エンジニアリングの作業が促進されます。 エンジニアリングの作業項目は、主にこの仕様の内容に基づいて作成されます。 実装チームは、作業項目、技術仕様、機能仕様を参照して、最終結果が機能要件と非機能要件の両方を満たしていることを確認します。
ディザスター リカバリー計画
ワークロードの信頼性要件を満たすために、アーキテクトは対象の回復時刻の目標 (RTO) および回復ポイントの目標 (RPO) の範囲内で復旧できるシステムを設計する必要があります。 アーキテクチャ設計仕様には復旧計画を含める必要があります。 この計画では、関連するアーキテクチャ コンポーネント、フェールオーバー メカニズム、ユーザーとデータ フローへの影響、運用上の推奨事項を取り扱う必要があります。 また、設計によってどの復旧対象がどのように達成されるかを説明する必要があります。
初期計画は訓練やインシデント後のレビューからの分析情報に基づいて進化することが想定されていますが、すべての新しいアーキテクチャの初期計画を提供するのはアーキテクトの責任です。
セキュリティとコンプライアンスに関するドキュメント
アーキテクトは、関連するセキュリティとコンプライアンスの制約に準拠するソリューションを設計する責任があります。 設計成果物では、これらの要件をサポートするために設計に組み込まれたアフォーダンスを強調し、要件を直接満たせない場合に必要な補正制御を特定することが重要です。
一貫性
テンプレートを使用して、ワークロードのさまざまな仕様を文書化します。 一貫性は、利害関係者、責任者、実装チームが仕様を読むときに役立ちます。
仕様に次のような主要なメタデータ フィールドが含まれていることを確認します。
- 状態: "ドラフト"、"レビュー中"、"承認済み" の状態。
- 作業項目リンク: チームのバックログ内の主要な作業項目へのリンク。
- 主要なクロス リンク: 関連する仕様または仕様をサポートするその他のドキュメントへのリンク。
- 主要な個人: 関与した主要な意思決定者の名前を一覧表示する場所。 この一覧には、ビジネス アナリスト、ビジネス パートナー、技術リーダー、製品所有者または仕様を承認したリーダーなどのロールが含まれる場合があります。