BR manifesto

Remettre le métier au coeur de l’IT…

Les dernières années ont vu une émergence massive de frameworks et d’architectures en tous genres. ORMs, micro-services, implémentations de certains patterns, MVC, MVVM, Cloud Computing, IAAS, PAAS, etc… Dans ce contexte, la communauté IT est en proie à la tentation du “hype”, au mépris, hélas, des problématiques métier. Cela contribue à creuser un fossé entre cette communauté et les gens du métier, en plus, bien évidemment, d’engendrer des coûts supplémentaires.

En 2015, la plupart des problématiques métier ont en partie été découvertes, même si des nouveaux acteurs de l’économie peuvent maintenant, avec l’avènement du numérique et du Web, proposer des “business models” disruptifs et parfois très novateurs. Pour ces nouveaux acteurs, l’IT a vocation à donner corps à de nouveaux modèles. Ce document ne tente pas de minimiser l’importance et le caractère décisif des innovations technologiques, qui catalysent l’innovation, et entraînent avec elles des cohortes d’idées nouvelles. Il s’agit de replacer toute cette effervescence technique dans un contexte business, contexte sans lequel elle ne saurait avoir ni réelle signification, ni réelle légitimité. Le , le Manifesto, le Manifesto sont autant d’initiatives devant permettre de replacer le métier au coeur des préoccupations, ou en tous cas, de sensibiliser à un certain nombre de dérives. Cela, tout en limitant l’effet “cascade” de certains projets dans lesquels le métier se distille doucement mais sûrement au fur et à mesure. Cette réforme en faveur du métier a lieu, parfois dans la douleur.

Les approches ne se valent pas et ne sont pas forcément comparables. Elles ne ciblent pas les mêmes types d’entités (par rapport à leur maturité…). Mais toutes vont dans le sens de produire de meilleurs logiciels.

L’agilité prônée par le Agile Manifesto est sujette à diverses interprétations de la part des développeurs. Ce manifeste est une boîte à outils visant à maximiser la collaboration entre les intervenants de l’IT, pour se concentrer sur les livrables et les attentes des clients, qui sont, comme tout le monde le sait, sujets à volte-faces. Mais certaines de ses interprétations sont à challenger. Pour beaucoup par exemple, l’agilité passerait par la réutilisation, autant que possible et même au delà, du code existant. Actuellement, l’agilité est perçue comme une norme devant régir tous les développements, mais dans les faits, elle ne fait pas de sens sur tous les types de projets. Si vous savez précisément ce que vous devez développer, laissez tomber l’agilité. Si vous savez que le besoin sera amené à évoluer dans peu de temps, allez-y !

En DDD, on préférera spécialiser le code, par le UL notamment, afin de ne pas encourager l’exploitation poussive de morceaux de code rendus inadéquats d’un contexte à l’autre. Le DDD va beaucoup plus loin dans l’accompagnement des développeurs dans leur travail quotidien. Il peut être défini à un niveau stratégique, par exemple. Le DDD, dans son esprit “lean” et pragmatique, qui vise à simplifier les développements par un meilleur alignement sur le métier, peut aisément accompagner les start-ups dans leur développement, surtout s’il est adopté à un niveau stratégique.

Le Business-Rules Manifesto place les règles métier au coeur des préoccupations et des priorités. Il promeut une approche “top-down”, commençant dès l’amorçage du projet par l’énonciation des règles par le métier, puis leur catégorisation, en balayant d’un grand revers de la main les aspects techniques qui seront, de toutes manières, incontournables. Chaque chose en son temps, il est inutile de prétendre trouver des solutions à des problèmes qui ne sont pas encore identifiés… Il vise à garantir, tout au long des jalons de réalisation, l’omniprésence des règles, y compris dans l’implémentation de la solution par le code. Et surtout, il embarque une série de lignes directrices visant à rendre au business (et nouveaux business) toute l’agilité et le soin qu’ils exigent, afin de pouvoir se développer.

Manifeste pour les règles métiers

Article 1er. Exigences principales, plutôt que secondaires 1.1 Les règles sont au cœur de l’expression des exigences métiers. 1.2 Les règles sont essentielles aux modèles métiers et aux modèles technologiques. Elles en font par ailleurs partie intégrante.

Article 2. Règles séparées des processus, plutôt qu’intégrées à ces derniers 2.1 Les règles sont des contraintes explicites en matière de comportement ou sous-tendent la conduite des activités. 2.2 Les règles ne sont ni des processus ni des procédures. Elles ne devraient pas être intégrées à ceux-ci. 2.3 Les règles s’appliquent à l’ensemble des processus et procédures. Il devrait y avoir un et un seul corpus cohérent de règles appliquées de façon systématique à tous les domaines pertinents de l’activité de l’entreprise.

