Power Platform 適切に設計されたワークロード

Power Platform Well-Architectedでは、望ましいビジネス成果を実現するために連携して動作するアプリケーション リソース、データ、およびサポート インフラストラクチャのセットを表すために、 ワークロード という用語を使用します。 ワークロードは、アプリケーションとテクノロジのコンポーネント、および動作、開発、運用のプロセスで構成されます。

ワークロードはアーキテクトによって設計され、ワー​​クロード チームによって構築されます。 機能的および非機能的なビジネスニーズを満たします。 ワークロードには多くの種類があります。

ワークロード分類の一般的な基準は次のとおりです。

• ワークロードの有用性、特性、および使用パターン。
• 主要な影響力のある推進要因。
• 対象ターゲット 対象者。

同じクラスのワークロードは、ターゲット 対象者、コンプライアンス要件、テクノロジー スタックなどの類似点を共有できます。 Well-Architectedの5つの柱、その原則、チェックリスト、トレードオフは、すべてのワークロード クラスに関連します。 Power Platform

柱となるガイダンスを、ワークロードの優先順位を表す技術設計原則と設計領域に適用します。 推奨事項に従って、ワークロードを正常にセットアップし、それを Power Platform Well-Architectedに適合させます。

Well-Architectedワークロードとは何ですか? Power Platform

あらゆるワークロードの設計と運用では、信頼性、セキュリティ、運用の卓越性、パフォーマンス効率、エクスペリエンスの最適化という5つのアーキテクチャの柱を考慮する必要があります。

成功するワークロードを作成するには、 Power Platform Well-Architectedの原則に従って開発します。

Power Platform 適切に設計されたワークロード:

• システムが何をすべきか、それをどの程度うまく実行すべきかを説明する要件があり、目標を達成するために重要度によってランク付けされています。
• リソースを使用し、設計パターンとトレードオフを組み込むことで、これらの要件を達成できるように設計されています。
• 設計と目的の仕様に従って構築および運用されます。
• 目的をどれだけ達成したかによって評価されます。
• 目的が改良されたり変更されたりしても適応できます。
• 必要なだけの信頼性があります。
• 必要なだけ安全です。
• 責任を持って開発・運営されています。
• 許容可能な期間内に目的を達成します。
• ユーザーの成功を保証するエクスペリエンスを提供します。

ワークロード チームと組織の中央チーム間のコラボレーションにより、前述の特性を持つワークロードを作成する必要があります。 次のセクションでは、これらのチームとその機能について説明します。

ワークロードチーム

幅広い技術およびビジネス分野を持つチーム メンバーで構成されるワークロード チームを作成します。 すべてのチームメンバーの主な焦点は、ワークロードの成功である必要があります。

ワークロードチームメンバーの例
ビジネス関係者 開発者またはソフトウェアエンジニア ソリューションアーキテクト データアナリスト データベース管理者	作成者 セキュリティアーキテクトまたはエンジニア インフラエンジニア 製品マネージャーまたはオーナー 品質保証（QA）エンジニア サポートチームメンバー

集中化されたチームと関係者

ワークロード チームは、集中化されたチームからサポートを受けることがよくあります。 これらのチームはサポート機能を提供し、組織のクラウド ワークロードの多くまたはすべてに対するガバナンスを強化します。 集中型チームは組織の成功を目指しますが、組織の成功はワークロードのパフォーマンスに部分的に依存します。 ワークロードに対するサービス、ガイダンス、ガードレールを提供します。

集中型チームとチームメンバーの例
ビジネスインテリジェンスアナリスト ビジネス関係者 センターオブエクセレンス（CoE）ボード プラットフォームチーム サイバーセキュリティアナリスト データベース管理者 エンタープライズアーキテクト	ビジネス アナリスト インフラエンジニア 法務およびコンプライアンス担当者 ネットワークエンジニア 調達スペシャリスト プロジェクト マネージャー

Power Platform Well-Architectedワークロード チームは、ワークロードの結果に重点を置いています。 彼らは、集中化されたチーム メンバーからの専門的なサポートと連携し、その恩恵を受けます。

要件を満たす

Well-Architected全体を通じて、推奨事項はワークロードの目的と期待される結果と一致します。 Power Platform 推奨事項では、どのチーム メンバーまたはチームがワークロードの義務を促進するかについては明示されていません。 ワークロード レベルのマッピングを実行して、ワークロードの種類と重要度に関連するチームの役割と責任を決定することで、各アクションを誰が実行する必要があるかを決定できます。

直接ワークロード チームがほとんどのワークロード要件を処理します。 一部の要件は、集中化されたチームとの共同作業として処理されます。 たとえば、実装の選択は、中央チームが設定したガードレールに基づいて行われる場合があります。 あるいは、集中化されたチームが実装の選択を独占的に処理する場合もあります。

