コンサルティング ロールでワークロードをサポートする
アーキテクトは、時間の経過と共に変化するワークロードに関与し続ける方法を模索する必要があります。 彼らの役割は、最初の実装中に設計の引き渡しや相談で終わるわけではありません。 アーキテクトは、製品の進化に関連する他のアクティビティで使用できる視点をもたらします。
モデリングの演習をサポートする
Teams では、複数のディメンションと複数の目的でワークロードをモデル化できます。 たとえば、ワークロードでは、実装の詳細からビジネス コンストラクトに正常性シグナルを抽象化できます。 または、時間の経過に伴うシステムの増加やライセンス プロセスをモデル化して、代替の課金モデルを評価することもできます。
モデルが抽象化であるか、仮説を評価して将来のビジネス上の決定を伝えるかにかかわらず、アーキテクトはそのプロセスに貢献します。 ワークロード設計、既知または予測された制限事項、スケーリング特性に関する分析情報を使用して、モデル内の前提条件を検証または調整し、システムをより正確に近似します。 たとえば、アーキテクトは、サービス レベル目標 (SLO) などの依存関係の特性を評価することで、重要なフローの正常性モデルを確認します。
潜在的な改善点を共有する
アーキテクトは、クラウド プロバイダーのオファリングや業界の設計パターンなどの基礎を常に最新の状態に保ちます。 ワークロードの設計時に最新の機能が使用されなくなった可能性があります。 または、アプリケーションの予想される使用パターンが、予測された方法で現れる可能性があります。 このような場合は、この新しい知識に基づいて現在の設計をさらに最適化または調整するための推奨事項を提示する機会があります。
アーキテクトは、ワークロードの稼働後にワークロード チームに定期的にフォローアップする必要があります。 継続的なコミュニケーションは、設計がどのように実装され、実際の使用でどのように実行されているかを確認することで、将来の設計作業に関する知識を広げるのに役立ちます。 また、実際の実装と使用に基づいて最適化の推奨事項を提供することもできます。
レビューの支援
正式な監査やコンプライアンス レビューなど、ワークロードがレビュー中の場合、システム アーキテクトの関与がプロセスの恩恵を受ける可能性があります。 ワークロードの アーキテクチャ決定レコード を使用して、実装の選択に関する質問に答えるのに役立ちます。 また、会話中にシステムを視覚化し、主題の専門知識を提供するための最新の図も提供します。
アーキテクトは、選択した顧客または資金調達契約中に製品に対する信頼を築く権限のある知識を持っています。 顧客が製品に対して持っている固有の要求について学習し、システムの設計におけるそれらのニーズを考慮することができます。
提案された変更をレビューする
すべてのワークロードには、広範な方向性レベルの作業から特定のタスクまで、作業のバックログがあります。 アーキテクトは、作業項目の要件の収集、スコープ設定、および受け入れ基準の構築に関与する必要があります。
実装チームは現在の作業項目の提供に忙しいため、アーキテクトは時間を使って将来の作業項目を確認、検証、調整できます。 新しい機能でシステム内のコンポーネントの再設計が必要な場合の検出、提案された変更に関するコスト分析の提供、または新しい変更を段階的に導入するアプローチの提案に役立ちます。 最終的には、新しい機能や拡張されたユーザー ベースを含む提案された変更のプロセスの早い段階でアーキテクトが関与することで、再作業が最小限に抑え、チームが設計の崖を発見するのに役立ちます。