Y a-t-il encore de la place pour une "autorité de design" dans des organisations de plus en plus agiles ? Thomas nous présente 2 retours d'expérience, et leur comparaison, pour étayer son discours.

Le rôle de l'architecte

Un architecte est comme un jardinier : il compose un système dans lequel vivre en harmonie et former un tout, pour évoluer vers un objectif commun.

Pour évoluer, il lui faut tenir compte du contexte et des spécificités. Chaque composant va évoluer de lui-même et l’architecte va devoir composer pour avoir un écosystème, une harmonie, et tendre vers son objectif pour ce jardin. Le rôle de l'architecte, c'est d'imprimer une intention commune à un gros organisme ou à une multitude d'organismes vivants.

5 objectifs :

1. L'apport de cohérence pour que les briques communiquent entre elles de manière efficace et forment un tout cohérent tout en tenant compte des individualités.
2. L'aide à la décision : identifier qu'un choix doit être fait, être face à des choix ou faire le choix de ne pas en faire ; bref, aider le système à se diriger.
3. Les aspects de cadrage : réunir un contexte pour permettre à une équipe d'avoir une vision claire lorsqu'on fait naître un nouveau composant, pour savoir vers où il va évoluer.
4. L'expertise ponctuelle grâce à des compétences larges sans être l'expert du domaine.
5. Le suivi de l'évolution du système dans le temps et la facilitation pour permettre d'avoir une évolution fluide.

1er retour d'expérience sur une digital factory qui va plein gaz

L’organisation de cette Digital Factory, c’est plus de 200 personnes réparties sur une vingtaine équipes. Initialement fondue dans un framework SAFe, elle a peu à peu glissé vers une autre topologie, du fait la grande indépendance des équipes :

• Des "stream-aligned teams" qui ont un objectif métier clair qui doit être délivré.
• Une "platform team", dédiée à l'usine logicielle d'intégration continue.
• Des "complicated subsystem teams" ponctuels qui peuvent être vu comme des fournisseurs de composants complexes pour les autres. Ils ont la charge de construire et packager ces composants et vont aider les équipes métier à l'intégrer à leur composants avec une interface d'intégration minime.
• Une équipe transverse "goal volant" ("enabling team") : c'est ici que sont les architectes. On compte 4 architectes pour une équipe d’environ 20 personnes aux expertises multiples : UX, sécurité, agile, etc. Très mobile, elle interagit régulièrement avec les autres équipes.

Les apports :

• Suivre l'évolution dans le temps : dans ce contexte, on va suivre le nombre de déploiement en production pour avoir des chiffres comparables. Cette comparaison n'est pas faite pour avoir un classement entre équipes mais pour suivre l'ensemble du système, voir s' il y a des problèmes locaux ou des problèmes globaux et permettre à l'architecte d'identifier où il doit intervenir. Objectif : accompagner le système pour qu'il évolue sans trop de friction au cours du temps.
• Les aspects de cadrage et l'expertise ponctuelle : apport de l'architecte en tant "qu'expert ponctuel" et “aide au cadrage". L'exemple est basé sur un nouveau besoin de pilotage énergétique à l'issue des différents traitements métiers qui interviennent. Expertise demandée : identification des "solvers opérationnels" existants pour ce cas de figure, aide à l'équipe pour détourer l'intégration de ce solver et comprendre les aspects essentiels du contexte à prendre en compte pour faire les premiers choix structurants pour démarrer. Dans l'exemple cité, la préconisation des architectes a été impactée par le contexte global de la digital factory, qui a modifié le choix initial open source pour sélectionner un solver du marché et l'enrober avec une interface afin que les autres équipes puissent l'utiliser, sans en être trop dépendantes d’une évolution future du métier.

2e retour d'expérience : Un projet SAFE qui roule

Ici, à l'inverse du 1er exemple, les équipes sont très liées et sont restées sur la méthodologie SAFe. Les équipes de développement qui livrent la valeur vont être accompagnées par une équipe transverse où se trouvent notamment les architectes, alias System Architects ou System Engineers.