ワークロード チームは、ワークロード目標を協力して達成するために、他のチームと協力関係を構築する必要があります。 コンポーネントまたは責任をアウトソーシングする場合は、それらの義務を確実に果たす必要があります。

制約を学ぶ

集中化されたチームは、チームのコア機能とコア インフラストラクチャに基づいて、さまざまなワークロードをサポートします。 このサポートを組織規模で提供するために、集中化されたチームは、提供されるサービスまたはインフラストラクチャに統一性と制約を実装する場合があります。 ワークロードを設計する際には、これらの制約を理解し、可能であれば、それらの制約を知っているエンタープライズ アーキテクトと提携することが重要です。 可能な限り、以前の実装から学びましょう。

要件を明示的に伝える

ワークロード要件に、コア機能またはインフラストラクチャの提供に関する制限やサービス レベル アグリーメント (SLA) があいまいな場合、それをリスクとして考慮してください。 ワークロード チームは、この問題がワークロードにどのような影響を与えるかを他のチームに説明する必要があります。 ワークロードの要件、設計、実装を調整したり、インフラストラクチャの提供内容を変更したりする必要がある場合があります。

組織の指令に関連するプラットフォーム チームの義務とワークロード チームの義務を理解すると、現実的な期待と推奨事項に基づいてワークロード要件を伝えることができます。

統一された勝利を目指す

責任の共有は、トレードオフ、制約、妥協だけではありません。 プラットフォーム チームは、多くの場合、個々のワークロード チームが維持できる範囲を超えて増強できる、高度に専門化されたスキルと専用の予算を持っています。 次の例を考えてみましょう。

セキュリティ専門家。 ワークロードには安全な開発ライフサイクルがある可能性があります。 集中化されたセキュリティ チームが組織全体で大規模な安全な開発タスクを実行すると、ユーザーの労力を超えた定期的な侵入テストを実行する場合があります。 また、インシデント対応戦略の計画と実行にも役立つ可能性があります。

エンタープライズ アーキテクチャ ガイダンス。 エンタープライズ アーキテクチャ チームのパターンとプラクティスに従えば、チームがすでにプロセスを合理化しているため、時間と労力を節約できます。 交渉なしではパートナーシップ内で解決できない場合でも、やり直しを防ぐことができます。

プラットフォーム チームは、自己学習用のドキュメント リポジトリの提供など、さまざまなアクティビティのためにワークロード チームにセルフサービス オプションを提供することがよくあります。

ワークロードに適したセルフサービス オプションを調べます。

成功と課題を共有する

他のチームと協力するということは、作業負荷の成果と困難を祝福し、認めることも意味します。 ワークロードが要件を満たし、目的の値を達成したら、パートナー チームにその旨を知らせます。 彼らがどのようにワークロードの成功に貢献したかを示します。 作業負荷が要件を満たさない場合は、問題を共有し、協力して調整し、軌道に戻ります。

プラットフォーム チームにも義務と成功基準があります。 パートナーは、あなたのワークロードがオファリングとうまく連携するかどうか、またはそれが迷惑な隣人になるリスクがあるかどうかを教えてくれるはずです。

継続的な改善に努める

継続的な改善は、すべてのWell-Architectedのテーマです。 Power Platform 変化に対してオープンになりましょう。 既存の問題を解決したり、新しいテクノロジーを使用したり、新しい要求を満たしたり、新しい制限の下で作業したりする新しい方法に遭遇する可能性があります。 時間の経過とともに作業負荷が変化する場合は、協力するチームにも同じ姿勢を奨励します。 ただし、あらゆる改善の機会には変更も伴い、適切な管理プロセスによってサポートされる必要があります。

ワークロード チームは、プラットフォーム チームのサービスに影響を及ぼす可能性のあるワークロード ニーズの計画された変更について、プラットフォーム チームに通知する必要があります。 同様に、プラットフォーム チームは、ワークロード パートナーを変更管理プロセスに関与させ、重要なプラットフォームの変更について明確に伝える必要があります。 製品の開発状況を理解し、共有するために、パートナーとの定期的なコミュニケーション スケジュールを設定します。

成功を収める

ワークロードは、ユーザー、株主、規制当局、従業員、センター オブ エクセレンス、最高エクスペリエンス責任者など、さまざまな利害関係者からの多くの要求に直面します。 こうした要求があると、明確な方向性を選択することが難しくなります。 Power Platform Well-Architectedは、肯定的な結果を達成するためのアーキテクチャ選択の理由を説明することで、設計と実装を理解するのに役立ちます。 成功するワークロードを構築し、その成功を組織とともに祝いましょう。