Débat : qui doit maintenir les règles métiers ?

Hier j'ai participé à un débat intéressant sur les BRMS et leur utilité pour changer la relation MOA-MOE. Il y avait là des DSI de sociétés utilisatrices de BRMS, des éditeurs de BRMS et des SSII qui mettent les BRMS en oeuvre. Nous étions une vingtaine. Les échanges ont été vifs et ont portés en particulier sur la possibilité donnée aux experts métiers, aux experts opérationnels d'éditer des règles métiers alors qu'ils n'ont pas été formé pour. 

Tout le monde dans la salle était d'accord pour dire que la tendance technique permet que les experts métiers soient de plus en plus autonomes. Tout le monde n'est pas forcément d'accord pour dire que c'est une bonne tendance tout en admettant que les frontières entre MOA et MOE sont de plus en plus floues et mouvantes.

Le premier débat a porté sur l'existence de deux familles de règles, appellons-les des règles MOA et des règles MOE. Les règles MOA seraient des règles que les experts métiers doivent maîtriser et les règles MOE des règles que les experts informatiques doivent maîtriser.

Ce point soulignerait un travers naturel, lorsque l'on dispose d'un BRMS on a tendance a mettre une trop grande partie de la logique sous forme de règles que ces règles soient des règles techniques ou des règles métiers. Je ne suis vraiment pas sûr que ce soit une bonne pratique, j'ai tendance à penser qu'il vaut mieux mettre sous une forme déclarative ce qui est de la logique métier et sous une forme impérative ce qui est de la logique technique. Ainsi on isole mieux les parties métiers et les parties techniques, si tant est que cela soit possible et que le contexte s'y prête.

Au fur et à mesure de ce débat, le monde s'est complexifié il est passé d'un monde binaire MOA-MOE  à un monde où les responsabilités sont multiples : il y a dans tout système plusieurs expertises métiers et plusieurs expertises pour interfacer ces bases de règles avec les systèmes existants. 

Fort de ce constat, nous avons plus ou moins unanimement conclu que ce qui comptait c'était bien un partage clair des responsabilités et que ce partage clair soit cohérent avec le découpage informatique.

C'est ce point qu'il convient de clarifier.  Il y a plusieurs expertises métiers, cela signifie soit qu'il y a plusieurs experts qui partagent la même expertise ou cela signifie qu'il y a plusieurs domaines d'expertise. 

Dans le cas où il y a plusieurs domaines d'expertise cela signifie que chaque expert à en charge la maintenance de son paquet de règles. Dans l'autre cas où il y a partage d'expertise cela signifie que chaque expert peut valider le travail d'un autre expert.

Dans le premier cas les droits de modification des règles sont liés à des bases différentes, dans l'autre cas les droits de modification concernent le même type de base.

Si le découpage technique n'est pas cohérent avec le découpage organisationnel, le risque est que chacun puisse changer n'importe quelle règle n'importe quand, là est le début de la fin ! 

Dependency and duplication

Steve Freeman pointed out that the problem with the test and code as it sits is not duplication. The problem is the dependency between the code and the test - you can't change one without changing the other. Our goal is to be able to write another test that "makes sense" to us, without having to change the code, something that is not possible with the current implementation.
Dependency is the key problem in software development at all scales. If you have details of vendor's implementation of SQL scattered throughout the the code and you decide to change to another vendor, then you will discover that your code is dependent on the database vendor. You can't change the database without changing the code.
If dependency is the problem, duplication is the sympton. Duplication most often takes the form of duplicate logic - the same expression appearing in multiple places in the code. Objects are excellent for abstracting away the duplication of logic.
Unlike most problem in life,where eliminating the symptons only makes the problem pops up elsewhere in worse form, eliminating the duplication in programs eliminates dependency. That's
why the second rule appears in TDD. By eliminating duplication before we go on to the next test, we maximize our chance of being able to get the next test running with one and only one change.


Kent Beck - 2004

Drools 5.1 and Eclipse 3.6 Installation

Here is how I have installed Drools 5.1 and Eclipse 3.6.

It’s just like it is described in the drools documentation.

There are few differences :

• Zip file names to download are given
• At each step a test is given in order to check how things are going
• Only one way of installation is given in order to simplify the installation process

