Quoi de nouveau dans la version 6 de SAFe pour le système architecte ?

11 juillet 2023

– 5 minutes de lecture

Salomé Culis

Consultante Architecture

Cet article est le premier d’une série présentant les évolutions des rôles des différents architectes dans la nouvelle version du framework SAFe.

Nous allons donc voir en détail les différences pour le System Architect, en particulier sur les sujets d’interactions avec les autres parties prenantes et les responsabilités du System Architect.

Changement de nom pour un nouvel architecte

Un premier point qu’il est important de souligner est le changement de nom de cet acteur lors du passage à la version 6 du framework. Celui-ci passe de “System Architect / Engineering” à “System Architect”, tout simplement.

Cela permet d’éviter une éventuelle confusion avec le Release Train Engineer ou même avec certains concepteurs fonctionnels qui sont plus proches d’un rôle de PO.

Mais ce changement de nom cache un changement beaucoup plus profond du rôle et de la posture de l’architecte système.

La compétence clé de l’architecte système, la collaboration

Dans cette nouvelle version du framework, la notion de collaboration est mise en exergue comme une compétence clé de l’architecte.

En effet, l’architecte système collabore avec différents groupes de parties prenantes :

Le PM et le RTE pour orienter les travaux du Train et contribuer au développement de la vision,
L’architecte solution et l’architecte d’entreprise afin de construire une architecture cohérente aux différents niveaux du framework et de l’entreprise,
Les équipes agiles pour les accompagner dans la mise en place de l’architecture,
D’autres équipes telles que la System Team ou des équipes Shared Services, notamment pour mettre en place des processus d’intégration et de tests automatisés.

Ainsi, l’architecte système doit être capable de travailler avec des acteurs très variés, de les aider à remplir leur rôle et de partager sa vision de l’architecture afin que le Train avance dans la bonne direction.

Nous voyons ici apparaître une notion de base de l’agilité, présente dans le manifeste agile (que vous avez tous sur votre table de nuit ou encadré au-dessus de votre bureau, j’en suis certaine !).

Cette nouvelle version du framework positionne très clairement l’architecte système comme un acteur qui sort de la tour de verre de l’architecture et va s’intégrer au quotidien dans les équipes.

La proximité favorise la collaboration

A titre personnel, en tant qu’architecte sur un programme de refonte de la relation client, j’avais fait le choix d’aller m’installer dans l’open space avec les équipes agiles. Cela permettait de :

Faciliter la collaboration avec elles,
D’être plus facilement impliquée dans des échanges avec le Programme Management et de mieux connaître les priorités pour pouvoir concentrer mes efforts sur les bons sujets,
D’avoir un vrai lien avec les équipes et qu’elles n’hésitent pas à venir me voir pour échanger sur l’architecture.

Au-delà des aspects cités précédemment, je me suis ainsi sentie comme faisant partie du projet à part entière. Je m’étais bien sûr assurée de garder une proximité forte avec mes collègues architectes (nécessaire pour s’aligner aux différents niveaux si vous avez bien suivi !).

Les responsabilités clés de l’architecte système

Vous vous dites peut-être que l’architecte système échange avec beaucoup d’acteurs. Et vous vous demandez peut-être en quoi consiste véritablement son rôle.

En effet, son rôle évolue pour assumer les responsabilités ci-dessous :

Aligner l’architecture avec les priorités Business (grâce à ses échanges avec le PM et les autres architectes),
Définir et communiquer la Vision d’Architecture (notamment auprès des équipes agiles),
Faire évoluer le système avec les équipes,
Favoriser la qualité au fur et à mesure de la construction du système et permettre la mise en place des NFRs (ou exigences non fonctionnelles). L’architecte s’assure qu’ils soient pris en compte dans le backlog et accompagne leur développement par les équipes,
Permettre la mise en place du DevOps et du Continuous Delivery Pipeline (par la collaboration avec la System Team par exemple).

Les deux derniers points notamment impliquent un véritable changement d’état d’esprit. Le travail de l’architecte ne s’arrête pas au moment de la présentation de la Vision d’Architecture, il doit continuer à accompagner le Train opérationnellement au quotidien pour pouvoir remplir l’ensemble de ces responsabilités.

Auparavant définies sous la forme d’une liste à la prévert, les tâches du System Architect deviennent à présent un nombre limité de responsabilités clés.

C’est un vrai shift pour la position de System Architect.

D’un architecte système qui s’assoit sur les “fauteuils pré-positionnés” par ceux qui ont défini le cadre de gouvernance SAFe, nous passons à un vrai acteur et “modeleur” de l’itération locale du framework SAFe.

Il n’est pas cantonné à des tâches définies de manière top-down, mais devient un acteur/décideur/influenceur du système.

Si ces sujets vous intéressent…

Pour plus d’informations sur ces sujets et sur le rôle d’architecte dans un environnement agile, n’hésitez pas à aller voir notre série d’articles sur l’architecture et l’agilité.

Les articles 1 et 4 peuvent en particulier se révéler utiles :

Article 1 : c’est quoi l’Agilité ? Cet article introduit notamment l’agilité à l’échelle et le framework SAFe. Des ateliers favorisant la co-construction de l’architecture sont également évoqués et pourront se révéler très utiles pour faire participer les différentes parties prenantes avec lesquelles l’architecte collabore.
Dans l’article 4, intitulé “Comment les architectes peuvent interagir avec l’agilité ?”, nous avions évoqué le fait d’aller vers des modes de travail plus collaboratifs et d’être véritablement partie prenante de la transformation de l’entreprise.