デジタル企業におけるハイブリット統合プラットフォーム

統合の様相 (つまり、企業のデータ、アプリケーション、サービス) は、ビジネスが成長するにつれ目まぐるしく変化します。現在のデジタル世界で競合他社に対する競争力を維持するには、次々と出現する新たなビジネス・モデルにデータ、アプリケーション、サービスを適応させなければならないからです。さらに、次の理由から、データ、アプリケーション、およびサービス自体の要件も変更されることがあります。

  • 新しいテクノロジーを活用して構築されたアプリケーションを追加するため
  • 既存のアプリケーションを移行するため
  • クラウドでホストされている各種のサービスに、市場で入手できるサード・パーティーのシステムやサービスを導入するため
  • ビジネス・チャネル、パートナー、サプライヤー、または他のビジネス部門および組織を新しく追加するため
  • エンタープライズ・システムがリアルタイム、あるいはほぼリアルタイムのビジネス・ニーズに対応できるよう、最近広まっている新しいコンピューティング・デバイスやセンサーをエンタープライズ・アプリケーションに統合するため

組織内ですでに定着している統合プラットフォームを増補する際に、エンタープライズ・システム間の不一致はシステム・インテグレーターにさまざまな課題を突きつけます。これらの不一致が発端となって、既存の統合プラットフォームを補完する新しい統合プラットフォームや統合ツールが出現するようになっています。その例としては、iPaaS (integration Platform as a Service)、iSaaS (integration Software as a Service)、およびアプリケーション・プログラミング・インターフェース (API) 管理スイートが挙げられます。このような新しい統合スイートと既存の統合プラットフォームの結合は、ハイブリッド統合プラットフォームと呼ばれています。

目下、ソリューション・ディレクターと統合アーキテクトにとって課題となっているのは、ハイブリッド統合プラットフォームを対象に最適化されたソリューション設計を策定することです。彼らは限られた予算の中で技術とビジネスに関するサービス・レベル・アグリーメント (SLA) を果たさなければならないだけでなく、企業のデジタル化への移行にも同調していかなければなりません。

この記事では、ハイブリッド統合プラットフォームを配置する主要な使用ケースの 3 つを特定し、ハイブリッド統合の実装概念について説明します。重要な点は、企業のデジタル化戦略に従って、ソリューションの設計に適したハイブリッド統合アーキテクチャーを定義することです。ハイブリッド統合アーキテクチャーが適切に定義されていれば、そのアーキテクチャーを基に、単一のベンダーによって構築されたプラットフォームを選択することも、企業のニーズに合わせてカスタマイズした独自の BIY (Build-It-Yourself) プラットフォームを選択することもできます。

使用ケース A: クラウド上でのアプリ、データ、サービスのホスティングに対する需要

企業はクラウドに適応することで、エンタープライズ・テクノロジーのコストを大幅に削減しています。アジリティー、弾性、そしてイノベーションを目的に、企業は既存のアプリケーション、データウェアハウス、ビジネス・プロセス・マネジメント (BPM) プラットフォーム、マスター・データ・マネジメント (MDM) プラットフォーム、そしてモバイル・アプリケーションをクラウドに移行するようになってきました。多くの企業が構想として描くのは、完全なクラウド・ファースト、クラウド対応、またはクラウド専用のテクノロジー・スタックですが、実際には、既存のオンプレミス・スタックに新しいクラウド・アプリケーションとサービスを混在させることになるのが現状です。そのため今のところは、クラウド・ベースのアプリケーションとオンプレミス・システムの両方をサポートできるような形でアプリケーション、データ、プロセスを統合しなければなりません。以下の図に、企業内の現在のシステム・ランドスケープと、これらのシステムの統合方式を示します。

企業内の現在のシステム・ランドスケープと、これらのシステムの統合を示す図

上記の図の左側では、リフトとシフト (lift-and-shift) 方式でアプリケーションをクラウドに移行しています。この方式では、オンプレミス統合プラットフォームへの統合という複雑さを取り除く一方で、アプリケーションを SaaS エンタープライズ・アプリケーションにシフトします。企業がコスト削減のためにまず採用するのがこの戦略です。

図の中央には、再設計を回避した、次の段階の費用削減が示されています。企業はこの段階で、費用のかかるデータおよびデータウェアハウス・ワークロードの物理的インフラストラクチャーをパブリック・クラウドに移行し、オンプレミスにある旧式のデータ・マートを段階的に廃止していきます。

