Trois semaines ou presque passées depuis le 23/11, jour de l’atelier organisé par Agile Rennes à la French Tech, où j’ai eu le plaisir d’expliquer l’urbanisation des SI par des métaphores utilisant les Lego, accompagné de Benoît Chanclou (merci Benoît d’être venu malgré un rhume carabiné !).
J’ai désormais un peu de feedback, donc après un résumé pour ceux qui étaient absents et me l’ont demandé, je détaillerai ce qui va être amélioré pour la prochaine fois où je jouerai cet atelier.
Objectif
Ce qu’on cherche à montrer dans cet atelier est qu’il existe des méthodes permettant en informatique de mettre en œuvre une industrialisation telle qu’elle existe dans les autres métiers plus vieux, comme l’industrie traditionnelle, l’automobile, la construction d’ouvrages, etc.
Aujourd’hui, en informatique, la tendance est à tout le temps tout réécrire, tout simplement parce qu’on n’a que récemment trouvé la définition de ce que pouvait être une brique renouvelable. Après les routines, les librairies, les composants, les composants distribués, COM, COM+, DCOM, DNA et tout le bazar, on sait maintenant que la brique doit être fonctionnelle (approche SOA). Mais comme il a fallu quelques dizaines d’années pour standardiser le filtre à huile de nos voitures, il va falloir du temps pour réaliser la même chose en informatique. Heureusement, les normes sont présentes et la techno est désormais prête (REST, microservices, EIP, diagramme 4 strates pour l’urbanisation, etc.).
Pour rappel, les critères d’industrialisation sont :
- prédictibilité
- normalisation
- capacité à mesurer la performance
Atelier 1
Le premier atelier consiste à trouver un moyen de rendre “interfaçable” une tour et un corps de château. L’ensemble doit correspondre au modèle ci-dessous, le but étant de pouvoir facilement changer la tour pour une plus grande.
Il s’agit de la première approche vers une interface contractuelle. Un retour important pour un prochain atelier est de mélanger les personnes connaissant déjà le Lego et celles n’ayant que peu touché aux briques magiques dans leur enfance. Les constructions, sinon, manquent parfois un peu de solidité. Or, le but est de ne pas sacrifier complètement celle-ci au caractère interchangeable.
Atelier 2
On passe à quelque chose de légèrement plus complexe, avec une modélisation des messages véhiculés dans un Système d’Informations sous forme de plaque contenant quatre “pistes”. La présence ou l’absence de crémaillère permet de spécifier des qualités d’une personne tandis qu’une piste avec des briques de couleur symbolise son identité, en permettant de nombreuses combinaisons. Mine de rien, avec seize couleurs différentes sur 4 emplacements, on obtient déjà 65000 et quelques codages !
La porte réalisée pour le passage de cette plaque correspond à l’interface, bref au contrat à respecter pour pouvoir laisser entrer et sortir des plaques standard. Le sens est essentiel car la porte n’est pas symétrique (vu pendant l’atelier… et corrigé aussitôt).
Ainsi, un module de traitement va être composé de deux portes, une pour l’entrée et l’autre pour la sortie. Comme les faces opposées des portes peuvent se clipser, on obtient bien la capacité de réaliser ce qu’on veut à l’intérieur des modules sans présupposer de l’ordre dans lequel ils vont être utilisés :
La créativité de tous a donné lieu à de joyeux délires (le passage de la plaque qui bat les œufs en neige, etc.), et deux perles que j’ai eu le temps de prendre en photo, à savoir le siège qui se penche pour les employés et qui éjecte les cadres :
et aussi le système de modulation du son et des lumières en fonction des privilèges associés à la personne (belle utilisation du gros engrenage, en prise directe sur la sirène tournante) :
Atelier 3
Le temps manquant sur une soirée (l’atelier dure plutôt une journée), les deux derniers ateliers ont été réalisés sous forme de démo. Le premier montrait comment on pouvait modéliser en Lego une activité d’orchestration. Les plaques à crémaillères contenaient ainsi la “recette” des opérations à lancer, et elle était exécuté par un moteur qui lançait des rotations des axes standards de sortie en fonction, ces derniers étant reliés vers des “effecteurs”, métaphore des services logiciels (non montrés ci-dessous) :
Le lien était ensuite fait sur de véritables processus d’orchestration de Systèmes d’Information :
Atelier 4
Enfin, le dernier atelier, également réalisé sous forme de démo, montrait une approche légèrement différente de l’intégration de services, à savoir une étape entrée / sortie correspondant à une portion d’un ensemble en mode “chorégraphie” :
La limite dans la métaphore (remontée en feedback par Benoît) était que l’entrée manuelle ne modélise pas suffisamment clairement le fait que cette entrée peut également provenir d’un évènement déclenché dans un autre module. J’ai acheté quelques plaques supplémentaires pour pouvoir modéliser ces évènements par la suite. Idéalement, une rotation de l’axe pourrait enclencher un interrupteur. Pour terminer le traitement, il serait également possible de fermer l’interrupteur lorsqu’une plaque de commandes (comme celle utilisée ci-dessus) serait utilisée.
Bref, il va falloir faire quelque chose de plus sophistiqué pour mieux montrer la réalité d’un SI. Ce sera d’ailleurs l’occasion de mettre plus en avant les EIP, qui ont été montrés en métaphore Lego, mais pas manipulés par manque de temps. En préparant un système complet et en rendant les blocs “EIP” plus robustes, il devrait être possible de demander aux participants de créer leur propre médiation complexe.
Au final, le but est de montrer qu’il est (relativement) simple, pourvu que les messages soient correctement normalisés, de rendre facile pour les utilisateurs de gérer une chorégraphie simple (une commande pour un évènement), un peu à la mode de ce que font les applications grand public de type IFTTT ou Microsoft Flow.
Derniers feedbacks
Un autre point à régler est que les métaphores ne sont pas les mêmes entre les deux derniers ateliers, ce qui rend plus complexes la compréhension. D’où l’idée de les rejoindre tous les deux dans un seul ensemble, quitte à ce qu’il soit plus gros… Le message resterait toujours la plaque de base, et les EIP pourraient être utilisés pour modifier le fonctionnement des axes en sortie avec des EIP. Les effectueurs pourraient eux-mêmes déclencher d’autres moteurs qui effectueraient des actions complémentaires.
Bref, on peut encore largement améliorer cet atelier, mais l’essentiel a été rempli lors de cette session Agile Rennes : les participants étaient contents, ils ont déclaré que la métaphore les avaient aidés à comprendre les principes exposés et, magie de la manipulation par rapport à l’image, 70% de ce qui a été compris est désormais acquis (au lieu de 10% avec des diapos de présentation) !
