【第1回】システムに事業視点の考えを付加するSOAの効用

現在、システム構築／改変の重要なキーワードとなっている「SOA」。だが、「ウチもSOAを使ってシステムを構築しよう」と意気込んだものの、ふたを開けてみると「対象となる製品が大規模すぎて合わなかった」「費用がかかりすぎるので断念した」という声を聞くのも実情だ。業務に即し、かつ柔軟で拡張性の高いシステムを構築できるはずのSOAは、本当に大規模システムだけのものなのか？　本連載では、SOAについての基礎、導入プロセスの注意点、実際の採用例などを見ながら、そうした疑問を紐解いていく。

SOAとはどのようなものか？

　まず、そもそものSOAとはどのようなものかを見ていくことにしよう。SOAとは、Service-Oriented Architectureの略称で、端的に言えばサービスの集合体としてシステムを捉えて、設計・構築する手法と定義されている。SOAでは、システム間の相互通信方法に関する標準が定義されており、この標準インターフェースを通じて各システムが通信する。これにより、複雑かつ多様なIT環境や個々のアプリケーションごとの違いを意識する必要をなくし、目的とする業務のプロセスを“サービス”として組み合わせていくというシステム設計・構築の手法となる。

　これまでのアプリケーション間の連携には、EAI（Enterprise Application Integration）を用いるかカスタム開発を行って対処する手法が取られていた。旧来のEAIを利用する場合には機能が単純で柔軟性に欠けるという欠点があり、一方、カスタム開発の場合には、ベンダー依存や高コストになるという欠点があった。

　また、SOAでは、オブジェクトやコンポーネントよりも機能粒度が高いモジュールをサービスとして扱うことで経営層にもシステムがわかりやすくなるというメリットがある。「信用照会」「注文処理」「在庫確認」といった大きな単位のビジネスプロセスを接続してシステムを構築する手法となるからだ。こうしたビジネスプロセスの結合の方法としては、ESB（Enterprise Service Bus）と呼ばれるインフラを導入してサービスの定型の結合を定義する方法や、より複雑なプロセスでも対応可能なBPEL（Business Process Execution Language）に代表されるプロセス定義のテクノロジーを利用する方法がある。

“プチSOA”によって手軽に効果を出す

　SOAといえば、とかく大企業向けの大掛かりなプロジェクトで、サービス粒度を十分に検討し、システムを再構築することのように思われるかもしれない。もちろん、最終的にSOAが目指すところは、企業にとって最適なサービス化が行われ、それらの組み合わせで新しいプロセスを構築できるようになることである。だが、SOAが適用できる範囲には、そうした高度なものだけでなく、もっとお手軽なものまで、幅広いレンジがある。ニーズとしては、EA(Enterprise Architecture)による基盤整備という大きな目標がある一方で、マスターデータベースの整備や統合、データの連携などの、より具体的なゴールを、アダプタという既存のサービスを利用することで実感していく“プチSOA”と呼べる身近な利用例もある。

　例えば、ある製薬の卸会社では、マスターデータベースの自動更新にSOAを適用したことで、それまでは難しかったリアルタイムでの更新を実現し、問題となっていた人的ミスを削減した。加えて、システムやワークフローの変更が容易化でき、さまざまなシステムとの連携が可能になったという効果が現れたという。

　また、ある企業の業務システムは、売上時の顧客マスターデータベースと請求時の顧客マスターデータベースが異なるものを使っていたために、請求ミスが会計ミスへとつながり、追徴課税を課されたケースがあった。この問題を解決するために、SOAを適用してマスターデータベースの自動更新を導入した。結果、データの型変換なども自動化したことによって、マスターデータベースの不整合や漏れをなくした。さらに、ワークフローによる承認プロセスを取り入れほか、通知や例外処理もSOAでサポートすることによって、人的なミスを削減し、信頼できる会計処理が可能になったという。

　このように、トップダウンだけではなく、ボトムアップ型のプチSOAからスタートしていくやり方は、現在のデータ処理やプロセス処理における課題を解決するという具体的な例からSOAの効果を計ることができ、将来的なプロセス間連携や統合に向けた準備を進める目的においても、有効な手段だと考えられているのだ。