ワークロード チームとのコラボレーション
アーキテクチャ仕様の提供は、1 回限りの作業ではありません。 アーキテクトは実装中にワークロード チームとやり取りすることが期待されます。
継続的なコラボレーション タスク
明確さを提供します。 アーキテクトは、実装チームの障壁がない状態を保てるよう、提供された仕様を明確にするために、すぐに連絡を取れる必要があります。 潜在的な阻害要因に対処するには、アーキテクトはイテレーション計画の演習とチーム会議に積極的に参加する必要があります。
実装シーケンスの提案をします。 アーキテクトは、設計から運用環境に対応した製品への移行は反復であることを理解しています。 アプリケーションのどの部分を最初に実装するかを推奨できます。 このアプローチを使用すると、ワークロード チームはそのエクスペリエンスから学習し、得た知識をワークロードの残りの部分に適用できます。
実装レビューのチェックポイントを設定します。 ワークロード チームは、実装とアーキテクチャ仕様を比較するための定期的なレビュー チェックポイントを確立する必要があります。 この方法を使うと、仕様に従って設計が実装され、仕様は予測される要件を満たすことができます。 このフィードバック ループは、設計または実装のエラーを修正できます。
利害関係者とコミュニケーションを取ります。 アーキテクトは、利害関係者やビジネスとの間に確立された関係を持ち、ワークロードについて深く理解しています。 その結果、多くの場合、実装チームの懸念やリクエストに対する要件の変更点のネゴシエートを中継するのに適した立場にあります。
環境の推奨事項を行います。 ワークロードの設計は、多くの場合、運用環境とそのディザスター リカバリーの設計を超えて拡張されます。 運用環境は、ワークロード実装チームが必要とする可能性がある多くの環境の 1 つに過ぎません。 アーキテクトは、運用前環境の適切なサイズ設定でワークロード チームを支援することもできます。
概念実証 (POC) を使用します。 アーキテクトは、ワークロード アーキテクチャの設計仕様に関する決定事項を伝えるために、デザイン段階で POC をよく使用します。 これらの POC は、実際のワークロード実装の実現可能性に関する分析情報を提供することもできます。 POC が存在しない場合、アーキテクトは、実装チームが開発を開始する前に作成する必要があります。
プラットフォーム チームとのコラボレーション
一部の組織では、Azure ランディング ゾーンで提案されているように、ワークロード チームとプラットフォーム チームの間で責任を分割します。 プラットフォーム チームと連携してソリューションと価値を共同提供するワークロードの場合は、それらのチームと共同作業することが重要です。 プラットフォーム チームと共同作業を行わない場合は、プラットフォームが提供する利用可能なオファリングのコストを活用できないか、ワークロードに対してプラットフォームが要求する制約に違反するソリューションを設計する可能性があります。