SOAの難しい課題を解決するポイント：動き出したSOAのいま（2/5 ページ）

[生熊清司，ITmedia]

SOA導入のためのステップ

　ITRではSOA実現のステップを図1のように4つのステップで定義している。それぞれのステップごとに、課題および留意点とその解決に向けた基本的な考え方を紹介する。

図1●SOA実現のためのステップ（出典：ITR）

ステップ1：現状調査

　このステップでは現状のシステムやアプリケーションについての棚卸しを行う。多くの企業においてシステムは継続的に変化しているため、稼働当初に書かれたドキュメントとシステムの実態が異なっている可能性がある。そのため、システム全体の俯瞰（ふかん）図を作成することは非常に重要だ。俯瞰図にシステム名、所有者、ビジネスプロセス、システム間インタフェース、使用されている技術、現在の利用状況と問題点などの情報を盛り込む必要がある。

　さらに、サービス化すべきプロセスを選定するのだが、この判断を行うには幾つかのアプローチが考えられる（図2）。

図2●サービス抽出のアプローチ（出典：ITR）

　ボトムアップ型の意思決定は、現場の声を反映するという点では適切であるが、「局所最適」という弊害が生じるリスクがある。システムが縦割り化し、相互運用に困難をきたす状況である。日本企業のほとんどが多かれ少なかれこのような問題を抱えている。ゆえに、アーキテクチャー設計プロジェクトがトップダウン型で推進されるのは当然の流れであろう。

　もともと、アーキテクチャーという言葉自体に共通の標準をトップダウンで決定していくというニュアンスがあるのは否めない。しかし、トップダウン志向が強すぎると、別の問題が発生する可能性が出てくる。

　まず、大規模企業のすべての情報システムに対して共通の規約や仕様を決定していくことは、その作業負荷を考えると非現実的といわざるを得ないケースが多い。また、各現場の状況を無視した全社的標準を強制することは、かえって変化への迅速な対応を妨げるおそれがある。さらに、現場の特殊事情を無視し、重要な例外処理が見逃されたり、アーキテクチャーから排除されたりすることで、現場の効率や顧客サービスの質をかえって悪化させることもある。

　どちらのアプローチにも一長一短があるとすると、アーキテクチャー設計においては、トップダウンとボトムアップを組み合わせたアプローチが必要となる。このアプローチは「ミドルアウト」と呼ぶことができる。各アプリケーション内ではトップダウン的な厳密なアーキテクチャーを適用し、複数アプリケーション間ではボトムアップ的な柔軟なアーキテクチャーを適用するという考え方である。