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