Agile à l’échelle : quels nouveaux rôles pour l’architecte ?
Les approches dites « agiles » ont su au fil du temps prendre le contre-pied des approches de gestion de projet traditionnelles. Si les rôles de chef de projet et des équipes de développeurs ont beaucoup été évoqués, celui de l’architecte l’a été beaucoup moins. Pourtant, celui-ci reste un maillon essentiel dans des organisations agiles à grande échelle. Quelle place pour l’architecte dans cet environnement de plus en plus indépendant et flexible ? Focus dans cet article sur ses nouveaux rôles.
Cet article présente un éclairage sur les rôles des architectes identifiés à horizon 2020 dans des organisations agiles à l’échelle. Il s’appuie sur un des frameworks d’agilité à l’échelle les plus adoptés par les entreprises, à savoir SAFe.
Cet article a été co-écrit avec Giulio Foresto, Senior Consultant IT & Data Architecture au sein du cabinet Wavestone.
Un modèle traditionnel encore utilisé par beaucoup d’entreprises
Dans les organisations classiques, les architectes interviennent sous la forme de deux rôles :
• l’Architecte Projet : il est intégré aux projets et intervient sur la partie opérationnelle. Il collabore avec les métiers pour les aider à décliner leurs besoins sur le SI. Il intervient sur un pan précis du SI (périmètre du projet), avec une perspective court terme (de 6 à 24 mois selon les projets).
• l’Architecte d’Entreprise : il intervient à un niveau stratégique pour assurer la cohérence globale de l’architecture. Il doit apporter une vision et un contrôle sur l’évolution durable du SI au regard de la stratégie métier ; il travaille en étroite collaboration avec la direction et les métiers sur une base prospective (2–5 ans). Il est amené à intervenir sur des grands programmes au sein de la DSI.
Selon les organisations et la complexité des projets, d’autres profils complémentaires peuvent être nécessaires (architecte de domaine, architecte de programme…). La relation entre ces deux profils est gouvernée en se gardant de les hiérarchiser, chacun contribuant également à la construction du SI.
Plusieurs éléments sont souvent irritants dans ce schéma, notamment le manque de vision produit final, ou le caractère de bottleneck de l’architecte d’entreprise positionné en validateur de tout projet (éventuellement par l’intermédiaire d’un comité d’architecture), ce qui participe également a lui conférer une stature d’autorité dans sa tour d’ivoire qui l’éloigne des équipes projet.
Les concept du Scaled Agile Framework (SAFe) : une organisation agile à l’échelle
L’essor des méthodes agiles a poussé ce schéma classique à évoluer afin de pouvoir assurer les grands principes de l’agile comme l’adaptabilité et l’évolutivité, tout en réduisant la durée des cycles de livraison.
Prenons l’exemple de SAFe : le Scaled Agile Framework est un cadre organisationnel qui adapte la méthodologie Agile, prévue initialement pour des équipes projet, à l’échelle de toute une entreprise, potentiellement de grande taille. Tout comme la méthodologie Agile à l’échelle du projet, SAFe promeut le développement par itérations, la collaboration spontanée, le foisonnement d’idées par les développeurs. SAFe vient notamment bousculer l’organisation et la gouvernance des grandes entreprises, et par là le rôle des architectes à tous les niveaux.
Un découpage en 4 strates :
- Le niveau PORTFOLIO est le niveau auquel sont définies les solutions ainsi que leur stratégie de développement. Les grands besoins métiers et non fonctionnels y sont déclinés en Epics.
- Le niveau SOLUTION est un produit final ou un système cohérent, apportant de la valeur à l’organisation. Elle est livrée par un ou plusieurs trains.
- Le niveau TRAIN rassemble des équipes agiles (feature teams) avec un certain niveau de cohérence ou d’adhérence métier ou technique, afin de livrer tout ou partie d’une solution. Le train cadence les travaux de plusieurs feature teams lors de PI Plannings ayant lieu tous les 2 à 3 mois.
En pratique, lorsque la solution est livrée par un seul train, les deux strates SOLUTION et TRAIN sont fusionnées en un seul et même niveau.
- Le niveau FEATURE TEAM est composé d’équipes responsables chacune de concevoir, implémenter, déployer et de maintenir un service.
Quels principes régissent une organisation agile à l’échelle ?
Des équipes plus autonomes dans leurs choix d’architecture
Les équipes sont orientées produit et sont plus autonomes dans leurs choix d’architecture. Toutefois, dans une grande entreprise, afin de garantir une cohérence sur l’ensemble du SI, cette autonomie pourra être encadrée par un framework arrêté de façon collaborative entre les différents niveaux de l’organisation (des Architectes d’Entreprise aux Feature Teams).
Des standards d’architecture reposant sur l’expérimentation
Les décisions d’architecture se prendront sur la base de l’expérimentation plutôt que d’une étude théorique détaillée. Les équipes peuvent expérimenter plusieurs solutions concurrentes en parallèle temporairement avant de faire leur choix et le partager. Les expérimentations peuvent être impulsées par les Feature Teams elles-mêmes ou exprimées en tant que besoins par les couches supérieures.
La collaboration et le partage favorisent les bonnes décisions
Afin de garantir un maximum de rendement de chaque choix d’architecture, le partage des résultats et des solutions trouvés par une équipe pour en faire bénéficier toutes les autres est essentiel. Symétriquement, la collaboration entre les différentes strates d’architecture (de la Vision à la Feature Team) dans la définition et la diffusion des standards d’entreprise est la clé pour leur bonne adoption par les équipes.
Des besoins non fonctionnels considérés à part entière
La solution à un besoin non fonctionnel (rationalisation du SI, brique technique…) apporte de la valeur ajoutée au même titre que dans le cas d’un besoin fonctionnel. Ainsi, les objectifs résultant de la Vision SI, ainsi que les besoins de briques techniques, doivent être intégrés au backlog sous forme d’enablers, et être traités comme un besoin métier.
Des rôles d’architecte réinventés
Sur chacune de ces strates, un rôle d’architecte avec des compétences propres à chacun aura sa valeur ajoutée :
• Au niveau FEATURE, un Tech Leader va émerger spontanément dans l’équipe de développement afin de mettre son expertise technique à disposition de ses collègues et mener ou coordonner les expérimentations.
• Au niveau TRAIN, le System Architect va garantir la cohérence d’architecture du train. Il priorise les pistes à explorer, assure la capitalisation des expérimentations et les escalades en cas d’arbitrage ou de synchronisation nécessaire avec d’autres feature teams ou trains.
- Au niveau SOLUTION, le Solution Architect est responsable de la solution qu’il doit livrer et de sa valeur ajoutée. Il anticipe la macro-conception d’architecture de sa solution et synchronise les différents trains lancés au service de sa solution pour s’assurer que celle-ci aboutisse et apporte la valeur espérée.
En pratique, lorsque la solution est livrée par un seul train, le System et le Solution Architect peuvent être la même personne.
• Au niveau PORTFOLIO, l’Architecte d’Entreprise va, en garantissant une vision long terme, décliner les objectifs d’architecture et les expérimentations en Epics, en construisant et diffusant une stratégie sur tous les pans de l’architecture, aussi bien sur le volet technologique que méthodologique. Il participe au Lean Portfolio Management en misant sur les axes de développement à plus forts potentiels.
De par la diversité des activités selon les strates, les profils d’architectes vont nécessiter des compétences diverses afin de répondre aux différents enjeux. Ces nombreux rôles de l’architecture au sein d’une organisation agile à l’échelle vont également nécessiter de nouveaux moyens de coordination entre tous les acteurs.
De la nécessité de coordonner ces différents rôles
Ce découpage en strates n’implique pas pour autant un cloisonnement des rôles, bien au contraire. Les interactions entre les différents architectes sont nécessaires.
• Au niveau VISION, l’architecte d’entreprise, en collaboration avec les Architectes Solutions, participe au découpage des epics, à leur affectation aux différents trains et à leur priorisation.
• Tous les architectes embarqués dans un même train se rencontrent lors des PI (Program Increment) Planning, afin que chacun s’aligne sur la vision du train et ses objectifs. Il s’agira également de faire une rétrospective du PI précédent ainsi que de planifier le prochain PI.
Une Guilde d’Architecture, constituée de tous les architectes et les personnes intéressées par l’architecture, permet de rassembler la communauté au travers de partages de REX, de discussions et de la capitalisation des connaissances. Elle catalysera l’échange, en permettant de commenter des expérimentations ou de proposer des enablers, en se donnant comme moyens des plateformes de partage documentaire, d’échange et des sessions en présentiel.
Une System Team d’Architecture, composée de représentants de tous les profils d’architectes, arbitre et diffuse les enablers réalisés par les feature teams et ayant vocation à être élargis à tout le SI, en validant ainsi des standards d’architecture. Elle est garante du référentiel d’architecture et apporte un support aux équipes sur des sujets spécifiques lorsque la documentation et l’aide de la communauté (de la Guilde) ne suffisent pas.
L’enabler : un facilitateur pour agiliser le SI
Les enablers sont des solutions ou des features qui ne correspondent pas à un besoin métier, mais qui fournissent les prérequis et capacités nécessaires pour développer les solutions et features fonctionnelles.
Un des principes de l’agilité à l’échelle est de considérer ces enablers au même titre que des besoins fonctionnels car ils permettent aux équipes de s’adapter facilement aux besoins remontés par les équipes.
Les enablers au niveau des features team peuvent être des initiatives spontanées venant d’un Tech Leader afin de pouvoir réaliser un besoin. Leurs retours d’expérience sont partagés en PI Planning afin d’instruire, de valider voire de diffuser les enablers ayant un intérêt pour tout le SI.
Les architectes d’entreprise se doivent également d’anticiper les enablers qui seront nécessaires au bon développement des solutions lorsqu’ils dressent la vision cible et les chantiers à lancer.
Les enablers contribuent à alimenter l’Architecture Runway, c’est-à-dire qu’ils constituent des éléments qui viennent régulièrement enrichir le patrimoine d’architecture des équipes (à l’échelle de la feature team, du train ou de l’entreprise). Elle consiste à anticiper les besoins d’architecture et à poser les rails qui vont permettre le développement des features.
En conclusion
Les enjeux portés par l’architecture ne sont pas réinventés : il s’agit fondamentalement pour les architectes de délivrer une solution qui apporte la valeur attendue tout en garantissant l’intégrité et la cohérence du système d’information.
Dans un framework agile, cela implique donc de réaffirmer le rôle de l’architecte d’entreprise, en l’établissant comme un facilitateur plus qu’une autorité incontournable pour toute décision d’architecture.
La démarche agile apporte également une vision produit (ou value stream), à laquelle des équipes, pilotées par des architectes responsables de leur coordination et de la valeur ajoutée finale.
Enfin, les équipes de développement sont responsabilisées en gagnant une certaines autonomie, et en contrepartie sont mises à contribution dans les expérimentations dont découlent les choix d’architecture.
Dans des organisations à grande échelle, il faut garantir un cadre favorisant la collaboration et le partage entre les différentes équipes d’architecture. Des concepts venus de divers frameworks comme la Guilde et la System Team d’Architecture permettent l’échange, la remontée et la résolution de problèmes, la consolidation des connaissances dans les référentiels d’architecture, l’arbitrage des choix et la diffusion des standards.
Le cadre est ainsi posé pour que la fonction architecture puisse répondre aux enjeux de demain, favoriser l’expérimentation tout en faisant preuve d’agilité.
