トップへ戻る

統合のアプローチと方法

エンタープライズ システムとアプリケーション間の統合にはさまざまな形があり、複雑さの度合いもさまざまです。 設計プロセス中に想定される統合に取り組むときは、どのような種類の統合が可能かを検討することが重要です。 たとえば、外部システムに REST API を搭載し、データベースにデータを送信して、その API をクエリーするための Python ベースの SDK を提供することが考えられます。 これらの詳細によって、ワークフローや独自システムの要件に応じたさまざまな統合アプローチが可能になります。 このセクションでは、次の 2 つの主要アプローチでの統合方法について説明します。

  • 統合を実現する方法の概要
  • 統合を支援する技術要素を含む使用方法

統合のアプローチ

統合には、以降で説明するような設計の意思決定を支援するいくつかの一般的なアプローチがあります。

データと機能を ArcGIS に取り込む

このアプローチでは、別のシステム、データベース、または API からデータを検索し、ArcGIS でホストされているデータと一緒に、通常はマップまたは表形式のインターフェイスで表示します。 また、データを ArcGIS の空間データと組み合わせて、データが結合されたときにのみ発生する新しい視覚表現やレポート作成を支援することもできます。 このアプローチでは、WFS や WMS などの OGC ベースのサービスや、統合に使用できるその他の標準化された地理空間データ形式を利用できますが、ArcGIS の Web マップに追加できる Web 対応の CSV エンドポイントのような単純なデータ形式でも、統合が可能な場合があります。

このアプローチを使用した統合の例には、次のようなものがあります。

  • 資産管理システムの API にクエリーを送信して、エンタープライズ GIS システムに位置情報が格納されている施設の作業指示とステータスを表示する ArcGIS Maps SDK for JavaScript アプリケーション
  • 境界を表示する OGC サービスに接続して既存のマップをオーバーレイ処理し、これに情報を追加する ArcGIS Pro
  • 外部管理のデータウェアハウスへのクエリー層接続をマップサービスとして公開し、Web サイト活動を郵便番号ごとに要約して、ArcGIS Enterprise のマップ インターフェイスに表示する

他のシステムにデータと機能を提供する

このアプローチでは、サーバー ソフトウェア、アプリケーション、またはデータ ストレージを含む他のシステムは、ArcGIS REST API、および ArcGIS Online と ArcGIS Enterprise の機能を通じて ArcGIS に対しクエリーを実行し、ArcGIS とやり取りできます。 これには、フィーチャ レイヤーからのデータのクエリー、イメージ サービスからの画像の表示、解析またはプロセスを実行するためのジオプロセシング ツールへのジョブの送信などが含まれます。 位置情報サービス システムの多くの例は、この目的のために構築されており、同システムでは、サービスが主に他のアプリケーション (ArcGIS 以外のシステムを含む) を支援しています。

このアプローチを使用した統合の例には、次のようなものがあります。

  • ArcGIS Geocoding service を呼び出して、ユーザーが入力した住所の座標を提供する CRM 顧客入力インターフェイス
  • 大規模なパーセル追跡および配送管理システム内で使用される ArcGIS Routing service
  • ベクター タイルとして提供され、さまざまな Web マッピング SDK またはツールを通じて組織のマッピング アプリケーション全体で使用される、ArcGIS が設計およびホストするベースマップ

ワークフローを通じた統合

ワークフロー、シリーズ、ステップに基づいて統合するには、通常、1 つのシステムで実行されるアクションを利用してから、ユーザー、データ、またはワークフローを別のシステムに移動してワークフローを完了する必要があります。 通常はどちらのシステムも統合を支援するようにカスタマイズされておらず、システム間のオーケストレーションまたは自動化によって同期が維持されたり、システム間でワークフロー ステップが移動したりするという点で、このアプローチは「最も軽量」な統合方法とみなされることがあります。

