Un système intégrant un moteur de règles a-t-il déjà vraiment été couronné de succès? [fermé]

StackOverflow https://stackoverflow.com/questions/206425

  •  03-07-2019
  •  | 
  •  

Question

Notre système (capture des transactions sur produits dérivés exotiques et gestion des risques) est en cours de réaménagement. L’une des propositions que j’ai entendu dire est qu’un moteur de règles sera intégré pour permettre aux utilisateurs finaux (négociants en produits de base, donc assez sophistiqués) d’apporter certaines modifications à la logique d’entreprise.

Je suis un peu sceptique quant aux moteurs de règles. L'agiliste en moi se demande s'il ne s'agit que d'une solution technique à un problème de processus ... c'est-à-dire. nos développeurs mettent trop de temps à répondre au besoin de changement de l'entreprise. La solution à ce problème devrait être une approche plus collaborative du développement, une meilleure couverture de test, des pratiques plus agiles.

Entendre parler de situations dans lesquelles un moteur de règles était vraiment une aubaine (en particulier dans un environnement commercial) serait certainement utile.

Était-ce utile?

La solution

J'ai vu deux applications utilisant le moteur Blaze Rete de Fair Issac.

Une application a regroupé des milliers de règles dans une seule base de connaissances, a eu de terribles problèmes de mémoire et est devenue une boîte noire que peu de personnes comprennent. Je n’appellerais pas cela un succès, mais la production est en cours.

Une autre application a utilisé des arbres de décision pour représenter environ 100 questions sur un formulaire médical destiné à un client concerné. Cela a été fait avec une telle élégance que les hommes d'affaires peuvent mettre à jour les règles au besoin, sans impliquer de développeur. (Cela reste à faire, cependant.) Je qualifierais cela de grand succès.

Cela dépend donc de la concentration du problème, de la taille de l'ensemble de règles et de la connaissance des développeurs. Mon préjugé est que faire d'un moteur de règles un point unique d'échec et que l'inclusion de règles dans ce dernier ne soit probablement pas une bonne approche. Je commencerais par une approche basée sur les données ou sur des tables et je l'aurais développé jusqu'à ce qu'un moteur de règles soit nécessaire. Je m'efforcerais également d'encapsuler le moteur de règles dans le comportement d'un objet. Je masquais le moteur de règles aux utilisateurs et tentais de partitionner l'espace de règles dans le modèle de domaine.

Autres conseils

Je ne sais pas si je dirais qu’ils ont toujours été une véritable aubaine, mais je pense qu’ils peuvent certainement être utiles. J'ai travaillé sur un système pendant quelques années dans le secteur des assurances, où un moteur de règles a été utilisé avec assez de succès pour permettre aux utilisateurs professionnels de créer des règles qui déterminent quelles politiques sont légales, en fonction de l'état.

Par exemple, si vous deviez avoir une quote-part dans certains États, ou si certaines combinaisons de franchise et de quote-part n'étaient pas autorisées, soit en raison de considérations relatives au produit, soit simplement parce qu'elles étaient illégales en raison de la loi en vigueur dans votre État.

Le nombre d’États dans lesquels la société opère, ainsi que le changement constant de règles (tous les trimestres), en feraient une pratique de codage vertigineuse. Plus important encore, ce n'est pas dans l'expertise d'un programmeur. Cela ajoute une communication inutile supplémentaire lorsque l’utilisateur final décrit la règle à appliquer à un programmeur qui n’est pas un expert du secteur de l’assurance comme ils le sont.

Conçu correctement, un moteur de règles peut toujours activer un système de flux de travail permettant de réaliser de bons tests. Dans ce cas, les règles étaient stockées dans une base de données et il existait des bases de données QA et PROD. Les BA peuvent donc tester leurs règles en matière d’AQ, puis les promouvoir au format PROD.

Comme pour toute chose, il s’agit généralement de la mise en oeuvre, et non de la technique réelle.

Oui, Microsoft a un moteur de règles métier (BRE) dans BizTalk utilisé avec succès depuis des années. J'ai entendu dire que des clients avaient acheté BizTalk (très cher) uniquement pour le BRE.

Selon mon expérience, la possibilité pour un utilisateur professionnel de mettre à jour les règles est pratique. Il faut généralement un technicien pour travailler avec l’éditeur de règles commerciales.

Un moteur de règles n’est guère plus que quelque chose qui exécute des instructions déclaratives. Ils viennent avec deux avantages principaux (que je vois):

  1. Votre logique métier est gérée à partir d'un emplacement unique au lieu d'être éparpillée dans le code de l'application. Techniquement, une application bien conçue devrait déjà le faire avec l’architecture, qu’un moteur de règles soit présent ou non.
  2. Vous devez vous soucier [moins] des dépendances entre les déclarations. Le moteur de règles doit être suffisamment intelligent pour décider de l'ordre d'exécution des règles en fonction des dépendances. Vous constaterez peut-être que certains moteurs de règles prennent en charge un ordre séquentiel des règles dans un ensemble de règles ou des ensembles d'appels de règles (groupes de règles) dans un ordre particulier, mais cela ne correspond pas vraiment à l'esprit de la programmation déclarative. De nombreux moteurs de règles utilisent Rete (un algorithme) pour décider quand planifier l'exécution des instructions déclaratives.