Article 3. Connaissance explicite plutôt que sous-produit 3.1 Les règles se fondent sur des faits et les faits reposent sur des concepts exprimés au moyen de termes. 3.2 Les termes expriment des concepts métiers ; les faits renvoient à des affirmations relatives à ces concepts ; les règles restreignent et sous-tendent ces faits. 3.3 Les règles doivent être explicites. En aucun cas, les règles ne peuvent présupposer des concepts ou des faits. 3.4 Les règles constituent le fondement de la connaissance que l’entreprise a d’elle-même, c’est-à-dire de la connaissance de base du métier. 3.5 Les règles doivent être alimentées, protégées et gérées.

Article 4. Règles déclaratives, plutôt que règles de procédure 4.1 Les règles doivent être exprimées de façon déclarative, en langage naturel, à l’intention des responsables métiers. 4.2 Si une information ne peut être énoncée, il ne s’agit pas d’une règle. 4.3 Un ensemble d’énoncés n’est déclaratif que s’il ne contient pas de séquence implicite. 4.4 Tout énoncé nécessitant des éléments autres que des termes ou des faits relève d’hypothèses relatives à la mise en œuvre de systèmes. 4.5 Une règle est distincte de tout mode de mise en œuvre qui lui serait appliqué. Règles et mises en œuvre de règles sont deux choses différentes. 4.6 Les règles devraient être définies indépendamment des modalités (« qui », « où », « quand » et « comment ») de leur mise en œuvre. 4.7 Les exceptions aux règles sont exprimées au moyen d’autres règles.

Article 5. Règles formulées de manière adéquate plutôt qu’improvisées 5.1 Les règles métiers doivent être exprimées de telle manière qu’elles puissent être validées par les experts métiers. 5.2 Les règles métiers doivent être exprimées de telle manière qu’elles puissent être vérifiées les unes par rapport aux autres afin d’assurer la cohérence du corpus de règles. 5.3 La logique formelle, notamment la logique des prédicats, est essentielle pour la formulation adéquate des règles en des termes propres au métier, ainsi que pour les technologies qui mettent en œuvre ces règles.

Article 6. à base de règles plutôt que mise en œuvre indirecte 6.1 Une application à base de règles métiers est construite dans le but explicite d’intégrer des changements continus dans les règles métiers. La plateforme sur laquelle les applications sont exploitées doit soutenir ces changements continus. 6.2 Il est préférable d’exécuter directement les règles, par exemple au moyen d’un moteur de règles, plutôt que de les transcrire dans un ensemble de procédures. 6.3 Un système de règles métiers doit toujours être capable d’expliquer le raisonnement par lequel il est arrivé à une conclusion ou déclenche une action. 6.4 Les règles sont basées sur des valeurs de vérité. Le mode de détermination ou de conservation de la valeur de vérité d’une règle doit rester caché des utilisateurs. 6.5 La relation entre événements et règles est en général une relation de type « n-n ».

Article 7. Processus dirigés par des règles, plutôt que programmation fondée sur des exceptions 7.1 Les règles définissent la frontière entre les activités admissibles et celles qui ne le sont pas. 7.2 Les règles nécessitent souvent une gestion spéciale ou spécifique des violations détectées. La gestion du non-respect de règles métiers est une activité à part entière. 7.3 Afin d’assurer le maximum de cohérence et de réutilisabilité, la gestion des activités non admissibles devrait pouvoir être séparée de la gestion des activités admissibles.

Article 8. Au service du métier plutôt que de la technique 8.1 Les règles concernent les pratiques de gestion et de gouvernance de l’entreprise. Elles dépendent ainsi des buts et objectifs métiers et sont influencées par de multiples facteurs internes et externes à l’entreprise. 8.2 Les règles constituent toujours un coût pour l’entreprise. 8.3 Les coûts liés à l’application des règles doivent être appréciés en fonction des risques encourus par l’entreprise ainsi que des opportunités que celle-ci manquerait si elle ne les appliquait pas. 8.4 La pléthore de règles n’est pas forcément bénéfique. En règle générale, il vaut mieux un nombre limité de règles correctement formulées. 8.5 Un système efficace peut être basé sur un petit nombre de règles. Par la suite, l’amélioration du système peut se faire par l’adjonction progressive de règles supplémentaires appropriées.

Article 9. Pour et par les spécialistes métiers plutôt que les spécialistes informatiques 9.1 Les règles doivent émaner de personnes ayant la connaissance de l’entreprise. 9.2 Les experts métiers doivent pouvoir disposerd’outils leur permettant de formuler, de valider et de gérer les règles. 9.3 Les experts métiers doivent pouvoir disposer d’outils les aidant à vérifier la cohérence entre les règles.