図の右側では、モバイル・テクノロジーを使用して顧客対応アプリケーションの機能を接続しなければならないため、新しいビジネス・モデルがやむを得なく必要になります。このモバイル・テクノロジーには、正しい API を使用してモバイル・アプリケーションを公開して、企業が運用するデータ・ストアとほぼリアルタイムでやりとりするという要件もあります。

アプリケーションは、パブリックおよびプライベート・クラウド環境全体にも、オンプレミス・データ・センターのサーバー内にも散在しています。これらのアプリケーションとデータ・サービスを統合する手段としては、ESB (Enterprise Service Bus)、ELT (Extract, Transform, and Load)、メッセージング・ミドルウェア・プラットフォームなどといった従来型の統合プラットフォームが使用されています。同様に、クラウド側では、移行されたアプリケーションとサード・パーティー・アプリケーションがそれぞれ独自のクラウド (SaaS) 上でホストされています。このように散在するアプリケーションを iPaaS ツールを使用して統合することで、アプリケーションの使用ケースに必要な機能の一部に対応します。一方、ビジネス・プロセス全体にわたる機能に対応するためには、オンプレミス・アプリケーションを直接、あるいは既存のオンプレミス・エンタープライズ・アプリケーション統合 (EAI) 層を介して、クラウドに移行されたアプリケーションまたは SaaS アプリケーションに統合する必要があります。この要件を満たすには、iPaaS プラットフォームあるいは従来型のオンプレミス EAI プラットフォームを再編成するという方法、またはこの両方のプラットフォームを結合して、ハイブリッド統合プラットフォームにするという方法があります。

データ・フロント上では、オンプレミスの運用データ・ストアとクラウド上の DBaaS (Database as a Service) または DWHaaS (Data Warehouse as a Service) との間でデータを同期するか、この 2 つの間でデータを移行する必要があります。データを同期する場合は、クラウド上でホストされるマネージド・データ統合プラットフォーム、またはオンプレミス統合プラットフォームを使用して、オンプレミスのデータ・ソースとクラウドのデータ・ソースを統合するという方法があります。

以前は、モバイル・アプリケーションを構築するために、SaaS アプリケーションなどのクライアント対応アプリケーションをベースにアプリケーションを接続するという方法がとられていました。今では、iPaaS プラットフォームをクラウド上にデプロイした後、SaaS アプリケーションから必要な API を作成し、SaaS アプリケーションからエンタープライズ・データを取り込むか、オンプレミス統合によってオンプレミスのデータ・ストアから直接データを取り込むという方法がとられています。ハイブリッド統合プラットフォームでは、これら 3 つのタイプのアプリケーション、データ、およびモバイル統合に極めて高い需要があります。

使用ケース B: デジタル API エコノミーの適応

より多くの収益を生み出すことを目的に、組織は新しいデジタル・ビジネスに参入するようになっています。そのための方法は、API という手段によって、組織の機能とデータを従量課金制サービスとして外部利害関係者に公開するというものです。以前は、このような API は企業のファイアウォールの背後に置かれ、社外秘とされていました。これらの API はドメイン固有の再利用可能なビジネス機能であったり、フロントエンド・システムとやりとりするための構成可能な対話式 API であったりします (Web チャネル、モバイル・チャネル、IoT (Internet of Things) チャネルなど)。デジタル API を実装するには、2 つの方法があります。それぞれの方法について、以降のセクションで説明します。

対話式 API による基幹システムの公開

アプリケーション・データを顧客に公開するという方法でデジタル API を実装するには、以下の図に示すように、構成可能な API を作成します。この場合、既存のアプリケーション・アーキテクチャーを変更するのではなく、SOAP または RESTful サービスによって、従来型の EAI システムから基幹システム (SoR) を抽出します。そしてクライアントに提示するフロントエンドの GUI のニーズに応じて、1 つのシステム API、あるいは複数のシステム API を 1 つにまとめて構成します。以下の図のフロントエンド API では、1 つまたは複数のシステム API を構成し、そのデータをフロントエンドのデバイスに提示します。システム API でコア・システムのデータにアクセスして、そのデータを RESTful API の JSON または XML オブジェクトにアセンブルするという仕組みです。

構成可能 API の構成を示す図

マイクロサービスの原則を適用した API の実装