Je pense que la plupart des moteurs de règles, voire tous, ajoutent plus de temps système que si vous deviez écrire le meilleur programme possible qui n'utilise pas de moteur de règles. Ceci est similaire à la manière dont l'écriture de code dans l'assembly est généralement plus rapide qu'un compilateur (mais vous n'écrivez généralement pas d'assembly car il est plus pratique et productif d'utiliser des abstractions de niveau supérieur).

Si vous vous arrêtez ici, vous utiliseriez probablement des programmeurs pour gérer les règles et utiliser un moteur de règles comme moyen pratique de créer un niveau de logique métier dans votre application. Certains moteurs de règles proposent des modèles qui vous permettent de définir des modèles pour les règles. L’avantage ici est que les utilisateurs non techniques sont supposés être capables d’écrire leurs propres règles et de modifier les règles existantes.

Un moteur de règles est un outil de plus dans votre coffre à outils qui, utilisé correctement, peut être utile.

Le problème avec beaucoup de ces moteurs de règles est le manque de rapidité et le fait que le remplacement ou l’augmentation des règles peut enfreindre les règles de travail existantes de manière subtile. Il vous reste donc à tester à nouveau le système après chaque changement de règle. En gros, vous n'échangez donc qu'un langage informatique contre un autre - un avec un nombre d'utilisateurs beaucoup plus réduit. Comme l'a mentionné une autre affiche, je n'ai pas encore vu un analyste métier utiliser avec succès un moteur de règles. De toute façon, vous avez besoin d’un programmeur.

Oui, certes, mais je ne peux pas en parler publiquement, mais vous avez probablement interagi avec plusieurs fois cette année;)

Je le vois dans 2 camps: les programmeurs logiques et les utilisateurs professionnels. Différents outils ciblent différents ensembles, certains les deux. Les cas réussis d’utilisateurs professionnels n’ont fonctionné que s’il s’agissait d’un sous-ensemble de la logique, et ils avaient également un moyen de définir des cas de test et de les exécuter eux-mêmes (et ils sont prêts à penser logiquement). Les programmeurs logiques sont plus rares, mais peuvent souvent provenir d’arrière-plans de programmation non impératifs (ce sont aussi des personnes qui trouvent la programmation fonctionnelle intuitive).

N'oubliez pas qu'à la fin de la journée, même avec des outils visuels, si vous demandez à un ordinateur de faire quelque chose, il le programme toujours.

Je travaille avec beaucoup de fournisseurs sur le marché et l'un des avantages de cette solution est que je peux parler à beaucoup de leurs clients. Alors, oui, des centaines d'entreprises ont obtenu exactement les avantages qui leur avaient été promis: agilité accrue, meilleure collaboration entre les entreprises et les TI, plus grande conformité aux réglementations, meilleure prise de décision, coûts de maintenance réduits, mise sur le marché plus rapide etc.

Je constate que, main dans la main, tous les principaux fournisseurs et les acteurs open source ont été utilisés correctement - pour automatiser et améliorer les décisions opérationnelles volumineuses avec de nombreuses règles, des règles qui changent beaucoup, des règles qui interagissent de manière complexe ou des règles avec un contenu de domaine professionnel élevé - les systèmes de gestion de règles métier fonctionnent.

Vraiment.

Mon expérience est limitée à (i) pas beaucoup et (ii) au prologue; mais je peux affirmer sans crainte qu'un moteur de règles peut vous aider à exprimer des concepts propositionnels beaucoup plus propres qu'un code de procédure.

Les moteurs de règles sont couramment utilisés dans le secteur des assurances. J'ai travaillé sur des systèmes avec des centaines (600) de règles implémentées dans un moteur de règles. Cela a très bien fonctionné.

Avez-vous une cote de crédit? Une note de FICO , peut-être? Il s’agit du F air I saac CO , développeur du moteur de règles Blaze.

Pendant un certain temps, j'ai travaillé pour le projet d'informatique distribuée PEATE, qui développait un système de calcul de données atmosphériques à grande échelle et à volume élevé. Le système comportait trois parties: le gestionnaire de données, le planificateur et le composant d'exécution de l'algorithme. Tous ces composants peuvent être utilisés par le biais de services Web, mais cela permettait à différents chercheurs d'exécuter des tâches arbitraires contre des données arbitraires, tout en permettant de brancher différents mécanismes de planification en fonction des exigences.

J'ai quitté le projet avant qu'il ne soit trop éloigné du projet, mais il semble que cela pourrait éventuellement correspondre au scénario et servir d'exemple supplémentaire à un type de moteur de règles. Cela étant dit, cependant, si les développeurs d'origine sont toujours ceux qui doivent exécuter les algorithmes, je ne vois pas vraiment l'avantage d'un moteur de règles, à moins qu'il ne gère un temps système important que chaque règle ou algorithme subirait. c'est propre.

Cela semble un peu plus compliqué qu'un simple moteur de règles, mais une telle architecture pourrait également s'appliquer à un moteur de règles.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top