06 – Modélisation formelle, méthode et Agilité

Challenge du mois : Comment - non pas en plusieurs ouvrages - mais en deux pages, transmettre l’historique des principales formes de modélisation classiques, leurs limites, leurs évolutions et leurs « agilisations » relatives - surtout lorsqu’elles tentent d’atteindre le Graal du model « Testable et Exécutable » tel que rêvé depuis 1991 et jusqu’à SAFe.

Cette communication tentera donc le grand écart entre les formalisations élémentaires - comme les « Factory method design pattern » ou le « Model-Based System Engineering » (réintroduit par SAFe » dans ses versions récentes) - et la modélisation du plus haut niveau des organisations - comme la standardisation d’architecture d’entreprise pour la composition « à la carte » de services digitalisés (à l’identique par exemple des techniques utilisées dans les composants de nos ordinateurs ou de nos voitures). Cette standardisation des services dans la similitude de celles des produits industriels fut préconisée dès 2007 par PUMA Entreprise. L’article proposera aussi de faire le point et le pont entre les formes de modélisation du passé (encore très présentes) avec celles nécessitées par un futur immédiat d’adaptation continuelle - s’appuyant sur le DevOps, le continuous delivery,  les plateformes d’infrastructure « as services » ou « as code » et supportées par l’émergence de classes d’outils comme Sweagle par exemple. Enfin, cette chronique s’attachera surtout à rester agile dans ses propositions de mise en œuvre. 

Actuellement il n’est pas aisé de traiter de modélisation formelle dans un contexte se souhaitant « Agile » - bien que ce qualificatif soit totalement détourné par un retour aux classiques errements du vieux Lean rebaptisé Amélioration continue.  A la fin des années 80, je me suis assez confronté aux tenants des modélisations exhaustives afin d’adapter et simplifier Merise, les DFD et même UML pour ne pas être considéré aujourd’hui comme le défenseur de la modélisation formelle.  Pourtant, je n’ai jamais songé à éradiquer l’indispensable. Sans compter qu’avec les récentes évolutions de SAFe et de ses « value stream », nous assistons au come-back du Lean management, de ses chaînes de valeurs et de ses tentatives de se faire passer pour « Agile ».  Cette carambouille aurait pu se contenter de se présenter comme « utile », et c’était déjà pas mal dans un monde où la plupart des développements sombrent - plus ou moins partiellement, mais jamais officiellement - par absence de vraie méthode et d’un minimum de rigueur.

Note : Une méthode consiste à généraliser un processus validé permettant d’éviter de faire n’importe quoi à chaque occasion. L’amélioration continue, nommée aussi « expérience » (pour son côté positif de la correction des erreurs) représente exactement l’inverse, ce qui consiste dans le meilleur des cas à tenter de corriger empiriquement les dysfonctionnements répétitifs dus à l’absence de méthode. Cette « approche de la vie » pour certains, si elle peut parfois concerner l’innovation, devrait se limiter au maximum à un douzième (soit moins de 10%) dans la majorité des développements actuels. A défaut, l’amélioration continue devient alors la formalisation indéfiniment renouvelée du mythe de l’éternelle erreur dont l’expérience ne profite qu’à celui qui l’a faite et corrigée.

Modélisation « informatique », rappel historique

L’évolution des activités de conception graphique (dites de modélisation) s’initia au tout début des années 90 avec la diffusion de la première méthode agile nommée RAD. La France se conformait alors à la « double » douzaine de modèles du formalisme Merisien. Les anglo-saxons préféraient le diagramme unique du Data Flow Design (DFD) associé à l’entité relation (ER) pour la définition formelle des données (figure suivante). 

Franco-canadien, j’eus l’opportunité de proposer et appliquer avec succès le principe des « raccourcis méthodologiques ». L’arrivée de l’Orienté Objet et d’UML déclencha alors l’initiative « AgileModeling.com » du Canadien Scott Ambler (figure suivante).

La mise en œuvre des premières méthodes Agiles n’en demandait pas plus. Par contre, il existait déjà des tentatives d’optimisation des processus à automatiser (ou non). En réingénierie immédiate s’exprimait le BPR (Business Process Reengineering). En amélioration continue et surtout permanente sévissaient déjà les divers aspects du Lean. Le Lean « Industriel » avait depuis longtemps frappé le mur de ses limites opérationnelles et sociales, alors que le Lean Office se confrontait aux mêmes problèmes.  L’élargissement « IT » de ces concepts et leur couplage avec des méthodes de développement d’applications allait suivre.

Les concepts et architectures d’entreprise

En ce qui concerne le « conceptuellement agile », ma première tentative de prendre du recul par rapport au simple développement d’applications m’amena dans les années 2000 à proposer (PUMA, Processus Urbanisant les Méthodes Agiles) les trois vecteurs déterminant d’une approche d’entreprise Agile : ressources humaines, processus, technologie. Ce triptyque s’exprima plus clairement dans le graphe (figure suivante) toujours utilisé dans Wikipédia sur la page Management agile que je créais alors. Soyons réaliste, aussi simple que ce schéma puisse paraître, il reste cependant hors de portée de la plupart des entreprises de ce pays (pour ne pas dire du continent).

Note : Depuis 1994, à la Seita, je n’ai plus jamais revu se mettre en place une réelle motivation rationnelle des RH ou une réingénierie immédiate des processus de développement.

