前回まで述べてきたように，企業の情報システムの中にセマンティクス・ギャップ（データの意味の違い）が存在する以上，アプリケーション間で意味がある連係を行うためには，データを（アプリケーション・レベルで）変換（トランスフォーメーション）し，ギャップを吸収するためのロジックを開発する必要がある。

　規模が大きく長い歴史を持つ企業では，セマンティクス・ギャップの多様性はきわめて大きく，このようなロジックの開発には大きな負荷がかかる（場合によっては，アプリケーション本体よりも大きな負荷がかかる）ことも十分あり得る。

◆避けたい“アプリケーション・スパゲッティ”

　多くの企業では，トランスフォーメーションのロジックをアプリケーション・プログラム本体と一体のものとして開発したり，特定のアプリケーション間連係のための専用プログラム内に埋め込んでしまったりする。このようなやり方は短期的解決策としてやむを得ない場合もあるだろうが，長期的に見ると大きな問題を引き起こす種になる。

　未熟なプログラマによる行き当たりばったりのコーディングで，とりあえずは動くものの文書性がきわめて悪く保守不可能なプログラムのことを“スパゲッティ・プログラム”と呼ぶことがある（最近はあまりこういう言い方はしないかもしれないが）。同じように，行き当たりばったりのアプリケーション連係を繰り返し行うことで，著しく保守性が悪い状態となってしまったことを“アプリケーション・スパゲッティ”と呼べるだろう。

　このアプリケーション・スパゲッティ状態は，気が付かないうちに情報システム部門の開発生産性を大きく低下させしまう。ガートナーの推定では，典型的な情報システム部門において，アプリケーション連係の「つなぎ」ロジックの開発のために要員負荷の40％程度以上が費やされている。アプリケーション間のつなぎという，地味で評価されにくい作業に忙殺されることによるスタッフのモラルの問題も生じるかもしれない。

　アプリケーション・スパゲッティのより大きな問題として，システムの変更が困難になってしまうことが挙げられる。アプリケーションの1個所の変更（たとえば，フィールド桁数の拡張）が，企業内情報システムの他の個所に与える影響を把握しにくくなるからである。このような俊敏性の欠如が情報システムの価値をどれほど損なうかは，あえてここで説明するまでもないだろう。

◆重要なのは変換ロジックの一元管理

　ここで重要となるのは，トランスフォーメーションのロジックを一元管理することである。一元管理しておけば，最初の構築は大変であっても，あとの保守は容易になる。これこそが「ハブ・アンド・スポーク・アーキテクチャ」と呼ばれているアーキテクチャのポイントである。ハブ・アンド・スポーク・アーキテクチャでは，アプリケーション連係のためのやり取りをすべてハブと呼ばれるサブシステム経由で行う（つまり，アプリケーション間の直接的なやり取りを認めない）とともに，トランスフォーメーションのロジックをアプリケーション本体から切り離しで，ハブで一元管理する。

　こうしておけば，アプリケーションの設計に変更があった場合でも，対応するトランスフォーメーション・ロジックの変更を簡単に特定することができる。また，一度開発したトランスフォーメーション・ロジックの再利用も容易になる。

　単にメッセージ・キューイングを介して少数のアプリケーションを連係したシステムを「ハブ・アンド・スポーク」と称している事例もあるようだが，本当に重要なのはセマンティクス・ギャップを解消するためのトランスフォーメーション・ロジックを一元管理できているかどうかなのである。

　すべてのアプリケーション間のやり取りをハブ経由で行うことで，これらのやり取りの順番やフローの制御が容易になるという副次的効果もある。これは，BPM（Business Process Managemet）という考え方につながってくる。

◆求められる企業神経系の構築

　ガートナーは，「ハブ」に相当するアプリケーション連係の基盤を「エンタープライズ・ナーバス・システム（ENS：企業神経系）」と呼んでいる。ENSでは，いわゆるEAI（Enterprise Application Integration）的なトランザクション連係だけではなく，BPM，さらにはリアルタイム性が高い分析アプリケーション（ガートナーではBAM（Business Activity Monitoring）と呼んでいる）も提供される。

　ここで，また全社的アーキテクチャ＝都市計画という例え（連載第2回参照）を持ち出してみよう。ENSは，都市計画でいえば，道路や鉄道などの交通インフラにたとえられるだろう。交通インフラへの投資が不十分であれば，いかに立派な建物を建て続けても効率的な都市を作ることはできないだろう。その意味で，ENS的な考え方は全社的アーキテクチャの検討において避けてはならない構成要素といえるだろう。

　次回は，もう1つの重要なアーキテクチャ（「システム設計の型」）であるサービス指向アーキテクチャ（SOA）について紹介しよう。