ソリューションにワークフローを導入することの重要性に気づく人がますます増えている。しかし、実際に利用する実装を検討する際に、自ら構築すべきか、それとも、すでにあるものを利用するか、という議論はいまだ続いている。Bernd Rücker氏は、彼の新しい投稿"ワークフローエンジン？ 私たち独自に構築したものは..." の中で、ワークフローエンジンについてのいくつかのよくある誤解について議論することで、この問題に重点的に取り組んでいる。
Bernd氏によれば、「自家製」ワークフローエンジンを構築する典型的な理由として、次のような内容が含まれる。
- 非常に基本的な要求しかなく、とてもシンプルなステートマシンである。ワークフローエンジンなんてやり過ぎだ。
- エンジンは私たちのアプリケーションの一部であるべきだ。
- xという製品を評価してみたが、単純にそれは適当じゃない。
一見この内容は妥当な懸案事項であるかのように見えるけれども、「自家製」実装の努力や費用をほとんど正当化できていないことがわかる。
非常に基本的な要求しかないため、その結果として新しい技術/実装を習得するのにかかる時間や努力を正当化することができない、としよう。結果的に、多くの実装が各プロセスのインスタンスと、その状態を保持できるようなシンプルなデータベーステーブルで始まる。しかし次には、以下のようなことをサポートすることが必要にはならないだろうか？
- インスタンス変数を保持しながら、ステートを待つことは？
- タイムアウトは？
- エスカレーションは？
- デシジョンゲートウェイは？
Bernd氏は自身の経験に基づき、実装は確かにシンプルな形で始まることもあるが、要求は時間とともに大きくなる傾向があり、最後には多くの会社が本格的なワークフローシステムのメンテナンスとサポートに「はまる」のが典型的な姿である、と指摘している。
エンジンは私たちのアプリケーションの一部であるべきで、結果として（多くの商用エンジンでいつものごとく要求されるような）追加的なハードウェア/ソフトウェア/統合/インストールの手続きに多く依存するようになりたくはない、という意見がある。
このようなシナリオに対してBernd氏は、軽量で、容易に製品に組み込めるようなJavaワークフローエンジンを検討することを提案している。そのようなエンジンの例としては、JBoss jBPM、Nova Bonita、Enhydra Sharkなどが挙げられる。このクラスのエンジンは、豊富な設定オプションを持つことが多く、それにより、特定のアプリケーションの要求にも容易に対応できるようになっている。
評価してみたが、適当じゃないという意見が、もっとも扱いにくい議論である。Bernd氏によれば、ここでの問題は、軽量でオープンソースのワークフローエンジンでさえ、妥当な評価を行うには時間と努力が必要であるということだ。もし、エンジンの評価に十分な時間を使うことができないのであれば、その結果もまた多くの場合十分ではない。その技術を理解するのに十分な時間を使うことができたなら、その実装が要求された機能を提供できないことはまずない、ということがわかる。Bernd氏は、例えば、自身の顧客は誰一人としてjBPMを使っても簡単には実現できないようなことを見つけることはできなかった、と述べている。それは単にその技術を理解するのに時間が必要だ、というだけなのだ。
Bernd氏は次のように投稿をまとめている
開発しないでください！ [非常に高価な作業です]。[あるエンジンを理解する]習熟曲線はほとんどの場合それに沿う価値のあるものです！... エンジンを利用する利点は[いったんその使い方さえ理解してしまえば]自明[なものになるの]です。
独自のデータベースやO/Rマッパーやアプリケーションサーバを実装するような人は今ではまれである。どうして独自のワークフローエンジンを書くべきだと考える人が多いのか？ワークフローエンジンは日用品であり、ほとんど常に、独自に設計し実装するよりも既存の実装を利用する方が費用効率が高いのである。