GIS を最も効果的に活用している組織は、新機能を活用し、技術投資を最大限に活かしてビジネス目標を達成するために、継続的に最新化を進めています。 最新化は多くの定義を持つプロセスですが、多くの場合はユーザー、グループ、またはコンテンツを 1 つの GIS システムから別の GIS システムに移動 (または移行) します。 今日の最新化プロジェクトの多くは、クラウド インフラストラクチャーへの移行を行います。
ArcGIS Enterprise やクラウドへの移行は、移行対象の環境や、ソフトウェアのデプロイメントと管理の方法が組織によって多様であることから、その規模や範囲が異なる場合があります。 移行が単純か複雑かにかかわらず、あらゆる移行には、ビジネスとユーザーのコンテキストへの理解と、確実に成功できる方法のアクション プランが必要です。
最も一般的な移行パターンには、次のようなものがあります。
このトピックでは、移行の理由と方法について解説します。 ここで紹介する考え方を基に、移行が組織にとって適切かどうかをより正確に評価できるようになります。 さらに、選択した移行のパターンに基づいて、どのアクションが行えるかを理解できます。 この概要では、地理空間戦略を開発および実装するのと同じ方法、すなわち理解、計画、および行動により、移行について説明します。 このトピックでは、特定の移行シナリオに従うのではなく、すべてのシナリオに関連する情報とガイダンスを提供することを目的としています。
まず、移行を行う理由、移行先の環境、移行先の構成について検討する必要があります。 理由を明確にするには、まず移行のビジネス目標を特定することから始めます。 具体的なビジネス目標を設定して、労力を測定し、目標を達成したかどうかを後から確認できるようにします。 目標が具体的でない場合、移行が成功したかどうかの判定は困難になります。 オンプレミスの ArcGIS Enterprise デプロイメントから商用クラウド プロバイダーに移動する例では、次のような目標が考えられます。
これらは適切な出発点で、通常はクラウドへの移行で達成できますが、特定のアクションや手法を定義するには一般的すぎます。 次のセクションでは、組織が移行を検討する一般的な理由を紹介し、これらの目標をより具体的かつ有効にする方法について解説します。
組織のインフラストラクチャーを商用クラウド プロバイダーに移行すると、パフォーマンスが向上することは珍しくありません。これは、ほとんどの IaaS プロバイダーでパフォーマンスが最適化されており、さまざまなオプションを使用できるためです。 クラウド インフラストラクチャーでパフォーマンスが向上する理由のいくつかを、次に示します。
クラウドへのデプロイメントによってパフォーマンスが向上する機能的な理由のいくつかは、これら 5 つのポイントで示されています。しかし、これらの目標が組織のためどのように直接役立つかの詳細な情報は示されていません
最良の結果を得るには、成功基準を使用してシステム パフォーマンス目標を定義します。
システムのパフォーマンス向上という組織の目標について、一般的な目標と、成功基準付きの定義された目標を考えます:
コスト削減、またはコスト削減の可能性は、組織がクラウド プロバイダーへの移行を検討する最も一般的な理由の 1 つです。 クラウドへの移行によるコスト上の利点には、次のようなものがあります。
コストに重点を置いた適切な目標は、負荷がかかった状態で追加の ArcGIS Server コンピューターをデプロイし、負荷の少ない時間にはスピンダウンする負荷ベースのスケーリング モデルに変更し、システム全体のコストを削減することです。
クラウド プロバイダーでは、オンプレミスの実装で利用できない、または現実的でない可能性がある、新しい能力や機能も利用できます。 例を以下に示します。
新しい機能に関連する目標として、ジオデータベースを管理されたデータベース プロバイダーに移行し、イメージ サービスを公開して、編集者が Web アプリケーションを利用できるようにすることで、GIS データ編集のワークフローを改善することが考えられます。
多くの組織は、セキュリティーの義務や組織のポリシーによって、インフラストラクチャーをクラウドに移動することを求められます。
セキュリティー標準に関連する具体的な目標として、PaaS コンポーネントとして提供される WAF アプライアンスを利用して受信アクセスを管理するなど、ゼロトラスト ネットワーク環境に ArcGIS Enterprise を実装することが考えられます。
セキュリティーのために設定した目標の中には、他の目標よりも明確に達成できるものがあります。 たとえば、FedRAMP のような政府の義務的なセキュリティー基準や、SOC-2 のような商用基準を満たすことは、合格か不合格かのイニシアチブです。
明確で具体的な目標と、成功を測定する方法を設定したら、移行の計画を開始します。
目標、成功基準、課題をしっかりと理解したら、次の手順として行動のプランを作成します。 ここに示す 8 つの大まかな手順を開始点にします。
移行を進める前に、移行するコンテンツ、システム、および機能について広く理解する必要があります。 機能やサービスのリスト以外のことも考えます。 組織で使用しているプロセスとワークフローを調べます。 ミッションにとって重要な情報は何か、それを保守するにはどのような能力やスキルが必要なのかも考えます。
既存のシステムの状態は、ターゲット システムの設計とはまったく異なる場合がありますが、既存のシステムがどのように構築されているのか、なぜそのように構築されたのかを理解することが重要です。 デプロイされたテクノロジーとその構成を理解すると、ユーザーがシステムと対話する方法と、移行が完了した後にシステムを操作する方法についての理解を深めることができます。
すぐに移行を行わない場合でも、明確なタイムラインを設定し、遵守します。 成功基準を使用してマイルストーンを作成し、スケジュールが守られたか、移行の各フェーズが成功したか評価できます。 ワークフローのテスト、ターゲット システムの受け入れの検証、およびスタッフへの知識の伝達のため十分な時間を計画して、ワークフローを新しいパターンに移行する方法をスタッフが理解できるようにします。
移行の各手順と部分について、責任者を明確に定義します。 その手順や作業を完了するために必要なすべての要素を考慮しましょう。テクノロジーの実装とコンテンツの移動だけでなく、それが組織内の全員にどのように影響するかを理解することも必要です。 必要な役割には、最初の会議の運営、利害関係者からのフィードバックの収集、新しいシステムに関するトレーニングの完了、およびシステムの設計、実装、テストの後で行われる変更管理手順の指導まで、すべてが含まれます。
前の手順が完了したら、監査に耐えうるレベルの詳細なインベントリーを完成させます。 たとえ小さなことであっても、特定のユーザーにとって重要な可能性があるため、見落とさないよう注意します。 システムに含まれるコンテンツの種類、構成、ユーザーが使用する URL、およびインストールされるソフトウェア コンポーネントをすべて識別すると、自信を持って移行手法を設計できるようになります。
移行が必要なすべてのデータ、ユーザー、ワークフロー、およびプロセスを深く理解すれば、新しいシステムの設計に必要な多くのコンポーネントが揃います。 アーキテクトが、新しいシステムで作業を行う可能性がある人々から要件を収集し、新しいターゲット システムを完全に文書化できるよう、十分に時間をかけられるようにします。 ターゲット環境の主要な違い (ドメインの変更、認証の変更、新しいセキュリティー規則など) に注意してください。
エンタープライズ環境での移行には、さまざまな技術的方法を採用できます。 一部の方法では、WebGIS DR ツールやJoin Siteの手法など、ArcGIS Enterprise の標準機能を使用します。 他の移行では、Python スクリプトでコンテンツを移動するなど、より実践的な方法が必要になることがあります。 移行の特定の条件、およびソース環境とターゲット環境の違いによって、必要な方法が決定されます。
最後に、移行プランのすべての部分をドキュメント化し、後で参照できるようにします。 このドキュメントは、移行中のロードマップであり、移行を成功させるため優先的に行うアクティビティーについて説明しておく必要があります。 移行自体を進めるときは、プランを使用して、スケジュールに対する進行状況を追跡し、進行状況を利害関係者に報告して、すべての手順が完全に終了したことを確認できます。
プランが完成したら、実際の作業を開始します。 この時点までに実行したすべての手順から、行う必要があるアクティビティー、作業の順序、および移行が成功したかどうかを評価するために使用される手段を明確に把握できているはずです。 以下の手順を、いくつかの主要な手順のガイドに使用してください。
既存のシステムから開始します。 データ、インフラストラクチャー、アプリケーション、またはソース システムで必要な他の変更が準備できていることを確認します。 これには、データと VM のコピーとバックアップの作成が含まれます。 また、移行の実行中にユーザーによる新規コンテンツの作成を防ぐために、ソース システムを読み取り専用構成に設定することもできます。
理想的には、このシステムのコンテンツを丁寧に整理してください。 ソース システムから不要または未使用のコンテンツを削除できれば、移行自体が小さくなり、移行中にユーザーがフル アクセスできない時間が短くなります。
計画フェーズで構築したシステム設計を使用して、ターゲット アーキテクチャーをデプロイします。 ターゲット システムがデプロイされたら、通常の環境検証手順を実行して、システムが期待したパフォーマンスを発揮していることを確認します。 ブラウザーまたはデスクトップから ArcGIS Enterprise への接続、Web マップまたはアプリケーションの作成、エンタープライズ ジオデータベースの登録、サービスの公開などのチェックは、ベースライン機能が正しく動作していることを確認するために役立ちます。 ソース システムから少量の代表的なテスト データを移動すると、これらの手順を実行するために役立ちます。 WebGIS DR 移行などの一部の方法では、ターゲット システムがすべてのユーザーからではなく、ターゲット マシン上からのみ完全にアクセスや利用可能な構成になる場合があることに注意してください。
ユーザー、グループ、コンテンツのソース システムからターゲット システムへの移行は、計画フェーズで選択した方法を使用して開始します。 このプロセス中は頻繁にチェックを行い、移行の失敗やコンテンツの問題をすべて記録します。 これらのメモは、移行の一部をロールバックする必要がある場合に重要です。
前の手順で、新しいシステムに移行された一部の既存のユーザーと協力し、新しいシステムでワークフローとプロセスが期待したように動作すること、およびすべてのコンテンツが表示され、正しいことを確認します。 このプロセスは繰り返し行います。同様のワークフローとニーズを持つグループによって、システムが期待したように動作することが検証されたら、新しいグループを招集します。 変数をできるだけ減らすようにすると、問題が発生した場合でも、原因を特定しやすくなります。
最新化を行わず、古いシステムから新しいシステムにそのまま移行する方が合理的な場合もあります。 たとえば、デプロイされたバージョンの ArcGIS Enterprise をアップグレードする前に、ユーザーのワークフローが新しいクラウド環境で引き続き機能することを確認する場合などです。 この場合、ユーザー、コンテンツ、ワークフローが検証されたので、初期実装時に処理できなかったテクノロジのアップグレードまたは追加を開始できます。 その後、ユーザーと協力してワークフローの再確認を行います。
別の一般的な移行方法では、移行ウィンドウをシステムのアップグレード機会として使用します。移行が完了した後で (ソフトウェアの同じリリースで)、ユーザーのダウンタイム中にアップグレードを完了し、1 つのプロセスとしてアップグレードと移行をまとめて実行できます。
ここまでのプロセスのすべての手順を参照用にドキュメント化するだけでなく、今後使用する新しい運用および保守手順と、それらを実行する方法もドキュメント化する必要があります。 監視、アップグレード、パッチの適用、テスト、チューニング、およびシステムが引き続き意図したとおりに動作することを確認するために従う予定のガバナンス計画などのタスクについても文書化します。
移行が完了したところで、まだ計画に残っている場合は、追加の知識の伝達、トレーニング、または変更管理作業を行います。 これらは、ユーザー、コンシューマー、管理者、または利害関係者向けです。
ここまでの作業により、組織の増大していくニーズを満たす新しい運用システムが完成しました。 前述したように、移行は多くの場合、最新化と密接に関連しています。 このプロセスは完了したものと見なすのではなく、GIS を最新化する継続的なプロセスの始まりと見なしてください。 移行が完了した後の将来について検討し、システムを最新の状態に保つため、時間の経過とともにどのような機能強化が可能かを検討します。