Un avis ? Un commentaire ?
Cet espace est pour vous.
ODASE est un logiciel permettant de formaliser la réalité du métier, de façon à constituer un référentiel exploitable par une multitude d’applicatifs.
La semaine dernière, nous accueillions Rémi Le Brouster pour nous parler de cette solution, de ses objectifs et du changement de paradigme que cela entraîne pour la définition des règles métier.
Nous nous retrouvons cette semaine pour échanger sur l’intégration de cette solution dans le quotidien des acteurs techniques.
RLB : Avec l’équipe informatique côté client, on définit en parallèle comment ils souhaitent interroger l’outil. On peut par exemple déterminer un ensemble de services pour interroger ODASE, auquel cas on établit alors un contrat d’API. Nous nous occupons alors de réaliser la partie technique qui va proposer les services, transmettre les informations à l’outil, demander le résultat, et le retourner. Ainsi, ni le client, ni le serveur n’ont à connaître le fonctionnement métier.
RLB : Les développeurs n’étant pas une entité unique, je suppose que leur accueil de la solution doit varier. Par exemple, je sais qu’en tant que développeur, j’adore me creuser la tête sur des problématiques métiers, définir le périmètre précis et les cas limites, et trouver des algorithmes efficaces, ce que rend obsolète ODASE sur la partie métier, le périmètre et les cas limites étant modélisés en amont, et les résultats étant calculés par l’outil.
A ma connaissance, la plupart des développeurs préfèrent s’occuper de la partie technique, ce qu’ils ont encore plus le loisir de faire grâce à notre outil. Cela leur évite également les frustrations de devoir gérer des spécifications métiers qui ne sont pas toujours limpides, ou de se rendre compte trop tard de la divergence entre la réalité métier et ce qu’ils en avaient compris, ce qui invalide parfois toute leur implémentation.
RLB : Dans une approche idéale où le client embrasse intégralement l’approche ODASE, notre solution devient en effet le point névralgique du système d’information, et je pense qu’il est essentiel de comprendre pourquoi, afin de saisir aussi en quoi cela peut aussi être émancipateur, notamment si le client veut changer totalement d’approche plus tard, et refondre son système d’information tout en revenant à une approche classique.
Tout d’abord, je tiens à rappeler que le système d’information ne se limite pas simplement à de l’applicatif, mais inclut aussi l’ensemble des échanges entre les acteurs et leur accès aux informations et documentations.
Dans une approche classique, la définition du métier est morcelée. Elle se trouve dans les connaissances et souvenirs des différents acteurs, dans des brouillons papiers, dans des mails, dans des outils de ticketing, dans des documents à destination du métier, des développeurs, du support ou des utilisateurs, dans le code aussi bien en langage informatique qu’en commentaires, etc. Il devient alors difficile d’interroger ces connaissances, et de savoir quelle source est fiable pour quel aspect. Car une spécification peut être obsolète ou décrire un changement qui n’a pas encore été implémenté, et même un expert avec une excellente connaissance métier peut se tromper, surtout face à des spécifications changeantes; l’interprétation du code par un humain peut passer à côté de certains cas particuliers, et le code lui-même est rarement une source unique, avec de multiples applications intégrant différentes règles, et comme nous venons de le voir, ces règles varient selon la source qui a été choisie en amont.
Dans l’approche ODASE, l’essentiel de notre travail est d’agréger toutes les connaissances de l’ensemble du domaine à modéliser, et de clarifier ce qu’est la vérité métier. A partir de là, nous construisons l’ontologie métier qui servira de référence. L’entreprise obtient ainsi un point unique qui définit toutes les règles de façon parfaitement indépendantes, et qui est interrogeable directement, que ce soit pour valider cette définition métier (plus besoin de tester extensivement le métier dans chaque application, et de devoir comparer les résultats !) ou pour vérifier ce qu’on obtient, d’un point de vue métier, dans telle ou telle situation. Cela signifie aussi que quelqu’un ayant une question métier peut la confronter à une source fiable. Cette source est réellement un point unique en ce que l’ensemble des applications peuvent se baser dessus, car elle ne décrit pas des règles métiers pour une application ou un ensemble d’applications, mais bien les règles métiers de l’ensemble du domaine. Ainsi, même pour une nouvelle application ayant besoin de nouveaux services afin d’interroger certains éléments intermédiaires, il suffit de rajouter techniquement de nouveaux services dans l’interface programmatique d’ODASE, autrement dit de nouveaux points d’entrée ou de nouvelles façons de l’interroger, mais sans toucher aucunement à la partie métier. De même, si c’est la partie métier qui change, sans que cela n’impacte les éléments nécessaires et donc la partie technique, il suffit de modifier les règles métiers, puis de déployer la nouvelle version sur les différentes plateformes intégrant ODASE.
Cette solution a donc ceci d’émancipateur que :
Pour ce qui est de la modification lorsque l’approche ODASE est en place, passer par nous est tout à fait possible et encouragé, notamment pour garantir la qualité de la représentation ontologique. Toutefois, il est également possible pour le client d’avoir son ou sa propre ontologue qui réaliserait tout ou partie des modifications (on pourrait par exemple former quelqu’un chez le client à cette fin).
Pour ce qui est des modifications classiques (par exemple les prix qui évoluent d’une année sur l’autre), on peut avoir ces éléments stockés dans des sources externes (fichiers Excel, base de données, autre), que le client pourra aisément mettre à jour, afin qu’il n’y ait qu’à relancer les instances du serveur ODASE pour que tout soit pris en compte (dans le cas d’une utilisation en mode serveur).
Enfin, nous sommes actuellement en train de développer un outil pour rendre les ontologies plus accessibles, aussi bien pour les visualiser que pour les modifier.
Il me semble que l’important, comme dans tout domaine, est de faire réaliser les modifications par des personnes dont l’expertise est adaptée à la complexité de la modification à apporter. Et nous visons à permettre que ces personnes puissent être côté client, afin justement d’offrir de l’autonomie et de la maîtrise, aussi bien en faisant progresser l’expertise côté client qu’en simplifiant la réalisation de modifications.
RLB : ODASE est actuellement utilisé dans le milieu de l’assurance, ce qui est gage de la fiabilité de l’outil et de l’intérêt de l’approche. C’est une très belle référence pour nous, et notamment de notre capacité à modéliser avec précision des ensembles métiers particulièrement complexes.
RLB : Nous sommes en train de créer notre propre outil qui permettra de visualiser et d’éditer les ontologies. L’objectif est que l’ensemble devienne plus simple, intuitif, pratique et confortable d’utilisation. Les étapes clefs sont :
Merci à Rémi Le Brouster pour cette présentation détaillée du fonctionnement d’ODASE !
Cet espace est pour vous.