SOAへの取り組みに立ちはだかる壁と、打開策

SOAへの取り組みに立ちはだかる壁と、打開策

SOAは、基礎的なサービス部品が現存する前提で効果を発揮するアプローチです。サービス部品の開発そのものは、従来の手組開発に依存せざるを得ないわけで、既存のアプリケーションを抜本的に構造改革するためには、サービス部品の品ぞろえに4～5年以上の歳月が必要です。

このため、SOAは、ごくわずかの先進企業でしか取り組まれていない状況です。しかも、IT主導のクローズドな構造改革であるが故に、ユーザー部門に直接的なメリットを提供できないことも、推進者の悩みでした。また、ビジネス・サービス部品の粒度をあらかじめどの位の大きさに設定すれば再利用性があるかを判断するのも、悩みの種の1つでした。

しかし、2～3年前位から、この状況は一変したように思います。その理由は、大きく3つあります。

1. ERPパッケージ・ベンダーが、アプリケーションのサービス部品をWebサービス・ベースで供給するようになった。
2. SaaSビジネス・モデルが登場し、クラウド・コンピューティング・サービスでサービス部品を利用できる技術環境が整い始めた。
3. SOAベンダーがこぞって、ユーザー部門に直接的なメリットを享受できるBPM（Business Process Management）を、SOAのソリューションとして打ち出した。

1.と2.は、ビジネス・サービス部品の第3者供給ビジネス・モデルが市場に登場したことを表しています。先述した住宅産業の例えの通り、ソフトウエア業界の産業構造も変わりつつあることが予見できます。

BPMとは

筆者が所属する日本BPM協会は、BPMの定義を「組織活動のパフォーマンス・変化対応力・ガバナンスの向上に向けて、ビジネス・プロセスの可視化・実行・改善サイクルを、人・組織とITにより迅速に実現するマネジメントの考え方・領域」と定め、BPMを側面的に支援するツールをBPMS（BPM Suite）と呼び、BPMと区別しています。

BPMを適用する開発アプローチでは、図2の横軸で示すように、組織および機能を横断したビジネス・プロセスの視点で、アプリケーション・システムを構築します。

従来のアプリケーション・システムの多くは、組織別、機能別に開発されてきました。このため、システムは縦軸のサイロ型に分断され、それらのシステムをつなぐのは人間に任されていました。こうした状況の反省から、BPMは生じました。

BPMはこれに加え、「システムは永続的に改善されるもの」という前提に立っています。システムのカット・オーバー後も、事業環境の変化に即してビジネス・プロセス、つまり仕事の進め方、業務ルール、ITの活用範囲を弾力的に変化できるようにします。

人間の作業効率を測定し、ビジネス・プロセスの改善ポイントを発見し、次の改善作業につなげていく、という循環サイクルを持っているのも特徴です。BPMにおける標準的な開発工期は約3カ月と短く、ユーザー部門に対して開発効果を速やかにフィードバックする開発スタイルが望まれます。

BPMがSOAを必要とし、SOAがBPMを必要とする理由

では、このように変化対応力があるシステムを、短期間でどのように構築するのでしょうか。そのアーキテクチャを図3に示します。この図の上段にあるBPM層はビジネス・プロセス・アーキテクチャを示しており、下段のSOA層はサービス・アーキテクチャを示しています。

BPM層では、人と組織の活動と目標成果を達成するプロセスを、プロセス開始イベント単位の小片に分解し、そのプロセスの詳細をワーク・フロー形式で定義し、ビジネス・プロセス層に配置します。

ここで言うワーク・フローとは、従来の承認・決裁フローに適用している狭義のワーク・フロー・システムのことではありません。あるプロセスの開始イベントから終了イベントまでの、エンド・ツー・エンドの"人の作業"と"システムの作業"を、時間的な流れに沿って定義したものです。

画面／帳票は、"人とのインタフェース"と考え（BPMのアカデミックな世界では「ヒューマン・インタラクション: 人の相互作用」と呼ぶ）、人の作業に関連する入出力データ・オブジェクトとみなし、プレゼンテーション層に配置します。

したがって、基本的には「"人の作業"のカウント数＝開発すべき画面数」になります。また、メニューや画面遷移も、基本的には存在しません。

従来の機能別アプリケーション・システムの画面は、あらゆる利用場面を想定して、テンコ盛りの機能設計が行われていました。一方、BPMSでは、"人の作業"の局面ごとに必要な入出力データと確定ボタンを配置した、シンプルな画面設計が行われます。

入出力データを格納するデータベース設計も基本的には必要ありません。入出力データは、プロセス終了時まで、そのプロセスの実行メモリー空間に保持されます。プロセス終了時に、これらの入出力データを、ログとして記録します。こうした仕組みを、BPMS側で装備しています。

"システムの作業"とは、既存のアプリケーション・システムやデータベースとの連携部を指します。既存システムのロジックを経由してデータを出し入れしたり、既存データベースから直接的にデータを出し入れしたりするシステム側の作業になります。

BPMでは、このシステム側の作業詳細をブラック・ボックスとして取り扱い、ブラック・ボックスとやりとりする入出力データの定義にだけ着目します。このブラック・ボックスは、SOAで言うコンポジット・サービスやWebサービスの呼び出し機能に相当し、ビジネス・プロセス・アーキテクチャとサービス・アーキテクチャの接点になります。

このように、サービス・アーキテクチャと疎結合したビジネス・プロセス・アーキテクチャは、組織と人の役割の変化に対して柔軟に対応できる構造になります。しかし、BPMSだけでは、"システムの作業"の変化対応力を担保できません。既存システムとの連携を必要とするBPMは、変化対応力を望む立場から、SOAを必要とするのです。

一方、SOA側から見れば、BPMはサービス部品の消費者である、という見方ができます。既存の基礎サービス部品を素材に、BPMによるサービス部品への要求条件に合致したコンポジット・サービスを素早く組み立てられれば、その都度ユーザー部門に直接的なメリットを提供でき、SOAの導入効果も得やすくなります。

最近では、SOA/BPMあるいはBPM/SOAと併記されることが多くなりました。この背景には、図3に示したアーキテクチャが、BPMとSOA双方の共通認識になったという状況があるでしょう。