“La montée en puissance des méthodes agiles annonce-t-elle le déclin de l’architecture ?”

L’agilité sonne-t-elle la fin de l’architecture  ?

Les méthodes agiles sont de plus en plus présentes au sein des DSI et rendent parfois le positionnement du rôle d’architecte plus difficile. Les visions des uns et des autres étant très différentes. Les architectes se doivent d’avoir une vision à long terme en cohérence avec la stratégie de l’entreprise, au contraire les équipes agiles se doivent d’avoir une vision à court terme axée sur la livraison d’un produit. Les architectes auront tendance à produire des documents de référence au contraire des agilistes qui préféreront une documentation collaborative et limitée au strict essentiel.

Parfois les architectes considèrent les agilistes comme des amateurs, sans expérience et devant être circonscrit à des petites applications web. Parfois, les praticiens Scrum ou XP perçoivent les architectes comme des personnes rétrogrades. Des individus capables de concevoir une architecture rigide, une architecture complexe sans valeur métier. Et de produire une documentation massive qui amènera des fonctionnalités non utilisées.

Différents positionnements de l’architecte existent : inclus dans l’équipe, dilué dans l’équipe, en dehors de l’équipe. J’ai déjà vécu plusieurs de ces positionnements et aucun ne m’a convaincu ni  satisfait.

Est-ce que ces vues sont fondées ? Est-ce que ces différents points sont opposés, contradictoires ou complémentaires ? Comment réconcilier une vision d’architecture d’entreprise avec des développements agiles focalisés sur la livraison d’un produit ?

Il existe une voie possible et très intéressante : l’architecture agile. Mais avant d’en parler examinons deux situations différentes issues de mon parcours.

 

Retour d’expérience : opposition entre développement agile et architecture

Cette première expérience non concluante a fini par opposer le travail des deux départements. Comment en est-on arrivé à une situation ou deux équipes n’arrivent pas à travailler ensemble ?

L’état des lieux de la DSI :

Un département d’architecture existant.

  • Ayant pour objectif de produire une vision d’architecture pour l’entreprise à plusieurs années.
  • Centré sur la production de livrable d’architecture, des documents de référence.
  • Ayant peu de relation directe avec les équipes de développement.
  • Travaillant plusieurs mois en amont sur les futurs applicatifs

Une nouvelle équipe de développement en cours de création.

  • Ayant pour objectif la création d’une application (le produit).
  • Centrée sur la production de code, à forte valeur métier.
  • Ayant peu de relation directe avec l’équipe d’architecture.
  • Travaillant sur un cycle de trois semaines sur leur applicatif.

Des actions malheureuses ont placé en opposition les visions portées par l’agilité et l’architecture :

  • Séparer les équipes physiquement ;
  • Réduire la communication au minimum ;
  • Outrepasser les processus en place sans prévenir les acteurs ;
  • opposer la documentation collaborative (wiki) aux documents de référence ;
  • Dissocier les cycles hebdomadaires des équipes agiles du cycle annuel des architectes ;
  • Disjoindre la vision à court terme de la vision à long terme.

Le résultat de ces actions n’a évidemment pas aidé à améliorer la DSI. Elle n’a fait que renforcer les divergences entre les points de vue.

Les inconvénients de cette situation :

  • Prendre en compte des besoins métiers trop tôt, qui seront remis en cause lors du développement. Les architectes assumant aussi le rôle d’AMOA pour la capture des besoins métiers ;
  • Développer des fonctionnalités inutiles. Je ne sais pas si Google Documents a été développé en mode agile. Mais j’arrive à produire un article, à qualité égale, avec Google Document (qui comporte beaucoup moins de possibilités que Microsoft Word) ;
  • Produire une documentation peu abordable et trop imposante. Autant j’adore ouvrir un roman de science-fiction comportant plusieurs centaines de pages, autant le même nombre de page détaillant des architectures fonctionnelles aurait plutôt tendance à me rebuter.

Mais cette situation n’amène pas que des inconvénients.

Les avantages de cette situation :

  • les rôles sont clairs, les architectes conçoivent l’architecture, les équipes de développement développent. Si toutefois les équipes ne se disputent pas la conception de l’architecture applicative ;
  • l’équipe de développement reste maître de ses choix (techniques ou fonctionnels), ce qui permet une plus grande implication donc motivation de ses membres ;
  • la livraison du produit reste l’objectif majeur de l’équipe. Cet objectif n’est pas laissé pour compte au détriment de la réalisation des composants d’architecture.

Retour d’expérience : architecture diluée dans les équipes de développement

Cette deuxième expérience non concluante a fini par faire disparaître, non seulement le rôle d’architecte, mais aussi ses contributions. Comment en est-on arrivé à une situation ou l’architecture n’existe plus ?

L’état des lieux de la DSI :

Plusieurs équipes de développement (en mode agile) composent la DSI. Ces équipes sont petites (deux à quatre développeurs) et toutes ne possèdent pas de concepteur expérimenté permettant de remplir le rôle d’architecte. Celui-ci est banni, on ne parle pas d’architecture c’est quasiment un gros mot. Il n’existe pas d’architecture partagée, ni de roadmap, encore moins de vision. Le rôle est donc assimilé par l’équipe, voire même digérée (et donc inexistant) par certaines équipes. Les interactions entre les équipes étant faibles, il n’existe pas de partage de l’architecture. Certains composants ou services sont dupliqués et les impacts de modification de composant ne sont visibles que lors de la phase d’intégration.

