BPMN 2.0の将来に関する議論が続いている(参考記事・英語)。(BPMNやその他のBPMに関する標準化の責任を負う)OMGのBMIタスク・フォースの副委員長であるFred Cummins氏は、BPMNとBPDMの違いの解消とBPDMの複雑さに関する問題に焦点を当てた最近のBPMNに関連する提案について語った。
BPDMはOMGで開発中のビジネス・モデリング言語スイーツに含まれています。例えば、SBVR(Semantics of Business Vocabulary and Rules)はビジネス上の概念の意味を定義したり、それらに含まれるビジネス・ルールをモデリングするのに役立ちます。BMM(Business Motivation Model)は事業計画モデルをとらえるためのフレームワークを提供します。OMGのBusiness Modeling and Integration(ビジネス・モデリングと統合)タスク・フォースの重要な目的はより効率的な事業計画立案、分析、設計、そして実装を補完するのために協調動作するビジネス・モデリング標準を開発することです。結果として、BPDMはBPMNのモデリング概念をサポートする強固な抽象メタモデルを持っています。抽象メタモデルは基本的な概念を定義していて、それらは様々なビジネス・モデルの多様な状況で登場してくるものです。
BPDMにおいて、特定のモデリング・ツールを意識することなくビジネス・プロセスをモデリング可能なように、このような概念は安定した基盤を提供する。最初にFred氏は以下のように述べている。
BPDMのメタモデルは複雑に見えるかも知れません。しかし、その複雑さが具体的な要素を定義するときに正確性をもたらすということを理解して下さい。この抽象的な概念はBPMNに新たな図として追加される訳ではなく、XMLの新たな要素として追加される訳でもありません。要するに、BPDMメタモデルの見掛け上の複雑さによってその仕様はより正確かつ強固なものになり、安定した開発をサポートし、将来起こりうるビジネス・モデリングも補完することができるのです。その複雑さがユーザにとってビジネス・プロセス・モデリングを複雑にすることも、開発ツールのベンダーに何らの制約を与える訳でもないのです。
Fred氏への返信としてBruce Silver氏は次のように述べている(リンク)。
メタモデルの複雑さは私のBPDMに対する不満のトップに位置する訳ではありません。もっと問題なのは表記法(BPMN)がメタモデルに従属的であるという点です。そしてそのことによって、ユーザ独自の意味定義は基礎をなすメタモデルで表現可能な場合だけOKということになってしまうのです。
Nick Malik氏はハイ・レベルなBPM言語／表記法によってビジネス・プロセスの創造と実行を完全に自動化できるのか可能にするのかについて論じている(リンク)。
"信奉者"によれば、よくできた言語(BPMNかBPEL)をユーザに与えれば彼ら自らソフトウェアを作るようになり、全てのIT開発者がクビを切られるということです。
Nick氏はこれらの言語によってしばしば実装が単純になるが、ビジネス・プロセスの実装においてIT開発者(と固有の開発プロセス)を完全に置き換えることはできないと指摘している。
...BPM言語は「人」の振舞いをモデル化します。"コード化"されるのは「コンピュータ」の振舞いを示すものです。コンピュータに対しては人に対する1000倍の明確さが必要になります。従ってコンピュータに対しては人に対する1000倍のコードを開発してあげる必要があるのです。
あいにく(素晴らしい示唆はあるものの)、Nick氏はBPMNとBPELを混同している。2つの言語はまったく異なる目的のためにある。これに対してBruce Silver氏が即座に返信をし、結論全般には賛同しつつも間違いを指摘した(リンク)。
Nick氏がBPMが何なのかということを考えるきっかけを与えてくれたことにしておきましょう。但し、BPMN自身は実装コードを生成することはできません(ただのアクティビティ・フローのモデリングに過ぎません)。BPELこそが開発言語であり、‘エンド・ユーザ’のためのものではありません。(Nick氏はJavaプログラマだけが"本当の"開発者だと思っているのかも知れません)。BPMNをベースにしたBPMスイーツは、業務担当者と開発担当者がプロセスの自動化について共同作業をするような、今までよりアジャイルな実装スタイルを提供します。
これらの議論を考慮するとBPMN2.0のロールも方向性も明確ではなく、合意形成もされていないことが明らかである。この不確実さがBPMによる設計と開発の進歩の重大な妨げとなってしまう可能性がある。