このアプローチを使用した統合の例には、次のようなものがあります。

  • ArcGIS Survey123 または ArcGIS Field Maps を使用したフィールド データの収集により、特定のレコード タイプが送信されると、Microsoft Power Automate を介して資産管理システム ジョブがトリガーされます。
  • 編集が ArcGIS フィーチャ サービスを通じて行われたときに、データベース トリガーを通じて新しいプロセスを開始する編集ワークフロー。
  • ユーザーが画像リクエストを開始し、画像を取得可能なプロバイダーを特定してデータを調達し、実行時に各プロバイダーのシステムで取得タスクを開始できる画像リクエスト プロセス。

焦点を絞ったビジネス アプリケーションを作成する

ArcGIS の機能を他のビジネス システムも参照する特定のアプリケーションに統合するには、ArcGIS REST API と SDK を使用して、動的な地理空間コンテンツ、ツール、および機能にアクセスします。 このアプローチは、1 つ以上のカスタム アプリケーションを通じて、ArcGIS のサービスおよび機能を他のサービス、エンドポイント、またはツールと統合することに重点を置いています。

共有データ ストアに公開する

一部の組織では、データ ウェアハウスやデータ レイクなどの共有データ ストアを共通の場所として使用して、さまざまなエンタープライズ システムからのデータをまとめています。 ArcGIS システムは、解析に使用されたり、他のデータ ソースと組み合わされたり、さまざまなエンタープライズ アプリケーションで参照される基本的な地理空間レイヤーを含むこれらの共有データ ストアに貢献できます。 ArcGIS は、さまざまな共有データ ストア プロバイダーからのデータの読み取りと解析もサポートしています。

セキュリティー システムまたは ID プロバイダーを統合する

ArcGIS は、SAML、OpenID Connect、LDAP、Active Directory など、さまざまなサード パーティーの ID システム、プロバイダー、またはパターンと統合されます。 これらのパターンについては、セキュリティーの柱の認証モデルとプロバイダーのトピックで詳しく説明しています。 さらに、Azure または AWS の ArcGIS Enterprise デプロイメントは、AWS Identity and Access Management (IAM) ロールや Azure Managed Identities などのセキュリティー モデルとネイティブに統合できます。

統合のインターフェイスまたは方法

移行に使用される技術的方法またはインターフェイスは、通常、状況によって異なり、すでに配置されているアプリまたはツールによって異なる場合もあります。 設計プロセスでは、目的のエクスペリエンスを統合および実現するための最適な方法またはインターフェイスを特定するために考慮し、互いに比較すべき技術的要素です。

アプリケーション層の統合

アプリケーション層またはプレゼンテーション層の統合は、データまたはサービスを特定のユーザー インターフェイスまたはエクスペリエンスに取り込むことに重点を置いています。 これは、多くの場合、最も浅いレベルの統合ですが、データまたはサービスを特に 1 つのアプリケーションまたはインターフェイスのセットで利用可能にすることに重点を置いているため、最も効率的、効果的、または低コストになることもあります。 これには、カスタマイズが必要な場合や、カスタム インターフェイス上での構築が必要な場合がありますが、既製のアプリケーションまたは ArcGIS およびその他のシステムの構成でもこれに対応できます。 プレゼンテーション層の統合の例を次に示します。

  • <iframe> タグまたは <embed> タグを使用してアプリケーションを埋め込むことで、より大きなアプリやエクスペリエンス内に表示されるようにする。 これは、ArcGIS Hub および ArcGIS Enterprise Sites で、他の ArcGIS アプリケーションや外部インターフェイスを埋め込むためによく使用されます。 この方法では、通常、「親」と組み込みアプリケーション間の通信は制限されます。
  • アプリは、ポップアップ、属性ベースのリンク、および関連レコードを介して相互にリンクできるため、ユーザーは既存のアプリケーションまたはシステムを切り替えて、要求されたデータまたはドキュメントにアクセスできます。
  • ArcGIS Maps SDK for JavaScript を使用して構築されたカスタム アプリでは、リモート API への API 呼び出しまたは要求を行い、結果を操作して、マップベースまたは表形式の情報としてインターフェイスに表示できます。 たとえば、あるアプリは、リモート API を呼び出して CRM から顧客の注文情報を返し、それをマップ上に表示して注文密度を解析できます。
  • ArcGIS ベースのルーティング サービス要求を使用して医療スタッフの自宅訪問ルートを効率的に決定する医療管理システムなど、ArcGIS REST エンドポイントにリクエストを送信するように他のアプリやインターフェイスをカスタマイズすることもできます。
  • この方法またはインターフェイスには、Zapier、Power Automate、Make.com などのワークフロー自動化プラットフォームも含まれます。これらのアプリケーションは、REST 要求を介して統合され、ワークフローを開始したり、外部サービスに呼び出したり、ワークフローやユーザー グループの複数の部分を結び付けたりできます。