1. Java
1. check java -version (java 1.5 is required)
2. Drools documentation

1. go to jboss.org/drools/downloads.html
2. download drools documentation (50.8MB)
3. read chapter 3 from drools introduction
1. Eclipse modeling tools 3.6 (Helios)
1. go to www.eclipse.org/downloads/
2. download and extract eclipse modeling tools (249 MB)
3. run eclipse
4. check if you can find GEF 3.4 or greater
5. exit eclipse
2. Drools 3.5 Eclipse Workbench
1. go to jboss.org/drools/downloads.html
2. download Drools 3.5 Eclipse Workbench
3. unzip this file in eclipse directory
4. run eclipse
5. it’s ok if you can open the drools perspectice
3. Download Drools binaries 5.1
1. go to jboss.org/drools/downloads.html
2. download and extract the binaries
3. run eclipse
4. click windows/preferences/drools/drools runtime and enter the path where the downloaded file has been extracted
5. click files/new/drools project
6. enter a project  name
7. click next and choose to add a  hello word test sample and to add a sample java class to load and run the hello world
8. check : compile and run this project  as a java application

Glossaire versus ontologie

Il est naturel de chercher à écrire des règles métiers qui soient faciles à lire et à comprendre à la fois par des dirigeants, des experts métiers et des informaticiens.

Pour que ces règles soient facile à lire et à comprendre, il est au moins nécessaire d’utiliser des termes et une syntaxe bien connus de l’ensemble de ces trois catégories de lecteurs.

Il ne suffit d’ailleurs pas que ces termes soient connus par tous mais il faut aussi qu’ils évoquent à chacun le même sens, autant éviter quiproquos et autres malentendus, ils sont parfois amusants mais génèrent surtout beaucoup d’inefficacités.

L’outil le plus couramment utilisé pour faire connaître et unifier le sens des termes s’appelle un glossaire. La rédaction d’un glossaire est une tâche difficile à réaliser, en tous cas souvent plus difficile que l’on ne se l’imagine. Seul ou à deux tout va à peu près bien, mais dès que le nombre de participants à l’élaboration de ces définitions augmentent, les discussions sans grand intérêt s’éternisent et se multiplient. Le groupe finit presque toujours par s’entendre, chacun peut sortir la tête haute, mais souvent au prix de définitions ambiguës et peu expressives.

L’utilisation d’ontologies est un bon moyen pour aboutir efficacement à des définitions qui parlent, c’est-à-dire plutôt que de rechercher à directement définir des termes, il s’agit d’identifier les concepts structurants, puis à les relier avec des relations explicites. Ces relations étant d’ordre sémantique ou taxinomique.

En pratique, cela consiste à établir un graphe orienté. Les noeuds du graphe sont les concepts et les flèches les relations. Une relation “exemple-de” peut clarifier facilement un concept. Ou autre exemple, les concepts peuvent être des classes ou des objets, les relations peuvent être des relations d’héritage ou d’instanciation, ces instances peuvent être des exemples servant à clarifier le sens de la classe.

Ce type de graphe, s’avère à la fois plus facile à faire valider par le plus grand nombre et plus pédagogique qu’un glossaire.

En effet, un terme est plus facile à expliquer lorsqu’il est plongé dans un contexte clair.
La proximité géographique des concepts les uns avec les autres est un excellent moyen pour exprimer du sens.
Elle permet d’ailleurs de différencier des homonymes sans nécessiter de longues explications.
Ces diagrammes permettent d’exprimer plus de sens avec moins de mots.

A l’inverse lorsque le contexte d’utilisation d’un terme n’est pas connu, chacun plonge ce terme dans le contexte qui lui est le plus naturel, contexte qui n’a que peu de chance d’être compatible avec celui pour lequel la définition a été conçue. Ce non-partage de contexte engendre souvent incompréhensions et quiproquos.

Il faut bien noter que ce type de graphe ne remplace pas un glossaire quand des définitions précises sont nécessaires mais il en facilite grandement la réalisation.

En résumé : plutôt que de se lancer directement dans la rédaction d’un glossaire mieux vaut d’abord passer par la réalisation d’une ontologie. C’est une manière simple et efficace pour donner du sens aux termes et le partager avec d’autres. Quand c’est nécessaire, elle peut être complétée par un glossaire.