ルール エンジンを組み込んだシステムが本当に成功したことがありますか?[閉まっている]

Question

当社のシステム (エキゾチック商品デリバティブ取引の捕獲とリスク管理) は間もなく再開発される予定です。私が聞いた提案の 1 つは、エンドユーザー (商品トレーダーなのでかなり洗練されている) がビジネス ロジックに特定の変更を加えやすくするためにルール エンジンが組み込まれるというものです。

私はルールエンジンには少し懐疑的です。私の中のアジャイル主義者は、それらはプロセスの問題に対する単なる技術的な解決策ではないかと疑問に思っています...つまり。開発者がビジネスの変化のニーズに対応するには時間がかかりすぎます。この問題の解決策は、開発に対するより協力的なアプローチ、より良いテスト カバレッジ、よりアジャイルなプラクティスをあらゆる面で行う必要があります。

ルール エンジンが本当に恩恵を受けた状況 (特にトレーディング環境) について聞けば、確かに役立つでしょう。

Answer 1

Fair IssacのBlaze Reteエンジンを使用した2つのアプリケーションを見ました。

1つのアプリケーションが、数千のルールを1つの知識ベースに非難し、ひどいメモリ問題を抱え、ほとんど理解されていないブラックボックスになりました。私はそれを成功とは呼びませんが、本番環境で実行されています。

別のアプリケーションでは、意思決定ツリーを使用して、医療フォームに何百もの質問を表示して、クライアントを処分しました。これは非常にエレガントに行われたため、ビジネスマンは開発者を関与させることなく、必要に応じてルールを更新できます。 （それでも1人で展開する必要があります。）私はそれを大成功と呼びます。

そのため、問題の焦点、ルールセットのサイズ、開発者の知識に依存します。私の先入観は、単にルールエンジンを単一障害点にし、そこにルールをダンプすることはおそらく良いアプローチではないということです。データ駆動型またはテーブル駆動型のアプローチから始めて、ルールエンジンが必要になるまでそれを成長させていました。また、オブジェクトの動作の一部としてルールエンジンをカプセル化するよう努めています。ルールエンジンをユーザーから隠し、ルールスペースをドメインモデルに分割しようとします。

Answer 2

これらが本当に恩恵だと言うかどうかはわかりませんが、確かに価値があると思います。私は保険業界で数年間システムに取り組みました。そこでは、ルールエンジンが非常にうまく採用され、ビジネスユーザーが州に応じて合法なポリシーを決定するルールを作成できるようになりました。

たとえば、特定の州で自己負担しなければならない場合、または控除対象と自己負担の特定の組み合わせは、製品の考慮または州法により単に違法であるために許可されていません。

会社が稼働している州の数と、規則の絶え間ない変更（四半期ごと）により、これはめまいがするコーディングの習慣になります。さらに重要なことは、プログラマーの専門知識ではありません。エンドユーザーが、実際のルールを説明する際に、保険業界の専門家ではないプログラマーに無意味なコミュニケーションを追加します。

正しく設計されたルールエンジンは、良好なテストを可能にするワークフローシステムを有効にすることができます。この場合、ルールはデータベースに保存され、QAおよびPRODデータベースがありました。したがって、BAはQAでルールをテストし、PRODに昇格させることができます。

他のものと同様に、通常は実際の手法ではなく実装に関するものです。

Answer 3

はい、MicrosoftにはBizTalkのビジネスルールエンジン（BRE）があり、長年にわたって正常に使用されています。 BREのためだけにクライアントにBizTalk（非常に高価な）を購入してもらったと聞きました。

私の経験では、ビジネスユーザーがルールを更新することの実用性はほとんどありません。通常、ビジネスルールエディタを操作するには技術者が必要です。

Answer 4

ルールエンジンは、宣言文を実行するものにすぎません。彼らには2つの主な利点があります（私が見る）：

1. ビジネスロジックは、アプリケーションコード全体に散らばるのではなく、1か所から管理されます。技術的には、適切に設計されたアプリケーションは、ルールエンジンが存在するかどうかに関係なく、既にアーキテクチャでこれを行う必要があります。
2. 宣言文間の依存関係について心配する必要があります。ルールエンジンは、依存関係に基づいてルールを実行する順序を決定するのに十分スマートでなければなりません。一部のルールエンジンは、ルールセット内のルールの連続的な順序付けまたは特定の順序でルールセット（ルールのグループ）を呼び出すことができますが、これは実際には宣言型プログラミングの精神ではありません。多くのルールエンジンは、Rete（アルゴリズム）を使用して、宣言ステートメントの実行をいつスケジュールするかを決定します。

