ガートナー ジャパン
メインメニュー ホーム リサーチ コンサルティング ベンチマーク エグゼクティブ プログラム イベント 会社情報 メインメニュー
SAMPLE RESEARCH

サンプル・リサーチ

イメージ iPaaS:統合のクラウド化

アプリケーション (APP) /APP-11-87
Research Note
M. Pezzini, B. Lheureux
掲載日:2012年2月7日/発行日:2011年8月25日

本リサーチ分析レポートのテーマに関心をお持ちの方は、2012年3月2日(金)に開催する 「ガートナー エンタープライズ・アプリケーション サミット 2012」 のページを是非ご覧ください。(イベント終了後も開催実績としてご覧いただけます)

 

サービスとしての統合プラットフォーム (iPaaS) は、アプリケーション、プロセス、サービス、データの統合と、それに関連するガバナンスをクラウド内で実施することを可能にする。大企業では、iPaaSとオンプレミス統合/ガバナンス・プラットフォームとの共存およびフェデレーションが標準になるであろう。

要約

iPaaSは、クラウド、企業間 (B2B)、オンプレミスのさまざまな統合/ガバナンス・シナリオへの対処を目的としたクラウド・サービスのスイートである。

本リサーチノートでは、ユーザー企業のCIO、CTO、エンタプライズ・テクノロジ・アーキテクト、統合コ ンピテンシ・センターおよびサービス指向アーキテクチャ (SOA) センター・オブ・エクセレンス (COE) のマネージャー、B2B統合マネージャー、プロジェクト・リーダー、ITプロバイダーの計画担当者を対象に、この革新的アプローチの発展、採用動向、業界 への影響に関する分析結果を示す。

主要な所見

    ● iPaaSは、組織内または組織間におけるオンプレミス/オフプレミス・アプリケーション、SOA、クラウド・サービス、プロセス、データのあらゆる組み 合わせの統合とガバナンスを目的に、複数のクラウド・サービスを1つのスイートに統合する。iPaaSは、アプリケーション開発およびホスティング指向 の、サービスとしてのアプリケーション・プラットフォーム (aPaaS) を補完する。

    ● iPaaSは、E-Commerce B2B統合やクラウド・サービス統合に広く採用されているサービスとしての統合 (IaaS) が進化したものである。

    ● iPaaSを最初に支持するのは中堅企業となる。大企業の間では、iPaaSを従来のアプリケーション・インフラストラクチャを補完するものととらえる見方が支配的になる。

    ● iPaaSの多くは、プライベート・クラウドに配備する、あるいは新たなiPaaSを実装するための製品 (クラウド対応統合プラットフォーム [CEIP]) の形でも提供されるようになる。
推奨事項
    ● ユーザーは、主にE-Commerce B2Bシナリオにおける統合/ガバナンスのサポートが目的である場合、または関係するアプリケーションの少なくとも一部がクラウド・ベースである場合に iPaaSをまず検討する。これらは、iPaaSの最も実績あるユースケースである。

    ● ただし、iPaaSが従来のプラットフォームに代わるエンド・ツー・エンドのプラットフォームへと成長するに従って、自社の統合/ガバナンス戦略の大幅な見直しについても考慮する。

    ● ユーザーは、既存の統合/ガバナンス・インフラストラクチャとiPaaSベースのアプローチとの長期的な共存を見据えた計画を立てる。

    ● アプリケーション・インフラストラクチャ、サービスとしてのソフトウェア (SaaS)、パッケージ・アプリケーション、システム・インテグレーション (SI)、クラウド・サービス仲介 (CBS)、クラウド・サービスにかかわるプロバイダーは、新たなビジネス・チャンスや付加価値製品/サービスの実現手段としてiPaaSをとらえる。

目次
    戦略的プランニングの仮説事項

    分析

      要旨

      概説

      PaaS:発展途上の市場
        PaaSスイートに向けた動き
        aPaaSとiPaaSの比較

      iPaaSとは何か
        iPaaSの定義の分析
        iPaaS、統合仲介、クラウド・サービス仲介の対比

      iPaaSがユーザーにとって重要な理由
        iPaaSの最初の対象はB2Bおよびクラウド・サービスの統合
        さまざまなシナリオに広く利用されるようになるiPaaS

      iPaaSのテクノロジ・コンテキスト
        次世代iPaaS
        「レガシー」iPaaS

      iPaaSが業界に与える影響
        構築途上にあるiPaaSオファリング
        複数の戦略的方向性に沿ってiPaaS市場に参入するプロバイダー

      採用のシナリオ

    推奨リサーチ

図目次
    図1 iPaaSの配備シナリオ

戦略的プランニングの仮説事項

● 2016年までに、全世界の大企業および中堅企業全体の少なくとも35%は、何らかの形で1つ以上のiPaaSオファリングを利用する。


分析

要旨
iPaaSは、(クラウド内で) 弾力的に拡張できるマルチテナント・プラットフォームを提供する一連のクラウド・ベースのサービスであり、以下のようなさまざまな統合シナリオをサポートする。
    ● クラウド/オンプレミス間

    ● クラウド間

    ● オンプレミス間

    ● E-Commerce B2B統合
iPaaSは、一連の統合サービスのほか、統合に関する固有の問題への対処に利用される成果物 (プロセス・モデル、構成、変換/ルーティング規則、サービス・インタフェース定義、サービス・レベル合意 [SLA]、ポリシーなど) の設計時および実行時のガバナンスを可能にすることを目的とするクラウド・ベースのサービスも提供する。

iPaaSは未成熟な市場であるが、安定したIaaS市場を基礎としている。iPaaSのビジョンを構成す る要素の一部、特に統合機能に重点を置いたものは、既に多くのプロバイダーから提供されているが、2012年から2013年にかけて、機能的により完全な iPaaSが登場してくるであろう。

短期的 (2013年まで) にいえば、柔軟性の向上、市場投入までの時間の短縮、クラウド中心の新しいビジネスモデルへの対応、コスト削減を模索している最先端のユーザー企業は、 iPaaSアプローチを、さまざまな要件に対応するための従来の (すなわちクラウド・ベースでない) 統合/ガバナンス・プラットフォームに代わる潜在的手段と考えるべきである。

iPaaSの市場が黎明期にあることを考えると、一般的な企業はiPaaSを、従来のプラットフォームを補 完するものととらえ、E-Commerce B2B統合やクラウド・サービス統合といった、低リスクのシナリオへの対応を主な目的として採用すべきである。これらのシナリオは、業界の長期にわたる IaaSの経験に直接根ざしており、これまでのところiPaaSのユースケースとして最も実績がある。

すべてのユーザーは、たとえiPaaSを限定的に採用する場合であっても、従来のプラットフォームに加えて新たなアプローチもカバーできるように、既存の統合コンピテンシ・センターおよびSOA COEの責任とスキルを拡張する必要があることを踏まえるべきである。

