EAI - 企業アプリケーション統合に求められる条件は?
最近EAIというキーワードをよく聞くようになった。正確にいうと「再び」よく聞くようになった。EAIはEnterprise Application Integrationの略であり、1998年前後にも一度ITの注目キーワードとして登場している。IT業界では単に読んだだけでは意味がよくわからない3文字略語が多い中で、EAIは比較的ストレートな用語であり、直訳しても「企業アプリケーション統合」とわかりやすい。具体的には、企業内で業務に使用される複数のシステムを連携させ、データやプロセスの効率的な統合を図るソフトウェアやその仕組みを指す。そのEAIが、なぜ再度注目を集めているのか? 以前話題になったときと何が違うのだろか?
EAI誕生の背景
企業の情報システムは、用途に応じて営業支援システム、顧客管理システム、財務会計システム、製造管理システムなど複数の業務アプリケーションが個別に構築され、また、それぞれのシステムの必要性に合わせて、メインフレームやワークステーション、パーソナルコンピュータなど、さまざまな環境が混在している。
近年、業務のスピード向上や、素早い意思決定・企業経営を実現するために、社内の異なる業務アプリケーションの連携が必要となってきた。アプリケーション間の連携を行うには、個別にその接続をコーディングして作りこむこともできるが、この方法では連携の数だけプログラム開発を行わなければならない。そこで、このアプリケーション連携を中心的につかさどり連結の数を大幅に減らすことで開発期間の短縮と柔軟性の確保を両立させるパッケージソフトウェアが現れ、これをEAIと呼んだ（図１）。
この定義上、EAIに求められる最低限の機能は、各アプリケーションとの結合を実現する「アダプタ」、アプリケーション同士のデータの関連付けや加工を行う「マッパー」、そしてそれらの処理の制御を行う「フロープロセッサ」となる。（図２）
第１世代EAIと第２世代のEAI
最初にEAIが脚光を浴びた1998年当時、XMLをはじめとしたインターネットテクノロジーは企業情報システムにおいてはまだ普及の途上だった。そのため、その時点で既に存在したプラットフォームとして、メッセージキュー、TPモニタ*1、DBMSなどをベースとしたEAI製品が多く生まれ、連携テクノロジーとしてはベンダー独自のMOM*2やCORBA*3が使われた。
その後、XMLやインターネット標準技術の普及が進み、企業におけるインターネット活用が当たり前となった。また一方で、グローバル化や構造不況の影響を受けて企業情報システムのビジネスの変化への迅速な適応への要求は加速度的に増してきた。そして、2002年頃から、インターネット標準技術をベースとした新しいEAIソフトウェアが生まれてきたのだ。この新しい世代のEAIの特徴を典型的な例で整理すると次のようになる。
| 第１世代EAI の典型例 | 第２世代EAI の典型例 | |
| 目的（重点） | 過去の情報資産の有効活用や異機種間の有機的なデータ連携（保守的） | システム間の処理の高速化や変化への適応のための連携（戦略的） |
| 規模 | 大規模 | 小規模?中規模 |
| 開発形態 | 集中的 | 反復的 |
| 連携技術 | プロプライエタリ | オープンスタンダード |
| フローの可視化 | × | ○ |
| 統合のスコープ | ホストを中心とした社内 | 社内外 |
| 価格 | 数千万円? | 数百万円? |
EAIは大企業だけのものではなくなった
第２世代EAIの特性は、規模にとらわれず、オープンな標準技術を使い、社内外にかかわらずアプリケーション統合ができる、つまり様々な意味でオープンであることである。そこで、本稿では第２世代EAIを「オープンEAI」と呼ぶことにする*4。ここに整理したような特性によって、オープンEAIで構成するEAIは構造的にも特徴をもつ。つまり、オープンEAIでは、モノリシックな単一ハブ構造を強要せず、必要に応じて複数のハブを持つことも可能となっているのだ（図３）。その意味でオープンEAIは、「アプリケーション統合」というよりは「アプリケーション連携」の意味合いが強い。英語で言えば、IntegrationというよりはFederationといったところだ。本稿で定義した「オープンEAI」はEnterprise Application Federationのためのパッケージと言うこともできるだろう。オープンEAIの構造によって、局所的に始めて、必要な応じたツールを組み合わせ、システム連携を成長させていくことができる。しかも、特定のベンダーや技術だけに依存する必要もない。オープンEAIの登場により、もはやEAIは、年間に何十億もIT投資ができる大企業だけのものではなくなったのだ。あらゆる企業でシステム連携のニーズは高まっているが、現実的には、EAIを最初から大規模に導入できる企業は少ない。しかも大企業であっても、そのシステムの多さと複雑さゆえに、全社的なシステム連携基盤を一斉に構築することができることは稀である。このような現在のビジネスの状況やニーズを分析すると、現在のEAIに求めらてている姿＝条件が浮かび上がってくる。
オープンEAIとしての５つの条件
条件 | 説明 |
| 小規模に迅速かつ低コストで始められるか？ | 企業の規模にかかわらず、アプリケーション連携のニーズは、まず局所的に始まるケースがほとんどである。局所的なニーズをそのメリットに見合うコストで迅速に開発できることが求められる。 |
| ミッションクリティカルな用途に耐えるか？ | 大量のデータ処理や24時間稼動などへビィデューティでミッションクリティカルな業務にまで耐えうる性能や実績があるかどうか。 |
| オープン標準技術ベースであるか？ | 統合対象となるアプリケーションを全てあらかじめ想定できなくなっている。オープンな標準技術を網羅的にサポートしていることで、新たな接続におけるコストや期間が減少する。特定のOSでしか稼動できないものは稼働環境を固定化することからオープンとは言えない。 |
| 処理が可視化されているか？ | 処理手順の変更、データ加工処理の変更などさまざまな変更が外的な要因で起こりえる。処理の可視化によって、現場担当者も設計を理解することができ、変更要求や追加要求などに迅速に対応できる。また、コーディングが排除されれば、特定のエンジニアへの依存性を減らすことも可能である。 |
| フロントエンドとの統合をカバーしているか？ | いまやアプリケーション統合のスコープはユーザーの使用するフロントアプリケーションにも及ぶ。そのため、Excel、電子メール、PDFなどユーザーのフロントアプリケーションとの統合が可能かどうかが重要なポイントとなる。 |
あなたがもしEAIパッケージの導入や提案を検討しているのであれば、この5つの条件に各企業の固有の条件を加えて評価するとよいだろう。
EAIパッケージ適用の状況
さて、ここまでEAIパッケージについて解説してきた。しかし、ガートナーの調査（図４）にも示されるとおり、企業アプリケーション統合においてはまだEAIパッケージが適用されず個別に作りこまれているケースが多い（図中、赤枠の部分）。つまり、実はEAIのパッケージ選定などという前に、EAIのパッケージすら使っていないケースが多々あるということだ。これは、企業アプリケーション統合の形態がまだ図1の左辺のような構造で作りこまれているものが多いということを示している。このようなケースは、「まず1対1だからEAIパッケージを使うほどでは・・・」というように、とりあえず目の前の問題を解決するためだけに採られたり、または悪いケースでは開発ベンダーの工数を稼ぐために採られることさえあるが、１対１の接続であれ、これからのことを考えて導入をしなければ「常に火を消して回っている」後追い型の企業システムから抜け出すことはできない。実際、「オープンEAI」はこのようなニーズをも満たすために「スモールスタート」ができるような構造になっているわけであり、最初の１対１の接続からEAIパッケージを適用していくべきなのである。
ASTERIAとオープンEAI
さて、最後に筆者の所属するインフォテリアの製品ASTERIAは、さきほどの「オープンEAI」5つの条件においてどうであろうか？興味のある方は、別表にまとめたので是非参照してほしい。手前味噌にならないように事実だけを検証してみた。他のEAIパッケージを検討されている方は、同様の検証をしてみてはどうだろうか。
まとめ
ホスト連携を中心として大企業から始まった企業アプリケーション統合=EAIは、いまや企業規模を問わず必要となってきている。そして、さまざまなEAIパッケージが登場している。システム連携を行う際には、(1)1対1の接続であっても短視眼的に手作りで作り込む事を止めEAIパッケージを適用すること、(2)EAIパッケージの選定においては本稿「オープンEAI」の5つの条件を考慮すること、の2点を強く推薦する。
【注釈】
- *1 TPモニタ：Transaction Processing Monitorの略。トランザクション処理を実現するためのソフトウェア。複数の個別処理をまとめて、一つの処理単位（トランザクション）として監視し、そのトランザクション全体を「全て成功」か「全て失敗」かのいずれかに帰結させる。
- *2 MOM：Messaging Oriented Middlewareの略。メッセージ処理を中心としたミドルウェア。
- *3 CORBA：Common Object Request Broker Architecture の略：OMG(Object Management Group)が定めた、分散したオブジェクト間でメッセージを交換するための仕様。
- *4 「オープンEAI」は本稿を理解しやすくするための造語であり、一般に使用されている用語ではない。
日時: 2004年09月30日 13:00 | | TrackBack
