8年以上にわたる懸命な研究の末、ソフトウェア産業とその顧客は大きな壁に突き当たっている。ドットコム時代にBPM新進企業によって定義されたビジョンは、まだ実現していない。我々は、（開発者の最小限の介入を伴っても）ビジネスアナリストが設計したビジネスプロセスモデルを利用して完全な実行可能ソリューションを作り出す能力からかけ離れている。プロセス駆動型アプリケーションモデルの必要性は現実のものだ。ビジネスプロセス改善（Business Process Improvement）のイニシアチブはGlobal 2000企業の至る所で活気良く進んでいるが、こうした継続的なプロセス改善の強い必要性をよそに、2007年、BPM市場は（可能だろうと思われていた状態と比べて）未だ小規模にとどまっている。これは、自らをBPMS（Business Process Management System; ビジネスプロセスマネジメントシステム）分野の次期Oracleだと早くから公言していた一部のベンダーの言葉とは全く対照的である。
では何が起きたのか? 実際、それを理解するのは非常に簡単だ。よくある、「私はあなたが買いたいものを売る」の話である。この種の状況では、一連の誤った考えが当たり前に生じ、必ずしも最適とはいえないソリューションへとつながってしまう。ほとんどの製品マネージャ、設計者および開発者がいくつかの箱と矢印（boxes and arrows）以上のビジネスプロセスを設計しようとしていないことは言うまでもなく、これまで決してビジネスアナリストと話し合いをしてこなかったことを加味すれば、現在の状況は誰にとっても何の驚きにも当たらない。
先日、Bruce Silver氏は「ラウンドトリップの再訪」(source)に関する批判的な問いを投げ掛けた。Bruce氏は、BPMの2つの主要な標準である、BPMN（Business Process Modeling Notation; ビジネスプロセスモデリング表記法）およびBPEL（Business Process Execution Language; ビジネスプロセス実行言語）の間に大きな食い違いがあることを訴えている。現在のBPMSアーキテクチャにミッシングリンク（失われた環）があることがしばしば議論されているため、BPELコンパイラに対しBPMNを作成することに着手している研究者チーム（Ouyiang、Dumas、van der Aalst、ter Hofstede）の際立った仕事についてBruce氏は指摘した。研究者チームは、この問題の解決に向けて大きく前進しているが、まだ不十分である。また、Bruce氏は、完全にBPELをあきらめて成功の道と思われることに焦点を当てるべきだと主張した。それは、表記法の下層に実行可能なBPMN標準を作成することである。
私は1997年以降この問題に取り組み続け、2002年には2つの記事（1(DOC・英語)、2(DOC・英語)）を書き、そのどちらもがOMG BPMN 1.0仕様(PDF・英語)で参照されている。これらの記事で展開した議論について、別の例を挙げ、より明確にあらためて主張したい。ここでの私の目的は、BPMSの現在のアーキテクチャの根底にある誤った考えを追究し、BPMSの新しいクラスを構築する新しいアーキテクチャの青写真を提供することである。
誤り#1: ビジネスアナリストはシステムの観点からビジネスプロセスをモデル化する。
プラクティショナーと話をする場合、彼らは実行の観点またはシステムの観点からではなく、ユーザーの観点からプロセスをモデル化するだろう。つまり、プロセスモデルはユーザーにすべきことを指示し、ユーザー入力に対するシステムの応答は決してモデル化しない。それにはもっともな理由がある。ビジネス継続性だ。すべてのシステムに障害が発生した場合に、ユーザーは事業を運営し続けるために何をすべきか知っておく必要がある。また、ビジネスアナリストの考え方と、プロセスからメトリクスを定義および取得する方法もだ。このユーザーの視点は、価値を生み出すアクティビティのワークフローに直接関係するため、ビジネスにとって非常に重要である。ビジネスアナリストは、システム境界、実行、メッセージまたはビジネスオブジェクトに関して決して考えることはない（ただし開発者は考える）。システムに対するビジネスアナリストの理解は、せいぜい、（情報を参照または入力するための）紙フォームの電子版に相当する画面くらいである。
誤り #2: ビジネスユーザーはBPMNを簡単に習得でき、その機能をすべて使用できる。
BPMN(PDF・英語)は300ページ以上からなる仕様である。ビジネスアナリストのほんの数人ですら、すべての概念をマスターできるようになるとは思えない。Michael zur Muehlen氏は、BPMNで最もよく使用される構図の研究を行い（スライド24を参照）(source)、約25の構図が日常的に使用されているという結論を出した。個人的に、私は10の重要な概念を基にビジネスアナリストのためのチュートリアルを作成した。そしてBPMNをペアダウンしても、BPMNの採用にあたって共に働いたリーンシックスシグマ(PDF・英語)のブラックベルトを納得させることは困難だった。
Bruce Silver氏は経験から次のように述べている(source)（彼はBPMNのクラスを教えている）。
BPMNにはBPEL生成のための多くの属性があるが、これらは一般に無視されています。
誤り #3: ビジネスアナリストはプロセスモデルから実行可能ソリューションを作成できなければならない。
私は、議論の中でBPMSベンダーが不誠実にBPMSをあなたに売ろうとしていると言っているのではないし、実際に不誠実なのではない。BPMは、より良いビジネス/ITの協調、より高速な開発サイクルといったビジョンの善意で始まった。ビジネスは実行可能コードに変換可能なモデルを生成できるというアイデアが浮かび上がった。そこにはなんら悪い行為はなく、CASEツール、MDA、MDD、DSLと同じ路線だ。このビジョンは我々の最も大切な夢である、早い、簡単、安いに訴えかけた。私は、このトピックに関するベンダーの宣伝文句を聞くたびにジョンレノン(サイト・英語)の歌「イマジン」(source)を思い出す（つまり、私はそのような世界で生きたいけど、そんなことは生涯あり得ない）。ベンダーは確かなアイデアに基づいて現実の（かつ巨大な）市場が存在することを感じた。それをあなたはVCからの無限に近い資金と組み合わせれば、今日我々が持っているものを十分に獲得する。いくつかのベンダーはそのビジョンのほんの一部を提供することで他よりも成功したが、そこにビジョンはないということを認めざるをえない。（ITの最小限の介入を伴っても）プロセスモデルからソリューションを作成するためにビジネスアナリストが使用できる汎用エンジンをベンダーが提供しているとは、誰も主張することができない。大きなプロジェクトに失敗し、BPMSの使用は社会の主流から取り残され、組織にほとんど利益をもたらさない。
ビジネスユーザーにソリューションを「巧みに作成」させたい人々に私がよく言う冗談は次のようなものだ。良い知らせはあなたが2000人の開発者を組織に加えたことであり、悪い知らせはあなたが2000人の開発者を加えたことだ。望むのは、ユーザーがソリューションを作成またはカスタマイズするのではなく独自のものにできるということだ。十分に制限されたケースでは、ビジネスユーザーにビジネスロジックの一部（たとえば規則）をカスタマイズさせてもよいことに注目したい。
誤り #4: ビジネスアナリストの入力から直接ソリューションを作成する魔法のようなBPMSを追加すれば、我々は既存のシステムとの統合を開発する必要も、既存の情報記憶システムを変更する必要も、QAを行う必要もない。
このように、魔法のようなBPMSを少なくともあと10年間は市場で目にすることはないであろうことに誰もが同意してくれることを私は願う。そして、ベンダーは開発者を蚊帳の外にすることを完全にあきらめた。しかしBruce氏は次のように指摘している。
多くの小規模企業はBPELを完全に無視することによりBPMバイヤーと業界アナリストの両方で成功を実証し始めています。Lombardi、Appian、Savvionなどのベンダーは、統合以上に人間中心のプロセスに焦点を当て、BPMNアクティビティの実装プロパティの形式で、実行可能な設計がプロセスモデルの上層に置かれている新しいBPMSスタイルの道を切り開きました。
ツーリング自体は、実装サイクルの全体を通してビジネスとITの協調を促進し、迅速な反復の方法論を適合させ、モデル化からソリューション配備までのサイクル時間を大幅に短縮しました。
Bruce氏に返答したMarlon Dumas氏は、私に同意している。
BPMライフサイクルから開発者を排除することはないでしょう。それは、XPath式に似たものや、その他の式言語を喜んで記述するビジネスアナリストはいないという単純な理由からです。
前に述べたとおり、私はこれらのベンダーがある程度の成功を経験したことを主張したい。ベンダーが人間中心のプロセスに焦点を当てているとBruce氏が指摘するとおり、特に既存のシステムの制限付きカスタマイズや既存のシステムとの統合が必要なときに、大部分は、これらのベンダーが開発したビジネスプロセスエンジンの集中型ビューに適合するであろう。
誤り #5: ビジネスプロセス実行は集中化されなくてはならない。
この件について少し時間をかけよう。Bruce氏は彼が新たな問題に直面していることを説明した。
実際、[BPMNユーザー]がすでにBPMランタイムを決定していたら、たいていそれはBPELです。BPELは、標準の、商品である、利用可能なオープンソースであり、IBMとOracleがBPMランタイムで使用しているものです。そのため、BPELが支持される強力な要因が存在します。しかしBPMNとBPELの両方を標準としているのでしょうか? いいえ、もちろんそれは論理的でありません。
およそ1年間ランドトリップ消滅（roundtripping-is-dead）キャンプにいますが、私は再びこの問題に直面しなければならないことに気付いています。たとえば、私のBPMNトレーニングでは、受講者は、彼らの期待するBPEL実装に適合するように、BPMN図でどんな戦略またはパターンを使用すべきか知りたがっています。それは私が開始時に考えるよう期待していたことではありません。
BPMN/BPELラウンドトリップはこの業界の聖杯であり続けた。これはBPMLとBPMNの創立組織BPMI.orgによって初期に提案されたビジョンであった。そこで何が起きたのか? 数社の企業は、実行セマンティクスをBPMNに追加したとき、中間のオーケストレーション言語を必要とせずに、どのように人間中心のプロセスにおいて成功した市場を創出できたのか? 問題は我々が適切な強調言語をまだ見つけていないという事実から生じているということを、他の人は示唆している。たとえばArzul Hasni氏は、GRAFCETはこのラウンドトリップを達成するためにBPELよりも優れた強調言語になり得ると主張している(source)。GRAFCETは、インダストリアルオートマトン専用のプログラミング言語である（Arzul氏は彼の投稿で詳細を述べる）。本質的には、GRAFCETはBPELにかなり近い。
Ouyiang氏、Dumas氏、van der Aalst氏、ter Hofstede氏は、BPMN/BPELマッピングの作成(PDF・英語)において大きな仕事を成し遂げた。私のように大学レベルの数学を忘れてしまった人のために、私はBPMN(JPG・英語)とBPEL用(PNG・英語)のUML図を公開した。これらのUML図は、2つの仕様の間のセマンティクスの相違（つまり、一方で表現できるものと、もう一方で表現できるもの）を理解するのに役立つであろう。この研究者グループによる結論は非常に明快である。
今後の活動で可能な手段は、BPMNモデル（たとえば例外処理やその他OR結合のような高度な構図に関するモデル）のより大きなサブセットをカバーするために、提案技術を拡大することです。残念ながら、BPMNの高度な構図の多くは不完全指定であり、関連標準化機関によってまだ改良されているところです。
この集中型プロセスエンジンの概念は新しくない。これは、90年代前半からこの分野で行われてきた99.99%の仕事の背後にある基盤である。この集中型アーキテクチャに当てられた焦点は、Fujitsu Computer Systemsの研究開発部長、Keith Swenson氏（BPMNの交換形式、XPDLに非常に関心がある）による素晴らしいプレゼンテーション(source)によって最適に理解できる。
残念ながら、この見解には救いようのない欠点がある。その理由を説明するため、いくらか時間を費やしたいと思う。この種の考え方では、我々はビジネスプロセスの本質そのものを単純に無視している。組織はリソースを変換することで付加価値を付けることができるということだ。Source-to-make（調達から作成まで）やQuote-to-cash（見積りから入金まで）などのプロセスはすべて、変換され消費されるリソースに対して最終的に（うまくいけば）付加価値を付けるアクティビティのワークフローに沿って「もの」を動かす。情報システムは単に、こうしたリソースとアクティビティの状態を促進、取得、報告するためにここに存在する。あなたは、物理的概念を説明するあらゆるビジネスオブジェクトを利用できる。Purchase Order（発注）、Invoice（インボイス）、Inventory item（在庫アイテム）、Employee（従業員）、Customer（顧客）など、これらにはすべてライフサイクルというものがある（ステートマシンで記述できる - 図2を参照）。
求職申請のビジネスプロセス（Candidate-to-Employee（志願者から従業員への）プロセス）を例に挙げたいと思う。志願者の申請を受け付け、その志願者を雇用するか申請を却下するかの、いずれかの地点まで処理するプロセスである。
以下に、一般的な求職申請の情報モデルを示す。
図1. 求職申請データモデル
この求職申請にはライフサイクルがある（求職申請データモデル（内容）はそのライフサイクルとは無関係であり、その逆も同様であることに注意してほしい）。:
図2. 求職申請ライフサイクル
求職申請ライフサイクル自体は、Candidate-to-Employee（志願者から従業員への）ビジネスプロセスと無関係である。このビジネスロジックは、たとえ相互に作用するプロセスが頻繁に変わることがあっても、めったに変わることはない。企業は、同じライフサイクルに対して複数のプロセスを持つこともある。たとえば、部長のポジション用のプロセス、マネージャ用のプロセス、その他すべての従業員用のプロセスといったものだ。別のケースとしては規定によるものがあり、一部のプロセスではさらなるアクティビティ（経歴調査など）が必要となる場合がある。このようなプロセス変形は極めて一般的である。しかし、ほとんどの場合、求職申請は求職申請であり、たとえ求職申請ライフサイクルの変形があったとしても、それらはたいていプロセス変形から切り離される。
目下の問題は、この求職申請ライフサイクルコンポーネントの実装にどのように取り組むかである。私の方法は、結果として状態遷移となるすべてのアクションを実装するサービスを作成することだ。:
図3. 求職申請サービス
これらすべてのサービスオペレーションは事実上、結果として状態遷移となるビジネスロジックを実行する。このサービスを実装する最適な言語は何か? Java/C#か? BPELか? GRAFCETか?
私の好みはBPELのようなメッセージ指向のオーケストレーション言語である。なぜなら、こうしたリソースのライフサイクルは長期にわたるからだ（数日、数週、数月、数年）。その要点を説明するために、顧客リソースの例を挙げよう。私は顧客として今週、クレジットカード会社との12年間の契約を解約した（顧客インスタンスのライフサイクルをその最終状態に遷移させる）。私が課金プロセスの故障と感じたものが原因で追加手数料を支払わなければならなかったからだ。プロセスは重要であり、クレジットカード会社はBill（課金）ライフサイクルを変更せずにアクティビティをプロセスに追加できていたら、私を満足させ続けることができただろうに、彼らはそれをせず、代わりに手数料を最大にすることを選んだ。このような長期にわたるライフサイクル（プロセスではない）において、BPELは理想的な実装言語である。なぜなら、BPELはメッセージ（受信、送信、呼び出し）やメッセージ相関を理解し、並行フローを処理できるからだ（リソースは複合状態を持つことができる）。また、BPELエンジンはプロセスインスタンスの脱水/水和を自動的に処理するように設計されているため、実装する（手間のかかる）ものが1つ減る。
BPEL実装は次のようになる（ベンダーの中立なBPEL表記法を使用）。
図4. 求職申請サービスの実装
多くの人がプロセスだと言うであろうことは分かっているが、プロセスではない。それは、求職申請の状態（ステート）を進める可能性のあるプロセスおよびアクティビティとは無関係に、求職申請のライフサイクルを実装するサービスである。プロセスはその状態を進めるアクティビティのセットである。リソースライフサイクルとプロセスは切り離されており、誰もがそれについて議論できるとは思わないが、皆、リソースライフサイクルを明確に理解することなくプロセスをモデル化および実装しようとしており、それには多かれ少なかれプロセスモデルが「組み込まれて」いる。
したがって、多くの人々がBPELエンジンを標準とするために行った選択は、非常に正しい選択である。SCA(source)により、お気に入りのプログラミング言語を、BPELセマンティクスを付加するように容易に拡張できることに注目してほしい。かつてなら、私はBPELよりもBPEL-Jを支持していただろうが、今日では従来の言語でビジネスロジックを表現する必要がある場合、SCAは、好きな言語（Java、C++、COBOL、PHP、ABAP...）でオーケストレーション機能を活用することを非常に簡単にする。
リソースライフサイクルとオーケストレーション言語の間には強力な関係がある。代表的なオーケストレーションエンジンは、オーケストレーション定義を作成する方法としてステートマシンパラダイムを提供する。このことは、IBM Process Server(source)、およびMicrosoft Workflow Foundation(source)について当てはまる（いくつか忘れていたらお詫びする。他に知っているものがあれば知らせてほしい）。
今までのところ私は、オーケストレーションエンジンを使用して、リソースのライフサイクルを管理するサービスを実装することを提案しており、まだビジネスプロセスやビジネスプロセスエンジンについて話していないことに注意してほしい。
ライフサイクルとプロセス間の関係に注目する前に、ライフサイクルは非常に直観的な概念であることを強調しよう。多くのビジネスアナリストはこれらのライフサイクルを（たとえばUML表記法を使用して）記述することができる。組織内のほぼ誰もが役割に関係なくこれらのライフサイクルを理解できるということを主張したい。しかし同時に、まさに正反対の側から、ほぼ誰も関連する全リソースのライフサイクルに従うビジネスプロセスを設計（BPMNを使用してグラフィカルに設計するなど）することはできないということも言いたい。あなたがそのようなモデルを作成済みと仮定して、プロセス変形を作成するとしよう。リソースライフサイクルが影響を受けていないということをどのように保証しますか? それを検証するためにどのくらいQAを行う必要がありますか?
プロセスとリソースライフサイクルは、プロセス実装時しか調和できず、ライフサイクルに従うようにプロセスを「曲げる」可能性がある。このアクティビティは、BPMNで表現されたビジネスアナリストの要件を慎重にマッピングし、組織のコアリソースのライフサイクルを管理する企業クラスのサービスを再利用する開発者しか実行できない。
では、ビジネスアナリストはBPMNを使用してどのように求職申請のビジネスプロセスの定義を作成するかに注目しよう。
図5. 求職申請プロセス（青のグループはヒューマンタスクの境界を示している）
第1に、BPMNは「資源」および「ライフサイクル」についての観念を持っていない。せいぜい、誰かが（図のように）プロセスの任意の地点に予想される状態でそのBPMNに注釈を付けることができるくらいだ。それはそれで良いし、BPMNは妥当である。第2に、ビジネスアナリストは、その状態に進むために求職申請サービスで呼び出される動作にまったく気付かない。それらはシステムビューに属する。ビジネスアナリストがユーザーアクティビティとして記述したアクティビティの間に「呼び出し」アクティビティを追加するというのを期待するのは、完全に間違っている。残念ながら、BPMNとBPELの間に人々が確立しようとしていた関係は間違ったものであったため、結局はプロセス表記法でSend（送信）、Receive（受信）、Invoke（呼び出し）のコアBPEL動作セマンティクスを追加することになった。これは完全に人為的であり、送受信されるメッセージが（求人担当者のデスクに到着する求職申請などの）呼び出される動作ではなくビジネスメッセージである場合以外、決して使用されない。
どのようにビジネスプロセスは実装されるのだろうか? ビジネスプロセス実行環境は、相互作用するサービスの集合体（図6）である（中央に組織化されたサービスのセットではない）。ヒューマンタスクと、プロセスを進めるイベントおよび単純なサービス呼び出しのほか、リソースのライフスタイルを実装するオーケストレーションの相互作用である。
図6. 求職申請プロセス実装
良い知らせは、我々はすでに、アセンブリ技術であるService Component Architecture(PDF・英語)を含め、このビジョンの達成に必要なすべての技術を持っているということだ。この図に見られるすべてのものが、SCA 1.0、BPEL 2.0、Webサービス（XSDおよびWSDL 1.1 - BPEL 2.0のため）、BPEL4People 1.0、Human Tasks 1.0の組み合わせで達成できる。
このBPMSアーキテクチャの青写真では、Bruce氏による以前の発言はもはや適用されない(source)。
BPELでは、あなたは自身がサポートしていない要素を無視する自由がありません。 BPELはBPELであり、仕様内のすべてをサポートする必要があります。残りは、プロプライエタリ拡張と呼ばれています。それらは独自の名前空間に所属しており、BPEL 1.1に対する妥当な批評は、実際のプロセスでそれらを非常に多く必要とすることです。BPEL 2.0では多少良くなっていますが、ヒューマンタスク、サブプロセス、およびその他の基本は依然として2.0で拡張を必要としています（ほとんど神話のBPEL4Peopleなど）。
WS-HumanTaskおよびBPEL4Peopleはタスクコンテナに属し、実際にBPEL自体と切り離されている。BPELが「サブプロセス」を必要とするかどうかについてすでに議論できるであろうが、リソースライフサイクルサービスの実装言語としてそれは重要ではない。再利用可能なステートマシンの要素はほとんどなく、それらはリソースに密接に属している。
現時点では、残念ながらMicrosoftはSCAまたはBPEL4Peopleに参加していないため、Workflow Foundationが完璧に仕事をこなすとしてもそれをBPELエンジンの代替として使用することはできない。ただし、お気に入りのBPELエンジンと、SCAから呼び出し可能なサービスを実装するサービスコンテナとしてWCFを使用できる。Microsoft自体はアセンブリ機構を持たないため、.Netでこのアーキテクチャの青写真を実装することはできない。オープンソース側では、ほとんどのコンポーネント（SCA(サイト・英語)、BPEL(source)、Serviceコンテナ(source)）を持つが、BPEL4Peopleコンテナが欠けている。それは重要ではなく、基本のヒューマンタスクコンテナは実際に構築するのに難しすぎない（ただしBPEL4People およびWS-HumanTaskのレベルまでではない）。
この新しいアーキテクチャにおける開発者の役割を理解するために、プロセスモデルの「面接スケジュール」アクティビティ（図5）に焦点を合わせよう。ご覧のとおり、このアクティビティはプロセスモデルで取り上げられているが（これは、求職申請システムが機能停止した場合にユーザーが実行すべきものであるため、理にかなっている）、最適化として、たとえば交換サーバーの上にスケジューリングタスクが自動化されることがビジネスで決定された。求職申請ライフサイクルは、志願者の申請が保持された後で面接がスケジュールされるフックを提供する（すなわち要求する）。求職申請サービスはこれがどのように実装されるのかを知らないということに注意してほしい。ヒューマンタスクで十分だったかもしれない。この時点での私の理解では、この種の設計の決定を自動的に解決することは単純に不可能である。これが、プロセスモデルがどの実行セマンティクスからも完全に切り離さなければならない理由である。プロセス定義に影響を与えない別の設計決定は、志願者の申請が違うヒューマンタスクコンテナで起こり得るという事実である。我々は、ポピュラーなキャリアサイトで行われる志願者の申請でこのプロセスを十分に「アセンブル」することができる。申請に対し面接が承認されると、アクティビティによって志願者に電子メールが送信され、その志願者がプロセスタスク（オファーの再検討、雇用情報の入力）に向けられる。現在のBPMSアーキテクチャでは（容易に）それを行なうことはできないであろう。
追記として、タスクエンジンはビジネスプロセスエンジンのサブコンポーネントではないことが分かるだろう。もちろん、これは現在のBPMSの設計方法だが、実際にはそうでなく、ヒューマンタスクを管理するアーキテクチャの独立したコンポーネントである（図6）。これらのヒューマンタスクは常に自然に1つまたは複数のビジネスプロセスと関連しているが、自らライフサイクルを持ち、リソースライフサイクルサービスと直接相互作用する。Dominique Vauquier[1]氏が自身の記事「Human tasks are grafted on the resource lifecycle」で説明しているとおりである。また、前のパラグラフで周知のとおり、「ビジネスプロセス」がいくつかのタスクコンテナと相互作用できることが重要である。
私はここではMaster Data Management(source)または規則(source)の役割について説明しなかったが（James氏(source)に詫びる）、これらは重要な役割を果たしており、BRMS（図6）としても知られている特殊なサービスコンテナを必要とする。Michael zur Muehlen氏(source)またはMark Proctor氏(source)が尋ねる質問は完全に無関係になる。SCAが（ランタイムの観点から）それを無関係にするからだ。SCAにより、決定サービスの最も適切な呼び出し機構（技術的に可能であればBPELエンジンでプロセス中に動作する）を選択することができる。SCAはこのアーキテクチャの要素間に大きな分離を提供し、それらを他のプロセスで再利用できるようにしつつ、各プロセスに可能な最良のランタイム設定を選択する。
B2Bの役割についても話さなかったが、これについては私の2つのオリジナル記事（1(DOC・英語)、2(DOC・英語)）で詳細に話している。このアーキテクチャの青写真は、アセンブリ内の任意境界の定義を可能にすることでB2Bをサポートしている。たとえば、発注ライフサイクルの2つの視点（買い手と売り手）をアセンブルできる。これは大きな利点である。従来の「集中型」実行モデルはB2B境界で人為的な断絶を課し、2つの異なる実行モデル、すなわち両側の集中型オーケストレーションと中央のアセンブリを強制する。いくつかの点で私の提案は単にOASIS ebXML Business ProcessのオリジナルのB2Bプロセス定義モデルに基づいているが、ビジネスパートナーレベルではなく、リソースレベルで適用される。そのため、実行モデルはビジネスパートナーとやりとりするため組織内部とその周辺の両方で継続している。
誤り #6: ビジネスプロセス実行セマンティクスは既存のプログラミング概念から容易に得ることができる。
「実行」標準の作業委員会（BPML、BPEL、WS-CDLなど）で私が出会った人のほぼ全員が（私も含め）プラクティショナーではなく、開発者や設計者だった。彼らはたいてい、複雑な数学理論（Pi-Calculus(source)など）に、それらの理論のセマンティクスが実際にビジネスプロセス実行のサポートに十分であるかどうか確認することなく重点を置いていた。一般的に、こうした技術委員会は、3～5つのユースケースに重点を置いて要件を記述している。これらのユースケースはささいなものであることが多く、「現実の世界」のビジネスプロセスの複雑さをほとんど反映していない。
ビジネスプロセス実行セマンティクスは概念化するのが難しい。実際、ほとんどの実行可能プロセスが未だに1行ずつ、我々のソリューションでハードコードされているほど困難である。より良い方法が存在していたら、誰もがそれを採用しただろう。私は、「なぜJava開発者はBPMを嫌うのか？」という議論のコメント(英語)を読むように勧められた。どのコメントも抽象化の正当性に対する不満を述べていない。Even code Kahunas、JBossのChief Architectなど、Bill Burke氏は次のように述べている（私は一時期、Burke氏と一緒に仕事をしたことがあり、彼がJBossに参加する以前にヒューマンタスクコンテナを一緒に構築した）。
私のBPMに対する考えは変わりませんでした。それはXMLスクリプティング、そして開発者のレベル低下にしかすぎませんでした。実際にBPMフレームワークを調べ始めるまでは、これらのフレームワークが提供すべき付加価値について見ていませんでした。信頼性(source)のある耐障害性(source)のステートマシンとして[それらについて]考え始めたとき、BPMフレームワークのポテンシャルを見出だし始めました。トランザクション管理と補償(サイト・英語)の使用をビジネスプロセスと組み合わせ始めると、アプリケーションの開発時に連動する非常に優れた抽象化が得られます。
前のセクションで私が説明したことに基づくと、彼とその他の人の発言(source)は正しい方向に進んでいる。開発者は、繰り返しステートマシンをコーディングしなければならないことと、汎用エンジンでどのように作業を楽にすることができるかに、困難を見ている（多くの場合）。
誤り #7: Bruce Silver氏は次のような言葉で投稿記事を結んでいる。「実行可能な設計がBPMNモデルの上層に置かれている強調的な実装パラダイムこそ、進むべき道である。」
Bruce氏は、ビジネスプロセスモデル実装はBPMNで表現されたビジネスプロセスモデルから動作し、実行可能プロセスを達成するために（開発者と協力し合って）注釈を連続して追加する必要があると信じている。
残念ながらこのビジョンはビジネスプロセスの実態（リソースの状態を勧めるアクティビティのワークフローとして）を考慮に入れていない。この発言は、たとえ概念的に有効な試みだとしても、アクティビティのワークフローとリソースライフサイクルを一緒にモデル化することは（少なくとも私の現状の知識では）できないため、全く間違った考えであると、あなたを説得できたらと思う。開発者はビジネスアナリストが作成したプロセス定義を、ヒューマンタスク、リソースライフサイクルサービスおよびサービス（決定とMDMサービスを含む）のアセンブリに変換することになるだろうと、私はかなり前から予測できている。
この新しいアーキテクチャの青写真は、あなたがお気に入りのBPMSに行った投資を損失するということを意味するのではない。ただし、コンポジットサービスコンテナ（BPELコンテナなど）とアセンブリコンテナ（SCA）を追加し、ヒューマンタスクコンテナとしてBPMSを使用する必要がある（それらは大半については実際に存在する）。ヒューマンタスクコンテナはアーキテクチャの重要かつ優れたコンポーネントである。現在のBPMSのタスクコンテナは非常に高度であり自分で構築することが困難なため、お金をかけた甲斐があった。私はこのコンテナの役割を台無しにしたくない。実際、2年以内にすべてのBPMSベンダーがこの記事で示したビジョンを採用し、ベンダーのスイートがこの青写真に基づいてSCAアセンブリとBPELコンテナ内で機能するように変わるであろうと、私は予期している。
また、実装の最後に、動作プロセスの「現状の」ビューを自動的に再構築することができると主張したい。まだそれを証明していないが、これが研究テーマになるだろう。
結論
長年にわたりBPMの特効薬（Magic Bullet）を探し求めてきた末、ソフトウェア産業は壁に直面している。 この壁は、リソースライフサイクルに基づくビジネスロジックの新しいファクタリングとパラダイムシフトにより、容易に克服できる。もし方向を誤って7つの誤った考えを信じ続ければ、ROIの不足のためこれらすべての製品と標準を無駄にして、すべて手動でコーディングすることに逆戻りしなければならないリスクを負う。しかし、我々が現在持っているまさにその技術を違った方法で利用すれば、ビジネスとITの両方にとって非常に有力なビジョンを実現することができる。私はそのビジョンをBPM自体とは呼ばない。ビジョンはBPM以上のものであるため、「コンポジットアプリケーション」またはより正確に「コンポジットソリューション」と呼びたい。
コンポジットソリューションのビジョンは、ビジネスがITから必要とするものを直接伝える。
- できる限り小さいプロジェクトで迅速にソリューションを構築する（多くの反復に頼る）
- 迅速にソリューションを変更し、反復のリーンシックスシグマ手法をサポートする
- 複雑な「現状」プロジェクトなしで、現時点で動作中のビジネス設計をビジュアル化できる
- 複雑な測定プロジェクトなしで現在のビジネス設計からオペレーショナルインテリジェンスを取得できる
「ビジネス設計を作成/変更することでソリューションを構築/変更できる」能力は（それがどんなに望ましく見えても）上記4つの要件に対立するということを、私は主張する。理由は、それが極めて単純かつかたくななタスク中心のアプリケーションモデルをもたらすからである（現在のBPMSで分かるとおりだ）。これらのアプリケーションモデルはビジネスの必要性を満たすことができないため、一般的にプロジェクト費用が増加する結果になる。これは、真のソリューションの開発が必要なときに、BPMSアプリケーションモデルの「周囲に」多くのカスタム開発が必要になるからである。問題を大きくしているのは、これらのスイートが、「なぜJava開発者はBPMを嫌うのか？」という議論(記事)で指摘されたように、このカスタムコードおよび大型プロジェクトに適した強力な開発環境を提供していないことである。
前進し続けているビジョンは、コンポジットソフトウェア（アセンブリ（SCA）とオーケストレーション（BPEL）の2つの複合モデルに基づく）である。当然、コレオグラフィがやって来るが、私はそれについて別の記事で説明するつもりだ。この青写真を作成する技術は現在利用可能である。また、BPELとBPMNは、現在定義されているとおり、機能する。BPMNで何かを変更する必要がある場合、すべての実行セマンティクスを取り除かなくてはならず、ビジネスアナリストが自分で表現できるように設計されていなければならない。これらの標準とこのアーキテクチャの青写真を使用したコンポジットソフトウェアの構築方法を詳細に知りたければ、先週からInfoQ上でミニブック(英語)が公開されている。
コンポジットソリューションプラットフォームのアーキテクチャは、この記事で記載したとおり、SOAとBPMの間によりクリーンなインターフェース(source)も提供する。これは、真に再利用可能なサービスを構築する機会を SOAに与える。そのサービスとはリソースライフサイクルサービスであり、プロセス領域やプロセス変数で再利用できる。リソースライフサイクルサービスはプロセスで再利用可能になるため、特定のプロセスの実装がより安く、高速で、簡単になることも意味している。リソースライフサイクルサービスの実装は、プロセス内の「コード」である。プロセス定義の中で図表を用いた表記法でライフサイクルをコーディングまたは再コーディングする知識をビジネスアナリスト（または他の誰か）が持っているという考えは、単純にBPMを誤った方向に向ける。
この青写真には、コンポジットソリューションプラットフォームとして、すでにそれをサポートできるPraxeme(サイト)企業法が含まれている。Praxeme Instituteは自社のアーチファクトを英訳しており、この目標に向けて大きく前進している。
現在の技術（SCA、BPEL...）に開発者を関与させることについて、私はBruce氏やMarlon氏と同じ懸念を共有している。これが、私がwsper(サイト・英語)と呼ばれるイニシアチブを開始した理由だ。このイニシアチブは、ライフサイクル実装時とプロセスアセンブリ時の開発者と設計者の作業を簡素化するために、抽象的なプログラミング環境を提供する。また、コンポジットソリューションプラットフォームを異種コンポーネントから構築することもできる。なぜなら、ビジネスロジック実装をコンポーネント（およびその将来の進化形）から切り離すからだ。また、ビジネスロジックを標準の進化形からも切り離す。
役立つリンクとコメントをたくさん提供してくれたSandy Kemsley氏(source)に心から感謝する。
[1] この記事はDominique Vauquier氏の記事（「ビジネスプロセス改善の6つの誤った考え」）を補足するものである。ここではビジネスプロセスモデリングの実行に焦点を当てている。Dominique氏の記事では、ビジネスプロセスモデリングがビジネスプロセス改善プロジェクトとどのように関係しているかについて追究している。私はDominique氏の記事をフランス語から翻訳した（2008年1月にBPTrends.com(英語)にて公開されることになっている）。フランス語で読む方のために、この記事がPraxeme(サイト)企業法の「Guide of the Pragmatic Aspect」(PDF・英語)の39ページに掲載されている。
原文はこちらです：http://www.infoq.com/articles/seven-fallacies-of-bpm