マイクロサービスを使用して API を実装するという別のイニシアチブでは、現在、既存のシステムをデジタル・プラットフォームに変換するために、API を適切に公開することでフロントエンドのチャネル統合を容易にするという方法がとられています。銀行、保険、テレコム、旅行などのさまざまな業界の組織では、すでに業務の一部あるいはすべてをオンラインのセルフサービス・モデルに移行することに成功しています。これらの組織はより直感的な方法でビジネスを促進するために、ロケーション・ナビゲーション、即時払い、格付けサービスなどの新しいデジタル機能とフィーチャーを追加しています。このような新しい要件に対応するために、IT ドメインでは新しいアプリケーションを迅速に開発する必要に迫られています。ここで言う新しいアプリケーションとは、自社の IT アプリケーションと世界中にデプロイされたパートナーのシステムからなる、マイクロサービスを使用して作成されたアプリケーションです。

マイクロサービスは、複雑なアプリケーションを設計し直すための新しい方法です。マイクロサービスは DevOps ツールを使用して作成され、オンプレミスのアプリケーション・サーバー上で実行されるか、あるいはクラウド内でホストされた Docker コンテナー内で実行されます。マイクロサービスによる複合アプリケーションは、自己完結型のマイクロサービス・コンポーネントに分割されます。マイクロサービス・コンポーネントの機能は、一度に 1 つの特定の目的を果たすことに重点が置かれます。独立した自己完結型のマイクロサービスには、処理する対象として、独自のデータ・コピー (理想的には、NoSQL データベース) が必要です。したがって、マイクロサービスが処理するデータをエンタープライズ・システムの運用データベースと同期する必要があります。以下のバックエンド・システムの統合を示す図を見るとわかるように、同期後のデータは、従来型のデータ統合パターン (データ同期、イベント・ストリームなど) を使用して実装されます。これらのマイクロサービスは、最新の API ゲートウェイ・テクノロジーを使用した API を公開することで、フロントエンドのチャネルとパートナーの SaaS アプリケーションに統合されます。

同期されたデータの実装を示す図

使用ケース C: IoT 対応エンタープライズの拡張

リアルタイムの意思決定を行うには、IoT デバイスから生成されるデータをエンタープライズ・アプリケーションに統合する必要があります。センサーからのデータをクラウド上のアプリケーションにも、オンプレミスのアプリケーションにも統合するために、ハイブリッド統合プラットフォームでは IoT 統合ゲートウェイを接続することが不可欠となります。IoT プラットフォームでは単一の統合ゲートウェイを持ち、標準的な各種の IoT チャネルを使用することで、すべてのデバイスを相互接続します。これらの IoT チャネルとしては、以下の例が挙げられます。

  • MQTT (MQ Telemetry Transport)
  • CoaP (Constrained Application Protocol)
  • WebSocket
  • Bluetooth
  • ZigBee
  • NFC (Near Field Communication)
  • RFID (Radio-frequency identification)
  • USB (Universal Serial Bus)
  • SPI (Serial Peripheral Interface) バス
  • I2C (Inter-Integrated Circuit)

IoT 統合では、データ・ストリームをオンサイトでフィルタリングして集約し、関連する情報 (エラーやアラート・メッセージなど) を中央の統合プラットフォームに送信します。以下の図に、典型的な IoT 統合を示します。

典型的な IoT 統合を示す図

ハイブリッド統合プラットフォームの戦略を策定する

