レベル: 初級 保坂 大輔, WebSphereテクニカル・セールス, IBM
2009年 6月 03日 本連載ではBPMのアプローチによりお客様の課題をどう解決することができるか、またIBMの提供するBPM製品がどのようにそれを実現するのかを紹介し ます。
今回はITの視点を中心にBPMで何が実現できるかに注目します。
BPMのメリットをITの視点で考える
第1回ではBPMについての一般的な話を、第2回ではビジネス中心の視点でBPMについてIBMのBPMミドルウェア製品WebSphere Dynamic Process Edition(WDPE)をご紹介しながらお話しました。第3回の今回はIT中心の視点で主にシステムの実装の面からBPMを考えます。
ここまで繰り返しご紹介しているBPMライフサイクルでいうと、IT中心の視点とは「実行」に相当します。（図 1）
図 1 BPMライフサイクル - 実行
「設計」を通じて作成したり改善したりしたビジネス・プロセスをITシステムの上で実際に動かすために実装し、それをサーバー上にデプロイ（配置）しプログラムとして実行します。
実行 - サービスとの関連付けとビジネス・プロセスの実行
第1回でご紹介したWDPEに含まれるソフトウェアWebSphere Business Services Fabric(WBSF) をBPMサイクルの「実行」で利用できます。WBSFは実装に使う開発ツールであるWebSphere Integration Developer (WID)とビジネス・プロセスの実行エンジンであるWebSphere Process Server (WPS)を含んでいます。（図 2）
図 2 WebSphere Business Services Fabric
製品名がたくさん出てきて嫌になって読むのをやめようかと思った方、ちょっと待ってください。今回の連載の趣旨は製品の売込みではなく（まぁ、正直それもちょっとはありますが）BPMの実践とはどういうものなのかを理解していただくことです。製品名を覚えていただく必要はありませんし、実践における一例としてIBMのソフトウェアを取り上げているだけです。もちろん他のベンダーのソフトウェアを使っても、あるいはある部分においては使わなくてもBPMは同様に実践できます。製品名の羅列で訳がわからないという説明にはしないつもりですので、投げ出さずもう少しお付き合いください。
WebSphere Integration Developer(WID)をつかった実装
さて話を戻しましょう。第2回の記事ではWebSphere Business Modeler(WB Modeler)というビジネス・モデリング用のツールを使ってビジネス・プロセスを記述するという方法をご紹介しました。WB Modelerは改善した（または改善はせずに現状のビジネス・プロセスを記述しただけかもしれませんが…）ビジネス・プロセスをBPEL1で表現し、そのBPELを含むSCA2モジュールをエクスポートすることができます。ここまでは第2回の記事で紹介しました。
ここからがIT視点で見た実装の話になります。
開発ツールであるWIDはそのSCAモジュールをインポートして自分の環境に取り込むことができます。SCAではサービスがお互いに結合されており、サービス同士がお互いに呼び合って一つのSCAモジュールとして動作します。SCAの世界では全てのものがサービスとして表現されています。BPELは“どの順番でサービスが呼ばれるのか”ということを知っていて実行するサービスの一つですし、第1回で紹介した人の行う作業もサービスです。また、既存システムに存在するアプリケーションが提供する機能もサービスですし（これが一般的にSOAの話で出てくる“サービス”のイメージかもしれませんね）、外部の第3者が公開しているサービスを利用する場合もあるでしょう。
ビジネス・プロセス、つまりBPEL、を含むSCAモジュールは一般的にはBPELのサービスからその他のサービスを色々呼び出しているという形になります。WIDを使った実装では主にこのサービス間の結合を定義して行きます。具体的には、BPELから既存のアプリケーションを呼び出したり、BPELから別のBPEL（サブプロセス）を呼び出したり、といったことを定義していくわけです。（図 3）
図 3 SCAの実装例
このように、WIDを使った実装は従来のアプリケーションのプログラム開発とは少し違っています。WID上のグラフィックで表示されるエディターを使用するため、開発者はプログラムのスキルはあまり必要とされません。サービスを組み合わせるための知識とスキルを持った “サービス統合開発者”のような新しい役割が必要になってきます。
第2回からここまでの記述を読むと、BPELはWB Modelerからエクスポートされたものを使わなければならないように思えるかもしれませんが、そういうわけではありません。WIDはBPELのエディターも提供していますので、BPELを一から作成することも可能です。（図 4）
図 4 BPELの実装例
実際、そうされているお客様もたくさんおられますし、要するにやりたいところだけ、便利なところだけにソフトウェアを利用すればいいわけですね。（ちなみに、例で挙げているSCAとBPELの絵は英語表記になっていますが、もちろん日本語で記述することも可能です。）
WID上では他にも定義することがあります。前回の連載の後半で出てきた、BPMライフサイクルの「監視」についての定義です。「監視」ではビジネス・プロセスのモニタリングをするわけですが、それはシステムから投げられるイベントを収集することにより行われているという話をしました。イベントはこのWID上の定義に基づいてシステムから投げられるわけです。定義自体は簡単で、基本的にはWID上で表示されたBPELの各ステップやサービスにチェックを入れていくだけです。ここでもプログラムは必要ありません。
さて、ここまで読んできて、実際のシステム開発を経験されている方は既存のアプリケーションや外部のシステムとの接続について「サービスを呼び出します」とだけ書かれているのには違和感を覚えるかもしれません。既存のシステムは、自分が呼び出されるためのサービスを提供している、いわゆる“SOA化されたシステム”ばかりではありませんし、たとえそうであってもデータの構造が違ったり、データの記述方法が違ったりするのが普通です。
このシステム間の接続に関する分野は、本連載のような連載記事が他にも一本書けてしまうぐらい深い話なので、今回の連載では深入りはしません。話が広がり過ぎないように、とはいえ気持ち悪さが残らないようにもう少しだけ、本当に少しだけ説明することにします。
SOAではエンタープライズ・サービス・バス（Enterprise Service Bus; ESB）というデータの通り道を介して色々なシステムがやり取りをします。またはアダプターというプログラムを介してデータのやり取りをします。ESBはネットワークのハブをイメージすると、アダプターは海外旅行で使う電源の変圧器なんかをイメージすると感覚的に理解できるかと思います。要するに間に何かをかまして、そこが通訳をしてくれるわけですね。
はい、どうですか？まだ何となく気持ち悪いですよね？しかし、この連載ではこの程度で我慢して「まあ、なんか繋がるんだな」「それはそれで色んな技術があるんだな」という曖昧な理解でここは通り過ぎてください。
WebSphere Process Server（WPS）上での実行
さて、実装が終了したら、次はそのモジュールを実行環境上で動かさなければなりません。
WID上で構成されたSCAモジュールはJavaのモジュールとしてEAR（Enterprise Archive）ファイルの形でエクスポートされ、実行エンジンであるWPS上にデプロイされます。
デプロイされ、実行されているモジュールはJavaですから、ここだけ見るとBPELでビジネス・プロセスを定義したかどうかは関係ないし、BPELを使わなくてもJavaでサービスを呼び出すコードを書いてもいいように思えるかもしれません。ただし、思い出していただきたいのは、ここで動いているビジネス・プロセスはBPMサイクルの「設計」でビジネス的な観点で作成されたもの（繰り返しになりますが、ビジネス・プロセスはWB Modelerでビジネス・プロセス・モデルとして作っても、今回の記事でご紹介したWIDでいきなりBPELとして作っても構いません）がそのまま動いているということです。もしビジネス・プロセスに変更があった場合、BPELの修正をすればプログラミング不要で素早くその変更を実行環境に反映させることができます。一般的にはJavaのコードをいじるより直感的、かつ手軽に修正が行えるわけです。
実行 - ビジネス・サービス
ここまでご紹介したようなWPS上でのビジネス・プロセスの実行は世界中の多くのお客様において現実に実践されています。みなさんが何の問題もなく実践されていればいいのですが、世の中、なかなかそうはいきません。運用していくうちに主に以下のような課題が発生し、報告されることが多くなっています。
1. BPELが複雑化する
2. BPELの数が増えていく
3. BPEL上にハードコードされている部分の変更が大変
以下に一つずつもう少し詳しく見ていきましょう。
1. BPELが複雑化する
この連載ではBPMサイクルの「設計」で ビジネス・プロセスの分析をして文章化し、それをBPELとしてITに引き渡すという流れを紹介してきました。ところが、こういうことを言うのもなんですが、実際には物事はそう簡単ではないのです。多くの企業では部門ごと、業務ごと、地域ごとにシステムが構成されており同じような機能を持つアプリケーションが存在しています。このような場合、BPELからあるアプリケーションのサービスを呼び出す時に適切なアプリケーションの呼び出しになるよう分岐を追加しなくてはならず、BPELの修正が発生します。
例えば、損害保険会社が火災保険と自動車保険のシステムを別々に持っている場合、そのアプリケーションを呼び出す時に保険種目による条件分岐を作って、それぞれのサービスを呼び出すようにBPELを書かなくてはなりません。つまり、「設計」で作ったビジネス・プロセスに対して、「実行」で出てきたIT視点の要件から変更を加えるということになります。
このようなことが発生するのは、システムが複数ある場合ばかりではありません。ビジネス要件に基づいてサービスを呼び分けなければならないケースでは常に同様の変更が必要になります。例えば、あるビジネス・プロセスの一部が違う場合、そこをサブプロセスとして切り分けて条件によって呼び分けるということがあります。「金額によって査定が1段階か2段階か違う」「ある地域への販売には自治体への許可が必要」などの要件です。このような場合にも、やはり条件分岐を作成して異なるサブプロセスを呼び分けるということになるのです。
以上のような理由によってBPELに条件分岐が増えれば増えるほどBPELは複雑になっていきます。「M&Aにより新たに加わった会社のシステムも呼び分ける必要ができた」「新しい法律による規制に対応しなければならない」などの変更要件により、その複雑なBPELをさらに修正しなければならず、以降の修正はどんどん複雑化し、難しくなっていきます。
2. BPELの数が増えていく
ビジネス・プロセスを分析すると「業務や地域は違っているが、実は同じようなビジネス・プロセスだった」ということがよくあります。同じようなビジネス・プロセスなので一つにまとめられるかというと、そうではありません。呼び出すシステムが違うため別のBPELとして定義しなければならず、結果的にBPELの数が増えていってしまうのです。例えば、ある小売業の会社が社内共通の流通ビジネス・プロセスを持っているとしましょう。BPELを一つ定義すれば済むように思えますが、実際のシステムでは、地域によって倉庫を管理している会社が違うため呼び出すサービスも違う、ということがあります。分岐によって対応すると前述の複雑なBPELになるので、それを避けるため、地域によってBPELを定義すると同じようなBPELを複数定義していくことになってしまいます。この会社が日本だけでなく海外にも進出した場合、BPELはさらに増えていきます。ビジネス・プロセスとしてやっていることはほとんど同じにもかかわらず、です。
BPELの数が増えるとBPELが複雑になる時と同様にBPELの維持コストは増えていきます。将来、何かビジネス・プロセスの改善が必要になったとしたら、どのBPELをいつ変更すればいいのでしょうか？一斉に変更するのか、それともある地域に関しては変更しなくてはいいのか。あるいは新しいBPELを追加するのか。いずれにせよ、時間の経過と共に管理すべきBPELの数は増えてゆき、当初想定していたよりもコストのかかるBPMのシステムになってしまいます。
3. BPEL上にハードコードされている部分の変更が大変
最初に作ったBPELをそのままずっと使っていくということはまれです。それはそうですね、ビジネス・プロセスを改善していけば変更が入るのは当然の流れと言えます。前述の「BPELが複雑化する」「BPELの数が増えていく」という場合もそうですが、他にも「現在は人間がやっている処理を将来的には自動化したい（つまり現在は人間が行うサービスに結合しているが、将来は新しい自動処理アプリケーションのサービスに結合したい）」とか「レガシー・システムで行っている処理をオープン・システムに移行していきたい」などの変更が考えられます。
変更に対応する手順としては「BPELの変更」→「実行環境へのデプロイ」ということになります。こういう変更は業務部門から見ると“ちょっとした変更“であっても、IT部門からすると”新規プロジェクト“です。それなりのコストとリスクを見積もって、変更を反映させることになります。業務部門からすると「なんでこれだけの修正でそんなに時間とお金がかかるの？」という不満になりますし、IT部門からすると「こっちの負荷はいっぱいいっぱいなのに、また五月雨的に変更依頼をしてくるよ」という不満になります。こうして現場からの新規の要件がバックログとして溜まっていくわけです。
変更が容易ではないということになってしまうと、せっかくビジネス・プロセスを改善するという目標を持って始めたBPMもITが足かせになってしまい、思うように実践できないということになってしまいます。
ビジネス・サービスという概念の導入
これらの問題に対処するため、IBMはビジネス・サービスという概念を提唱しており、それを開発、実行するためのプラットフォームが冒頭でご紹介したWIDとWPSを含む製品WBSFです。（図 2）
ビジネス・サービスとは一言で言うとビジネスの観点から見たサービスです。
まあ、これだけではわかりませんよね。ここでも具体例を使って説明しましょう。例えば、とある製造業の会社が「納期回答ビジネス・プロセス」をシステム上で動かしており、そのプロセスの１ステップとして「納期問合せ」というタスクがあるとしましょう。「納期問合せ」タスクはプロセスから入力された情報を元にその製品/部品の納期を返すサービスを呼び出しますが、そのサービスは一つではありません。製品/部品によって、あるいは地域や事業部などによって、呼び出し先となる複数のサービスが存在しています。ある部品に関しては在庫量から判断して納期を返す“システムA”に問い合わせなければなりませんし、地域によっては人間が電話によって確認し納期を返したり、あるいはルール・エンジンが導入されて納期を返したりする製品があったりします。これを条件分岐の挿入や部品ごとのBPELの定義などで対処していては前述の問題が発生してしまいます。
そこで登場するのがビジネス・サービスの概念です。このケースをよく考えてみると「納期回答ビジネス・プロセス」からすれば、あるいは言い方を変えるとビジネスの観点からすれば、「納期問合せ」サービスは納期を返すということが重要であって、それを提供しているのがなんであるかはその次の話です。「納期問合せ」をビジネスの観点からみたのが「納期問合せ」ビジネス・サービスです。実際にどのサービスが呼ばれるのかということは「納期問合せ」ビジネス・サービスを呼び出した後でWBSFがレポジトリーに定義された条件を見て適切に判断します。（図 5）
図 5 ビジネス・サービスの例
拡大図
こうすれば元々のビジネス・プロセスに詳細なビジネス・ロジックを記述する必要はないため、BPELがシンプルになり、似たようなBPELを大量に書く必要がなくなります。（図 6）同時に、ビジネス・ロジックがレポジトリーに一元管理されるため、複数のBPELに散在しているよりもより管理しやすくなります。
図 6 ビジネス・サービスによるBPELの簡素化
拡大図
つまり、ビジネス・サービスという概念の導入は言い方を変えると、BPEL上にハードコードされたビジネス・ロジックをレポジトリーに集約することだということができます。前述の具体例で言うと、「○月○日までは人間が処理するサービスを呼び出す」「○月○日からは自動化したサービスを呼び出す」というロジックをレポジトリーに定義しておくことで、BPELの変更や実行環境へのデプロイを必要とせず、○月○日にサービスの呼び出し先が自動的に変更されます。また、このレポジトリーにある定義を変更すれば、BPELの呼び出し先を動的に変更することができるため、BPELを作成した後に出てきた変更要件を柔軟かつ素早く取り入れることができます。人間は将来を正確に予測できるわけではないため、あらかじめ変更を組み入れるということには限界がありますが、このような仕組みを活用すれば、予期しない変更に効果的に対応することができます。
ビジネス・サービスという概念はまだ新しくWBSFという製品も市場に出てからそれほど時間が経っているわけではありませんが、いち早く導入されているお客様の環境では、“新規ビジネスへの対応が1/2～1/3になった”、“プロジェクトのコストが30%減った”、“IT資産の再利用率が40～70%になった”などという成果が出ています。将来の変更が多いと予想されるシステムにおいてはビジネス・サービスという概念を活用することは有意義だと思われます。
まとめ
今回の記事では主にIT中心の視点から話をしました。IT面の説明であったため前回よりも製品に沿った説明になりましたが、前回と合わせて、これでBPMライフサイクルをぐるっと一回りして、どのようにBPMが実践され、どのようにITがそれをサポートするのかというイメージを持っていただけたかと思います。
次回はいよいよこの連載の最終回です。BPMの現状やBPMプロジェクトを成功するためのポイント、または連載を通じてご紹介しているようなミドルウェアをどのような場合に利用すればいいのか、ということについて考えます。
注釈
1第1回の記事、注釈を参照
2第2回の記事、注釈を参照
参考文献
著者について  | | | IBMソフトウェア事業WebSphereブランドに所属するテクニカル・セールスです。BPM関連製品を担当しており、主にお客様への提案活動やセミナー等での講演を行っています。 |
記事の評価
| 