Les inconvénients de cette situation :

  • Pas de rôle clairement établi, la responsabilité est reportée sur l’équipe. Ceci peut être normal, voire conseillé dans certaines équipes. Mais lorsque les développeurs ont peu d’expérience et sont peu nombreux, la responsabilité disparaît tout simplement ;
  • Du refactoring en masse. Pas le refactoring nécessaire à chaque sprint permettant d’améliorer le code, mais du refactoring qui oblige à interrompre un sprint afin de revoir en profondeur la conception ;
  • des impacts suite aux modifications non anticipées et qui se dévoilent lors des mises en production.

Mais cette situation n’amène pas que des inconvénients.

Les avantages de cette situation :

  • pas de documentation à réaliser donc gain de temps à court terme évidemment ;
  • peu de conception applicative, la production de code reste focalisée sur la livraison des fonctions répondant aux besoins métiers ;
  • des coûts de développement plus faibles sur le court terme. Un développeur débutant étant moins cher qu’un senior.

 

 

La voie du sage : l’architecture agile

 

S’adosser aux méthodes agiles permet aux architectes de concevoir une architecture, répondant aux besoins métiers, aux objectifs de l’entreprise, le tout délivré au juste moment.

Un architecte doit coopérer et quoi de mieux que les cérémonies Scrum pour établir desinteractions entre leurs méthodologies, leurs processus et les équipes agiles. Suite à ces interactions, leslivraisons des architectes devront s’adapter aux rythmes agiles.  Enfin, la communication est un des fondamentaux du rôle d’architecte. Autour de ces trois items, le travail de l’architecte et des équipes agiles prendra toute sa valeur et son utilité.

Interaction

  • Planification initiale

Lors de la planification initiale, comme dans tous les projets, les architectes doivent :

  • Faire les principaux choix logiciels et matériels ;
  • Identifier les composants ou services réutilisables ;
  • Générer des diagrammes de haut niveau ;
  • Communiquer avec les acteurs du projet (métiers, développeurs, production) afin de recueillir leurs besoins généraux et partager avec eux les orientations prises.
  • Storyboard et backlog

Lors de la définition des storyboards et du backlog, l’architecte fait partie des acteurs. De par sa compréhension des enjeux métiers et des contraintes (ou opportunités) techniques, l’architecte tient un rôle clé dans la définition des besoins.

  • Participation au sprint

L’architecte se doit de coopérer fortement, avec l’équipe. Il doit comprendre les objectifs du sprint afin d’aider l’équipe de développement à définir les grandes lignes de la conception. Arrivé à ce point, l’architecte devient alors un contributeur clé,  localisé physiquement avec l’équipe, avec la co-responsabilité du travail à réaliser.

  • Revue de sprint

La revue de sprint permet à l’équipe de présenter aux différents acteurs l’avancée du produit. L’architecte est partie prenante des acteurs. Il aura préparé en amont la revue de l’architecture grâce à la documentation itérative fournie par le projet. Chaque erreur ou omission sera corrigée dans le sprint courant ou le suivant limitant ainsi les dettes d’architecture.

Livraison

En plus, de ces différences interactions, l’architecte doit s’adapter et délivrer des éléments d’architecture en respectant les points suivants :

Décomposition des composants

En mode agile, inutile d’espérer produire les documents d’architecture avant le sprint zéro. À l’identique du Product Owner qui décomposent les besoins métiers en features puis en user stories, l’architecte doit identifier les limites des composants d’architecture. Ceci afin de permettre à l’équipe de s’assurer que la décomposition des besoins métiers respectent ses limites.

Contribution de l’architecture au backlog

Intégrer les user stories d’architecture au backlog nécessitera certainement beaucoup de conviction de la part de l’architecte. La valeur métier de celles-ci n’étant pas forcément établie par le Product Owner. Néanmoins, plusieurs solutions existent :

  • Ouvrir un deuxième backlog spécifique aux users stories d’architecture.
  • Intégrer les users stories au backlog du produit suite à une estimation de leur valeur métier avec le product owner.
  • Noyauter les users stories existantes avec les demandes d’architecture.

Communication

Livrer c’est bien, communiquer en amont et lors des livraisons est primordial.

Toute documentation n’est pas superflue

Souvent un prototype peut suffire afin de valider l’architecture. Mais certaines circonstances amènent à décrire plus formellement l’architecture, par exemple, la communication vers d’autres entités de l’entreprise ou pour répondre aux réglementations externes.

La valeur de l’architecture

Je ne saurais vous dire combien peut vous rapporter une architecture, par contre je pourrais vous décrire une dizaine d’exemples de ce qu’il en a coûté de ne pas avoir d’architecture. Le plus dure est certainement de placer le curseur à sa juste valeur. Concevoir l’architecture sans tomber dans le piège de l’architecture parfaite.

Auto-promotion auprès du Product Owner

Le métier d’architecte inclus une grande part de communication et celle-ci va être cruciale vis-à-vis du Product Owner. En effet, celui-ci est le rouage entre les besoins métiers et le produit final. Il va donc falloir le convaincre de l’utilité et de la pertinence de l’architecture. Dans le cas contraire les travaux d’architecture auront toujours des priorités basses et ne seront donc jamais réalisées.

 

En finir avec cette opposition contre-productive

Agilité et architecture ne sont donc pas des ennemis. Vous vous en doutiez avant de commercer à lire cet article, j’espère vous avoir fourni quelques arguments pour vous en convaincre.

La conception top-down initiée par les architectes et la conception bottom-up conçue par les équipes agiles sont complémentaires et nécessaires afin de délivrer un produit conforme aux besoins, parfaitement intégré dans le SI et robuste sur le long terme. L’anticipation n’est pas interdite dans l’agilité comme l’adaptation doit être une nouvelle vertu de l’architecture.

Pourquoi est-ce à l’architecte de s’adapter aux méthodes agiles et non l’inverse ? Car c’est toujours la personne la plus souple, la plus adaptable qui survivra !

 

Références :