アーカイブ

Archive for 2008年5月

WfMCがXPDL 2.1仕様を正式公開

2008年5月26日 コメントをどうぞ

WfMCは本年4月23日にXPDL 2.1の採択を完了し、仕様を正式公開した。

XPDL2.1は、ベンダの製品対応が進んでいる現XPDL2.0に対し大幅な変更はなく、サポート対象プロセスモデル表記をBPMN1.0から最新のBPMN1.1に変更し、これまでの仕様書で曖昧であったBPMNとXPDLのマッピング仕様を例示を交えながら詳細にガイドしている。

昨年、BPMNおよびXPDL2.0をサポートするベンダの相互運用性検証を(私も参加)実施した結果、仕様書記述の曖昧性によるミスマッチがベンダ間で多く見られたことが今回の改定の発端である。改訂仕様書では、多くのBPMNプロセスパターンとXMLマッピングサンプルが盛り込まれ仕様書読者のミスリードを排除するよう再編集されており、目を通すとXPDLの仕様書でありながらBPMNの仕様書でもあるような錯覚に陥る。また、アクティビティコスト、所要時間、待ち時間、割り当てリソースなどプロセスシュミレーションのパラメータもプロパティとして追加され、プロセス分析・設計レベルでのプロセスモデル交換の実用性を強く意識している。

今回の改定では、WfMCは「XPDL2.1がBPMNの実用的メタモデル」と主張し、OMGが標準化を進めているBPDM (Business Process Definition Metamodel)を牽制しているように感じる。WfMCはのBPMN対応のXPDL標準化に「2.0仕様公開→ベンダ実装→実証実験→2.1仕様改訂」のプロセスを経て、おおよそ3年の歳月を費やしおり、現在のところ、「ベンダ間のプロセスモデル相互運用性の領域」ではOMGを1歩も2歩もリードしていると言える。

BPDMのOMG標準化作業は現在、BPMNの表記メタモデルを望むビジネスアナリストグループとBPMNの表記メタモデルではなく、むしろBPELの上位に位置するプロセス抽象化言語を望むBEA-IBM-Oracle-SAP連合の2派に分かれて綱引きしているらしい。 ITソフトウエアベンダグループは「ユーザ企業が望むベンダに依存しないプロセスモデルの可搬性」について、毛頭考えていないらしく、誠に残念なことである。このような状況では、BPDMを使って「ベンダ間のプロセスモデル相互運用性」を実用化できるのは早くて4年先と予想される。ただし、OMGが過去に標準化したデータウェアハウス向けのメタモデル:CWM(Common Warehouse Metamodel) と同様に多くのベンダ支持が得られないケースも十分に考えられ、XPDLへの期待が増すばかりだ。

広告

BPMNプロセスモデルのデータ交換Hub ソフトウエアの登場

2008年5月23日 コメントをどうぞ

ビジネスプロセスモデル交換ツールの専門ソフトウエアベンダであるドイツのTransWare社は、今年4月に”BPMNプロセスモデルの交換Hub”を発表した。同製品はベンダごとに異なるさまざまな表記のビジネスプロセスモデルをWfMCが標準化したXPDL 2.0 (ビジネスプロセスモデル交換フォーマット)に変換しBPMN準拠のワークフローエンジンで再利用可能にするものだ。この動きは既存のプロセスモデル資産をBPMで再利用したいユーザニーズに応えるもので、大いに期待したい。

同社は、ARISのEPC図をMS Visioに変換しVisioを使ってEPC図を設計できる製品群を持っており、EPC to BPMNの変換ツールもここ1年以内に登場するだろう。また、”Moving from Yesterday to Tomorrow: connecting different Business Procee Modeling Platforms and Methodologies”という表題のWhite Paperを発表しており、異色のソフトウエアベンダである。

BPMN-to-BPELにおける課題:最終回

2008年5月22日 コメントをどうぞ