ハイブリッド統合プラットフォームを導入する際には、組織内にこのプラットフォームを配置するための明確な戦略を立てる必要があります。それにはまず、ハイブリッド統合プラットフォームを配置するのに適切な場所を把握しなければなりません。それによって、プラットフォームの機能コンポーネントを最適な形で統合し、適切なガバナンスを選定することが可能になります。ハイブリッド統合プラットフォームの実装を成功に導くには、以下の手順に従う必要があります。

  1. 場所を計画する 。組織内のどこでインフラストラクチャーをホストするかを計画します。アプリケーション・ランドスケープの「重心」となる場所を特定します。3 年から 5 年計画のアプリケーション変換戦略を考え、その戦略が指し示す方向がクラウドまたはオンプレミスのどちらであるのかを判断します。ハイブリッド統合プラットフォームとアプリケーション/データとの間の距離が短ければ短いほど、サービス品質 (QoS) の要件を満たしやすくなります。統合のホスティング形式としては、オンプレミス、クラウド、またはこの両方 (ハイブリッド・クラウド) を選択できます。
  2. 所有権を決定する 。このプラットフォームと IT アプリケーションの制御権を持つ所有者を決定します。最近のクラウド・サービス・オファリングをベースとした IT システムは柔軟に制御できるようになっているため、プライベート/パブリック・クラウド統合、ハイブリッド・クラウド統合、マネージド・サービス・クラウド統合のうち、目的に応じた最適な統合を選択できます。これらのバリエーションにより、プラットフォームを完全に、または部分的に管理することも、プラットフォームの管理を完全にアウトソーシングすることもできます。
  3. リソースを識別する 。プラットフォームの実装を担当するスキルを持った人材を識別します。オンプレミス・アプリケーションを統合するには、高度なスキルを持ち、ベンダー・プラットフォームに精通した統合スペシャリストが必要になります。クラウド上のアプリケーションの統合については、iPaaS プラットフォームには必要なツールが備わっているため、開発者が十分に実装を担当できます。iSaaS プラットフォームの場合は、ビジネス・アナリストがこのプラットフォームの GUI を操作してシステムをマッピングするので、これらのビジネス・アナリストがシチズン・インテグレーターという肩書で統合を実装します。
  4. ガバナンスと管理を確認する 。新しい統合の方法や手法が導入されると、基幹システムのデータ品質に影響が出たり、データが破損したりする可能性があります。例えば、開発者が基幹システムについて十分な知識を持っていなければ、システムにうっかり悪影響を与えかねません。許可されたユーザーだけがアプリケーション・データにアクセスできるようにすること、そしてリスクを軽減するために適切なレベルのガバナンスと管理態勢を整えておくことが必要です。

ハイブリッド統合プラットフォームを構成するコンポーネント

ハイブリッド統合プラットフォームは多数のコンポーネントで構成されます。それは、統合のスコープが企業全体に及ぶためです。

API 管理スイート

API 管理スイートには、API を開発して実行するためのツールとサーバーがすべて揃っています。API 管理とは、一連の API の作成と公開から、それらの API の利用規定の適用、アクセスの制御、サブスクライバー・コミュニティーの育成、使用統計情報の収集と分析に至るまでのすべてのプロセスを指します。

API 管理スイートの主要なコンポーネントは、API ゲートウェイ・サーバーです。フロントエンドとして機能する API ゲートウェイ・サーバーは、API リクエストを受信し、スロットリングとセキュリティー・ポリシーを適用した上で呼び出しをバックエンド・サービスに渡した後、そのレスポンスを呼び出し側に返します。API ゲートウェイには変換エンジンの機能が備わっており、リクエストとレスポンスをオーケストレーションすることができます。また、アナリティクス・データを収集したり、キャッシングを行ったりするなどの機能も備わっています。

API 管理スイートの他のコンポーネントとしては、一連の API 公開ツールもあります。これらの API 公開ツールは、API ライフサイクルを定義して管理するためのものです。また、コミュニティー・ユーザーが API にサブスクライブするための開発ポータル、API の使用状況をモニタリングするためのレポートおよびアナリティクス・ツール、商用 API の使用料を請求するための収益化コンポーネントも、API 管理スイートに含まれています。

オンプレミス・アプリケーション統合スイート

オンプレミス・アプリケーション統合スイートは従来型のベンダー固有のアプリケーション統合スイートであり、統合フローを開発するための一連のツール、統合フローを実行するランタイム・サーバー、仲介モジュールをモニターおよびデバッグする一連の管理ツールからなる ESB スイートです。このスイートが対象とするアプリケーション統合としては、データ・マッピング、プロトコル、メソッド呼び出しの変換、そしてプロバイダー・アプリケーションとコンシューマー・アプリケーション間のリクエスト・ルーティングが挙げられます。

データ統合ツール

データ統合ツールは、オンプレミスまたはクラウド上のデータ・ストアを対象としたものです。独立したデータ構造体を操作するには、CDC (Change Data Capture)、ETL、データ仮想化などの手法が使用されます。さまざまなベンダーがそれぞれ独自の手法に従って、複数のデータ・ソースの結合や、エンティティー間でのデータ同期を行っています。

B2B 統合ソフトウェア

B2B ゲートウェイ (またはマネージド・ファイル転送 (MFT) ソフトウェア) は、取引パートナーとの間でのデータ交換を可能にするバックエンド・システムからのデータを統合します。また、B2B ゲートウェイは一元化された変換ポイントとして、相互運用可能な標準 (XML、cXML (commerce XML)、EDI (Electronic Data Interchange) など) を使用して複数のデータ・ソースを変換します。このプラットフォームが企業内のサービス指向アーキテクチャー (SOA) のコンポーネントとなっていることも珍しくありません。B2B ゲートウェイのその他の機能には、取引パートナーの管理、取引パートナー間でのセキュリティー制御もあります。

