La plupart des personnes que je rencontre, ont une vision très technique du travail d’un architecte et n’ont pas forcément conscience de l’importance que doit revêtir la place de l’humain dans notre réflexion et nos décisions.
Je vais m’attarder dans ce billet surtout au travail de fond, conjoint avec les développeurs que l’architecte doit engager, tant il est évident qu’un architecte se doit de connaitre toutes les ressources mises à sa disposition et ou susceptible de le devenir.
Une partie de ce travail est parfois similaire à celui que devrait faire un ‘bon’ (troll inside) chef de projet mais il est également plus profond.

Parmi toutes les contraintes que nous devons gérer se trouvent principalement le trio maintenabilité, évolutivité, productivité, que l’on doit définir dans la durée. Je fais souvent le rapprochement entre ces 3 contraintes et le théorème CAP (https://fr.wikipedia.org/wiki/Théorème_CAP) qui démontre l’impossibilité dans un système distribué d’allier les trois contraintes que sont la disponibilité, la cohérence des données et la résistance au morcellement : sur ces 3 il n’est possible de n’en choisir que 2.
Sans avoir de preuve formelle, l’expérience tend à démontrer qu’il est fondamental de savoir où positionner le curseur dans le triangle représentant le MEP suivant :

D’autant plus qu’il faut le percevoir sur une dimension supplémentaire, car savoir où le curseur est placé à un instant T n’est pas suffisant, il est vital de savoir où l’on souhaite qu’il soit placé à terme et comprendre les mécanismes qui nous permettrons de réaliser la transition entre l’état courant et les états à venir qui sont corrélés avec : la motivation et les compétences des équipes, la stratégie de l’entreprise, les technologies utilisés/utilisables, la réalité du marché…

En fonction du choix que nous devons faire, les solutions à mettre en oeuvres peuvent être remarquablement différentes.

Du dangereux attrait des choix extrêmes :

Que penser de cette première tentation, la plus insidieuse : sacrifier l’évolutivité au profit de la productivité. C’est probablement le choix le plus fréquent !
Qui n’a pas bavé devant un framework somptueux permettant la création d’écrans pré-câblé, magnifiques et où le développeur se ballade dans un clickodrome paradisiaque qui utilise – pour l’instant – toutes les dernières versions de ses IDE et librairies préférés ?

Se dire que le directeur de projet serait heureux d’apprendre que les temps de développement seront réduit de 20% ou 30% (même si malheureusement peu de personnes ne le diront haut et fort, préférant garder au choix : une marge, ou bien du temps pour travailler sur des sujets de fonds difficilement vendable à un directeur de projet nommé pour 1 ou 2 ans et qui se fiche de savoir que son successeur ira dans le mur si ce n’est pas fait).

Se dire qu’un tel gain de productivité ne peut être balayé par des considérations techniques qui ‘potentiellement’ ‘pourrait’ me contraindre dans 1, 2 ans voire plus !

Se dire que tant pis si les propriétés de tel ou tel composant ne me permettent pas de réaliser l’exact tableau que les fonctionnels souhaitaient, puisqu’au lieu de 2 jours pour réaliser une page, je ne met plus qu’une demie journée !
Se dire que tant pis si les mises à jours ne prennent pas en compte l’évolution du framework de persistance que nous utilisons, qui pourtant ajoute quelques fonctionnalités et améliore les performances ! Ben oui, après tout le temps homme coûte toujours plus cher que le temps machine, ce n’est pas grave !

Se dire que tant pis si l’évolution du design et des supports ‘pourrait’ me contraindre à une certaine adaptabilité et souplesse, ce n’est qu’un effet de mode, les interfaces ici sont tellement belles et rapides à produire !

Attention, je ne dit pas que le choix de la productivité maximale est forcément mauvais, seul le contexte décide. Il est sûr que si l’objectif et les moyens imposent de se lancer rapidement dans un marché et qu’une fois gagné vous aurez les moyens de refondre l’application ensuite, le choix sera plus nuancé.
L’important est toujours d’une part de poser les contraintes et les besoins avant de donner des réponses et d’autre part, d’en avoir conscience, ce qui n’est pas toujours le cas.

A l’opposé, que dire de l’envie de réaliser une application tellement modulaire qu’elle pourrait laisser le développeur coder dans le langage qu’il désire, suivant la méthodologie qu’il souhaite ! Avec les règles de nommage qu’il désire ! C’est l’idéal, je motive les troupes en leur permettant de travailler comme ils l’entendent…
Et puis ce n’est pas grave s’ils y a des bugs, le développeur initial les corrigera sur son périmètre car il sera toujours là ! Pourquoi partirait-il alors qu’il est si heureux ?
Tant pis si mon infrastructure technique est plus lourde, le développeur est tellement plus productif en travaillant avec son langage préféré ! Une machine est bien moins cher qu’un humain non ?
Et puis tant pis si l’un des langages choisit devient obsolète ou bien à une faille critique de sécurité, mon application est tellement modulaire que je réussirai bien à remplacer la fonction avant de me faire pirater non ?

Attention, je ne dis pas non plus qu’il faille tomber dans l’excès inverse, il ne faut pas contraindre totalement les développeurs dans un carcan qui briderait leur productivité ou leur créativité !
Tout est toujours (oh une certitude, c’est si rare !) question de dosage.

Et c’est là où je veux en venir, la gestion de l’humain à travers la vue de l’architecte.
Lorsque l’on doit concevoir une architecture, qu’elle le soit à partir d’une feuille vierge ou d’un existant fortement contraint, le paramètre de l’humain est fondamental. Il est impensable qu’un architecte puisse définir ne serait-ce que l’esquisse d’un diagramme s’il ne connait pas les équipes qui seront à la réalisation ni les évolutions possible et probable de ces équipes.
Je ne parlerai pas ici du cas où en plus de l’architecture applicative, il faut constituer les équipes à partir d’une feuille blanche, même si c’est une belle aventure.

Je vais traiter ici du cas traditionnel où il faut mettre en oeuvre une architecture avec la contrainte d’équipes déjà en place (complètes ou partiellement).
Il est, à mon sens, difficile de faire un travail correct si l’on ne connait pas personnellement chaque membre de l’équipe. Il est indispensable de passer du temps avec chacun d’entre eux, que ce soit en déjeuner ou à travers des activités annexes.
Pourquoi ? Eh bien c’est assez basique en fait.
J’ai croisé trop souvent le dégoût de venir travailler dans certaines équipes dont les managers ont oublié (ou n’ont jamais su/compris/voulu…) que la certitude et l’exactitude des suivis, des temps d’activité, de toute la paperasse de flicage ne représente qu’une infime partie de leur travail. La raison pour laquelle ces équipes tournent mal est bien souvent la facilité. Oui la facilité : ce travail de suivi, d’indicateurs, de mise en place des procédures est facile (et dans certaines proportions utile, je ne dit pas le contraire), mais de là à ne se baser QUE sur ces données pour piloter est une erreur. Grave. Notamment avec des équipes de développement dont le coeur de métier est de devoir résoudre des problématiques en utilisant ses connaissances, sa logique, son désir de trouver des solutions, sa volonté d’aider, sa capacité à améliorer… bref sa créativité. Comment exploiter au mieux leur ‘temps de cerveau disponible’ ? Comment les bien faire fonctionner s’ils n’en n’ont pas l’envie ?!
Se connaitre, connaitre ses équipes et provoquer l’envie de venir travailler est la base d’une société qui avance ! C’est une tâche difficile.

Et puis également, un projet nécessite des compétences, jusque là rien d’extraordinaire, mais lorsque ce projet subit des modifications contraignantes ou doit faire face à l’imprévu, ou tout simplement dérive car la planification, le chiffrage, ou la relation client est mauvaise ? (Lire à ce sujet l’Illusion de la planification) sur qui pourrez vous compter ? Qui sera capable d’absorber au mieux une partie de la pression supplémentaire ?
C’est en connaissant les membres d’une équipe que l’on est également capable de percevoir les lignes de forces et de faiblesses qui peuvent influer sur les rôles à distribuer et même sur la conception de l’architecture.
Alors non, une équipe ne va pas intégralement remettre en cause votre archi (et tant bien même, quel serait le problème ?) et que d’un souhait de micro-services nodejs dockerisés vous finirez avec un bon gros serveur monolithique !
Cela ne changera pas fondamentalement la technique, mais cela changera le sentiment d’écoute, d’importance, de collaboration, de réactivité, de souplesse, de gestion des crises, et cela influera sur la précision de votre design MEP.

Bien sûr si votre équipe est composée de 250 personnes, c’est délicat.. certes… mais je n’imagine pas que vous descendiez seul dans des détails architecturaux, les experts, les lead développeurs sur lesquels vous vous appuyez, ainsi que les chefs de projets doivent également avoir cette qualité, créer une chaine via cette approche anthropologique qui permet de déterminer qui, pourquoi et comment votre projet peut passer d’une catastrophe annoncée à une réussite inattendue.

Passez du temps avec vos équipes, connaissez-les comme un virtuose connait les touches d’un piano et composez au mieux, personne ne pourra vous le reprocher, du moins pas sans une bonne dose d’ignorance et/ou de mauvaise fois.