John Raynolds 氏は最近疑問を投げかけた。なぜ Java 開発者は BPM を嫌うのか(source)？
彼は、彼自身や他の人たちの経験から次のような結論を出した。
BPM スイートはあなたの創造性を奪い、どのようにアプリケーションを開発するかを命令する。そしてプログラミングを退屈なものにするうえに、あなたがプロセスダイアグラムをデザインするのにポイント・アンド・クリック、ドラッグ・アンド・ドロップツール、データモデルとフォームを使うことを強制する。
更に悪いことに、BPM スイートはビジネスに携わる人々に自分たちでプロセスをモデリングし、フォームを設計するように仕向ける。
彼は次のことを主張している。
一般の Java 開発者達は BPM スイートの制約を押し付けられるよりも、むしろ Struts や Spring のようなフレームワークを使うだろう。Spring または Strutsでほとんどのものを構築することができる（すでにあなたが Java の複雑さを習得しているなら）。Spring や Struts は軽くてアジャイルだし、業務経歴としても魅力的だ。
私たちは Java の知識があること自体の重要性を薄くするツールを構築するために Java を利用してきた。そしてそれが Java を学ぶのに時間をかけなかった人達との競争をもたらした。
私たちは自身の成功の犠牲者であり、それは私たちの負担になる。
だから Java 開発者は BPM を嫌うのだ。
読者は様々に違った理由を述べている。例えばこの読者は以下の理由から BPM を嫌っている。
BPM が物事を処理するのに実用的なツールになり得るとは本当に思えないんだ。NetBeans にはフリーの BPM ツールがあるが、単純な Web サービス自動化ツールのように見える。これは私が出くわすビジネスの要求や関心事には全く役に立たない。更に凝ったツールでさえ、たいした価値を提供しないハイレベルのプロセススクリプティングツールのようだ。これらのすぐれた BPM スイートが全く自由に開発者の手に入らないから試用が困難になっている。金額的に高いから私の上司は買ってくれない。
成功した導入事例はどこにあるのか？ このテクノロジを使った実際のアプリケーションがあるのであれば、是非とも教えて欲しい。
別の読者は次のようなことを述べている。
私たちは使うべきではないから BPM を嫌ってるんだ。BPM のアイディアは、ビジネスに携わる人々がモデリングタスクを行うというものだが、彼らが使っていないという事実があるから、私たちは結果的にそうしてるんだ。
この読者はたびたび宣伝される、"ポイント・アンド・クリック・アンド・ラン" の見せかけのシンプルさに賛同していない。
プロセスの最もシンプルな部分を考えても、実際にはコンピュータ上で実行されるのが現実だ。それにコンピュータは私が意味することではなく、私が言うことしか理解しない。
ダイアグラムのワイヤフレームが何を言うかに関係なく、互いにワイヤでつながれたこれらの小さいブロックが表現する現実を根本的に理解していなくてはならない。"請求書送付後" というボックス内に含まれる微妙なディティールはたくさんあり、どんなに私たちが頑張ってもこれらの微妙さは現れてきて周りのプロセスに影響を与える。
結局、これらのダイアグラムを記述する必要のある人達はコンピュータとコンピューティングを理解する必要がある。こういった人達はプログラマで、プログラミングは技術的な知識だけではなく特定の物の見方を要求する。
だから、ダイアグラムで単一のボックスとなって現れるかもしれない一方で、これらの 100 行もの J2EE コードで何が起こっているのかを理解するべきである。小さいボックスの色や形を問わず、そこにはまだ複雑さがある。
開発者として、いつ私のシステムが、このインフラの塊を導入する価値があるほど十分に大きくなるのだろうかと頭を抱えてしまう（私のシステムにはスクリプト言語のインタープリタとシステム自身のためだけに 1GB の RAM を要するランタイムが必要だ）。
明らかに、抽象化は時間を経て、長期的に私たちの開発環境をより良いものにしてきた。バイナリコードからアセンブラニーモニック、C 言語、Java に至るまで。1 行の Java コードは 100 ものマシン語インストラクションを表現する 10 の Java バイトコードを表現する。しかし、優れた Java プログラマはこれらの 100 ものマシン語インストラクションが何を行っているかをよく理解している。そして、駆け出しのプログラマは無知ゆえに時折痛い目にあう。
BPM ツールを使った開発経験をもつ Robert Perkins 氏は BPM スートを好まない理由を以下のように述べている。
あなたの製品の次のリリースを VISIO のようなツール内でフローチャートとして書いてもらうように技術者に頼むといい。彼らは JavaScript の使用を制限されるだろう。自動化された回帰テストシステムを利用する術も失うだろう。彼らがこれまで頼っていた Eclipse や IntelliJ IDEA の機能も一切使えなくなる。ビルドやデプロイ用のスクリプトもないので、デプロイには手作業によるファイルのコピーが必要になってくる。あとそれに彼らはバージョンコントロールの手段も持たないだろう。
開発者がビジネスにとって最も大きな価値を生み出すツールや製品よりもこれらのツールを使いたがるのは自分勝手な理由からだと、あなたは言うかもしれない。
それにはいくつか真実がある。多くの技術的でないビジネスは、開発者とビジネスサイドの間に不信を生み出して、この主張を信じるようになったと思う。私の前の会社がこの問題を抱えていたのを知っているし、たくさんのベンダとセールスチームがこの主張を利用していることは想像が付く。
私がサクセスストーリーにどれだけの信念を注いできたかはわからない。私の会社は成功例として数えられるようになった。だが実際にはプロジェクトはひどいもので、エンドユーザは憤慨していた。そして3月の時点で開発チーム全体が現場を去った。
「問題は単に BPM だけの話ではなくもっと一般的だ」いくつかのビジネスロジックやプレゼンテーションロジックをパーソナライズするために、ビジネスが最高のポジションに着ける場所はたくさんある。最近 Mark Proctor 氏は、多くのプロセス定義はルールエンジンの表現力を要求し、そのルールはプロセスエンジンの状態管理能力から恩恵を受けることができると述べ、統合されたルールとプロセスエンジンの利点について疑問を投げかけた(source)。Mark 氏は次のように付け加えた。
統合されたモデリング環境の利点の一つは、あなたがどのように物事をモデリングするかを選べるようになることだ。
Dave Wright 氏はすべてが密接につながっていると見ている。
データモデルや用語と意味のモデルを考慮すると、ルールとデータはルールとプロセスより強固につながっていると言われている。あなたがプロセスとルールプラットフォームを切り離したくないのはわかるが、離れたデータプラットフォームも同様に取り除きたいだろか？
これは Agility Chain Management Systems ( ACMS ) (サイト・英語)の Pierre Bonnet 氏の分析によって確認されている。ACMS は MDM と BRMS と BPM の間に強い結びつきを見ている。
- マスタデータ管理(MDM). 参照データとパラメータの管理を合理化し、サービス設定モデルの実装が実行を状況に適応させることを可能にする。
- ビジネスルール管理システム(BRMS). ルールは参照データとパラメータに依存する。組織的サービスの事前条件と事後条件はルール管理システムに置かれる。
- ビジネスプロセス管理(BPM). プロセスは様々なステージの活動を推進するためにルールを利用する。編成されたサービスは MDM と BRMS によって状況に適応させられる。
Peter Evans-Greenwood 氏はアプリケーションのセマンティックスを定義するために新しいアプローチについて述べている(source)。
ルールとプロセスの分離は、技術がそうあってほしいことによる結果ではなく、技術が必要とされる背景があって、そこから生まれたものだ。分離されたルールとプロセスのエンジンを持っていることは膨大な量の不要なオーバーヘッドをもたらすことになる。
より実り多いアプローチは逆方向から問題に取り組むことかもしれない。トップダウン方式で行こう。どのようにして人々がプロセスのビジネスロジックを理解するかを徹底的に調査して、私たちのアプローチを形にしたツールと技術を作り出そう。
原文はこちらです：http://www.infoq.com/news/2007/11/developers-hate-bpm