　こうしたSOAの設計原則にのっとって考えれば、サービス（アプリケーション）の開発は、あくまでコンポーネントに過ぎないと言うことができる。コンポーネント化を進めることにより、アプリケーションの再利用性を高め、部分的にシステムを変更することができるというメリットは当然あるが、それだけでは、従来のコンポーネント化とさほど変わるものではない。

　重要なのは、開発されたサービスを「組み合わせ」、新たな業務アプリケーションを構築することである。すなわち、各サービスを必要に応じて連携させ、ビジネスプロセスに従ってコントロールする仕組みこそがSOA の有用性を高める大きなポイントとなる。これを実現するミドルウェアとして昨今、注目を集めているのが、ESB（エンタープライズサービスバス）とBPM（ビジネスプロセス管理）である。

　ESBは、SOAで設計されたサービスどうしの連携を仲介する伝送路のようなものであり、SOA環境を実現するための基盤となるものである。また、BPMは、連携させたサービスをあらかじめ定義した実際の業務プロセスに従って呼び出し、その実行を自動化するものである。具体的には、GUI（グラフィカルユーザーインタフェース）ツールを用いて、複数のアプリケーションにまたがるプロセスをフローチャートを作成するようにグラフィカルに定義し、さらに定義したプロセスが適切に実行されているかの管理機能も備えているのが一般的である。

　ちなみに、BPM自体は必ずしもSOAの環境においてのみ適用可能な技術ではない。これまで、アプリケーション統合のミドルウェアとして利用されてきたハブ＆スポーク型のEAI（企業アプリケーション統合）技術と組み合わせて使うことももちろん可能である。しかし、以下に述べる特徴ゆえ、SOAとの親和性が非常に高い。

　その特徴とは、業務プロセスをルールという形で定義し、ルールエンジンで実行するといったように、アプリケーションの外側に置く点である。

　これは従来、IT部門でしかコントロールできなかったビジネスルールを、ビジネスユーザー側でも変更できるようになったことを意味し、SOAの考え方にマッチする。先に述べたように、SOAはビジネスプロセス単位のサービスを実装するものであり、BPMを用いることでSOAを効果的かつ効率的に実現できるということになる。

ビジネス視点から考えることの重要性

　以上が、SOAの概略であるが、これを効果的に導入するためのポイントをあげておくことにする。

　実際のところ、一般的にみられるSOAの導入プロセスには、いくつかの段階がある（図3参照）。サービス（アプリケーション）をコンポーネントとして設計、開発し、実装を行うことを第1段階とすると、ESB、BPMによって各サービスを連携させるのが第2段階である。現在、最も多くみられるのは、これら第1段階に加え、第2段階の導入を検討するというものである。

　しかし、SOAがもたらす価値をさらに高めるには、さらに高次な第3 段階が存在する。それは、SOAを単なるシステム上のツールとして導入するのではなく、ビジネスプロセスのモデリングを行い、システムの実行状況のモニタリングからPDCA（Plan―Do―Check―Action）サイクルを改善に役立てていくことである。

　このモデリング作業では、ビジネスプロセスにおける業務イベントを抽出し、内容を明確にすると同時に、具体的な業務の処理手順や各プロセスの所要コスト、所要時間などについて、あるべき姿を描く。このため、モデリング作業はIT部門ではなく、実際の業務に精通しているビジネス部門が行うのが望ましい。モデリングを行った後に、前述したBPMツールなどを用いて実際の現場へ適用しBPMを実行していくことになるが、実行状況を継続的にモニタリングし、そのパフォーマンスを分析していくことになる。これにより、ボトルネックを発見し、改善策を検討することができるというわけである。

　当たり前のことであるが、ITシステムは事業を効率的に運営していくためのツールに過ぎない。したがって、最初にITシステムありきで考えるのではなく、ビジネス視点から考えることが重要である。システム構築の原点に立ち返り、上流から体系化していくことが必要である。こうしたことを考えれば、いきなりIT部門によるアプリケーション開発から始めるのではなく、「何のためのITか」をよく考え、「ビジネス視点発」を前提とし、ビジネスプロセスのモデリングからSOA導入を開始することが望ましいと言えよう。