Les architectures modernes et l’agilité, en fusionnant technologies et processus de réalisation, permettent une livraison plus rapide et une évolution durable des applications, tout en intégrant une dimension humaine cruciale pour une efficacité optimale. L’humain doit être au cœur des architectures modernes.
Les architectures distribuées tendent aujourd’hui à s’imposer dans la démarche de modernisation du système d’information des entreprises. Dans leur volonté de développer des applications qui répondent mieux aux attentes de leurs clients et de leurs métiers, les DSI veulent mettre en œuvre des technologies plus modernes, mais aussi entrer dans un nouveau paradigme de développement. Les piles logicielles sont ainsi devenues un enjeu de ressources humaines car mettre en œuvre des technologies nouvelles et innovantes va attirer les développeurs et fidéliser les plus expérimentés, toujours soucieux de nouveaux challenges et de travailler sur les langages les plus à la pointe. Néanmoins, les nouvelles technologies logicielles doivent être mises au service de l’entreprise et non pas répondre à des effets de mode. Les architectures modernes doivent ainsi s’inscrire dans les enjeux métier de l’entreprise, l’objet n’étant pas de faire de la Tech pour la Tech.
Technologie et organisation doivent aller de pair
Nos métiers et communautés de pratiques se rapprochent : Agilité et Architectures Modernes convergent. L’alliance des deux permet de délivrer des applications beaucoup plus rapidement et de les faire évoluer dans la durée. C’est bien plus difficile à faire lorsqu’on doit travailler sur une application monolithique dont les dépendances entre composants sont extrêmement difficiles à gérer. Devoir attendre 9 à 12 mois de développement avant de déployer une nouvelle application n’est plus concevable aujourd’hui par les ComEx. Typiquement, une banque ou un assureur doit pouvoir lancer un nouveau produit en quelques mois et ne pas attendre un an pour voir une idée de produit se matérialiser enfin sur le marché.
Modern Architecture et agilité associent les technologies, processus de réalisation et les personnes qui vont mettre en œuvre ces technologies. Ces trois piliers qui constituent la base des systèmes socio-techniques permettent d’avoir une vision holistique pour mieux résoudre les problèmes liés au développement du système d’information de l’entreprise. L’humain est une composante essentielle de ce triptyque que l’on a peu adressé jusqu’à aujourd’hui. Or, il ne sert à rien de créer des architectures et des systèmes complexes sans tenir compte du fait que ce sont des humains qui vont les exploiter et les opérer.
Limiter les dépendances, faciliter l’autonomie et permettre à l’équipe de faire ses propres choix, sont des principes de base qui doivent être systématisés pour être efficaces, mais, pour autant, ils ne sont pas suffisants.
A l’instar du monde économique et de la loi de rendement maximum, on sait dorénavant que pour mener à bien un projet, au-delà d’une certaine limite, il ne sert à rien de mettre plus de personnel pour aller plus vite. Il n’est pas efficient de confier le développement et l’évolution d’un microservice à 15 ou 20 personnes et encore moins à une seule personne. Selon l’anthropologue Britannique Robin Dunbar, la taille optimale d’un groupe s’établit autour de de 5 à 7 membres. Ce chiffre varie selon les experts mais – sur le terrain – pour qu’une équipe ait à la fois les compétences et l’autonomie et en même temps un nombre limité d’interactions de personnes à personnes, nous retrouvons bien cet ordre de grandeur. Le Scrum Guide, par exemple, conseille justement des équipes de 3 à 9 personnes. L’autonomie se pense donc dès le build d’un produit. La technologie apporte, quant à elle, quelques éléments de réponse : passer par un bus de données (i.e. asynchrone) va permettre d’éviter le couplage fort lié aux appels d’API d’un composant à un autre, lors du build et du run du projet. Lorsqu’on n’a pas de contraintes de disponibilité, de criticité de l’application, on peut tolérer un couplage relativement fort entre composants car c’est la solution la plus simple à mettre en place et la moins coûteuse. Dès lors que le projet implique une multitude d’acteurs, qu’il y a des enjeux forts en termes de disponibilité et de performances, alors il faut privilégier un système découplé, en limitant par conception les dépendances.
Idéalement, les entreprises devraient basculer vers une architecture moderne et dans une organisation agile simultanément. Lorsque c’est le cas, je recommande systématiquement de le faire sur un périmètre restreint dans un premier temps, puis au bout de 3 à 6 mois d’expérimentation, élargir le périmètre. Mettre en place une dynamique de découplage de type bus ou API dans une approche « Contract First » et adopter un framework itératif et incrémental est par exemple réellement synergique. Pour autant, réfléchir à l’architecture la plus adaptée au contexte, mettre en place une organisation agile, est-ce suffisant ? Non, car les membres de chaque équipe ont tous des capacités et une propension à interagir avec les autres qui diffèrent. Une organisation telle qu’idéalisée par Spotify ou un mode de management à la Google peuvent être bien acceptés par les uns, mais beaucoup plus sollicitants pour d’autres. Nous vivons tous dans un cadre préexistant qui nous sert de repère et nous avons tous nos limites, moi le premier. Ces modalités d’organisation et de changement requièrent énormément de compétences et d’adaptabilité. Il faut donc bâtir les équipes en fonction des personnes qui les composent et pas uniquement sur de simples profils techniques type ou au travers de concepts architecturaux.
Faire fonctionner de concert une multitude de petites équipes reste par ailleurs un enjeu important, notamment dans les grands projets. Les approches Agile at Scale de type LeSS, SAFe ou Large Scale Scrum apportent des éléments de réponse sur les cérémonies et les rôles, là ou une approche telle que la sociocratie évoque un fonctionnement par consentement et par cercles qui communiquent les uns avec les autres. Quelle que soit l’organisation choisie, cette autonomie et ce besoin de constamment interagir avec les autres demande une vraie capacité humaine à s’adapter. Or, tout le monde ne dispose pas des mêmes capacités interpersonnelles et on ne peut négliger cette dimension.
Penser les systèmes pour ceux qui vont devoir les faire vivre
Il ne faudrait donc pas penser un système seulement par les fonctions qu’il va remplir, mais aussi à la façon dont l’équipe qui va soutenir ce processus, métier ou informatique, va pouvoir le construire et l’opérer. Une équipe doit pouvoir être dimensionnée afin de fonctionner de manière autonome. Un découpage fonctionnel très global peut avoir un sens métier mais peut nécessiter d’être découpé en domaines fonctionnels plus restreints afin de les confier à de petites équipes.
Ce niveau de granularité tant du côté architecture qu’humain a été peu mis en avant jusqu’à aujourd’hui, or la charge cognitive liée à un projet informatique est une contrainte dont il faut absolument tenir compte. Avoir en tête l’ensemble des fonctionnalités qui sont implémentées dans le logiciel, les règles de l’entreprise et toutes les technologies mises en œuvre dans le produit, représentent une charge cognitive énorme. Cette charge est d’autant plus critique que les architectures modernes sont bien plus complexes et hétérogènes que les applications d’ancienne génération très monolithiques. Il faut être capable de réduire cette charge mentale pour la rendre humainement acceptable. Les auteurs de Team Topologies proposent par exemple la classification suivante : simple, compliqué, complexe. Ils recommandent alors de ne jamais attribuer un périmètre compliqué et un autre complexe à la même équipe.
Il y a encore quelques années, dans les organisations du travail très contributives, ou chaque équipe apportait son expertise sur son champ – un projet enchaînant ainsi une douzaine d’étapes au détriment du Time to Market – la charge cognitive était effectivement limitée. Hélas, l’allègement de ce fardeau déresponsabilisait trop souvent les acteurs vis-à-vis de l’objectif global, conduisant par ailleurs à l’ennui voire à la perte de sens.
Les Component Teams “agiles” ne font pas exception à la règle : chacune a la responsabilité d’une petite partie du développement du produit global. Sous couvert d’un périmètre fonctionnel limité, elles impliquent néanmoins de multiples dépendances entre elles pour accomplir un acte métier et porteur de valeur complet. Ce report de charge est un premier compromis mais il pèse alors sur l’ensemble de l’organisation en raison de dépendances fortes. Il requiert alors des trésors de planification et de gestion des versions.
Dès lors, quelle organisation et quelles architectures techniques garantissent une production rapide, de qualité et sereine pour les entreprises ? Les Feature Teams ou Steam Aligned Teams apparemment si productives mais qui requièrent des humains efficaces dans tous les domaines ? Les microservices soit disant si indépendants mais qui complexifient à outrance la communication et l’exécution ? Les compétences d’une part et le seuil de tolérance de cette charge d’autre part, variant d’une personne à l’autre, il n’existe nécessairement pas de réponse toute faite. Il est donc primordial d’ajouter la dimension cognitive, propre à l’humain, aux deux autres axes que sont la technologie et l’organisation pour atteindre les objectifs stratégiques de l’entreprise mais surtout pour conserver ses équipes dans la durée.
___________________
Par Jean-Rémy Revy, Practice Leader Modern Architecture chez Ippon Technologies
puis