【解説】
SOA導入の「阻害要因」とそれを踏まえた「現実解」

課題を解決しうる「設計図の参照」や「ミドルアウト型アプローチ」

（2008年04月28日）

SOA導入の従来型アプローチ

　SOAの本質や導入の阻害要因を確認したところで、以下より、実際に自社のシステム／アプリケーションにSOAを導入するうえでの具体的な手法について考えてみたい。まずは、このアーキテクチャが世に知れ出した当時から叫ばれていた、従来型、ないしは基本型と呼べるアプローチについてあらためて確認しておく。

　SOAを導入する際には、EA（エンタープライズ・アーキテクチャ）の策定によって、自社の業務プロセスの標準化と使用する技術の標準化を行ったうえで、以下のような4つのステップを踏むことが必要であると考えられてきた（図3）。

ステップ1：現状調査
　自社における既存の業務プロセスからサービス化するべきプロセスを洗い出す。

ステップ2：サービス要件の定義と管理体制の確立
　サービスの利用者と提供するレベルを定義する。加えて、提供するサービスが複数の業務プロセスや組織に関係することから、関係者間でサービスの設計や変更に関する手続きと役割を定めるための管理体制を定める。

ステップ3：サービスの定義と実装
　実際のサービスを構築するために、サービスの粒度や階層、構成要素やインタフェースなどを定義したうえで、サービスを実装する。

ステップ4：管理と監視
　円滑な運用を行うために、サービス管理体制に沿った運用と改善を行い、効果を監視する。

図3：SOA導入のステップ

　この4つのステップを踏む従来型のアプローチは、SOAを導入するうえでの王道とも呼べる、理想的なものである。しかしながら、現実には、すべてのケースでこのような理想的／教科書的アプローチがとれるわけではない。

　現場における実際の状況や制約条件を軽視し、理想を追い求めることによって、作り手と使い手の間に大きなギャップが生じてしまうという事態が、特にトップダウン型で進めるITプロジェクトにおいて発生しやすい。例えば、国内の大企業においては基幹系の業務アプリケーションが1つの設計手法で統一されていることはまれである。会計や人事のような基幹業務にERPを導入したとしても、その周辺には異なるベンダーの業務パッケージや自社開発の業務アプリケーションが配されており、結果として、企業内で用いられているマスタ・データの統一さえままならないというのが現実だ。

　また、EAにより全社の業務プロセスの調査と標準化を行い、上記の4つのステップに沿ってサービスを切り出し、社内の全業務プロセスに対してSOAの導入を試みようとしても、ビジネス環境や技術トレンドの遷移が激しすぎることから、導入を遂げた時点では、サービス化したビジネス・プロセスや採用した技術が現状と合致せずに陳腐化してしまう可能性すらある。

前のページへ < ｜1｜2｜3｜4｜5｜ > 次のページへ