Mardi 07 mars 2006
Le rachat de Fuego par BEA ($87,5m en cash) la semaine dernière et l’acquisition récente de FiveSight Technologies par Intalio ramènent à l’avant-scène le thème des « business rules ». L’idée d’isoler la « logique métier » des applications informatiques d’entreprise – exactement comme la mutualisation de la gestion de données a créé les systèmes de gestion de bases de données, dont l’énorme marché a donné, vingt cinq ans après, des leaders comme Oracle, IBM, Microsoft et Sybase – renvoie aux toutes premières réflexions sur l’architecture client-serveur dans les années 1980. L’apothéose de ce discours fut atteinte avec la fameuse « 3-tier architecture » en trois niveaux, de l’utilisateur jusqu’aux données d’entreprise : l’interface graphique, la gestion de la logique métier et la gestion des données. Piliers de la réutilisation, chacun de ces niveaux devait être utilisable par différentes applications partageant (partiellement ou totalement) leurs données, leurs règles métier, voire leur interface graphique.
Cette architecture, au départ présentée pour les bénéfices techniques qu’elle pouvait apporter au système d’information de l’entreprise, et servant, devrais-je ajouter, les vues commerciales des vendeurs de PC, de réseaux locaux et de leurs systèmes d’exploitation de l’époque, a remarquablement résonné en France, en particulier, où elle a concrétisé tout le courant de réflexion sur la modélisation et sur l’urbanisme des systèmes d’information. Est-ce le fond « cartésien » français, l’idiosyncrasie du marché informatique européen avec le rôle prééminent tenu par les SSII et les intégrateurs, l’historique ancien du développement de méthodes d’analyse et de conception en Europe – l’un des « three amigos » à l’origine du repositionnement complet de Rational dans les années 1990, Ivar Jacobson, est d’origine suédoise et avait développé Objectory fusionné dans Rose - ; quoi qu’il en soit, l’architecture identifiant les business rules acquérait ici une forme de légitimité conceptuelle.
Or, l’ambiguïté sur le terme de « rules » illustre l’opposition entre deux conceptions de ces fameuses règles métier. Les deux conceptions des business rules sont toujours d’actualité : elles s’opposent maintenant sur un terrain technologique qui a changé avec la banalisation du Web et de XML pour les applications de l’informatique d’entreprise. C’est cette ambiguïté qui permet à des sociétés aussi différentes que FairIsaac, Ilog, Corticon, Webmethods, Seebeyond/Sun, Versata/Trilogy, Sybase, IBM, Oracle, BEA et Microsoft de se réclamer des business rules.
Une vision "locale" des règles métiers
Dans la première acception, les règles métier représentent effectivement les connaissances « métier » requise pour résoudre un problème particulier, pour évaluer un risque, pour parvenir à un diagnostic etc. Inspirée des travaux des chercheurs en Intelligence Artificielle, ces règles, que l’on appelait à l’époque suivant son allégeance dogmatique, soit règles de production, soit règles d’inférence, soit encore clauses de Horn, capturent sous une forme simple et automatisable les « granules » d’expertise des spécialistes métier du problème en question. (Ainsi des systèmes experts de référence, véritables incunables de l’approche IA, comme MYCIN, DENDRAL, R1/XCON et INTERNIST).
Au plan technique, l’idée directrice est celle de « pattern directed » ou « data driven control » : le programme est entièrement contrôlé par l’existence de relations particulières entre données valuées, par opposition au contrôle impératif d’un langage de programmation classique.
C’est comme si pour indiquer un itinéraire entre le point A et le point B – entre l’énoncé d’un problème et sa solution – l’expert ne donnait que des informations locales : lorsque l’on voit tel monument, tourner à droite ; lorsque l’on passe le second feu rouge, poursuivre jusqu’au croisement, etc. En suivant ces indications individuelles au moment où la situation se présente, sans préjuger de l’ordre dans lequel elles sont suivies, on est mené du point A au point B. On comprend que ce dispositif est sensible à d’autres formes de perturbation que ne l’est un programme informatique impératif. Si l’on se trouve dans une situation imprévue par les conditions des règles le système s’arrête, perdu. En revanche, si se produit une erreur dans le suivi d’une règle, le système peut éventuellement se « rattraper » si une situation se représente ultérieurement : on applique à nouveau une règle qui remet dans le droit chemin.
Une vision qui s'appuie sur un bus d'entreprise
Une seconde conception des business rules sous-tend les technologies d’EAI et de workflow. Dans cette deuxième acception du terme, les règles modélisent l’enchaînement des tâches et des transactions, couvrant éventuellement plusieurs applications d’entreprise et, dans ce cas, précisant les transformations à appliquer aux données lors du passage d’une application à la suivante.
Au plan technique, le contrôle est impératif car cet enchaînement ordonné des tâches est toujours le même, prévu dès la phase de conception – d’où l’intérêt actuel pour l’extension de notations comme UML à la capture des business rules dans ce sens. Souvent, l’implémentation de ce contrôle impératif fait appel à des messages transitant sur un « bus » applicatif, parfois appelé « bus d’entreprise », avec de nombreuses variantes suivant que les messages sont synchrones (RPC) ou asynchrones (MQS), en XML ou non, et que les protocoles de transport sont Web (http, voire SMTP) ou plus anciens (Corba, DCOM, Java RMI).
Naguère, ces business rules étaient le modèle des fameuses « procédures stockées » et des « triggers » des bases de données relationnelles. Les éditeurs de SGBD, déjà devenus grands fournisseurs de l’informatique d’entreprise, tiraient alors à eux la couverture en tentant de phagocyter le niveau « logique métier » et de l’absorber dans leurs serveurs de données. À l’ère du Web et de XML, c’est le même débat, transposé dans les technologies modernes. On parle alors plus volontiers de « business process » pour désigner une collection cohérente de « business rules » dans ce deuxième sens. Le produit Biztalk Server de Microsoft est une illustration de cette vue des business rules ; au plan des standards, l’initiative BPML, (datant de 2000) de formalisation d’un langage XML pour la représentation des « business processes », fusionnée avec la spécification comparable BPEL en est aujourd’hui à sa version 2.0.
Cette vue transactionnelle des règles métier, que l’on pourrait qualifier d’analytique, peut donc être distinguée de la première conception, franchement orientée résolution de problème, et que l’on qualifiera du coup de synthétique. Ces distinctions se révèlent tant au plan technique qu’au plan des objectifs business qu’elles servent chacune. L’évolution générale des idées de Services Web reflète plus ou moins cette distinction dans sa version moderne : d’un côté le « stack » des Web Services pour les applications d’entreprise (toute la floraison de spécifications WS-*, BPEL, UBL, etc.) où règnent les notions de transaction, de sécurité, de « provisioning » et d’administration – dans lequel s’opposent partisans de l’architecture dite REST et de celle appuyée sur SOAP ; et de l’autre, quelque chose qui serait plutôt illustré par le Web Sémantique, centré sur la représentation des connaissances (RDF et OWL), l’annotation, l’échange et la réconciliation de modèles – sujets qui ne sont pas non plus exempts de débats théoriques, voir, par exemple, « Ontology is Overrated — Categories, Links, and Tags » de Clay Shirky.
La sensibilité sur cette distinction est telle que l’OMG a même adopté il y a quelques jours une spécification abstruse, SBVR, pour « Semantics of Business Vocabulary and Business Rules », normalisant le vocabulaire descriptif à employer pour la documentation des objets et des règles métier. Ce vocabulaire est interprétable, dixit la spec., en logique des prédicats, avec, nous précise-t-on quand même, une petite extension en logique modale ! Voilà qui rassure certainement les « business people » à qui la spécification est destinée... Le W3C, quant à lui s’intéresse à la définition de formats d’échange entre systèmes de gestions de règles métier, le RIF (« Rule Interchange Format »). Au sein du W3C, les travaux du groupe technique Production Rule Representation, dirigés par Paul Vincent, visent précisément à jeter les premières passerelles entre les deux conceptions des business rules mises en œuvre dans toute une variété de progiciels. Ce rapprochement est considéré comme indispensable pour passer des Services Web aux Services Web sémantiques
