L’agilité sonne-t-elle la fin de l’architecture ? Les pratiques agiles sont de plus en plus présentes au sein des DSI. Ce développement redéfinit le rôle de l’architecte dans les projets et plus généralement au sein de la DSI. Néanmoins les architectes se doivent d’avoir une vision à long terme en accord avec la stratégie de l’entreprise contrairement aux équipes agiles qui ont une vision à court terme axée sur la livraison d’un produit. Par Christophe Cosnefroy, Consultant Sénior, chez Neoxia.

Divers positionnements existent dans l’organisation : “inclus”, “dilué” ou “en dehors de l’équipe”. Pour avoir vécu personnellement vécu deux de ces situations, aucune ne m’a convaincu.

Expérience “Les opposants” : opposition entre développement agile et architecture

Deux visions s’opposent.

La première du département d’architecture est une vision long terme. Le département livre des documents d’architecture plusieurs mois en amont des développements, ces documents traduisant la stratégie de l’entreprise. Les inconvénients majeurs sont la prise en compte de besoins métiers non matures, la livraison de fonctionalités inutiles et une documentation peu abordable.

La seconde vision, de l’équipe de développement, est centrée sur la livraison d’un produit, à court teme, au travers de la production de code.

Cette opposition à pour avantage de clarifier les rôles de chacun. Les développeurs restent maîtres de leurs choix et leur objectif primordial reste la livraison du produit.

Expérience “Les dilués” : architecture diluée dans les développements

Plusieurs petites équipes de développement agiles, elles ne possèdent pas toutes de concepteur expérimenté. Il n’existe pas d’architecture partagée. Le rôle est assimilé par l’équipe ou n’existe pas dans certaines équipes.

Cette situation à pour inconvénient un manque de conception entrainant un refactoring massif, des impacts non prévus et des composants dupliqués entre équipes.

L’avantage se limitant à un gain de temps temporaire dû à la non production de documentation. Donc des coûts de développement plus faibles.

La voie du sage : l’architecture agile

S’adosser aux pratiques agiles permet de concevoir une architecture, répondant aux besoins métiers, le tout au bon moment. Un architecte doit coopérer via les cérémonies Scrum pour établir des interactions. Ses livraisons s’adapteront aux rythmes agiles. La communication restant un de ses fondamentaux.

Interaction

1. Planification initiale

§ choix des logiciels et matériels ;

§ identification des composants réutilisables ;

§ communication avec l’ensemble des acteurs du projet.

2. Storyboard et backlog

Participation aux storyboards et au backlog. L’architecte tient un rôle clé dans le recueil des besoins.

3. Participation au sprint

Coopération avec l’équipe. Compréhension des objectifs du sprint afin d’aider à définir la conception. L’architecte a la coresponsabilité du travail à réaliser.

4. Revue de sprint

L’architecte est partie prenante des acteurs et aura préparé en amont la revue d’architecture.

Livraison Décomposition des composants

En mode agile, pas de document d’architecture avant le sprint zéro. L’architecte doit identifier les limites des composants correspondant aux besoins métiers.

Contribution au backlog

Intégrer les user stories d’architecture au backlog nécessitera beaucoup de conviction de l’architecte.

Plusieurs solutions existent, soit par l’ouverture d’ un deuxième backlog. Ou l’Intégration des users stories techniques au backlog du produit. Soit enfin par un “noyautage” des users stories par l’architecture.

Communication La documentation est utile

Un prototype peut suffire pour valider l’architecture, mais certaines circonstances amènent à décrire plus formellement l’architecture.

La valeur de l’architecture

Difficile à mesurer objectivement, mais les coûts augmenteront à coup sûr sans elle.

Auto-promotion auprès du Product Owner

Convaincre le Product Owner de l’utilité de l’architecture. Sinon elle aura des priorités basses et ne sera jamais réalisée.

En finir avec cette opposition

Agilité et architecture ne sont pas des ennemis. J’espère vous avoir fourni des 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, intégré dans le SI et robuste. L’anticipation est recommandée dans l’agilité comme l’adaptation se doit d’être une nouvelle vertu de l’architecture.

Christophe Cosnefroy, Consultant Sénior, chez Neoxia