今回はお約束通りBPMN-to-BPELの問題をふまえてどうすべきかという話をします。でもその前に、Bruce Silver氏のブログ “BPMS Watch Rating” の内容についてふれておきたいと思います。そこではいくつかのベンダのBPMスィートを3つの視点でランキングしいますが、その内容が “どうすべきか” に関係すると思うからです。

3つの視点とは、対象とするプロセスのタイプを次のように区別したものです。

① Integration-Centric Processes

② Human-Centric Processes (Production Workflow)

③ Human-Centric Processes (Case Management)

主にITシステムとITシステムをつなぐプロセスがIntegretion-Centricで、主に人と人をつなぐプロセスがHuman-Centricです。そして、Human-Centric のうち、定型プロセスであり業務フローで管理するのがProduction Workflowで、非定型プロセスでありケースフォルダで管理するのがCase Managementになります。

なお、ケースフォルダとは、その中にあるデータやドキュメントをみんなで登録/参照/更新したりするものです。ブレーンストーミングでやるべき仕事を洗い出して担当者を割り当てて進捗を管理するというようなことにもそのフォルダを利用します。

BPMS Watch Ratingを見ると、各ベンダのBPMスィートでは得手/不得手とするプロセスがあることがわかります。①のタイプのプロセスではOracleといったBPELエンジンが評価されています。メッセージルーティングやフォーマット変換などのESB機能やERPなど様々なシステムをつなぐアダプタが充実しているからです。②のタイプのプロセスではLombardiなどのBPMNをBPELに変換せずに実行するエンジンが評価されています。フォームやスクリーンフローなどのユーザインターフェースや動的な作業の再割り当てなどのアサイン管理機能が充実しているからです。

(③はBPMNで可視化したフローを実行するという類いのものではないので、この話題の対象からはずれます。)

ここから “どうすべきか” という本題に…。

まずは②のようなプロセスの場合、Keith Swenson氏がブログでBPMN-to-BPELには問題があるのでBPELに変換せずにBPMNを直接実行するエンジンを選ぶべきといっていますが、その通りだと思います。

(※ただし、問題を解決するためというより、BPMS WatchRatingが示すことから必然的にそうなるというべきでしょう。)

しかしながら、①のようなプロセスの場合、Keith Swenson氏の意見に対してBruce Silver氏がブログでそれが理想だが現実的ではないといっているように、 BPELエンジンを利用すべき状況にもなります。

実際には、ビジネスプロセスをモデル化してきた経験から、人と人が書類や電話でやり取りした結果をいくつかのITシステムが連携しながら処理するというような、①+②パターンが多いと思います。

(※余談ですが、人と人のやり取りについてはITシステムを利用せずにその結果を登録するところからITシステムの利用が始まるという形態が、従来は多かったためか、そのようなプロセスであってもITシステムの連携しか考えないことが多いと思います。でも、BPMでは人的パフォーマンス管理も重要なので人と人のやり取りもITシステムを利用して管理します。)

そのような点を考えると、下の図が典型的な姿になります。 Human-Centric系エンジンで人と人のやり取りを管理しつつ、ITシステムとの連携はIntegration-Centric系エンジンに任せる形態です。

BPMN-to-BPMS

そこで、まずはITへの実装を意識せずにBPMNモデルを描くことから始めるというやり方をお勧めします。ビジネスの視点で可視化するという本来の目的からも当然なのですが、モデルで可視化して初めて最適なBPMSが選択できるという理由からでもあります。

さらに、そのためのBPMNモデリングツールについては、次の2つの機能について実用性を評価して最適なツールを選択することをお勧めします。

1. BPMNモデルを様々なBPMSに渡す機能(モデル連携機能)

BPMSは、BPELやXPDLといった標準XML形式でインポートする機能を持っています(全くインポート機能がないのもありますが…)。BPMNモデリングツールでもそれらの標準をエクスポートする機能があればBPMSに渡すことができます( ITP Process Modeler は、BPEL、XPDL、XLANGに対応しています)。