サービスとしての統合プラットフォーム

iPaaS プラットフォームはクラウド・バージョンの統合層であり、クラウド・アプリケーションとクラウド・データ・ソースの統合専用として使用されます。iPaaS はクラウド・サービスとして提供されるため、クラウド環境内でのみホストされます。従来型の ESB プラットフォームとは異なり、iPaaS 内では統合が大幅に単純化されます。したがって、臨時のインテグレーターでも、このスイートを使用してソリューションを実装することができます。ベンダーの多くは、このプラットフォームに API 管理スイートの機能を提供しています。

サービスとしての統合ソフトウェア

iSaaS プラットフォームは、クラウドで提供される、パッケージ化されたクラウド・ストリームであり、クラウド対地上のエンドポイントとして、さまざまな SaaS アプリケーションを接続します。iSaaS は (シチズン・インテグレーターと呼ばれる) ビジネス・ユーザーでも簡単に使えるインターフェースです。ビジネス・ユーザーは iSaaS を使用して、例えば Twitter フィードを自分の Google ドキュメントに統合するといった単純な統合タスクを他人の助けを借りることなく実行できます。

IoT 統合ゲートウェイ

IoT 統合ゲートウェイは、ソフトウェア・スイートまたは PaaS クラウド・オファリングです。IoT 統合ゲートウェイはユーザーがプラットフォーム上に構築したアプリケーションを使用して、多種多様なエンドポイントをモニターし、場合によってはそれらのエンドポイントを管理、制御することさえあります。IoT エンドポイントが関与する処理や、エンタープライズ・リソースとの統合は、IoT 統合ゲートウェイによって容易になります。

このプラットフォームは、さまざまなドメインの統合テクノロジーで構成されています。したがって、既存の統合テクノロジーの製品ベンダー各社は、その多くがこのプラットフォームを使用して、他の分野の統合機能を自社の製品に統合し、市場における製品の地位を確立しています。

ハイブリッド統合プラットフォームの設計手法

既存の統合インフラストラクチャーを維持しつつ、ハイブリッド統合プラットフォームを設計する際には、セキュリティーとパフォーマンスに関して多くの課題とリスクが関連してきます。新しく開発した仲介サービスと移行した仲介サービスをデプロイすることによってビジネスの継続が中断されるようなことがあってはなりません。本番環境で遷移とデプロイメントを円滑に進めるためには、本番環境に導入するプラットフォームをカスタマイズする前に、ハイブリッド統合プラットフォームのマスター概念実証 (PoC) を作成してテストする必要があります。

ハイブリッド統合プラットフォームの設計を最適化するには、以下の手順に従ってください。

  1. 統合のタイプを識別します。また、各デプロイメントに含める統合タッチ・ポイント (つまり、組織のオンプレミス、IaaS、または PaaS) の数を決定します。
  2. あるデプロイメント環境から別のデプロイメント環境への統合エンドポイントを識別します。企業はエンドポイントのタイプのうち、オンプレミスからクラウド、クラウドからオンプレミス、SaaS アプリケーションから IaaS アプリケーション、SaaS からオンプレミス、エンタープライズ・クラウドからサード・パーティ・クラウド、オンプレミスからオンプレミスへの統合ポイントを使用できます。
  3. 既存の統合ミドルウェアと使用されている手法を識別します。例えば、ポイント・ツー・ポイントのメッセージング・システムまたはファイル転送を使用しているのか、あるいは統合サーバー (ブローカーなど)、サービス・バス、ゲートウェアを使用しているのかを考慮します。
  4. 既存の統合プラットフォームを、表 1 と表 2 で提案されているリファレンス統合プラットフォームで置き換えます。
  5. 標準的な統合プラットフォームの初期設計をたたき台として、ハイブリッド統合プラットフォームを最適化または統合します。
  6. アプリケーションおよびデータ・ストアの中核にできる限り近くに、ハイブリッド統合プラットフォームをデプロイするのに適切な場所を確定します。

以下の表に、統合のタイプおよび統合を行うデプロイメント環境を基準とした最適な統合プラットフォームを要約します。