サービス層の統合

サービス レベルでの統合では、通常、Web サービスを介してデータが統合され、そのデータが ArcGIS ベースおよび外部のさまざまなアプリケーションで利用可能になります。 この方法には想定される多くの例がありますが、最も関連性の高い例として、クエリー レイヤー、カスタム データ フィード 、サーバー オブジェクトの拡張またはインターセプターが挙げられます。

  • ArcGIS Enterprise SDK を使用して構築された統合には、ArcGIS Enterprise の強力な機能である カスタム データ フィード が含まれます。これにより開発者は、ほぼすべてのデータ ソースから読み取り専用のフィーチャ サービスを作成できます。 データ ソースの例としては、API へのクエリー、データベース コネクション、ファイルなどがあります。 生成されるサービスは ArcGIS に統合された読み取り専用のフィーチャ サービスであるため、Web クライアント、デスクトップ アプリ、およびフィールド アプリに提供できます。 カスタム データ フィードのソース データはネイティブ形式のままで、ETL ワークフローを使用せずに ArcGIS Enterprise から直接読み取られます。 カスタム データ フィードは、ArcGIS が特定のデータ ソースをネイティブにサポートしていないシナリオで役立ちます。 その他のユース ケースとデータ ソースのサンプルについては、ドキュメントをご参照ください。 カスタム データ フィードを作成するには、次のような開発者リソースと専門知識が必要です。
    • ArcGIS Enterprise SDK、NodeJS、およびカスタム データ プロバイダー パッケージを作成するための JavaScript IDE がインストールされている開発環境。
    • 公開されたフィーチャ サービスをホストするカスタム データ フィード ランタイムがインストールされた ArcGIS GIS Server のデプロイメント。
    • カスタム データ フィードの開発と設定に関する詳細については、ドキュメントをご参照ください。
  • 別の Enterprise SDK パターンは、サーバー オブジェクト エクステンション (SOE) とサーバー オブジェクト インターセプター (SOI) の開発であり、ArcGIS Server サイト内の個々の地理空間 Web サービスをカスタマイズしたものです。 通常、拡張機能は新しい機能 (リソースやメソッドのための新しい REST エンドポイント) を追加し、インターセプターは /query や /exportImage などの既存のメソッド内で動作して、処理中のリクエストやレスポンスに対して応答や変更を行います。 SOE と SOI は、別のエンドポイントやディスク上のデータに対するクエリーなど、他のデータ ソースを統合するために使用でき、他のセキュリティー プロバイダーを統合して、サービス内のレイヤーに行レベルのセキュリティーまたはグループベースのアクセスを適用するためにも使用できます。
  • ArcGIS REST API は、サービス層の統合にも使用でき、他のシステムから呼び出したり、API とフィードがこれらをリンクしてユーザーと開発者が検出できるようにする中央カタログまたはシステムに組み込まれる、エンタープライズ サービス バス パターンで使用することもできます。

データ層の統合

