SOAを理解する

はじめに

   本連載は、SOAの概念を活かした柔軟なシステムとはどのようなものかを説明することを目的にしている。

   まずは、柔軟性の高いシステムの条件を説明し、その条件を満たすSOAの技術の列挙をする。その後、SOAにおいて大きな役割を持つESBについて 説明する。そして最後に、柔軟性を表現するBPELおよびSOA技術を用いたシステムのリファレンスアーキテクチャについて説明する。

柔軟性が求められる背景

   まず、はじめにITシステムに柔軟性が必要とされている背景について説明する。昨今のビジネスは複雑化しており、事業の統廃合／事務効率化／アウト ソーシングなどがおこなわれている。しかしこういったビジネスの変化に、システムがうまく対応できていないケースが見受けられる。

   例えば、事業部ごとに請求業務を実施していたが、このプロセスを統合して1つの請求業務に取りまとめる業務統合がなされたとしよう。

図1：請求業務の統合とその限界
（画像をクリックすると別ウィンドウに拡大図を表示します）

   図1はこの業務統合のイメージをあらわしている。このようなバックオフィス統合は事務効率化の上での常套手段だ。しかし、各事業部で取り扱う商材や サービスが異なっているため、システムもそれに特化した形で作られており、前受け金の処理／請求承認のやり方なども部署ごとで異なっている。こうなると、 新しい組織の業務のやり方と異なってしまう。

   例えば効率を高めるために業務を改善しても、システムが対応していなければ、業務のやり方が元に戻ってしまう。これではシステムが足かせになり、業務統合による効率の効果があらわれない。

   このような業務改善が成功するためには、業務を支援するシステムが柔軟に再構成できなければならない。システムを柔軟に再構成するためには、システ ムが疎結合されている必要がある。もしシステムが密結合しているとすれば、再構成のたびに変更が多く発生し、簡単に再構成することができないであろう。

   例えば、図1の請求業務のシステムを再構成した時に、請求業務のシステムが他のシステムと密結合している場合を考えてみる。

   この場合は、3事業部のシステムがすべて違っており、請求統括部では3つのシステムを利用して、納品書、検収書を元に請求をおこすことになる。その 製品やサービスを確認して、部署によって違うシステムを用いるため、画面、入力方法、入力項目、ルールが異なることになり、請求統括部は1つの部署として 統合した意味がなくなるくらい煩雑な業務になり、請求業務を効率化することができない。システムが密結合していると業務改善の足かせになりかねないことに なる。

   このように、密結合ではなく、疎結合をすることがシステムの再構成に対しても重要になる。