かねてから、SOAの実装を改善する試みは、BPMとの統合を含んでいた。James Taylor氏によれば、この取り組みにおけるミッシングリンクはビジネスルールマネジメントだという。
BPMやSOAに飛びついて、ルールを無視しないで下さい。将来には、ルールとBPMそしてSOAに影響が出るのです。ビジネスルールは、アジリティ、コンプライアンス、一貫性を提供することによってビジネスの成長を助けます。ビジネスルールは差別化の助けになると同時に、ビジネスを推進するための手がかりを掘り起こしてしてくれます。
なぜルールが重要なのかに関するJim Sinur氏のプレゼンテーションにコメントして、Taylor氏はビジネスルールと意思決定を管理することが持つ以下の価値を強調している。
- 警告をモニタして根本原因に取り組むことで、受け入れがたい種類ないしレベルのリスクを防ぐ。
- 閾値やインパクトをモニタし、リスクの可能性を最小化することにより、ビジネスの結果を受け入れる。
- イベントを識別し、迅速な対応を実装することでチャンスをつかむ。
プレゼンテーションにおいて、Sinur氏はルールに関するガートナーの視点を記述している。すなわちルールは、明示的なルールとゴールシーク機能を活用する適応型ソフトウェアの根底に位置づけられるものであり、同時に、プロセスのビジネスコントロールに関する主要な推進者としてふるまうことになるだろうというものだ。
Sinur氏が描いているのは、全てのルールをシステムに埋め込んでいるいくつかの企業からはじめ、ルールとプロセスの混成物を用いて半ば構造化されたスイートスポットを経て、完全にルールベースかつダイナミックな企業に至るグラデーションです。今日、市場は成長していますが、いまだにほとんどが実際の複雑な舵取りを明示的なルールとしては表現しきれずにいます。一旦市場が成熟すれば、過去のルールに誘導されたプロセスのふるまいからルール駆動の混合物とルールベースのダイナミックなプロセスへと移行する必要があるでしょう。
Taylor氏のポストにコメントして、Tom Graves氏は次のように語っている。
（前略）これは優れた記事で、読むことをお勧めします。そして、この記事が含意している、ビジネスルールに関する規律が現実にそして緊急に必要であるということにも強く合意します。（中略）［しかし］読み進めると私の中でエンタープライズアーキテクチャ警報が全て鳴り始めました。（中略）この記事はビジネスルールを「求めていた答え」として提示しており、それも、ITベースの「ビジネスルールエンジン」をそれとしているのです。
Graves氏の意見によれば、このようなアプローチはその他のIT駆動ビジネスの失敗、例えばビジネスプロセスリエンジニアリングに酷似しているというのです。
- 全てのビジネスルールをシステムによって自動化することは、「フィット＆フォーゲット」という態度につながります。それを防ぐには、ルールのメンテナンスを強く強調する必要があります。このルールメンテナンスは、全てのビジネスプロセスの「IT化」へとBPRが殺到する際に忘れられてしまう多くの「人間的要素」のうちの１つなのです。
- ビジネスルールの識別とコード化は、現行のプロセスを実行している人間から引き出されるルールが十分で、変わることなく、正確で完全であると想定してます。しかし初期のナレッジマネジメントが発見したように、そうであることは滅多にないのです。
- 意思決定を自動化することの実行可能性はコンテキストに依存しますが、恐ろしいことにこの事実を自覚しているITシステムデザイナはほとんどいないように見えます。
Graves氏はTaylor氏のアプローチの欠点は、ITによるビジネスルールの実装において、そこで見える景色が平坦なものではないという事実にあると説明する。ITがもつ主な力は二元的な真／偽ロジックに基づく単純なビジネスルールをサポートする点にある。二元的ではないロジック、例えば様相論理学（"modal logic"）や確率論理（"probabilistic logic"）においては、人間の方がより適切に実行できることが多い。ITはパターン認識においては発展している。たとえば既存のパターン／写真と比較することによる顔認識などである。しかしパターンが知られていない、あるいは存在しないリアルタイムのカオスにおいてはそれほどうまくふるまえるようにならないのではないだろうか。結果として、ビジネスルールに対するITアプローチは以下の結果に終わることになる。
全てはITによってなされるべきであり、ITが最も巧く扱えるのは単純なルールであるという本末転倒（"cart-before-horse"）な考え方に従って、全てが単純なルールに還元されることになります。言い換えれば、これは危険な前後の誤認です。意思決定のためにITから使えるものをすべて取り出そうとすることが既に間違っていますが、全ての意思決定にITを使うこと≠ｱれはTaylor氏の記事において明らかに好まれている「楽園」ですが≠ﾍ致命的です。エンタープライズアーキテクトとして、BPRその他と全く同じ過ちへと軽卒にも殺到しているのを止めるために、私たちが何ができるのか、私には全く分かりません。今回がこれまでと違うのは、プロセスの実装全体ではなく、よりはっきりとプロセスの「ルール」的側面から由来しているということだけです。
Richard Veryard氏はGraves氏に同意し、次のように語っている。
- 私たちはビジネスルールが十分で、変わることなく、正確で完全であると想定すべきではありません。現行のプロセスを実行している人間からルールが引き出された時には特にそうです。したがって、ビジネスルールの識別やコード化は一般的に何か必要なものをとりこぼしているのです。（現実はシンボル化に抵抗するとも言えます。）
- ルールのメンテナンスを非常に強く強調する必要があります。そうでなければ、全てのビジネスルールを自動化されたシステムにおくことは、「フィット＆フォーゲット」という態度につながります。（ダブルループ学習もしくは二次的学習が求められるとも言えます。）
- 意思決定を自動化することの実行可能性はコンテキストに依存します。
Veryard氏による評価に反対するのは非常に難しい。しかし、私たちの実装にビジネスルールの自動化を含めることは間違いなく重要である。同時に、何が自動化され、何が人間によって実行されるべきかを決定する必要があるのだ。