統合は、データ ストレージや永続層のレベルでも実現できます。 通常はデータ移行、抽出、転送、読み込み (ETL)などのプロセスによって、システム間でデータを移動します。 一部のデータベースは、他のソース (PostgreSQL の外部データ ラッパーや SQL Server のリンクされたデータベースなど) への接続をサポートしていますが、一般に、データレベルの移行では、システム間での自動的かつ反復的なデータ移動が行われます。 一般的なパターンは次のとおりです。

  • ArcGIS Data Pipelines や ArcGIS Data Interoperabilityのほか、値の変更、ジオメトリー情報の付加、形式の変換などの処理に伴ってデータを移動できるツールがあります。
  • クエリー レイヤーは、ArcGIS Pro で作成および公開され、まず外部リレーショナル データベースまたはデータ ウェアハウスに接続して、テーブルまたはデータのビューを取り込みます。 重要な点として、これらのデータベースは、enterprise geodatabase のオブジェクトや構成なしで完全に ArcGIS の外部に存在でき、これらのシステムのネイティブ空間タイプを使用する空間データを含む場合と含まない場合があります。 クエリー レイヤーは、トランザクション システムの個別行の表、集計や解析結果の表示、特定の列のビューまたは定義を通じて変更および簡略化されたバージョンのデータを表示などに利用できます。 この柔軟な方法は、クエリー レイヤーを含むマップをマップ イメージ レイヤーとして公開することで実現され、これにより、構成可能な ArcGIS アプリケーションまたは ArcGIS SDK ベースのアプリケーションから、なじみのある REST インターフェイスを通じてデータにクエリーを実行できます。
  • Python スクリプトは、スタンドアロン スクリプトまたは Python Notebook で、品質管理、操作、ジオエンリッチメント、異なるソース間のデータ結合など、システム間のデータ移動を自動化するためによく使用されます。
  • その他の ETL プロセスについては、「データ パイプラインと ETL アーキテクチャー プラクティス」のトピックで取り上げています

すべてのデータレベルの統合では、アーキテクチャー プロセスの設計段階で以下の複数のトピックを慎重に検討する必要があります。

  • 更新頻度 - データが別の記録管理システムから統合されている場合、他方のシステムの更新頻度と、更新されたデータが ArcGIS システムに表示されるまでに予想される遅延または許容できる遅延の長さを把握してください。
  • データ品質 - システムが外部データに依存している場合、そのデータの品質が最も重要であり、データ ソースの構成につながったトレードオフと選択肢を把握することで、ArcGIS システムでそのデータをどのように使用するかの判断材料になります。
  • データの復元力 - 別のシステムに依存している場合は、リモート システムが使用できないとき、または正しくないデータや破損したデータを提供しているときに、更新プロセスがフォールバック オプションを提供することを確認します。データセットの静的コピーまたは以前のバージョンを (適切な免責事項を添えて) 使用すると、短いギャップまたは停止を埋めやすくなります。

推奨される統合戦略

アーキテクチャー設計段階での統合の成功に寄与する有効な戦略には、次のようなものがあります。

戦略的なアプローチを取る

エンタープライズ システムを統合すると、組織の機能のあり方が変化し、従来はコストのかかっていたプロセスやタスクを、繰り返し可能で低コストな作業に置き換えることで、新たな時間的余裕が生まれます。  エンタープライズ統合を優先的な戦略的コンテキストで活用することで、プロセス、アプリケーション、データの統合を通じて、製品やサービスのポートフォリオの生産と提供における連携を改善し、組織は価値の高い成果を実現できます。

この価値提案を初期要件の定義の指針として適用し、スコープとコストの見積もり作成し、統合作業のためのリソースを手配してください。

ワークロードに適したシステム層とデータに適したシステム層で統合する