ただし、特にBPELの場合には、BPMN⇒BPELという難しい変換にどこまで対応しているか、BPELに変換できないBPMNモデルを描かないように誘導する機能があるか(ITP Process Modelerでは、To-Doリストでどこをどう直せばBPELに変換できるモデルになるか確認できるようにしています)などをしっかりと評価しておく必要があります。

2. “the problems of round-tripping” を解決する機能

やはり、BPMの改善サイクルではこの問題は無視できません。BPELをBPMNに逆変換(BPMN属性も含めて完全に)できるツールは無いとは思いますが、少なくともその代替機能が必要です。 ITP Process Modeler では、BPEL、XPDL、 XLANGをそのままXML形式でインポートし、タグのまとまりとしてBPMNの各図形にマッピングする機能で解決を図っています。

将来、Bruce Silver氏のブログ “Bashin the Stackers” に登場する一文 “But if IBM, SAP, and Oracle (with BEA) succeed in their BPMN 2.0 proposal, we’ll see BPMN-direct executable design from
all of the Stackers in a year or two.” の通りになることを期待しています。IBM、SAP、OracleもBPMNを直接実行するエンジンを提供する理想的な姿です。そこでは少なくとも ”the problems of round-tripping” はなくなっているはずです。さらに各ベンダの製品間でBPMNモデルの交換が自由自在になっていれば、なおうれしい…。

そして、そんな理想が現実になったとしても、モデル連携機能を重視しているBPMNモデリングツールで可視化しておけばOKです。

2008年春、BPMへの関心がSOAを超した

2008年5月9日 コメントをどうぞ

私は時々、市場の関心を測る目的でグーグルを使ってキーワードのヒットページ数を調べている。

今日調べたところ、驚いたことにBPMのページ数がSOAを上回っていた。


Google日本語ページ数(2008年5月9日現在)

キーワード=
BPM: 684,000件

キーワード=
SOA: 527,000件

これまでBPMページ数はSOAを上回ることはなかったが時間の経過とともにSOAページ数に肉薄しつつあった。いつか逆転する日が来ると考えていたが、その時期は意外に早く訪れた。

IT業界の方々との意見交換でも「今年に入ってからBPMに関する問い合わせが多くなった」と皆さん口を合わせたようにおっしゃる。日本BPM協会でもインターネットアクセス数が4月に入ってから急上昇しているという。

この傾向は、SOAベンダはユーザ企業への訴求力向上のため、キーワードをSOAからBPMに移していること、さらにJ-SOX対応の「プロセス文書化」段階から次の「プロセス自動化」段階にユーザ企業の関心が移りつつあることがが発端のようだ。

海外市場では2年前から同様に情報発信キーワードがSOAからBPMに移行されていたと聞く。このことから日本はやっと2年前の米市場に近い状況になったということか?

カテゴリー:BPM

SAP、初のBPM製品「SAP NetWeaver BPM」でBPMNをサポート表明

2008年5月7日 コメントをどうぞ

BEA AuaLogic BPMがBPMNをサポートのニュースに引き続き、SAPも5月6日に「SAP NetWeaver BPM」でBPMNをサポート表明した(@ITニュース)。

残る関心事は、IBMがいつBPMNをサポートするかであろう。IBMが買収したFileNetは以前からBPMNをサポートしており、FileNetとWebSphereのモデリング環境統合がどのように行われるか見ものだ。

BPMN-to-BPELにおける課題:第2回

2008年5月2日 コメントをどうぞ

前回はBPMNからBPELを生成するために複雑な変換が必要になるという話をしました。複雑でもツールが自動で変換してくれるから良いのでは?と思われるかもしれませんが、やはりそこには問題が潜んでいます。それは前回紹介したブログで登場する”the problems of round-tripping” という言葉が示すもので、BPELで手を加えた内容をBPMNに戻すことができないという問題です。

