前回は，企業内に存在するデータの意味の多様性，すなわち「セマンティクス・ギャップ」について述べ，それがアプリケーション間の連係を行う上での大きな課題となっていることを述べた。

◆統合されているかのように見せる

　もちろん，セマンティクス・ギャップを解消するための努力は必要である。これは，要するに全社的なデータ標準化を行うことにほかならない。しかし，前々回にも述べたように，今日の企業内のアプリケーション・ポートフォリオでは，多くの独立した組織がアプリケーション設計に関与しており，セマンティクス・ギャップを完全に解消することはできない。

　一番分かりやすい例を言えば，新しく購買したエンタープライズ・アプリケーション・パッケージと，長年のあいだ使用してきたレガシー・アプリケーション間のデータのセマンティクスの違いを完全に解消するのは不可能と言ってよい。

　ここで，重要になってくるのは，データやメッセージを必要に応じて適切に変換し，できるだけシームレスにアプリケーション間の連係を行えるようにするための仕組みの構築である。いわゆるEAI（エンタープライズ・アプリケーション統合）の考え方の基本はここにある。つまり，データ設計のレベルから根本的に統合するのではなく，データやメッセージの変換により，「あたかも統合されているかのように見える」ようにするということである。

　都市計画型アーキテクチャの設計においてもセマンティクス・ギャップの存在とその変換に関する考慮は避けて通れない。その具体的ポイントについては，次回以降に述べることにし，ここではまず用語に関する考慮点について考えてみよう。

◆「変換」という言葉

　日本語で「変換」と言った場合に，英語において対応する術語が2つあることに注意すべきだろう。すなわち，トランスフォーメーション（transformation）とコンバージョン（conversion）である。前者は，セマンティクス面での変換を言い，後者はシンタックス面での変換，例えば，文字コードの変換，データ形式の変換（10進数とバイナリ間の変換，フィールド幅の拡張など）を言う。両者が混同されて使用されてしまうこともあるが，多くの場合，明確に使い分けられていると思う。

　残念なことに，日本語ではどちらも「変換」と訳すしかないようだ。誤解を招きそうな時は「トランスフォーメーション」「コンバージョン」とカタカナで言うか，「アプリケーション・レベルの変換」「システム・レベルの変換」と説明を加えるしかなさそうだ（もちろん，「セマンティクス・レベルの変換」「シンタックス・レベルの変換」と言った方がより正確ではあろうが，ますます話を混乱させてしまうかもしれない）。

　ここで，コンバージョンは比較的容易な課題である。市販のツールの採用により対応できるからである。一方，トランスフォーメーションには，アプリケーション・ロジックの開発が必要となる。コード体系の相違くらいであれば，表引きをするだけで対応可能であろうが，複雑なアプリケーション・ロジックの開発が必要となるケースもある。

　例えば，前回述べた「月次売上」の例では，アプリケーションによって，売上データから返品分を差し引いたり，足し込んだりするロジックが必要となるだろう。

　さらに，根本的なデータ・モデリングが異なっていた場合などには，トランスフォーメーションのロジックはきわめて複雑となり，1つのアプリケーションを開発するくらいの負荷がかかることもあり得るだろう。例えば，あるシステムでは「顧客」を「法人」と捉えており，別のシステムでは「営業のコンタクト先」と捉えてシステム構築している場合などである。

　もちろん，トランスフォーメーションにもツールが有効なケースはある。例えば，「ETL（エクストラクト・トランスフォーメーション・ロード）」と呼ばれるツール群を使用することで，スクリプト言語やパラメータ設定により，ある程度，アプリケーション・レベルの変換を容易に行えるようになる。しかし，ツールが100％の解決策になることは，ほとんどないことに注意すべきだ。

◆EAIの勘所

　セマンティックス・ギャップが不可避である以上，全社的なアプリケーション統合では，数多くのトランスフォーメーション・ロジックが必要となる。これらのロジックをいかに一元管理するかが，効率的で変化に強いシステムを作り出す上での要となる。

　ここで，重要になってくるのが「ハブ・アンド・スポーク・アーキテクチャ」である（ここでの“アーキテクチャ”は，「システム設計の基本的型」と言う意味で使用している）。スペースも尽きてしまったので，この話は次回に回させていただくこととしたい。