ソリューション アーキテクトの基礎

すべてのワークロードは、コンポーネントとトポロジの設計プロセスを通過します。 このプロセスは、ワークロードの開始時に最も激しく、初期要件の設計とワークロードの長期的な成功が含まれます。 アーキテクチャは、ワークロードが時間の経過と同時に変化し、organizationが機能を追加、変更、または削除する場合にも設計されます。

コンポーネントとトポロジの設計は、アーキテクトの主要な機能です。 クラウドベースおよびハイブリッド ソリューションに重点を置くアーキテクトは、多くの場合、 クラウド ソリューション アーキテクトと呼ばれます。 一部の組織では、クラウド ソリューション アーキテクトは、エンタープライズ アーキテクチャ グループ内の一元化された容量に存在します。 また、特定のワークロードに集中することもできます。

専用のロールは、アーキテクトの機能を提供できます。 場合によっては、信頼できる技術専門家 (ワークロード エンジニアリング リーダーなど) がアーキテクトの機能を提供できます。 または、organizationは、ワークロードに関連付けられているシニア エンジニアの小規模なグループ間で関数を配布する場合があります。

通常、アーキテクトはシステム設計以外の役割を果たしました。 次の場合があります。

• 開発者および運用チーム のメンバーです。
• カスタマー サポート チームと協力しました。
• 品質保証とユーザー受け入れについてシステムがどのようにテストされるかを理解する。
• ディザスター リカバリー訓練またはインシデント対応を行いました。
• ワークロードの増分と大規模な機能変更の両方に公開されています。
• 解釈された仕様とユーザー受け入れ基準。

上記の一覧は網羅的ではありませんが、これらの観点は、アーキテクトが設計業務にもたらす重要な側面です。 Azure Well-Architected Framework では、ガイダンスを最も効果的に使用するために、これらのプラクティスが実施されていることを前提としています。

次のセクションでは、アーキテクトが機能を有効にするために従う必要がある指針について説明します。

意思決定フレームワークを持つ

設計の重要な側面は、一貫したプロセスを使用して意思決定を行うということです。 アーキテクトは、厳格に初期設計と増分設計の両方に取り組む必要があります。

予想される決定事項を特定します。 学習したエクスペリエンスを使用して、意思決定の識別に役立ちます。 行う予定のすべての決定をログに記録します。

情報に基づいた意思決定を行います。 制限、制約、トレードオフ、労力、可逆性、リスクを考慮してください。 概念実証からの証拠をサポートし、テクノロジのドキュメントとガイダンスを含めます。

アーキテクチャ決定レコード (ADR) の意思決定を文書化します。 理由を各決定と共に文書化します。

実装のフォローアップ。 すべての意思決定を伝え、実装する。 実装から学習し、将来の決定を導きます。 意思決定を特定できないとリスクが発生した領域を探します。

クラウド設計パターンを把握する

クラウド設計パターンは、アーキテクチャの基本的な構成要素です。 クラウドベースのアーキテクチャとアプリケーション設計は、多くの場合、パターン認識の演習です。

パターンを認識するために、ワークロードの機能要件と非機能要件を評価します。 標準化されたパターンを使用して、設計をユース ケースにマップする機会を探します。

先に進む

現在の要件を達成するための設計は必須ですが、アーキテクトがワークロードの進化を予測することが重要です。 実装されたシステムに変更を組み込む方が、実装前に設計を変更するよりもコストが高くなります。

計画された寿命が終了するまで続くシステムを設計するには、アーキテクチャの柔軟性を念頭に置いてワークロードを設計する必要があります。 それらを識別できる場合は、デザインの崖を避けてください。

成長モデル。 ワークロードの使用量が時間の経過とともにどのように増加または縮小するかを予測します。

コンプライアンスの変更。 将来的にワークロードがコンプライアンス要件を満たすことが予想される場合は、事前に対策を講じてください。 この方法では、コンプライアンスに従う必要がある場合の手戻りを減らすことができます。

地域展開。 今後、ワークロードを複数のリージョンに拡張することを検討してください。 1 つのリージョンに制限されている設計は、複数リージョンのデプロイに対して大きくリファクタリングする必要があり、コストのかかる変更になる可能性があります。 ワークロード設計でコンプライアンス要件が異なる複数の地域に対応する必要がある場合は、さらに複雑になります。 地域の拡大に関する合理的な予測に設計要因があることを確認します。

製品ロードマップ。 設計では、非推奨へのパスにあるコンポーネントを含めないでください。 同様に、現在プレビュー状態にある機能をデザインに含める場合も注意してください。 リリースされる可能性がありますが、取り消される場合もあります。 プレビュー機能を使用して曲線を先取りすることは、非常に有利な場合があります。 機能がリリースされた直後に、ワークロードが運用環境に移行する準備が整います。 ただし、慎重なリスク分析を行った後にのみ、プレビュー機能を設計に含めます。 許容されるリスク プロファイルを持つ機能のみを出荷します。

サポート性を高める設計

次の 3 つの主要なサポートパースペクティブを使用してワークロードを設計します。

クラウド プロバイダーのサポート。 プラットフォーム サポート チャネルに関与している場合の中断を回避するために、ワークロードはクラウド プロバイダーのサポートされている構成内で動作する必要があります。

運用上の可視性。 設計では、インシデント対応中の混乱を防ぐために、ワークロード運用チームの実行を可視化する必要があります。

カスタマー サポート機能。 設計はユーザーのニーズを満たすだけでなく、カスタマー サポート機能も容易にする必要があります。 サポート チームが顧客を調査または支援する能力を妨げる設計は不十分です。

スキルを維持し、強化する

建築家の専門知識は、多くの場合、実用的な経験に根ざしています。 進化するクラウド エコシステムに追いつくために、スキル セットの拡張に投資することが重要です。

教育。 テクノロジ プロバイダーがアーキテクトに提供するトレーニングと認定の機会を求めます。

コミュニティへの参加。 オンラインおよびローカル アーキテクチャ コミュニティを通じて、ピアと交流します。

探索的演習。 組織が主催するハッカソンや同様のイベントに参加して、慣れない分野でスキルを身に付けます。

共同作業を成功に導く

アーキテクトは、クラウド プロバイダーまたは実装パートナーの専門知識を活用する必要があります。 ほとんどのプロバイダーは、ワークロードをプラットフォームで成功させたいと考えています。また、多くの場合、アーキテクチャ設計レビュー セッションやクラウド ソリューション アーキテクトとのコンサルティング セッションなどのサービスを提供しています。 ベンダー関係内でレビューと支援を受ける機会を求める。

設計アプローチでメソッドを使用する

アーキテクチャ フレームワークは、ワークロードの観点と方法論的アプローチを提供することで、アーキテクトをサポートします。 Well-Architected Framework では、包括的なワークロードの観点が提供されます。 設計者は、Well-Architected Framework と、Open Group Architecture Framework (TOGAF) などの他のアーキテクチャ フレームワークを組み合わせることができます。

アーキテクチャ フレームワークの原則、チェックリスト、評価、および参照資料を使用して、ワークロードに適合するプロセスを確立します。 フレームワークと、マインド マッピングなどの個人の手法を組み合わせます。

アーキテクチャは、最終製品と同じくらいコミュニケーションに関するものです。 確立されたプロセスで、意図的な意思決定、トレードオフの確認、明確なコミュニケーションのために最適化していることを確認します。

次の手順

アーキテクトのチェックリスト