アプリケーションは、パブリッシュ・サブスクライブ型で統合せよ

ピア・ツー・ピア型：
それぞれのアプリケーションを1対1の関係で個々に接続した形態。

メッシュ型：
ピア・ツー・ピア型を複数のアプリケーション間接続に応用した形態。接続するアプリケーションが増加するに従って、必要な接続の数が増大します。現在のほとんどの企業は、この形態で接続している言っても過言ではありません。

ハブ・アンド・スポーク型：
アプリケーション間連携を集中管理する形態。アプリケーション数が増加すると接続数が増大してしまうメッシュ型の短所を補う形態です。

パブリッシュ・サブスクライブ型：
各アプリケーションは連携を意識しません。ネットワーク上に流出させる（パブリッシュ）データのみを規格化し、そのデータを必要とするアプリケーションだけがデータを取得（サブスクライブ）する。この形態も、アプリケーション数が増加すると接続数が増大してしまうメッシュ型の短所を補うものです。

これらのうちどの接続形態を選択するかによって、TCOがかなり違ってきます。

もし少数のアプリケーションを連携させるのであれば、どのような接続形態であっても、大きな問題が生ずる心配はありません。

アプリケーションの数が一定レベルを超えると、接続形態について十分に検討する必要性が出てきます。それは、各アプリケーションを連携させる際に必要になる接続の数を考えてみれば明らかです。

つまり、それぞれのアプリケーションを「1対1」の接続の延長である「メッシュ型」で接続するとすると、連携させるアプリケーションの数が5台の場合には、
「5×（5－1）＝ 20とおり」の接続を考えなければならなくなります。

開発するにしても、20のインターフェースを作らねばなりません。アプリケーションの変更や保守に莫大な労力とコストが必要になることは明らかです。つまり、統合するシステムが一定の数を超える場合は、アプリケーション統合の基盤として、「メッシュ型」ではなく、「ハブ・アンド・スポーク型」や「パブリッシュ・サブスクライブ型」といった形態を検討する必要が出てきます。

実際に、SAP R/3の導入の際、SAP側が開発するインターフェースの数が40を超えたことがあります。何だ、たった40か、とは言わないでください。テストの結果が思わしくなかった場合、原因を特定する作業がかなり煩雑になります。

また、これに付随するレガシー側アプリケーションの改修、レガシー側同士のインターフェースの改修、データの意味合いを統一するためのマッピング、変換アプリケーションの開発。挙げたら限はないですが、導入アプリケーション以外のところでの改修費用がバカになりません。

アプリケーション統合の際には、接続形態以外にも考慮する必要のある重要な機能があります。

まず、上で挙げたような、データ項目の並び順をアプリケーションごとにマッピングしたり、文字コードの違い（EBCDIC、SJIS）を吸収したりするデータ・フォーマット変換機能です。

また、ERP、CRM、SCM などの各パッケージ・ソフトウェアを接続するアダプタ機能や、どのデータをどのシステムからどのシステムへ流すかを管理するフロー管理機能のほか、トランザクション管理機能など、メッセージのやり取りの完全性を保証する機能などについても考慮する必要があります。

これらの機能がサポートされることにより、複数のシステムを連携させ、アプリケーションを統合することが可能になるのです。

さらに、アプリケーション統合を行うための大切な作業として、共通辞書の作成があります。一般的に、異なるシステム間では同じ言葉が違う意味で使われていることが多いため、全社のシステムで言葉の使い方を統一し、共通の辞書を構築する必要があります。また、辞書だけではなく、マスター類、コード類も考慮する必要があります。

マスター類、コード類を統一できるのであれば、それに越したことはありません。統一した方が、後の管理、改修は楽になるのが目に見えています。

三菱電機では、品目コードの桁数が75桁でした。SAP R/3は、18桁（？確かなことは忘れてしまいました）です。SAPのコード類は、コード自体に意味合いを持たせないことをコンセプトにしています。属性は、マスタ項目として定義することが基本です。しかし、インターフェースプログラムが非常に複雑になります。

このプロジェクトでは、結局、R/3が75桁に対応するよう、R/3の大改修を行うこととなりました。当然、日本ではできないので、ドイツ本社の了解の下、ドイツで責任を持ち行うこととなりました。

ちなみに、SAPがこのような対応をするのは、例外中の例外です。

しかし、今現在も使用しているのでしょうか？三菱電機の関係者の方が読者におられましたら、教えてください。