時が経つにつれてiPaaSテクノロジやビジネスモデルが成熟し、それとともにベンダー製品も、従来のオン プレミス型シナリオのさまざまな側面を含め、より多様なユースケースをサポートできるように進化する。その一方で、ユーザーによるSaaSの採用の増加、 より緊密に結合されたマルチエンタプライズB2B統合に対する要件の変化、ビジネス・パートナーとの関係における俊敏性向上のニーズ、さらには絶え間ない コスト削減圧力により、iPaaSの価値提案は、たとえ大規模な統合/ガバナンス・アプリケーション・インフラストラクチャを長年にわたって運用している ユーザーにとっても次第に説得力を増していくであろう。

したがって、中長期的 (2015年以降) にいえば、ユーザー企業は、統合/ガバナンス戦略上のiPaaSとオンプレミス型プラットフォームの比重を大きく見直す必要に迫られる可能性に備えるべきである。

アプリケーション・インフラストラクチャ・ミドルウェア・ベンダー、SaaSプロバイダー、パッケージ・ア プリケーション・ベンダー、システム・インテグレーター (SIer)、統合仲介およびクラウド・サービス仲介プロバイダーは、iPaaS (オンプレミス型製品であるCEIPの形も含めて) をビジネス機会として、また付加価値製品/サービスの実現プラットフォームとしてとらえるべきである。

概説
企業は、アプリケーション・インフラストラクチャをめぐって以下のような差し迫った問題に直面している。
    ● アプリケーション機能の一部をクラウドでホスティングする場合、それを既存のオンプレミス・アプリケーションと統合するにはどうすればよいか。

    ● 自社のオンプレミス・アプリケーションを外部のビジネス・パートナーと統合するにはどうすればよいか。

    ● サービスとしてのプラットフォーム (PaaS) が話題になっているが、自社でも利用すべきか。そうだとしたら、どのような場合に利用すべきで、どのような場合に利用すべきでないか。
本リサーチノートでは、iPaaSの概念、統合およびガバナンス要件を対象にしたPaaSの具体的な形態、クラウド/オンプレミス間および他の関連要件に対応するための利用方法を紹介することにより、これらの問題について検討する。

PaaS:発展途上の市場
ガートナーの見解では、クラウド・コンピューティングのアーキテクチャは、以下の3つの基盤レイヤで構築される。
    ● システム・インフラストラクチャ・サービス・レイヤ:一般にIaaSと呼ばれ、中核的なコンピューティング、ネットワーキング、ストレージ・サービスを提 供する (監訳者注:本リサーチノートには、サービスとしてのインテグレーション [Integration as a Service] とサービスとしてのインフラストラクチャ [Infrastructure as a Service] の2つの意味合いで、IaaSという略語が登場するが、基本的には前者の意味で使用されており、後者は、SaaS/PaaS/IaaSという3つの基盤レ イヤの対比の中でのみ登場する。そのため、いずれのIaaSであるかは文脈から容易に判別できるものと考える)。

    ● アプリケーション・インフラストラクチャ・サービス・レイヤ:一般にPaaSと呼ばれる。データベース管理システム (DBMS)、アプリケーション・サーバ、アプリケーション・セキュリティ、メッセージング、ビジネス・プロセス管理 (BPM)、マネージド・ファイル転送 (MFT)、B2B統合、データ/アプリケーション統合、SOAガバナンス、その他のさまざまな「中間層」アプリケーション・サービスを実装する。

    ● アプリケーション・サービス・レイヤ:主にSaaSとして知られる。ERP、CRM、人財管理 (HCM)、コラボレーション、Web会議、電子メール、その他の多種多様なシナリオ (特定業種向けのものを含む) などのユーザー・アプリケーション機能を提供する。
SaaSと、SaaSほどではないにせよIaaSも、ユーザー・コミュニティの間で広く採用されているもの の、PaaSがあまり理解されておらず、他のレイヤほど普及していないことは確かである。これは、SaaSのようにエンドユーザー指向ではなく、IaaS のように既存アプリケーションの配備のサポートに容易に利用できないという、PaaSが提供する中間層サービスの性質に起因する。

PaaSはまだ初期段階にあり、一般的なユーザーのほとんどは、PaaSの概念について漠然とした知識しか 持っていない。さらに、その主要な対象ユーザーとなるのは、クラウド・ベースの新しいアプリケーション・システムの実装に重点的に取り組んでいる (エンドユーザー企業内の、または独立系ソフトウェア・ベンダー [ISV]/サービス・プロバイダーに勤務する) アーキテクト、プロジェクト・リーダー、開発者らのコミュニティである。そうしたプロジェクトは、次第に増加しつつあるものの、新規開発プロジェクト全体 の中ではまだ少数派にすぎない。

PaaSスイートに向けた動き
PaaSの採用を遅らせていると考えられる要因の1つは、市場の過度な細分化である。市場では、多数のベン ダーが個別のPaaS機能を提供している (MFT、DBMS、メッセージング、アプリケーション・サーバ、データ統合、B2B統合、BPMテクノロジなど。詳しくは、リサーチノート、APP- 10-103、2010年9月10日付「クラウド・コンピューティング向けアプリケーション・インフラストラクチャ:成長する市場 (2010年)」 を参照されたい)。しかし、統合された包括的なPaaS製品を提供しているプロバイダーは存在していないに等しい。こうした状況は、ユーザーやベンダーが まだ主にその概念を試し、テクノロジやビジネスモデルのテストを行い、アプリケーションや製品の試験運用を行っている、PaaSのライフサイクルの初期段 階ならば許容され得る。しかし、そうした細分化状態では、ユーザーやサービス・プロバイダーが複数のPaaS機能 (例えば、ユーザー利便性、アプリケーション・サーバ、DBMS、セキュリティ、メッセージング) の併用が必要とされるビジネス・クリティカルな大規模アプリケーションの実装を始めた段階で対処することは不可能であろう。

地理的に分散した複数のデータセンターに配備された、4〜5社のプロバイダーによるPaaSサービスを基盤 とするアプリケーションの開発、配備、運用、管理、モニタリング、支払いを行うということになると、パフォーマンス、セキュリティ、可用性、管理、料金請 求に関して数々の厄介な問題が生じる。複数ベンダーの製品をベスト・オブ・ブリードで組み合わせた分散PaaS上に、厳しいサービス品質要件を持つビジネ ス・クリティカルなアプリケーションを実装することは不可能に近く、間違いなく非現実的である。