すべてではありませんが、ほとんどのルールエンジンは、ルールエンジンを使用しない最適なプログラムを作成する場合よりもオーバーヘッドが増えると思われます。これは、アセンブリでのコードの記述が一般にコンパイラよりも高速であることに似ています（ただし、高レベルの抽象化を使用する方が便利で生産的であるため、通常はアセンブリを記述しません）。

ここで停止する場合、おそらくプログラマを使用してルールを維持し、ルールエンジンを使用して、アプリケーションにビジネスロジック層を構築するのが便利です。一部のルールエンジンは、ルール用のテンプレートを定義できるテンプレートと呼ばれるものを提供します。ここでの利点は、技術に詳しくないユーザーでも独自のルールを作成し、既存のルールを変更できることです。

ルールエンジンは、ツールチェストにあるもう1つのツールであり、適切に使用すると価値があります。

Answer 5

これらのルールエンジンの多くに伴う問題は、速度の欠如と、ルールを置換または拡張すると、既存の作業ルールが微妙に破壊される可能性があるという事実です。そのため、各ルールを変更した後は、システムを徹底的に再テストする必要があります。つまり、基本的には、あるコンピューター言語を別のコンピューター言語に交換するだけです。ユーザーの数がはるかに少ない言語です。別のポスターで述べたように、ビジネスアナリストがルールエンジンをうまく使用しているのを見たことはありません。とにかくプログラマが必要です。

Answer 6

私は確かに持っていますが、それらについて公に話すことはできませんが、おそらくあなたは今年何回かやり取りしたと思われます;）

私は、論理プログラマーとビジネスユーザーの2つのキャンプでそれを見ています。さまざまなツールがさまざまなセットをターゲットにしていますが、その両方が対象です。ビジネスユーザーの成功事例は、それがロジックのサブセットである場合にのみ機能し、テストケースを定義して自分で実行する方法もありました（そして、論理的に考える準備ができています）。 ロジックプログラマーはまれですが、非命令型プログラミングのバックグラウンドから来ていることがよくあります（関数型プログラミングを直感的に理解する人もいます）。

コンピュータにまだプログラミング中の何かをするように指示している場合は、視覚的なツールを使用しても1日の終わりに注意してください。

Answer 7

私はこの分野で多くのベンダーと仕事をしていますが、このことの素晴らしい点の 1 つは、多くの顧客と話すことができることです。そう、何百もの企業が その通り 約束されたメリット - 俊敏性の向上、ビジネス/IT コラボレーションの向上、規制遵守の容易化、意思決定の一貫性の向上、メンテナンスコストの削減、市場投入までの時間の短縮など。

すべての主要ベンダーやオープンソース プレーヤーにわたって、多くのルール、頻繁に変更されるルール、複雑な方法で相互作用するルール、または他のルールと相互作用するルールを使用して、大量の運用上の意思決定を自動化および改善するために、これが正しく使用されていることが何度も見られました。ビジネス ドメインの内容が高い - ビジネス ルール管理システムが機能します。

本当に。

Answer 8

私の経験は、（i）それほど多くなく、（ii）プロローグに限定されています。しかし、ルールエンジンは、手続き型コードよりもはるかに明確な命題の概念を表現するのに役立ちます。

Answer 9

保険エンジンでは、規則エンジンが日常的に使用されています。私は、ルールエンジンに実装された数百（600の）ルールを持つシステムに取り組んできました。とてもうまくいきました。

Answer 10

信用格付けはありますか？おそらく FICO スコアですか？これは、Blazeルールエンジンの開発者である F air I saac CO 企業です。

Answer 11

しばらくの間、大規模で大量の大気データを計算するシステムを開発していたPEATE分散コンピューティングプロジェクトに携わりました。システムには、データマネージャー、スケジューラー、アルゴリズム実行コンポーネントの3つの部分がありました。これらのコンポーネントはいくつでもあり、すべてWebサービスを通じて行われますが、許可されたのは、さまざまな研究者が任意のデータに対して任意のジョブを実行し、要件の変更に応じて異なるスケジューリングメカニズムをプラグインできるようにすることでした。

プロジェクトが地面から離れすぎてしまう前に去りましたが、これは潜在的にシナリオに適合し、ある種のルールエンジンの別の例として役立つ可能性があるようです。ただし、元の開発者がまだアルゴリズムを実行する開発者である場合、各ルールまたはアルゴリズムが発生する実質的なオーバーヘッドを処理しない限り、ルールエンジンを持つことにはあまりメリットがありませんそれは自分のものです。

これは単純なルールエンジンよりも少し複雑に聞こえますが、そのようなアーキテクチャはルールエンジンにも適用できる可能性があります。