Une astuce pour moderniser son « legacy »

Le « legacy » c’est le Système d’Information déjà en place… Celui qui est hérité des projets antérieurs et qui mériterait parfois d’être modernisé. Mais ce n’est pas forcément facile pour tout un tas de raisons. J’ai constaté récemment, qu’utiliser un moteur de règles pour moderniser son « legacy » peut s’avérer une option intéressante.

Externaliser l’intelligence du legacy

Un moteur de règles a pour objectif d’externaliser des applicatifs, l’intelligence métier et des règles de fonctionnement. Une fois que le moteur de règles est en place, les applicatifs métier, sont interfacés avec ce dernier. Pour faire simple, ils interrogent le moteur de règle et ce dernier lui retourne une réponse (une autorisation, un refus, une valeur…).

Les moteurs de règles ont l’avantage d’être « packagés » et de pouvoir être pris en main assez facilement. La création, la modification et le déploiement de nouvelles règles sont rapides et ne nécessitent pas ou peu de développement. On parle d’application « low code » dans la mesure où il n’est pas nécessaire de développer les règles mais qu’on peut, dans une large mesure, gérer les règles en quasi langage naturel. Ils ont vocation à être manipulés directement par des utilisateurs métier ou Maîtrise d’Ouvrage (MOA). C’est donc une façon de répondre à des besoins métier sans pour autant mettre les mains dans le code.

La structure des règles est identique pour toutes celles-ci. On définit la règle ainsi que les conditions d’application et enfin on indique le résultat. Ainsi, une règle se décomposera, par exemple, comme suit :

• Définition : validation d’une demande de crédit sur la base des revenus
• Conditions : si les revenus sont supérieurs à X et que le montant est inférieur à Y
• Résultat : alors le statut de la demande de crédit est changé à « acceptée »

Ainsi, là où l’application historique est difficile à faire évoluer et parfois « aride » pour les utilisateurs, le moteur de règle vient apporter de la souplesse et de la simplicité. L’externalisation de certaines fonctionnalités vient ainsi compléter le « core business » qui reste lui dans le legacy.

Les avantages d’un moteur de règles pour le legacy

En plus d’être simple à mettre en place, ce système bénéficie de quatre gros avantages :

1. X et Y se modifient plus facilement. En cas de modification de la règle métier (si le seuil X doit passer de 100 à 200), il ne sera pas nécessaire de modifier le code dans l’applicatif d’origine. On le change dans le moteur de règle et ce dernier effectuera les contrôles à la place de l’applicatif d’origine,
2. Ceci simplifie le déploiement et réduit les délais, les efforts et les coûts de modification. En effet, il n’est plus nécessaire de retester tout l’applicatif « legacy » qui se contente d’envoyer les informations et de recevoir le retour du moteur de règle,
3. Cela permet de responsabiliser les utilisateurs et responsables métier. Ils ont directement la main sur les applicatifs ce qui du coup permet là aussi d’avoir des applications plus en phase avec l’actualité du métier (ex. si les règles doivent être plus permissives ou plus drastiques en fonction de la stratégie business).
4. Enfin, l’aide à la prise de décision. Un moteur de règles permet surtout, à partir des éléments contextuels du métier et des événements produits par les applications métiers, internes ou externes, de fournir une décision intelligente et automatique ou de fournir des indices pour une prise de décision (on peut ainsi mettre en place des comités de validation des décisions sur les cas les plus complexes).

Ainsi, l’utilisation d’un moteur de règles apporte de la souplesse et de l’agilité. Ceci permettant d’éviter un SI trop figé et permet de suivre les évolutions métiers. Cela s’avère donc extrêmement pertinent lorsque ce Système d’information repose sur des applicatifs legacy.

Quels sont les résultats?

Sur un cas auquel j’ai récemment contribué, nous avons utilisé un moteur de règles externe pour éviter de coder les nouvelles contraintes réglementaires dans le legacy. Nous avons ainsi déployé près de 300 règles et contrôles métier en moins de 4 mois. Ceci représente un avantage évident dans la rapidité de déploiement d’autant modifier le legacy aurait pris bien plus longtemps et présenter un risque important de régression.

De plus, l’effort a été limité. Il aurait toujours été possible de faire coder les 300 règles dans les applicatifs Mainframes. Mais cela aurait représenté un effort considérable (spécification, développement et tests de validation).

Ici, le moteur de règle réduit également le temps passé par les opérationnels sur ces phases de contrôles qui sont dès lors automatisées. C’est donc un bénéfice opérationnel évident d’autant qu’on a ainsi réduit le risque opérationnel avec des contrôles systématisés.

Est-ce pour autant la panacée ? S’il y a des avantages indéniables à utiliser un moteur de règle, je peux vous dire que même si la modification d’une règle est aisée, elle ne doit pas être faite à la légère. En effet, il est parfois difficile d’assurer une cohérence de ces règles métier, surtout lorsque plusieurs intervenants doivent collaborer. Il est alors indispensable de bien documenter les règles métier et de prévoir une conception solide des règles et du modèle pour éviter de faire des erreurs.

En résumé, la mise en place d’un moteur de règles simplifie la modernisation de son legacy. Facile et rapide à mettre en place, l’application de ces règles métiers permet structurer le gouvernance des applications et d’adapter ou moderniser son système d’information.

Découvrez l’interview de Jérémy Amourous, DSI de Colissimo, qui explique les valeurs ajoutées de la mise en place d’une Architecture Réactive en temps réel.

(Merci à Han qui a co-écrit cet article!)