こうした理由から、PaaS製品は機能スイートへの集約が急速に進み、適切なレベルのパフォーマンス、セ キュリティ、管理容易性、可用性をもたらすために同一のデータセンターにコロケーションされた、(同一または別々のサプライヤーからの) 十分に統合され、最適化されたプラットフォーム・サービスをユーザーに提供するようになるとガートナーは予測している。この集約プロセスは、段階的に進む とみられる。まず (2013年頃)、特定の利用シナリオに基づいてPaaS機能が統合される。その後 (2015年以降)、包括的なPaaS製品も登場するはずである。それらの製品は、共通のテクノロジ基盤によってさまざまな利用シナリオやプロジェクト・ タイプをサポートできる統合コロケーション・サービスのスイートを提供するであろう (リサーチノート、APP-11-41、2011年4月25日付「PaaSのロードマップ:新大陸の出現」参照)。

aPaaSとiPaaSの比較
PaaS市場は、ポイント・サービスを提供するベンダーが増え続けている現在の状態から、さまざまな直接/ 間接チャネルを通じてユーザーに提供される比較的少数 (おそらく数十) の業種別に統合された (「スイート・マスター」やそのパートナーからのコロケーションされたサービスをそれぞれ集約する) PaaSスイートへと変化するであろう。ユーザーにとっての課題は、特定要件をサポートするポイントPaaSサービスの統合から、別々の開発チームによっ て採用される、あるいはさまざまなクラウド製品/サービスに組み込まれている垂直統合型PaaSの共存、相互運用性、フェデレーションの管理に関する問題 へと移ることになる。

特化型PaaSスイートへの流れは、ベンダー戦略や提供または発表されている製品/サービスを見れば既に明らかである。特定のユーザー要件に対応するために、少なくとも以下2種類のスイートが概念的に具体化し始めている。
    ● aPaaSスイート:個々のアプリケーションおよびアプリケーション・サービスをホスティングし、管理するための統合プラットフォームをユーザーに提供す ることを目的とする。一般に、aPaaS製品は、アプリケーション・サーバ、アプリケーション開発ツール、構成、ポータルおよびユーザー利便性、オーケス トレーション、データ管理、アプリケーション・セキュリティその他のクラウド・サービスを集約したものである (「APaaS: A Step to a 'Killer App' for Cloud Computing?」参照)。

    ● iPaaSスイート:別々に設計されたアプリケーションやサービスを連携させるための統合/ガバナンス・プラットフォームをユーザーに提供することを目的 とする。通常、iPaaSオファリングは、プロトコル・ブリッジ、メッセージング・トランスポート、変換、ルーティング、サービス仮想化、アダプタ、オー ケストレーション、パートナー・コミュニティ管理、MFT、レジストリ/リポジトリ、開発ツールなどのためのクラウド・サービスを組み合わせたものであ る。
今後2〜3年の間に、テクノロジや製品/サービスが成熟し、ユーザー要件や利用パターンが具体的に明らかになるにつれて、その他の類似スイート (例えば、BPM、コラボレーションその他の利用シナリオを対象にしたもの) が登場してくることが見込まれる。

iPaaSとは何か
iPaaSは、統合機能、ガバナンス機能、その他の機能を単一の統合インフラストラクチャとして調達/配備 /管理するという新たなユーザー要件に対応するために、それらの機能を組み合わせたものである。こうした要件は、統合とガバナンスの強力な連携を必要とす るSOAの採用が拡大した結果である (「Magic Quadrant for Shared SOA Interoperability Infrastructure Projects」参照)。10年以上にわたるSOAの利用経験の中で培われてきたベスト・プラクティスは、クラウド・コンピューティングが登場した現在 も引き続き有効である。たとえクラウド中心の環境が一般化しても、ユーザーは引き続き一体的に統合とガバナンスに取り組むはずであり、結果として、関連す るすべての (あるいは少なくともほとんどの) クラウド・サービスを統合プラットフォームとして提供できるベンダーが支持されることになるとガートナーは考えている。しかし、多くのベンダーおよびユー ザーは、この新たな市場について学習途上にある最初のうちは、完全なiPaaSのサブセットのみを選択的に提供/利用するであろう。

したがってガートナーでは、iPaaSの定義を「個々の組織内または複数の組織間におけるオンプレミス型お よびクラウド・ベースのプロセス、サービス、アプリケーション、データのあらゆる組み合わせを接続する統合フローの開発、実行、ガバナンスを可能にするク ラウド・サービスのスイート」としている。