Article 10. Gestion de la logique métier plutôt que des plateformes matérielles ou logicielles 10.1 Les règles métiers constituent un élément essentiel du patrimoine de l’entreprise. 10.2 À long terme, les règles métiers sont plus importantes pour l’entreprise que les plateformes matérielles ou logicielles. 10.3 Les règles métiers doivent être organisées et stockées de manière à pouvoir être redéployées facilement sur de nouvelles plateformes matérielles ou logicielles. 10.4 Les règles métiers et la faculté de les faire évoluer de manière effective sont essentielles pour renforcer l’adaptabilité de l’entreprise.

Ce qu’implique le BR Manifesto
PrincipesConséquences
Article 1.
Exigences principales, plutôt que secondaires
Impact sur le métier. Les règles doivent être exprimées dès les réunions d'expressions des besoins (EB). Les règles qui sont identifiées comme des faits incontournables (loi, code civil...) doivent être séparées des règles définies par l'entreprise, et catégorisées. Les règles doivent être énoncées dès ce moment. Sans ambiguïté, de façon claire et accessible par tous. En poussant vers le DDD, les règles permettent ensuite de concevoir le modèle métier sur lequel s'appuieront les fonctionnalités à venir. Elles permettent de comprendre la séparation des règles et des processus d'entreprise.
Article 2.
Règles séparées des processus, plutôt qu’intégrées à ces derniers
Impact sur toutes les équipes. Elles demandent un effort et une hygiène toutes particulières lors des phases de conception. Les développeurs ont parfois le réflexe de coder les règles dans/avec les processus, bercés par l'espoir de pouvoir un jour refactorer la solution pour y mettre de l'ordre. Ne pas identifier en amont les règles rend l'adoption d'un moteur de règles très coûteuse, et ne permet pas de faire sponsoriser le refactoring par le métier, qui n'y verra pas son intérêt.
Article 3.
Connaissance explicite plutôt que sous-produit
Impact sur le métier et le pilotage de projet. Cette guideline est assumée par la MOA. L'expression des besoins doit comporter en premier lieu les définitions, puis les règles "fonctionnelles", puis les séquences. Les règles sont identifiées par des identifiants fonctionnels qui ne souffrent d'aucune ambiguïté. Le nommage des règles à différents endroits du SI doit embrasser le vocabulaire usité par le métier, quotidiennement.
Article 4.
Règles déclaratives, plutôt que règles de procédure
Impact sur toutes les équipes, mais surtout sur l'IT, prompt à faire la différence entre déclaratif et procédural... Les règles doivent être énoncées comme des faits physiques. Les règles de procédures doivent être détaillées séparément (lors d'une réunion de Event-Storming, avec le métier, par exemple...). Elles doivent exister en dehors du code permettant de les appliquer dans la solution, elles doivent être énoncées en dehors du code. Afin d'avoir des règles qui puissent être écrites sans trop d'effets personnels, l'utilisation des prédicats tels qu'ils sont enseignés en mathématiques est une excellente pratique.
Article 5.
Règles formulées de manière adéquate plutôt qu’improvisées
Impact sur le métier et le pilotage de projet. Alerte : ne pas avoir à revenir dessus. Lorsqu'une une règle est formulée, les règles dont elle dépend le doivent aussi. Définitions, termes techniques, etc... Si l'IT découvre une règle, il doit en informer la MOA et le métier et la préciser dans les documents disponibles.
Article 6.
Architecture à base de règles plutôt que mise en œuvre indirecte
Impact sur l'IT. Développer de manière top-down. Les processus doivent pouvoir être implémentés quelque soit le modèle de prise de décision. Les règles doivent être testables. Processus testables. Séparément. Une même règle peut intervenir dans 2 endroits distincts. Métadonnée, permet de différer certains choix (stockage, etc...). Base de données spécifique. Les règles doivent aussi pouvoir être testées, validées, en dehors des processus de l'entreprise.
Article 8.
Au service du métier plutôt que de la technique
Impact sur toutes les équipes. Les 3 points suivants convergent vers l'idée que le développement, dans sa tendance actuelle, relègue le métier à un rôle parfois secondaire, dans l'ombre de l'exploitation des frameworks les plus "hypes", et les plus judicieux à épingler sur son CV. La réalisation d'un référentiel de règles, pour le métier et l'IT, s'impose.
Article 9.
Pour et par les spécialistes métiers plutôt que les spécialistes informatiques
Impact sur le métier. Aucune notion technique ne doit apparaître dans l'énoncé d'une règle. Aucune notion dans les réunions d'expression des besoins. Les modalités de transfert de la données par "micro-service", ou de leur stockage par une "bases de données", sont des questions qui doivent être laissées de côté lors des première étapes.
Article 10.
Gestion de la logique métier plutôt que des plateformes matérielles ou logicielles
Impact sur toutes les équipes. Business Agile. Pilotage par le business, pas par l'infrastructure. Les questions d'infrastructure doivent pouvoir devenir secondaires.

Add a Comment

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

+ 3 = 11