L'organisation du travail programme et le développement s'organisent autour de macro tâches (dans un backlog programme) déclinées et affinées dans des backlogs plus concrets, adressables et activables par les équipes. Ce travail est cadencé par un tempo sur l'ensemble d'un train SAFe, avec des incréments composées de 5 itérations. Toutes les 5 itérations, les équipes se retrouvent pour se redonner de la vision sur l'ensemble du système. Ces grands messes ont été nécessaires pour maintenir la cohérence du projet.

On reprend 3 de nos 5 objectifs sur ce REX :

• Les aspects de cadrage L’un des rôles de l’architecte, c’est de cadrer suffisamment pour apporter quelque chose d'activable en développement. On parle de solution intent, un terme particulièrement adéquat car l'architecte a bien une intention, définie selon les besoins métier, les objectifs à moyen et long terme, ou encore le contexte. Une fois que cette intention commence à partir en production, elle s’affine peu à peu avec les retours des équipes.

• L'aide à la décision et à l'évolution du système On utilise les ADRs (Architecture Decision Records) pour documenter le système en cours de construction - une pratique recommandée par ThoughtWorks depuis 2017. Un exemple d'une décision :

  Ces décisions s'empilent comme des logs (car le “cadrage 0” parfait n'existe pas) et se font à plusieurs niveaux : des décisions centrales ou plus locales, concernant uniquement une équipe voire un seul composant. Elles sont stockées et versionnées comme du code, avec des outils classiques pour des développeurs et les bonnes pratiques associées.

  Le format est assez simple, il y a :

  • un contexte ;
  • la décision en elle-même ;
  • les conséquences qu'on envisage au moment de prendre la décision. Celle-ci est datée et a un statut qui permet de connaître son état (si d'autres décisions l'ont fait évoluer).

Le contexte est essentiel : il permet d'expliquer pourquoi on a fait ce choix et facilite donc dans sa future remise en question de manière éclairée. Cela va supprimer la peur du changement, un peu comme un harnais de tests unitaires. En loggant les décisions, leur contexte, et en ayant conscience de leurs conséquences, on permet au système de continuer son évolution en évitant les frictions causées par la crainte des modifications des décisions d'architecture.

En complément de ces ADR, on maintient une documentation collaborative, sous forme de Markdown, elle aussi versionnée. Comme dans la hiérarchie des ADR, la documentation peut être centrale ou locale. Cette documentation décentralisée est une force car centraliser toutes les décisions et la documentation est un travail fatiguant qui peut faire peur. On préfère conserver la connaissance, la partager aux yeux de tous, puis, par la suite, si l'on souhaite mettre en commun des éléments, il sera possible de faire un refactoring.

Comparaison des 2 REX

Les 2 organisations présentent des points communs et des différences :

• Les moyens sont très différents : 4 architectes pour 200 personnes contre 6 pour 130.
• Le mode d'échange : très ritualisé versus des échanges plus informels avec des architectes plus présents dans les équipes (mais avec une probabilités de présence variable).
• La documentation : très indépendante dans le premier exemple, très hiérarchique dans le second.

Les 3 apprentissages

• Apprentissage #1 : avec l'agrandissement d’échelle, on a besoin d'individus clairement identifiés. La charge mentale nécessaire associée passe mal l'échelle : les échanges doivent être plus structurés.

• Apprentissage #2 : l'agilité peut entrer en conflit avec des organisations classiques. La cellule "isolée", très "descendante", n'a que peu de chances d'être efficace. Les équipes d'architectes doivent se rendre compte des impacts des décisions et des retours des équipes de développement. Il vaut mieux susciter l’intérêt plutôt que d’imposer la contrainte (anti-pattern : “authority without responsibility").

• Apprentissage #3 : la boucle de feedback asymétrique peut être frustrante pour les architectes. L'agile permet des retours réguliers qui permettent de se rendre compte rapidement des impacts, mais lorsqu'il faut changer de direction, cela peut être plus compliqué et prendre davantage de de temps sur les décisions d'architecture faites en centrale. Attention à la frustration de n'avoir qu'une moitié de la boucle de feedback qui s'accélère !