iPaaSの定義の分析
iPaaSの定義を分析し、いくつかの要点を明確にしてみよう。
    ● iPaaSは、統合プラットフォーム・サービスと総称されるクラウド・サービスの組み合わせをユーザーに提供する。その目的は、統合フロー (すなわち、適切なメッセージ変換、ルーティング、プロトコル変換、サービス仮想化、オーケストレーション、セキュリティ・フェデレーション、利用追跡、 アドミニストレーション、モニタリング、管理などを実行することで複数のアプリケーションを接続するために必要な「統合ロジック」を実装したカスタム開発 ソフトウェアおよびメタデータ) の開発、実行、管理である。

    ● iPaaS上で実行される統合フローは、オンプレミス/オフプレミス型アプリケーション、サービス (SOAとクラウドの双方の意味において)、プロセス、データのあらゆる組み合わせを多対多の形で接続することができる。統合フローは、iPaaSの顧客 (iPaaS開発環境にアクセスできる顧客) が開発することも、顧客の代わりにサービス・プロバイダー (iPaaSプロバイダー自身を含む) が開発することもできる。開発環境がiPaaSベンダーにしか利用できない (顧客や他のサービス・ベンダーが利用できない) 製品は、iPaaSプロバイダーから提供される広範なサービス (後述する統合仲介やクラウド・サービス仲介など) に組み込まれた形でのみ機能が提供されることから、「組み込み型iPaaS」と呼ばれる。

    ● iPaaSは、同一組織内の統合だけでなく、複数組織間のB2B形式での統合もサポートする。これには、E-Commerceサプライヤーと顧客が関与する場合が多いが、マルチエンタプライズ統合やコラボレーションが含まれる場合もある。

    ● iPaaSは、統合プラットフォーム・サービスに加えて、ガバナンス・プラットフォーム・サービスも提供する。そうしたサービスには、レジストリ/リポジ トリ、成果物ライフサイクル管理、ポリシー管理/実施のほか、関連データの抽出も含まれる (「What SOA Governance Is and Will Be」参照)。iPaaSのガバナンス・プラットフォーム・サービスは、例えば標準的なオンプレミス型SOAバックプレーンを用いたSOAイニシアティブ におけるガバナンス・プロセスのサポートや施行といった目的で、統合プラットフォーム・サービスから独立して使用できる可能性がある (「Gartner's Reference Architecture for SOA Application Infrastructure」参照)。

    ● iPaaSサービスは、共存する複数のユーザー (テナント) コミュニティに対し、テナントの完全性、セキュリティ、サービス・レベルを保証しながら、弾力的かつ拡張可能なセルフサービスの形で提供されるのが理想的 である。現時点で、これらの属性のすべてをサポートしているiPaaSの実装事例は少ないが、いずれは多くの実装でそのようになる可能性が高い。
iPaaS、統合仲介、クラウド・サービス仲介の対比
一般に、iPaaSベンダーの商用製品は、トレーニング、サポート、コンサルティング、従来型のSI、その他のサービス (IT管理/運用の特定の側面など) によって補完される。

ここで強調しておかなければならないのは、iPaaS自体は特定のユーザー企業向けに特定のアプリケーショ ンを統合するサービスを提供するわけではないということである (例えば、企業のSAPオンプレミス・インスタンスとクラウド内のsalesforce.comのインスタンスの統合)。iPaaSが提供するのは、エン ドユーザーまたはサービス・プロバイダーがそうした特定の統合シナリオの実装/サポートに利用できる開発ツール、実行環境、ガバナンス機能である。

しかし、多くのベンダーは、事前定義された統合フロー・テンプレートのカスタマイズ、拡張、構成を行えるよ うにすることで、最も一般的な統合シナリオの実装の迅速化を目的とした「汎用統合フロー」を (自社またはサードパーティのiPaaS上で実行するサービスとして) 提供するようになる (統合フローは、エンドポイントの少なくとも一方がクラウド・サービスである場合、クラウド・ストリームと呼ばれることが多い)。こうした汎用性のある特 化型統合モジュールは、基本的にiPaaSアプリケーションであり、iPaaSの一部ではないが、統合スペシャリストにとっては便利なアドオン機能であ る。そのため、PaaSレイヤというよりも、むしろクラウド・コンピューティング・アーキテクチャのSaaSレイヤに近い。

統合仲介プロバイダー (「Integration Brokerage Provides Facilitated Intermediation for B2B E-Commerce and Cloud Services Brokerage」参照) は、自社の専有 (多くは組み込み型) iPaaS上で、あるいはユーザーに見えない形でサードパーティの1つ以上のiPaaSオファリングを利用して、エンド・ツー・エンドの統合ソリューショ ン (専門サービスやアウトソーシングの側面を含む) の実装、管理、サポートを行うためのあらゆるITサービス機能を提供する。しかし、一部の統合仲介プロバイダー (通常はSIer) は、コスト、技術的な親和性、SLA、地理的条件、垂直分業といった基準に基づいて、使用するiPaaSをユーザーが選択できるようにしている。

クラウド・サービス仲介事業のプロバイダー (リサーチノート、APP-11-18、2011年2月18日付「クラウド・サービス仲介事業:仲介を次の段階へ進める」 参照) は、iPaaSベースの統合サービスと他のクラウド・サービス (aPaaSなどを含む) を組み合わせることで、複数のクラウド・サービス・プロバイダーからのサービス利用を伴う特定のビジネス課題に対処するエンド・ツー・エンドのソリュー ションをユーザーに提供することができる。

iPaaSがユーザーにとって重要な理由
iPaaSは、パブリック・クラウドまたはプライベート・クラウドにおいて、同一エンタプライズにおけるさ まざまな統合シナリオ (クラウド間、クラウド/オンプレミス間、オンプレミス間)、E-Commerce B2B統合、適切なガバナンスの側面をサポートするための機能を提供する (図1参照)。 ユーザーにとっての明らかな利点は、従来のオンプレミス型の統合/ガバナンス・プラットフォームを採用する場合とは異なり、自社データセンターにおける ハードウェアおよびアプリケーション・インフラストラクチャ・ソフトウェアの調達、配備、管理が不要ということである。

図1 iPaaSの配備シナリオ
図1
A2A:アプリケーション間
出典:ガートナー (2011年3月)

iPaaSの最初の対象はB2Bおよびクラウド・サービスの統合
「サービスとして提供されるサードパーティの統合プラットフォーム上で統合フローを実行する」という考え は、十分に理解され、実証されている。というのも、E-Commerce B2B統合との関連では、この概念が一般的に用いられており、クラウド/オンプレミス間統合 (クラウド・サービス統合ともいう) にも次第に用いられるようになっているからである。E-Commerce B2B統合に対応しているベンダー (Crossgate、E2open、GXS、Hubspan、IBM-Sterling Commerce、Seeburger、Liaison Technologies、SPS Commerceなど)、ならびにクラウド・サービス統合を対象にしているベンダー (Appresso、Dell-Boomi、IBM-Cast Iron Systems、Informatica、Fiorano、Infoteria、iWay Software、Jitterbit、Microsoft、Pervasive Software、Vigience) は、2000年代初頭から、iPaaS統合プラットフォーム・サービス機能 (ガートナーでは、サービスとしてのインテグレーションと呼んでいた。リサーチノート、SOR-10-15、2010年4月15日付「クラウドの統合:サービスとしてのインテグレーション (IaaS) によるB2Bインテグレーション/アウトソーシング」参照) の少なくとも一部を提供している。したがって、これらのベンダーは、本格的なiPaaSの機能をすべて提供しているとは限らないものの、iPaaSプロバイダーと見なせる。

従来、オンプレミス型の統合ミドルウェア・ベンダーとIaaSプロバイダーは、原則として異なる企業であっ た (ただし、一部のIaaSプレーヤー [IBM-Sterling CommerceやGXSなど] は、かつてB2B統合ソフトウェアやクラウド統合製品といったアプリケーション・インフラストラクチャ製品も販売していた)。それ以前のIaaSのよう に、iPaaSは、従来の統合ミドルウェアに代わる補完的製品の性質を多少帯びている。しかし、今後しばらく、とりわけ大企業においては、従来のオンプレ ミス型インフラストラクチャとiPaaSベースの統合が共存して互いに補完し合うことになる。また、従来のIaaSとの親和性を考えると、少なくとも初期 フェーズにおいては、クラウド間、クラウド/オンプレミス間、従来のE-Commerce B2B統合のような特定のシナリオをサポートするために、iPaaSの採用がにわかに進む可能性もある。オンプレミス・アプリケーションの体系的な統合や SOAインフラストラクチャの配備といった他のシナリオでは、従来のオンプレミス型統合ミドルウェア (将来的には何らかの形のプライベートiPaaS) の配備が多くのユーザーにとって最も受け入れやすい選択肢であることに変わりはないであろう。

しかし、個々のPaaSサービスの成熟、機能的により完全なiPaaSへの集約、既存のIaaSベンダー製 品の進化、さらには市場への新規参入も進むはずである。したがって、エンドユーザーもサービス・プロバイダーも、従来のアプリケーション・インフラストラ クチャ・ミドルウェア (エンタプライズ・サービス・バス [ESB] スイート、B2B統合ソフトウェア、MFT、データ統合ツール、SOAガバナンス・プラットフォームなどのテクノロジ) に代わって、iPaaSがより幅広いユースケースに対応し得るものと次第に考えるようになるであろう。

さまざまなシナリオに広く利用されるようになるiPaaS
ほとんどの大企業は、広く採用されている統合インフラストラクチャやSOAガバナンス・プラットフォームを 既にかなりの規模で構築済みである。そのため、これらの企業が今後3〜5年間にすべてのアプリケーションをiPaaSに完全移行することは考えにくい。し かし、クラウド・コンピューティングに対する理解が深まれば、SaaSアプリケーションの利用は拡大するであろう。したがって、iPaaSが実証済みで従 来の統合ミドルウェアに対して経済的にも魅力的な代替案となる要件への対応においては、iPaaSへの注目が徐々に高まるであろう。主な例としては、クラ ウド・サービス統合、E-Commerce B2B統合、遠隔地の子会社の統合、SOAフェデレーションのサポートなどが挙げられる。

また、大企業は、従来のやり方では実装にコストや時間がかかりすぎると思われる機能 (例えば、レジストリ/リポジトリや成果物ライフサイクル管理といった、SOAガバナンスの特定の側面) で既存環境を拡張する際にも、場合によってはiPaaSに注目するであろう。その一方で、現在IaaSプラットフォームを利用している大企業は、E- Commerce B2Bやクラウド・サービスの統合と高い親和性を持つ要件 (例えば、遠隔地の子会社の統合やSOAフェデレーションのサポート。「Seven Things to Think About When Initiating Federated SOA」参照) に対応するために、こうした製品の利用を徐々に拡大するはずである。このような動きは、プロバイダーがより包括的なiPaaS機能セットの提供に向けてプ ラットフォームの範囲を拡張するにつれて、いっそう加速することになる。

アプリケーション・インフラストラクチャ・ミドルウェアにほとんど、もしくはまったく投資していない中堅企 業の間では、おそらく大企業よりも急速にiPaaSの採用が進むであろう。これは、E-Commerce B2B統合を行う必要があるものの、B2B統合ソフトウェアを単独で実装するには技術的リソースや人材が不足している企業に幅広く採用されているIaaS の場合と同様である。そのような企業は、SaaSソリューションを広く採用しており、いずれはそれらのアプリケーションを既存のオンプレミス・システムと 統合し、結果として生じる統合フローのガバナンスを行う必要に迫られる。したがって、そうした企業が、(多くは統合仲介プロバイダー、クラウド・サービス 仲介プロバイダー、SaaSプロバイダーのいずれかを通じた) iPaaSの提案に魅力を感じる可能性がある。なぜなら、迅速な配備が可能になることに加え、従来のアプリケーション・インフラストラクチャ製品と関連 ハードウェア・インフラストラクチャの配備に伴う資本投資とIT運用コストが回避されることになるからである。

たとえ当初はiPaaSにほとんど価値を見出していないユーザーも、今後5年間にこの新しいアプローチを完 全に無視することはできなくなる。実際、iPaaSの機能は多くのSaaS製品に (パートナーシップ、OEM契約、社内開発のいずれかを通じて) 組み込まれるようになり、統合仲介、クラウド・サービス仲介、その他のITサービスのプロバイダーによって製品/サービスの実現手段として利用されるよう になるはずである。2016年までに、全世界の大企業および中堅企業全体の少なくとも35%が、何らかの形で1つ以上のiPaaSを利用するようになる。

iPaaSのテクノロジ・コンテキスト
概略的には、「クラウド・アプリケーションは1つ以上のaPaaS上で稼働し、1つ以上のiPaaSを通じ て互いに統合され、またiPaaSオファリングは関連するガバナンス・プロセスの管理にも利用される」ということができる。これは、従来のアプリケーショ ン・インフラストラクチャ・ミドルウェア環境におけるアプリケーション・サーバ、ESBスイート、SOAガバナンス・ツールの関係と非常によく似ている。 アプリケーションは、アプリケーション・サーバ上で稼働し、ESBスイートを通じて統合され、関連するガバナンス・プロセスはSOAガバナンス・ツールを 通じて管理される。しかし類似点はそれだけにとどまらない。

次世代iPaaS
ESBスイートには、トランザクション管理、クラスタリング、負荷分散、高可用性、モニタリング/管理を提 供するプラットフォーム・ミドルウェア基盤が必要となる。多くのESBスイート (Software AGのwebMethods Integration ServerやProgress SoftwareのSonic ESBなど) において、通常そうした基盤は、ユーザーがアクセスできない組み込み型の (カスタムまたはサードパーティ製) ソフトウェアとして実装されている。しかし、それ以外のESBスイート製品 (IBMのWebSphere ESBやOracleのOracle Service Busなど) において、基盤サービスは、スタンドアロンの製品としても市販されているエンタプライズ・アプリケーション・サーバ (WebSphere ESBの場合はIBM WebSphere Application Server、Oracle Service Busの場合はOracle WebLogic Server) によって提供される。

同様に、iPaaSには、弾力的な拡張性、マルチテナント性のサポート、クラウド・トランザクション処理、 プロビジョニング、計量、請求といったクラウド属性を提供する基盤インフラストラクチャが必要である。クラウド属性は、場合によっては組み込み型のカスタ ム製またはサードパーティ製のソフトウェアによって実装される。あるいは、同一ベンダーまたはサードパーティからの高制御aPaaS (リサーチノート、APP-11-42、2011年4月25日付「生産性 vs. 制御性:クラウド・アプリケーション・プラットフォームの成功に向けた二分化」 参照) を通じて、クラウド属性が提供される場合もある (すなわち、あるプロバイダーのiPaaSを同じプロバイダーのaPaaS上に実装することも、他のプロバイダーのaPaaS上に実装することもでき る)。基盤となるインフラストラクチャを最大限に制御したいが、クラウド属性を開発するスキルやリソースがないiPaaSプロバイダーは、サードパーティ のaPaaS上でiPaaSを開発/運用するのではなく、クラウド対応アプリケーション・プラットフォーム (CEAP) (すなわち、特にクラウド属性を「製品として」提供するアプリケーション・インフラストラクチャ・ミドルウェア) をOEMから調達することを選択できる。

最新のiPaaSオファリングは、一般にCEIPを通じて実装される。CEIPとは、基本的に統合プラット フォーム・サービス、ガバナンス・プラットフォーム・サービス、補助機能 (管理、アドミニストレーション、セキュリティ)、iPaaSの基盤を成すクラウド属性を実装したソフトウェア・プラットフォームである。したがって、 iPaaSベンダーは、(社内開発を通じて、またはサードパーティのテクノロジを採用することで) CEIP全体を実装するか、あるいはサードパーティのaPaaS (またはCEAP) 上に配備するためのものとして、少なくとも統合プラットフォームおよびガバナンス・プラットフォーム・サービスを実装している。プロバイダーによっては、 自社iPaaSの基盤を成すCEIPを他のサービス・プロバイダーやエンドユーザー組織に販売することで利益を上げようとするケースもあり得る。このよう に、サービス・プロバイダーは、(例えば本来のiPaaSベンダーがターゲットにできない、あるいはターゲットにすることを望まない地域や業界にサービス を提供するために) 互換性のあるiPaaSサービスを実装し、独自の付加価値で拡張することが可能である。エンドユーザーは、iPaaSベンダーのCEIPを自社のプライ ベート・クラウドに配備し、社内ユーザーやパートナーにプライベート (またはコミュニティ) iPaaSとして提供することができる。

「レガシー」iPaaS
E-Commerce B2B統合向けのiPaaS実装の多くは、10年近くも前から存在する。このためそれらは、しばしば全世界に広く分散した数十、数百、場合によっては数千 に及ぶB2Bコミュニティに代わって複数の大規模B2Bプロジェクトをサポートするために必要とされる、大容量の通信ミドルウェア (例えば、さまざまなB2Bプロトコルをサポート)、高スループットの統合ミドルウェア (例えば、メッセージ変換を実装)、コミュニティ管理機能、あらゆる補助機能 (セキュリティ、管理など) を組み合わせたテクノロジの、拡張性とマルチテナント性に優れた多様な実装によって実現されている。これらの実装のほとんどは、何らかの方法 (可用性や拡張性の向上、プロセス可視性といった新機能の追加など) で近代化されているが、依然としてレガシー・テクノロジ (メインフレーム上の電子データ交換 [EDI] メールボックスなど) と最新テクノロジ (SOAインフラストラクチャ上で稼働するインテリジェンス/プロビジョニング・ツールなど) が組み合わされている。多くの配備では、時として複数の大陸にわたって地理的に分散したマルチサイト・ディザスタ・リカバリ機能が利用されている。こうし た実装の多くは、拡張性と信頼性が次第に向上しているものの、「純粋な」クラウド実装ではない (すなわち、弾力性、API、セルフプロビジョニングといったクラウド属性が欠如している)。

iPaaSが業界に与える影響
iPaaSの概念はまだ初期段階にあり、この用語を認識しているベンダーやユーザーさえまれである。しかし、今後3年間に、かなりの規模のiPaaS市場がはっきりとした形で定着し、活況を呈することになるとガートナーは確信している。

構築途上にあるiPaaSオファリング
iPaaS市場の登場を示す主な証拠として、以下の事象が挙げられる。
    ● 前身であるIaaS市場が定着し (iPaaSモデルが理論的に機能し得る証拠)、かなりの規模 (2009年の市場規模は約9億4,500万ドル、「Market Share: All Software Markets, Worldwide, 2009」参照) があり (顧客がiPaaSスタイルの製品採用に前向きである証拠)、GXS、IBM-Sterling Commerce、E2open、Crossgate、Liaison Technologiesなどの強力な既存ベンダーによってサポートされている (「Magic Quadrant for Integration Service Providers」参照)。

    ● IaaS市場の従来のE-Commerce B2B統合サブセグメントは、収益があまり伸びていないが (普及が減速しているのではなく価格の下落が主な原因)、Dell-BoomiやIBM-Cast Ironといったベンダーに代表されるクラウド・サービス統合サブマーケットは、小規模なインストール・ベースからとはいえ2桁成長を示している (「Market Trends: Multienterprise/B2B Infrastructure Market, Worldwide, 2010-2015. 1Q11 Update」参照)。これは、クラウド・サービスの形で提供される統合に対する需要が高まっていることを証明している。

    ● E-Commerce B2B統合とクラウド・サービス統合は、IaaSの採用が有力な2つのシナリオであるが、E2open、Hubspan、Liaison TechnologiesといったプロバイダーのiPaaSを使用してオンプレミス間統合の要件に対応しているユーザー事例が既に存在する。一般に、そう したオンプレミス統合プロジェクトは、何らかのB2B統合構想と併せて実施される。

    ● 従来のオープンソース統合ミドルウェア・ベンダーの一部は、既に (部分的な) iPaaS機能を提供しているか (例:Cordys BOPアプリケーション・インフラストラクチャ・プラットフォームに基づくCapgemini Immediateクラウド・サービス仲介製品を提供するCordys、iWay Service Manager製品を提供するiWay Software、Mule iON製品を提供するMulesoft、Tibco Silver PaaS製品を提供するTibco Software)、iPaaS市場に参入する意向を発表している。2011年には、アプリケーション・インフラストラクチャ・ミドルウェア・ベンダーか ら、さらに多くの発表や製品リリースが予想される。

    ● InformaticaやPervasive Softwareといったデータ統合ベンダーは、従来のオンプレミス型データ統合ミドルウェアの「サービスとしての」バージョンを提供し (それぞれInformatica CloudとPervasive DataCloud)、定評を得ている (「Who's Who in Cloud Computing/SaaS Integration, Volume 1」参照)。

    ● Appresso、Infoteria、Jitterbit、Vigienceといった、クラウドに重点を置いた新興企業やSIerは、従来のミドルウェ ア製品に加えてオンデマンド製品をクラウド・サービス統合市場に投入している (リサーチノート、APP-10-96、2010年8月10日付「クラウド・コンピューティング/SaaS統合プロバイダー - その2」参照)。

    ● IBMは2010年に、E-Commerce B2B統合プロバイダーの大手2社の1つであるSterling Commerceと、最も注目すべき新興のクラウド・サービス統合ベンダーの1つであるCast Ironを買収した (「IBM Makes a Big B2B Play With Strategic Potential as It Acquires Sterling Commerce」および「IBM Adds Comprehensive Cloud Service Integration to WebSphere via Cast Iron Acquisition」参照)。これは、特にiPaaSを自社のE-Commerceおよびクラウド・サービス統合資産とうまく融合してハイブリッド利 用のシナリオに対処できれば、iPaaS市場が戦略的に重要な機会となるという認識がIBMの経営陣の間で強まっていることを示唆している。

    ● Dellは2010年に、大手クラウド・サービス統合プレーヤーの1つであるBoomiを買収し、クラウド製品の拡充を図った (「Dell Must Take Decisive Action to Fully Leverage the Boomi Acquisition」参照)。

    ● Microsoftは2010年10月のPCD10において、2011年にMicrosoft Azure AppFabric Integration Serviceのテクノロジ・プレビューをリリースする計画を発表した。これは、Azure AppFabric Container aPaaSをある程度ベースにしたものになる見通しである。Microsoftは、Azure AppFabric Integration ServiceをCEIPの形でリリースする意向も発表した (「Windows Azure AppFabric: A Strategic Core of Microsoft's Cloud Platform」参照)。

    ● Software AGは2011年2月に、PaaS戦略の一環として、プロセス・モデリング、モニタリング、開発、実行サービスも組み込んだ「サービスとしての統合および SOAプラットフォーム」を2012年からリリースする意向を発表した。これらの製品は、現行のARIS (プロセス・モデリング) とwebMethods (統合およびSOA化/SOAガバナンス) アプリケーション・インフラストラクチャ・ミドルウェアをベースにしているが、後方互換性を維持しながらクラウド属性をサポートできるように完全に再設計 される予定である。Software AGの発表は、iPaaSにおいて起こりつつある統合機能とガバナンス機能の統合の一例である。

    ● クラウド・サービス仲介プロバイダーは、SaaS、aPaaS、iPaaS、ITサービスを組み合わせて実装したソリューションを提供するようになる。多 くのE-Commerce B2B統合サービス・プロバイダーは、クラウド・サービス仲介プロバイダーへと進化を遂げるために、ネイティブ・クラウド・サポート、ガバナンス・テクノ ロジ、その他の新機能でソリューションを最新化するはずである (「Cloud Service Brokerages Create a New Role for Integration Service Providers」参照)。こうしたB2B統合サービス・プロバイダーの多くは、数百万ドル規模に上るIaaS市場に既に大きく貢献しているため、クラ ウド・サービス仲介プロバイダーに進化した際は、iPaaS市場にも同様に貢献するとみられる。
複数の戦略的方向性に沿ってiPaaS市場に参入するプロバイダー
多くの場合、iPaaSスイートの具体化は、既存クラウド・サービスの段階的な拡張と集約を通じて行われ る。例えば、一部のIaaSベンダーが自社製品にガバナンス・プラットフォーム・サービスを組み込むのに対し、Amazon、my-Channels、 StormMQといったクラウド型のサービスとしてのメッセージング (MaaS) ベンダー (「Cloud-Based Messaging Services and Technology Are Positioned for Rapid Growth」参照) の一部は、自社の中核的なメッセージング・プラットフォーム・サービスに、さらに多くのiPaaS機能を追加するであろう。場合によっては、従来の統合/ ガバナンス・プラットフォームをリエンジニアリングし、リファクタリングし、CEIPに拡張することによってiPaaSが実装されることもある。

ミドルウェアのバックグラウンドを持つベンダーは、まずiPaaSの統合プラットフォーム・サービスの側面 を提供することに重点を置くであろう。それに対し、SOAガバナンス・ベンダーは、主にガバナンス・プラットフォーム・サービス機能の提供を目指す。しか し、いずれのベンダーも、製品の守備範囲を広げてさらに多くのiPaaS機能を網羅するようになり、結果としてベンダーやテクノロジの何らかの統合につな がることとなる。既存のアプリケーション・インフラストラクチャ・ミドルウェア・ベンダーおよびIaaSプロバイダーの最大手には、統合プラットフォー ム・サービスとガバナンス・プラットフォーム・サービスの両方を提供するiPaaSを、今後12〜18カ月以内にリリースできるだけのスキルとリソースが ある。

自明のこととして、iPaaSはあらゆる統合シナリオに対応できなければならないが、リソースと労力を集中 させるために (または歴史的理由により)、多くのベンダーは厳選されたシナリオ (典型的なE-Commerce B2B統合、クラウド・サービス統合、SOAフェデレーション、SOAガバナンスなど) のみに取り組むことになると思われる。大企業をターゲットにしているiPaaSプロバイダーは、従来のオンプレミス間アプリケーション統合やSOAバック プレーン・シナリオを、二次的な市場としてしか見ないであろう。一方、SaaSアプリケーションに対するユーザーの欲求のレベルと、統合ミドルウェアの採 用が比較的少ないことを考えると、中堅企業にサービスを提供することに重点を置くベンダーは、オンプレミス間シナリオに対しても、最重要機会の1つとして 取り組むことになりそうである。

アプリケーション統合ミドルウェア・ベンダーの中には、クラウド・ビジネスモデルに精通していなかったり、 従来のビジネスと並行した「サービスとしての」事業部門の立ち上げに十分なリソースを保有していなかったり、あるいは自社の既存ビジネスと共食いになると いうリスクを背負い込むことなく慎重にクラウドの舞台に移行したいと考えていたりするベンダーも存在する。したがって、そうしたプレーヤーは、「サービス としての」ビジネスモデルを採用するのではなく、iPaaSの実現テクノロジ (すなわちCEIP) の提供に重点を置くことを選択する可能性がある。さまざまな商業協定を通じて、それらのプレーヤーはサードパーティ (ITサービス・プロバイダー、電話会社、IaaSプロバイダー、統合仲介プロバイダー、クラウド・サービス仲介プロバイダー、他の事業体など) に、自社CEIP上への (おそらくは複数で、互換性が高く、競争力のある) iPaaSサービスの実装を委託することになる。またCEIPは、プライベートまたはコミュニティiPaaSの実装を目的としてエンドユーザー企業にも採 用されることが予想されるため、従来の統合指向のアプリケーション・インフラストラクチャ・ミドルウェア (ESBスイート、B2B統合ソフトウェア、SOAガバナンス・プラットフォームなど) は次第に取って代わられる。

最終的に、iPaaSおよびCEIPは、マルチエンタプライズ・ビジネス・アプリケーションの実装をサポー トするためや、異種混在の統合要件に取り組むプラットフォームを顧客に提供するために (パッケージ・アプリケーション・ベンダーが、自社製品の不可欠な一部あるいはオプションとして統合ミドルウェアを提供するのとほぼ同様に)、パッケー ジ・アプリケーション・ベンダーやSaaSプロバイダーによってOEMで調達されることになる。

採用のシナリオ
本リサーチノートの冒頭で述べた差し迫った問題 (「どのようにしてクラウド・ベースのアプリケーションを統合するか」「どのようにして外部のビジネス・パートナーと統合するか」「自社はPaaSを利用 すべきなのか、もしそうならいつ利用すべきか」) に対して、ガートナーでは次のように考えている。
    ● 前身であるIaaS製品を通じて、既にiPaaSは、ユーザーが外部のビジネス・パートナーとつながるために、またクラウド・ベースのアプリケーションを 既存のオンプレミス・アプリケーションと統合するために利用できる、主要なオプションの1つになっている (そして、今後ますますそうなる)。

    ● 多くのユーザー企業にとって、iPaaSはPaaSに対する最初のアプローチとなる。実質的にすべてのユーザー企業 (規模の大小を問わず) が、必ずアプリケーション統合を行わなければならず、対象アプリケーションの少なくとも一部はクラウド内にあるというケースが増加しつつある。一部の業界 (金融サービス、通信、Webコマース、オンライン・ゲーム、ソーシャル・ネットワーク、クラウド・サービスなど) では、依然として新規アプリケーション開発が大々的に行われているが、ほとんどの主流企業は、パッケージ・ソフトウェアを新たなアプリケーション機能の主 要ソースと見なしており、SaaSも次第にそのように見なされるようになってきている。したがって、新規アプリケーション開発に向けてPaaSを評価する ユーザーよりも、統合の問題解決を試みているという理由でPaaSを検討する企業の方が多くなると思われる。そのため多くのユーザー企業は、新規開発をサ ポートするためにaPaaSを選択することによってではなく、クラウド統合の問題に取り組むために (また従来の統合プラットフォームの高いコストと複雑さも考慮して) iPaaSを採用することによって、初めてPaaSを利用し始めると考えられる。
この新規市場の初期段階においてiPaaSの採用を遅らせる主な要因としては、以下が挙げられる。
    ● 市場の過度な細分化

    ● 実績のないテクノロジや不完全な製品を提供する新興企業の多さ

    ● ビジネスモデルと価格設定オプションを変更するプロバイダー

    ● セキュリティ、プライバシー、SLAに対する懸念

    ● iPaaS採用の投資収益率 (ROI) の不確かさ

    ● インストールされている従来の統合指向アプリケーション・インフラストラクチャ・ミドルウェアの慣性
しかし、2012年から2013年にかけて、従来のアプリケーション・インフラストラクチャ・ミドルウェ ア・ベンダーが次々にこの市場に参入してくれば、統合や合併・買収 (M&A) の連鎖の火蓋が切って落とされることになる。(「マスタ」iPaaSと同じ場所に配置され、それと統合されたサービスを提供する) 大規模なパートナー・エコシステムにサポートされた、比較的少数の大規模なiPaaS「スイート・マスタ」プロバイダーの出現により、主流のユーザー企業 にはより大きな信頼感がもたらされる。ごく少数の厳選されたユースケースのためだけでなく、より多様なプロジェクト・タイプをサポートするために、大企業 がiPaaS (パブリック、プライベート、コミュニティのいずれか) を採用するようになると、iPaaSは幅広く採用され始めるようになる。

それまで (2015年頃まで)、iPaaSは主に最先端ユーザーと中堅企業向けの市場であるとともに、主流企業にとっては (例えば、E-Commerce B2B統合、クラウド・サービス統合、SOAガバナンスに対する) 補完的機会となる。

ほとんどの大企業にとっては、おそらく複数のiPaaSと従来のアプリケーション・インフラストラクチャと の共存が標準になるであろう。したがって、既存の統合コンピテンシ・センターやSOA COEは、テクノロジ、既存の統合に関する組織的かつガバナンス上のフェデレーション、iPaaSを伴うSOAバックプレーン・インフラストラクチャをサ ポートするという課題に直面することを余儀なくされる。

iPaaSに向けた収束および整理統合のプロセスは、荒れたものになることが予想される。多くのプロバイ ダーが姿を消し、リーダーシップをめぐる競争の中でベンダーは未熟なテクノロジを市場に投入し、一部のM&Aは失敗に終わり、プラットフォームを 効果的に拡張してクラウドの大きな作業負荷をサポートすることができないベンダーや、増加の一途をたどる顧客に質の高いサポートを提供するために苦闘する ベンダーが出てくる。

要件に対する製品の機能的および非機能的な適性の分析に加えて、iPaaSを検討しているユーザー企業は、 それぞれの特定業種や地域におけるベンダーの実績はもとより、ベンダーのエコシステムについても慎重に評価して、iPaaSの採用によるリスクを最小限に 抑えるとともにメリットを最大限に高めるようにすべきである。

市場の成熟と整理統合を気長に待ちすぎるのは、企業にとってリスクを伴う可能性がある。その間に、競合他社 がiPaaSを利用してコスト削減、効率向上、独創的手法による競争優位性の創出に向けた取り組みを進めてしまうからである。iPaaSの採用を成功させ るための鍵は、テクノロジとベンダー・リスクのトレードオフと、効率性および有効性の向上の中にある。

    推奨リサーチ
    ・ 「クラウド・コンピューティング向けアプリケーション・インフラストラクチャ:成長する市場 (2010年)」(APP-10-103、2010年9月10日付)
    ・ 「クラウドの統合:サービスとしてのインテグレーション (IaaS) によるB2Bインテグレーション/アウトソーシング」(SOR-10-15、2010年4月15日付)
    ・ 「PaaSのロードマップ:新大陸の出現」(APP-11-41、2011年4月25日付)
    ・ 「APaaS: A Step to a 'Killer App' for Cloud Computing?」
    ・ 「Magic Quadrant for Shared SOA Interoperability Infrastructure Projects」
    ・ 「What SOA Governance Is and Will Be」
    ・ 「Gartner's Reference Architecture for SOA Application Infrastructure」
    ・ 「Integration Brokerage Provides Facilitated Intermediation for B2B E-Commerce and Cloud Services Brokerage」
    ・ 「クラウド・サービス仲介事業:仲介を次の段階へ進める」(APP-11-18、2011年2月18日付)
    ・ 「Seven Things to Think About When Initiating Federated SOA」
    ・ 「生産性 vs. 制御性:クラウド・アプリケーション・プラットフォームの成功に向けた二分化」(APP-11-42、2011年4月25日付)
    ・ 「Market Share: All Software Markets, Worldwide, 2009」
    ・ 「Magic Quadrant for Integration Service Providers」
    ・ 「Market Trends: Multienterprise/B2B Infrastructure Market, Worldwide, 2010-2015, 1Q11 Update」
    ・ 「Who's Who in Cloud Computing/SaaS Integration, Volume 1」
    ・ 「クラウド・コンピューティング/SaaS統合プロバイダー - その2」(APP-10-96、2010年8月10日付)
    ・ 「IBM Makes a Big B2B Play With Strategic Potential as It Acquires Sterling Commerce」
    ・ 「IBM Adds Comprehensive Cloud Service Integration to WebSphere via Cast Iron Acquisition」
    ・ 「Windows Azure AppFabric: A Strategic Core of Microsoft's Cloud Platform」
    ・ 「Cloud Service Brokerages Create a New Role for Integration Service Providers」
    ・ 「Cloud-Based Messaging Services and Technology Are Positioned for Rapid Growth」

    (監訳:飯島 公彦)

APP: APP-11-87
※本レポートの無断転載を禁じます。

←INDEXに戻る

 

gartner.com
TOP OF PAGE
Copyright