エンタープライズ統合は、通常、ユーザーが使用するアプリケーションに組み込まれたコンポーネントを含め、人間と自動化されたプロセスを調整すること、他のシステムの人間およびプロセスが生成するデジタル コンテンツまたは分析データへのアクセスを許可すること、またはアプリケーション プログラミング インターフェイス (API) を介してこれらのアプローチを組み合わせることによって実現されます。また、エンタープライズ統合の技術的範疇内で、エンタープライズ ID とセキュリティーのための共有システムと共有プロセスを活用することも一般的です。 integration-1.png

十分なリソースを投資する

エンタープライズ統合は技術的に複雑になることがあり、多くの場合、複数のシステム階層や、パフォーマンス、セキュリティー、可用性に関する詳細な要件が含まれます。これらのプロジェクトでは、多くの場合、ソフトウェアおよびシステム エンジニアリングの訓練と経験が必要であり、これらは従来の GIS チームやプロジェクト チームの外部に存在する場合があります。組織のさまざまな部分から適切なリソースとチーム メンバーを割り当てることは、統合機能が期待どおりに動作し、ユーザーがテクノロジーではなく自分の仕事に集中できるようにするために不可欠です。

複数のシステム間でアクセスされるデータが使用に適していることを確認する

システム間の統合により、本来交わることのないデータが集約されることが多く、それによって機密性、適切性、関連性に関連する懸念が生じる可能性があります。 情報リソースは、企業ユーザーと外部ユーザーによって異なる解釈がなされることがあるため、開発チームは、システム間で統合されるさまざまな形式のデジタル コンテンツの意味と利用範囲を明確に理解しておくことが重要です。

コンテンツの種類、フィールド、値などを誤って解釈すると、悪影響が生じ、エンタープライズ統合への投資の価値も低下する可能性があります。 強力なデータ ガバナンスは、データセットに適用される標準を開発者とユーザーに確実に理解させることで、この分野に貢献できます。

適切なネットワークと情報セキュリティーを実装する

機密情報のリソースとシステムの保護は、すべての組織にとって重要な要件です。ネットワーク セキュリティーにより、適切な担当者が認証され、情報リソースにアクセスしてこれを利用する権限があることを保証できます。 情報セキュリティー対策により、対象とする各オーディエンスがデジタル コンテンツ リソースを適切な形で利用できることが保証されます。

あらゆる形式の情報に対するネットワークと情報セキュリティー上の制約により、所定のオーディエンスの使用目的に適した正しい形式のコンテンツを生成するために、複数のデータ処理段階が必要になる場合があります。これにより、データ層とアプリケーション層での統合が複雑になり、移動中のデータ資産をあるシステムから別のシステムに変換または処理するために、プロセスの自動化が日常的に必要になることがあります。 セキュリティーに関連するその他の検討事項については、セキュリティー アーキテクチャーの柱でご確認いただけます。

不要になったシステム、データ、および統合を廃止する

すべてのエンタープライズ システムは、ライフ サイクルを明確に定義した形で運用する必要があります。 これらのシステムの進化は遅い場合もありますが、変化は避けられず、明確なライフ サイクル計画がなければ、多くの組織はシステム、ソリューション、および統合のポートフォリオを管理するのに苦労します。統合されたエンタープライズ ソリューションは、データとテクノロジー環境の安定性に左右され、これらの環境の変更により、アプリケーションや関連するワークフローの使用が妨げられ、組織の生産性に影響が及ぶ場合があります。 システムとそのデジタル コンテンツが変化するにつれて、これらの依存関係を追跡して、エンタープライズ統合を進化させ、不要になったときに廃止できるようにしてください。

結論

これらの概念の多くは、どのエンタープライズ情報システムにも該当しますが、エンタープライズ地理情報システムの統合には、地理空間データの相関関係や、マッピングの視覚化とインターフェイスのサポートなど、追加の検討事項が含まれます。 ArcGIS システムと他のビジネス システムとのエンタープライズ統合により、組織全体の人々が協力し合い、連携を改善して、地理情報をより巧みに、かつ効果的に活用できるようになります。

Top