表 1. 標準的な統合プラットフォームのリファレンス
統合のタイプ オンプレミス IaaS PaaS
A2A ESB クラウド ESB iPaaS
データ統合 ETL クラウド ETL iPaaS
SOA サービス ESB クラウド ESB iPaaS
プロセス統合 BPEL クラウド BPEL PaaS BPEL
マイクロサービス API ゲートウェイ API ゲートウェイ API ゲートウェイ
IoT チャネル IoT ゲートウェイ IoT ゲートウェイ IoT ゲートウェイ

以下の表に、統合のタイプと、ターゲット・システムのデプロイメント環境へのエンドポイントの接続性を基準とした最適な統合プラットフォームを明示します。

表 2. 各統合エンドポイントに標準的な統合プラットフォームのリファレンス
統合のタイプ オンプレミスから オンプレミス (異なる企業) への統合ポイント オンプレミスからクラウド、またはクラウドからオンプレミスへの統合ポイント
A2A MFT ゲートウェイ iPaaS
データ統合 ベンダー固有のツール iPaaS
B2B B2B ゲートウェイ iPaaS
SOA サービス ESB ゲートウェイ iPaaS
マイクロサービス API ゲートウェイ iPaaS
IoT チャネル IoT ゲートウェイ IoT ゲートウェイ
SaaS アプリケーション 適用外 iPaaS

設計理念を理解するための一例として、ある企業が雇用した統合アーキテクトが、その企業の現状の統合アーキテクチャーを調査しているとします。統合アーキテクトは企業の設計チームから、アプリケーションのランドスケープを今後の 3 年から 5 年にわたって変換する戦略について説明を受けました。企業のアーキテクチャーに関する調査結果を基に、統合アーキテクトは将来の統合ランドスケープについて、表 3 に要約されている詳細の検討に入りました。

表 3: Acme 社での統合の詳細
統合のタイプ タッチ・ポイントの数: オンプレミス タッチ・ポイントの数: IaaS タッチ・ポイントの数: PaaS
A2A 多数 (50 超) 中程度 (50 未満、25 超) 少数 (25 未満)
データ統合 中程度 少数 少数
B2B 少数 少数 少数
SOA サービス 中程度 中程度 少数
SaaS アプリケーション 少数 少数 少数
マイクロサービス 中程度 多数 多数
IoT チャネル 少数 少数 少数

ステップ 4 の説明に従って、既存の統合プラットフォームを上記で提案されているリファレンス統合プラットフォームで置き換えます。以下の図に、表 2 と表 3 の情報に基づく初期バージョンのハイブリッド統合プラットフォームを示します。

初期バージョンのハイブリッド統合プラットフォームを示す図

ステップ 5 の説明に従い、以下の点を考慮に入れて、ハイブリッド統合プラットフォームを最適化します。

  • データ統合タッチ・ポイントは IaaS クラウド環境にも PaaS クラウド環境にもほとんどないため、提案されているクラウド・バージョンの ETL を iPaaS ソリューションで置き換えます。
  • また、どちらの環境にも B2B ゲートウェイがあることから、クラウド内にデプロイした iPaaS で両方の環境の B2B ゲートウェイ機能に対処します。
  • iPaaS が導入されていることから、クラウド内に API ゲートウェイを配置すると冗長なソリューションになるため、初期設計に含まれていた API ゲートウェイは排除します。
  • 一方、オンプレミスの API ゲートウェイには手をつけません。これを排除すると、ESB 層を介したオンプレミス・システムの統合での QoS 要件が高くなるためです。

以下の図に、最適化されたハイブリッド統合プラットフォームを示します。

最適化されたハイブリッド統合プラットフォームを示す図

まとめ

この記事では、ハイブリッド統合プラットフォームを配置する場合の主要な 3 つの使用ケースと、ハイブリッド統合の実装概念を明らかにしました。この記事で説明したように、企業の既存のビジネス・プロセス・モデルには多種多様なデプロイメント環境、運用モデル、新しいテクノロジーが追加されていることから、単一の統合プラットフォームでは統合要件に対応しきれません。幸い、ハイブリッド統合プラットフォームを構築するための単一ベンダーによる製品スタックを使用することで、相互運用性の標準に対応し、各種の統合製品に含まれる機能コンポーネントを重複して統合するという事態を避けることができます。

謝辞

この記事のレビューに時間を割いて、フィードバックを提供してくれた、IBM UK で Integration Portfolio Architect を務める Kim Clark に感謝の言葉を贈ります。