Tel que l’analyse Neal Ford à travers son concept d’Emergent Design, plus un projet (informatique) avance, plus les connaissances sur celui-ci sont avancées, ce qui demande à reculer au maximum toute prise de décision concernant ce projet.

La connaissance acquise est essentiellement métier et ergonomique (pour autant que la technologie employée est maitrisée). Si pour les aspects ergonomiques, un prototypage graphique peut (ou devrait) être proposé, comment faire de même avec le code sous-jacent, le code représentant les connaissances métier ?

Un première approche se base sur un processus itératif, suivant un processus dit “agile”. Cela est toutefois rarement compatible avec des langages de développement “classiques”. En effet, il faut alors prendre très tôt des décisions majeures et structurantes. De plus les changements deviennent de plus en plus difficiles et coûteux. Il conviendrait donc de pouvoir poursuivre le plus tardivement possible la phase de conception, ce qui peut apparaître contradictoire avec cette approche “agile”. De plus, l’expérience montre que même les meilleures des conceptions ne peuvent prévenir de nécessités de correctifs en phase de réalisation.

L’idéal serait donc de pouvoir disposer d’un langage tout à la fois de spécification tout en étant exécutable pour pouvoir valider cette même spécification à travers des cas de test. Cela est rendu possible par des langages de type “règles métier”. En effet, ceux-ci permettent pour la plupart de construire des modèles objets (dits “BOM”) de façon souple, voire dynamique, tout en proposant (plus ou moins automatiquement suivant le Business Rule Management System utilisé) un langage de type DSL permettant d’exprimer et d’exécuter des règles métier s’appliquant sur ces objets.

À noter que les principaux BRMS proposant une couche d’interfaçage entre le code décrivant les règles et le framework sous-jascent (Java, .NET, xml, Cobol, etc.), il est tout à fait possible de ne faire le choix de ce(s) framework(s) (plusieurs pouvant cohabiter) que tardivement en fonction des contraintes finales de l’application à développer.

On s’aperçoit également que cette technologie permet de gérer beaucoup plus facilement les cas particuliers. En effet, ces “cas” sont en général caractérisables par un ensemble de contraintes, pouvant être soit directement exprimées au niveau des règles, soit être gérées par le ruleflow. De plus, le fait d’exprimer clairement le domaine métier au sein de règles fait ressortir beaucoup plus facilement ces cas “hors normes”.

Enfin, il est bien rare que la première mise en production d’une application soit la dernière pierre de l’édifice. Les phases de maintenance et de migrations sont primordiales dans la vie d’un logiciel. Des correctifs et évolutions sont donc à prévoir. Ici aussi, les points soulignés ci-dessus (changement de framework sous-jascent, traitement des cas particuliers, etc.) pourront être mis à profit. Avec de plus un avantage décisif par rapport aux langages informatiques traditionnels : le code des règles étant tout à la fois le code exécuté (et donc évoluant avec les mises à jour) et les spécifications de l’application, il y a alors garantie de non divergence entre ces deux aspects, ce qui bien qu’essentiel pour la maintenance est rarement le cas pour la plupart des applications informatiques.

En conclusion, l’usage d’une approche “règles métier” permet de changer radicalement le mode de développement d’applications informatiques, tout particulièrement en permettant de retarder les prises de décisions au moment où la connaissance du sujet est enfin suffisamment avancée, tout en facilitant les ajustements rendus nécessaires dans les phases ultérieures du projet.

The post Ou comment reporter à plus tard… first appeared on In Fine - Le Blog.

“When should we, or not, use BRMS?” is the Question that arises almost every time Business Rules Management Systems are under discussion. Well, that’s a decision making, which may be handled by rules, in the form of a Decision Table…

The proposed rules to answer that question are not only based on technical aspects of BRMS, but also on organizational ones. In fact, those organizational aspects are often more important than the technical ones in the adoption of BRMS. Of course, those rules are not well formalized and their “Right Hand Side” (“then” part) may vary depending on the case. However, we hope that the following table could help in choosing or not a BRMS to develop an application.

The pluses and minuses of using BRMS:

Of course, that table is not complete nor rigid and your comments to improve it are welcomed.

The post BRMS, But When? first appeared on In Fine - Le Blog.