Mais de toute façon, pour que l’organisation atteigne la véritable agilité couvrant l’ensemble des préoccupations il fallait couvrir méthodologiquement les trois aspects, comme le proposait sommairement en 2007 PUMA Entreprise (figure suivante dont l’encadré rouge en haut à gauche » a été traité dans le cartouche 01 – Anticipation rationnelle du changement.

Ce fut à la même période que, par jeu, je préconisais une modélisation unique d’entreprise, basée sur la standardisation et l’interopérabilité d’éléments organisationnels (du même type que les pièces des voitures ou des éléments de nos ordinateurs).  L’erreur commise par les autres approches « sérieuses » était toujours de vouloir formaliser dans le détail une structure. Dans la réalité si la structure semblait figée, la plus grande partie du contenu se révélait le plus souvent en évolution permanente.  Dans ce type de contexte, seules les interactions dynamiques entre éléments de la structure déterminaient son agilité (figure suivante).

Revenons au développement applicatif basique

Encore aujourd’hui, comme par le passé, des trois « préoccupations » : données, fonctionnalités et communications, seule la modélisation formelle des données demeure indispensable à la génération automatique de leur instanciation physique - qui dans l’ensemble des cas actuels s’effectuera encore en mode Entité-Association 

Outre les raccourcis méthodologiques réduisant le nombre de modèles, avec la première méthode agile, le plus important se situait dans le processus de recueil d’informations. Il s’effectuait lors d’ateliers de travail, imposait la présence de l’utilisateur impliqué dans l’élaboration et la validation d’une modélisation textuelle et graphique à partir de son discours sur le métier. Il en découlait une validation permanente et Agile de cette étape de conception (figure suivante). Les formes les plus récentes de cette expression Agile et graphique ont été traitées dans les cartouches 04 – Expérience client et 05 – Consensus produit ou service.

La formalisation immédiate de cette expression de besoins, succincte mais exhaustive, se trouvait dirigée par un animateur facilitateur. Dans le même temps, le rôle de « secrétaire d’atelier » s’était élargi à des activités de rapporteurs (utilisant si possible la visualisation immédiate à l’aide de plusieurs vidéoprojecteurs :  rapporteurs de modélisation textuelle et de modélisation graphique - figure suivante d’époque).

Depuis, en ce qui concerne les fonctionnalités et les parcours utilisateurs, les nouvelles formes « agiles » basées sur du Story « telling, puis mapping » remplacent très bien la conception classique dans la mesure où le métier et l’utilisateur final participent à la réalisation en mode de « validation permanente ». Dans le cas contraire – alors qu’il ne serait même pas être question de parler d’agilité - vouloir sauter ces étapes devient le danger majeur. Ces aspects furent traités dans la cartouche 05 - à laquelle on pourrait rajouter la modélisation oubliée d’une carte « conceptuelle » s’élargissant aux diverses contraintes du contexte.

Les modèles spécialisés et les techniques émergentes

Vint le temps des architectures supportant l’émergence des « micros-services », lesquels impliquaient leur orchestration à partir d’un management de processus adapté mais surtout « optimisé » avant leur automatisation. A défaut de cette étape organisationnelle, le nouveau SI, développé le plus souvent suite à une obligation de différenciation concurrentielle, reproduisait les dysfonctionnements existants.  L’identification et la granularité des « services » représentent d’ailleurs toujours la préoccupation essentielle lors de ce type de refonte (figure suivante d’époque).

En réponse, PUMA proposait - cela demeure pertinent - une dérivation effectuée à partir de deux modèles UML s’auto-validant, et une classification des composants de service prenant en compte la stabilité des objets métiers. Leur assemblage visait à répondre à une demande de « service » cherchant à limiter les associations de classes appartenant à des couches de stabilité différentes. 

Conclusion et avertissement de principe

Plusieurs articles sur internet traitent de ces sujets complexes. Comment situer tous ces éléments en regard des préoccupations de l’agilité réelle telle qu’imaginée par ses initiateurs depuis 1991 devient une autre affaire, surtout avec les récentes évolutions de SAFe. L’utilité de la méthode réside alors dans la mise en œuvre d’un process ayant démontré son efficacité et couvrant la plus grande partie des préoccupations du professionnel de l’IT. Les traitements spécifiques seront abordés d’une manière empirique (amélioration continue) validée à posteriori sur la base d’un feedback permanent (rétrospective). 

Le Manifeste Agile implique 12 pratiques et l’amélioration continue ne représente dans cet ensemble indissociable que la douzième roue du carrosse méthodologique Agile invoqué comme garant du succès d’une conduite de projet (ou de feature team si vous préférez). Sans ce rapport d’un 90% minimum d’expérience et de 10% maximum d’improvisation, pas d’Agilité optimum !  Présenté autrement, on ne compose pas avec les impératifs de l’agilité dans les fondements de la méthode quelles que soient les « bonnes mauvaises » raisons de s’en dispenser ! Avez-vous seulement lu et vraiment compris la première phrase du Manifeste Agile ? Elle implique clairement l’expertise de la réussite professionnelle formalisée en tant que méthode, et non le bricolage permanent « de touche-à-tout soi-disant autonomes », formés souvent en quelques heures, et n’ayant parfois même pas la moindre expérience de la conception ou du développement.

Donc, comme avec SAFe, retour au vrai professionnalisme et à la rigueur.  En revanche, dans le cadre de cette communication, il demeure indispensable de conserver à l’esprit quelques réflexions pragmatiques : « Un bon graphique vaut mieux qu'un long discours « , « Tous les modèles sont faux mais certains sont utiles », « les modèles sont de par leur nature réducteurs mais indispensables à  la compréhension de la complexité ».  Le plus important - en termes d’agilité - me semble une autre de mes affirmations des années 90 « En matière de développement d’applications, tout ce qui n’est pas la production d’une fonctionnalité utilisable – donc la conduite de projet ou la modélisation - s’avère une activité parasite, aussi utile semble-t-elle être sur le moment ».