システムの設計にはさまざまな道筋があり、異なるアプローチや方法が関与する可能性がありますが、成功を収めている最新の ArcGIS アーキテクチャーの取り組みではいくつかの重要な原則が共通しています。 Well-Architected Framework のこのセクションには、ソフトウェアとハードウェアの分離、クラウドに関する検討事項、または統合へのアプローチに関連する、より伝統的なアーキテクチャーのトピックがいくつか含まれています。 しかし、追加のトピックの幅広さは、企業またはシステム アーキテクトの役割やアーキテクチャー アクティビティの成果がどのように変化したかを示しており、それに伴って新しい知識やトピック、検討事項が求められるようになっています。 これらの推奨事項は、特定の手順や成果物の提示ではなく、基本的なアプローチの指針を提供することを目的としています。
1 つ目に、ビジネスファーストのアプローチをとることが極めて重要です。 これは実際には何を意味するのでしょうか? これは基本的に、組織で実現する必要がある特定のワークフロー、ビジネス機能、または成果をサポートすることを主な目的としてアーキテクチャーを設計する必要があることを意味します。 パフォーマンス、可用性、デプロイメント テクノロジー、製品の拡張などの領域に個別に焦点を当てるのではなく、その機能に対するビジネス ニーズが何であるかに根ざしてこれらすべての決定を下す必要があります。 ニーズ主導型のこのアプローチにより、最初に主要な機能をサポートし、次に効果的に拡大して組織全体への影響を高めて導入を進めるシステムにつながります。
2 つ目に、アーキテクチャー開発方法論 (ADM) に従うことが重要です。 多くの異なる ADM が存在し、すべてに対応できる 1 つの最適なオプションはありませんが、可能であれば、アーキテクチャー プロジェクトを組織内で一般的に使用されている方法に合わせる必要があります。他のシステムの設計手法を用いることで、システム要件の伝達、他のアーキテクチャー ガイダンスの統合、そして最終的には組織の他の部分の承認やサポートを得ることが容易になります。 これは、可能な限り、組織の他の部分の IT アーキテクトとビジネス アーキテクトを関与させることにまで及びます。
3 つ目は、ハードウェア サイズや物理的な定義を完璧に重視するのではなく、柔軟性を重視した設計に重点を置くことです。 ハードウェア取得の設備投資は長年にわたってプロジェクト コストを押し上げてきましたが (一部の組織では今でもそうです)、仮想化とクラウド コンピューティングへの広範なアクセスにより、アーキテクチャー フェーズでの正確なハードウェア コミットメントの重要性が低下しています。 今では、システムのコンピューティング、メモリー、またはストレージの変更は通常、従来に比べて、より簡単かつコスト効率がよく対応できます。これは、ほとんどのアーキテクチャーでは柔軟で緩やかに定義されたハードウェア プロファイルで十分であることを示唆しています。 多くの組織では、今後もシステムの初期サイジングに関する強力な推奨事項を求めることになり、これらのシステムやアプリケーションは、これらのシステムの継続的なコストに対して依然として責任を負っています。 要約すると、合理的な初期見積もりと、使用量の増加、新機能、または新しいユーザー コミュニティによってもたらされる可能性のある変化とのバランスを慎重に取ることが、アーキテクトが考慮すべき重要なタスクとなります。
新しい要件領域により、セキュリティ、エンタープライズ統合、データ主権、従来のケースでは目立たなかったであろうその他のトピックなど、構造化されたアーキテクチャー アプローチの重要性が増しています。 これらの要件は、ソリューション設計やハードウェア選定、プロジェクトやシステムの全体の管理方針にも影響を及ぼし、従来は機能要件や性能要件によって左右されていたアーキテクチャー選定においても、同様に重要視されるようになっています。
ArcGIS システムの設計に関するその他のベスト プラクティスには、次のようなものがあります。
ArcGIS を使用してシステムを設計する場合、多くの組織では通常、使用されているアーキテクチャー開発方法論 (ADM) に依存する構造化されたプロセスで同様の手順を実行します。 追加のコンテキストを提供するために、これらはアーキテクチャーのフェーズの例であり、ArcGIS 固有の詳細が含まれています。
構造と入念に計画されたアーキテクチャー プロセスにより、システムの規模を問わず、慎重に設計し、効果的に実装し、ユーザーや対象者が変化しても長年にわたって効率的に保守することができます。