【 ここから本文 】
Microsoftウォッチ
ソーシャルブックマークに登録 ：
印刷用ページの表示
【解説】
SOA導入の「阻害要因」とそれを踏まえた「現実解」
課題を解決しうる「設計図の参照」や「ミドルアウト型アプローチ」
（2008年04月28日）
SOAの本質とメリット
ここで、“SOAの本質”とは何であるのかについて、あらためて整理をしておきたい。SOAという概念を定義するなら、一般に、「サービスというソフトウェア部品の組み合わせによりアプリケーション／システムを構築する手法」となろう。しかし、ソフトウェアの部品化という考え方は、これまで構造化プログラミングでのサブルーチン化、共通ライブラリ化やオブジェクト指向の分散オブジェクトのように、SOAという言葉が広まる以前から存在している。
では、SOAにおけるサービスという部品とこれまでの部品とでは何が異なるのか。SOAでのサービスとは単純なプロセス処理ではなく、ビジネス・プロセスを実行するソフトウェア部品であり、かつ複数のアプリケーション間で共用が可能である──この点が従来とは異なっていると考えられる。そして、SOAがもたらすメリットとして、アプリケーション間でビジネス・ロジックを共用化することによって得られるアプリケーションの生産性と柔軟性の向上が挙げられよう。
このように、SOAは今日求められるITシステムを構築するのに有効な方法論であるはずなのだが、なぜ、一向に導入が進まないのであろうか。次節では、その理由を考えてみる。
SOA導入の阻害要因
SOAに基づくシステム構築を検討するにあたり、このアーキテクチャの導入を阻害する要因には、以下のようなものが考えられる。
- 技術／製品におけるベンダー主導のアプローチ
- 利用される技術の標準化に対する遅れとその定義内容のあいまいさによって起きる、バージョン間やベンダー間での不十分な互換性
- 導入実績が少ないことに起因した、品質やパフォーマンスに対する不安
- アプリケーションのサービス化における分析および開発手法の未整備
- ビジネスの視点から見たサービスと、技術の視点から見たサービスでの認識の違い
上記のうち、利用する仕様・規格の標準化の遅れや、SOA関連製品に対する品質・パフォーマンスの不安といった要因は、技術的な阻害要因と言えるものだ。これらについては、Webサービス標準による接続プロトコルや、BPEL（Business Process Execution Language）によるプロセスの表記法、さらに最近ではESB（Enterprise Service Bus）によるサービス間の接続性など、SOAに関する技術の進歩と標準化が進んだ結果、相互接続性が高まり、欧米を中心とした導入実績の増加によるノウハウの蓄積や製品の品質・性能の改善と相まって、しだいに解決に向かっている。
しかし、SOAベースのシステム構築を行う際に、企業内の既存のアプリケーションをどのように分割してサービス化するのかや、ビジネス・プロセスの整合性とアプリケーション構築の柔軟性をどのように協調させるのかといった問題に対しては、いまだに最適な解決方法が示されていないというのが実情だ。
さらに、日本は欧米に比べて業務プロセスが多様かつ複雑であることが多く、企業内での業務プロセスの単純化や標準化が遅れていることによって、サービス化を難しくしていることも要因の1つだろう。これは、日本企業の場合、欧米企業に多く見られるトップダウン型アプローチよりも、現場主導のボトムアップ型アプローチが好まれることや、きめ細かい業務プロセスを構築し、完全に定型化していない業務プロセスが存在しても「あうんの呼吸」と呼ばれるような属人的な調整機能によって実行可能にしてしまう日本人の特性が、かえってSOAの導入の妨げになってしまっていると考えられる。これらの問題は、SOAの導入を検討する際に、サービスの粒度の大小が問題になることが多いことにも表れているように思える。
