DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

今回は企業システムにおける今後のＩＴアーキテクチャーの大きな潮流となるであろう”疎結合モデル”についてお話ししたい。前回ブログにもある通り、ＩＴアーキテクチャーは時代とともに変化し、特にTA、AAの領域でそれは顕著である。2015年の今、2000年前後に一世を風靡したERPの時代がそろそろ終焉を迎える。同時に、ITインフラのあり方を変えるクラウドコンピューティングが2010年頃から急速に台頭してきた。そして一昨年頃から、蓄積されたビッグデータを有効活用しようという動きも活発化している。

ビジネスにおいても、日本企業は否応無しにグローバル対応が迫られると同時に、オリジナリティも発揮して世界市場で戦って行かねばならない。多様性を認めた上で、既成の概念を打ち破る新たな付加価値の創造が求められている。このような時代背景にあり、ＩＴアーキテクトとしては、今後20年、いや少なくとも30年はもつＩＴアーキテクチャを考えたい。過去のブログで度々、ＥＡにおけるＤＡの普遍性に触れ、DATA-CENTRICアーキテクチャの重要性に言及したが、今回はその次に長寿であってほしいＡＡ（Application Architecture）について言及する。

ここへきて我が国の“大企業”システムは、ユーザ至上主義と手厚い保守によって、想像以上に巨大化、複雑化を招いている。大企業と書いたのは、中小では高額なＩＴ保守費用は捻出できず、ふんだんな保守要員も抱えることは難しいからだ（こちらの方がむしろ問題は少ない）。そして、大企業の基幹系システムの中核をなすのが、2000年前後にビッグバン導入されたＥＲＰシステム若しくは、手組みのＯＬＴＰ（Online Transaction  Processing）システムであることが多い。

これらはいずれも、企業システム全体が今ほど巨大でなかった時代に作られたもので“密結合モデル”が主流である。（正確に言えば、さらに遡ること十数年前から存在する“バッチ処理システム”がもう１つのアーキテクチャとして根強く残っている。）

これらの密結合モデルの最大の問題は、システムが予想以上に大きくなったことで、トラブルの連鎖波及によりビジネスリスクが増大することである。限界を超える長いトランザクション処理では、ひとたびトラブルが検出されれは、想像を絶する膨大なロールバックが発生することになり、ひいてはデータ保全が危うくなる。

また、更新波及が多ければ多いほどリアルタイム処理に遅延が発生し、トータルレスポンスに問題を来たす。元来、ＯＬＴＰ処理はＤＢの排他制御の関与で、データを全件処理するスループットはバッチシステムより遥かに遅い。ＯＬＴＰや（リアルタイムでデータを波及更新する）ＥＲＰは、その規模が大きくなり過ぎると破たんを来たすことになる。これを力技でハードウエアを増強したりインメモリー化すれば、さらなるオーバーヘッドが発生することになる。そして、ロジックの複雑性がもたらす問題は依然解決しない。

さる3月5日、縁あってソフトウエアの未来をテーマとした「知働化フォーラム」なる集まりに参加した。Microsoft萩原さんのセッションの中で、現実社会における疎結合の例として“都内の地下鉄”を挙げておられた。地下鉄の一路線内の運行は順序固定の密結合であるが、異なる路線間は疎結合であり、一路線の運行トラブルが他の路線には直接的影響を及ぼさない（乗換駅での待ち行列はできるが）等、とても分かり易い説明であった。余談であるが、最近、複数私鉄の相互乗り入れによって、接続した路線に運行トラブルが波及するのは密結合の弱点なのだと妙に納得した次第である。

今後、クラウドコンピューティングの時代に入り、企業システムが利用するネットワーク環境はインターネットベースとなる。様々な理由によるデータ伝送の遅延と、アプリケーションシステムの複雑化を考慮すれば、これからの企業システムは、どうしてもリアルタイムな密結合処理を必要とする部分を除き、疎結合アーキテクチャにせざるを得ない。トラブル波及のビジネスリスクを排除し、複数システムの同時並行開発を可能とすることは、ダッシュボードでリアルタイムにデータを眺めて一喜一憂することより遥かにＲＯＩに勝ると思われる。

次回は、企業の基幹系システムにおける疎結合アーキテクチャの具体例についてお話したい。