情シスは何度でも甦るさ。

VBA!VBA!

ESBとEAIとETL。

共に、システム間連携をサポートするミドルウェアだ。
この三つが共存する環境を作らなきゃならなくなったって話。



あるプロジェクトで、EAIツールを導入することになった。

当初、製造ベンダーが、開発費削減のために、EAIツールを入れさせてくれと言ってきたのが始まりだった。
そのときの担当者は、二つ返事でオッケーした。

その後、インフラ周りがウダウダになって来たのでオレにお鉢が回ってきたのだが、社内申請などまったく通ってなかったのに、すでにそのEAIツールありきでプロジェクトは進んでいた。

ちょっとやばそうな感じがしたが、そのはじめて聞くツールを調べてみると、シェアも、機能もイケてるようだった。


で、いざ、社内稟議用の資料を作成しようと、費用対効果を算出してみると、、、


とても、そのプロジェクト単体では効果が出るようなものではなかった。

というのは、
 1.保守費が考慮されてない(普通だったら、5年の保守費も盛り込む)
 2.開発環境の構築がまったく考慮されてない(本番環境だけだと、触るに触れない)

製造ベンダーは、本番のライセンス料だけを試算して効果があるから導入してくれと言ってきていたのだった。


かと、言って今更このツールを導入しないとなると、かなり危険だ。


案件単体で、効果が出ないとなると、他案件でも流用したケースを考えて効果を見ようという話になったのだが、
全体のシステム間連携の標準化はSOA導入の中ですでに話されており、ESBと言ってることがもろかぶり。という話になって、もめることに。

しかも、ひそかに別案件でETLツールも導入されていたということもわかり、さらに大モメ。

と、言うわけで、SOA導入プロジェクトに名前を連ねるオレが、なんとかEAIを導入しなければ、ならなくなってしまったのだった。



とういわけで、本題。

まず、EAIとETLの違いを調べた。

以下、超簡単に違いを説明する。

ETL:基幹システムのDBから、データウェアハウスにデータを投入するために、データを集約する。

EAI:分散するシステムの既存のデータを流用し、各システム間にデータの連携を実施する。

と、簡単に言えるのだが、いざ機能比較をしてみると、かなり重複している。
はっきし言って、どっち使っても、いーんじゃねーの。って感じ。

ただ、さらに色々調べていくと、ライセンス体系に大きな違いがあることがわかった。

ETL:ETLが稼動するサーバと、ETLの機能を使用するDBサーバに対してライセンスがかかる。

EAIEAIツールが稼動するサーバにのみライセンスがかかる。

すべてのソフトウェアに対しては、言えないが、今うちの会社で導入しているETLツールOracle製)については、上記のようなライセンス形態ということがわかったため、今後汎用的に使うのは難しいだろうとう言うことを、言い切ってEAIを導入すべきと説明した。


さて、次にESBとEAIだ。
もっとも、単純に比較対照としては微妙なのだが。

ここでオレは、ESBの弱点を補完するためにEAIを導入しようという言い方をしようとした。

ESBの弱点
 大量データのバッチ系の処理は、他のリアルタイム系の処理に影響を与える
 呼び出し元、呼び出し先共に、サービス化に対応することが必要(EAIは、既存のファイルやDBをそのまま流用可能)

というところを、補完する意味でEAIを導入しようと書いたのだが、

「じゃぁ、ESBがボトルネックになる連携とはどの程度なのだ」

という指摘が返ってきた。

いや、確かに、うちのマスタ連携如きじゃボトルネックにはならない気もするのよね。

と、ここで、しょうがなく、うちの会社のシステム間連携を全部洗い出すことにした。

そこで見えてきたのは、1:N、N:1、1:1という連携が混在しているということ。
1:N、N:1という関係は、連携方式を標準化、サービス化すれば、SOAとして効果があるだろうと。
ただし、1:1の連携を標準化しても、それは意味がない。

ここから、1:1の連携に対しては、EAIを使うべし。

と、いう逃げ方で、EAIを導入しようとしたんだが、、、、いざ、今回の案件の連携を見てみると、


思いっきり1:Nの連携部分にEAIツールを使おうとしていたのだった。。。


EAIツールの製造ベンダーに聞いても、EAIとESBが同居している事例は聞いたことが無いんだって。




っつーわけで、いったい、このプロジェクトはどうなるんだろうか。

今非常に困ってます。誰か助けてヘルプミー。