BPMは継続的な改善サイクルを廻すので、BPMN→BPEL→BPMN→BPELというサイクルも廻さなければいけません。もしBPELに手を加えたのならば、その内容をBPMNに戻してからビジネスプロセスを改善する必要があります。BPMNからBPELという複雑な変換の逆変換も当然複雑になると思いますが、BPMNの仕様書ではBPMNからBPELへの筋道を示していますが、その逆の筋道は示していません。

サイクルが効率良く廻らないことが問題になってしまいます。

ところで、そもそもBPELに変換した後に手を加える必要があるのでしょうか?

次にその点について…。

BPMNの仕様書では、タスクのAssigmnets属性やWebService属性など、BPELの生成に必要な詳細情報までをBPMN属性として規定しています。例えば、BPELの中でXPATH式を使用する場合にはBPMN属性に記述します。それら属性をしっかりと定義すれば基本的には即実行できるBPELをBPMNから生成することができます(※図形の形状はBPMN、でもBPMN属性は持たないというツールが多いので、その存在に気づいていない方も多いのでは…)。しかも、BPELの<pick>はBPMNではイベント準拠ゲートウェイ、<compensate>は補償イベントというように、少し複雑な振る舞いであってもBPELで表せるものは基本的には全てBPMNで記述することができます。つまり、基本的にはBPMNをBPELに変換した後にBPELに手を加える必要はない、BPELをBPMNに戻す必要もないということになります。

しかしながら、あくまでも “基本的には” であって、実際にはBPELエンジンを提供するベンダ固有のBPEL拡張についても考える必要があります。拡張を考慮するとBPELエンジン側で手を加えるのは必然のことになります。

さらなる問題を、Keith Swenson氏がブログで “The additional non-executable information (graphics, etc) asuseful in order to display the running process to a user.” と表しています。 BPMNからBPELに変換する際にBPELの実行には関連しないが有益とされる情報が欠落してしまうという問題です。

例えば、BPMNのレーンは対応するBPELがないので変換されません。折角、ビジネスプロセス図でレーンを使って作業の実行者(役割)を明示してもBPELには引き継がれず、BPELが呼び出す「人の作業を管理するWebサービス」などで同じことを設定し直す必要があります。

その他にもメッセージフロー、注釈、グループというビジネスプロセス図を分かりやすく飾る図形も一切変換されません。BPMNで分かりやすい図を描いても、BPMスィートのスクリーンフロー(※ビジネスプロセス図上で作業の進捗などをビジュアルに確認する画面)では分かりやすさが半減してしまいます。

BPMNではアドホックサブプロセスやシグナルイベントなど、BPELでは実現できない振る舞いが描けるが…、という問題まであります。

BPMNからBPELに変換すると情報が欠落するのならば、なおさらBPELをBPMNに戻すということが難しくなるともいえます。

その他にも、ビジネスプロセス図(BPMN)の実行が失敗した際にどこを直せば良いのかをプロセスエンジンが指摘できないなど、いくかの問題が語られています。

Bruce Silver氏がブログでBPELのことを “a poor runtime partner for BPMN” と呼ぶことに思わず肯いてしまいます。

次回は、このような問題をふまえてどうすべきか、という最も大切なことを話したいと思います。

(つづく)

BEA AuaLogic BPMがBPMNをサポート

2008年5月1日 コメントをどうぞ

BEAはやっとビジネスプロセスモデルの表記を独自のものからBPMNに切り替えるようだ。

これまでの独自表記とBPMN表記の比較は次のページを参照。

http://www.brsilver.com/wordpress/2008/04/28/bea-edging-toward-bpmn/

ユーザはBPMNに移行しやすいよう同じモデリングツールで二つの表記を選択できるらしい。

オラクルのBEA買収により、Human-Centric(人間系)に強い「AquaLogicBPM」とOracleのIntegration-Centric(SOA統合基盤)である「Oracle SOA Suite」が統合され、BPMNが双方のモデリング表記になるもの時間の問題だろう。