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.

Pour les entreprises qui sont confrontées à un virage vers le data driven, le fait de sous-estimer le besoin de changement organisationnel est souvent un problème plus important que les questions de technologie. Une entreprise peut disposer d’outils puissants et de données significatives, mais sans l’accompagnement et les processus appropriés pour mettre ces données entre les mains des bonnes personnes, l’extraction de la valeur peut s’avérer difficile. 

Mettre en place une culture de l’apprentissage continu au sein de l’entreprise est un vrai levier de performance pour votre organisation et d’épanouissement de vos salariés.

Prenons l’exemple d’un programme de libre accès aux données:

Lorsque les données sont fondamentales pour la gestion de votre organisation, des analyses doivent être effectuées très rapidement au sein de toute votre organisation car elles sont essentielles à votre business.

L’idée des données en libre-service est la suivante : plutôt que d’engager un nombre infini de talents hautement qualifiés en data, pourquoi ne pas employer votre capital intellectuel et votre capital humain existant au sein votre organisation et leur donner les moyens de faire leur propre travail d’analyse des données ? Dans un système en libre-service, les différents métiers de votre organisation et les analystes peuvent accéder et travailler directement avec les données et leur visualisation. Ils sont aidés par des experts data, mais sans en dépendre, pour effectuer leur travail. C’est l’essor des “citizen data scientist”. 

Ce type de programme permet aux entreprises de supprimer les frontières techniques et donne aux collaborateurs la possibilité d’utiliser leur propre expertise en la matière – après tout, ils connaissent mieux les problèmes auxquels ils s’attaquent, et ils savent de quelles données ils ont besoin – pour générer des idées et exécuter leur travail. 

Qu’est-ce que cela signifie pour la gouvernance des données ?

Les données en libre-service et la gouvernance vont certainement de pair. Il y a un équilibre délicat à trouver dès le départ. Vous devez protéger les utilisateurs et l’entreprise, vous assurer que vous êtes en conformité et que vous respectez les règlements, et permettre une meilleure compréhension des données. Mais en même temps, vous ne voulez pas être un obstacle tel que les gens ne puissent pas faire leur travail. 

Le catalogage des données, la traçabilité des données et la mise en place d’un cadre d’utilisation (rôles, responsabilités, process, etc.) autour des données sont des éléments clefs de la gouvernance, car les collaborateurs doivent disposer des bonnes informations et du bon contexte concernant les données qu’ils consultent pour réussir. 

Construisez la culture data d’apprentissage et prévoyez un temps de réflexion 

Ce paragraphe ne concerne pas uniquement vos enjeux data, mais peut répondre à la question plus globale de l’organisation apprenante.

Établissez les bonnes bases culturelles en plaçant l’apprentissage au centre de votre organisation. Une organisation apprenante ne peut voir le jour que dans le cadre d’une culture d’intégration, de confiance, de collaboration et de leadership engagés sur le lieu de travail. Le changement cela ne se décrète pas. Donnez à votre équipe l’espace et le temps de réfléchir, de prendre du recul et de travailler sur leurs idées. Créez une culture de travail personnalisée et adaptée, qui accueille la dissidence, récompense la créativité et sollicite des avis extérieurs pour améliorer la prise de décision globale. 

In fine ces bonnes pratiques d’acculturation data en interne et de gouvernance des données vous aideront à répondre à une solution simple à fort potentiel : au lieu de trouver un objectif pour les données, trouvez des données pour un objectif. Cela vous permet de piloter vos données comme des actifs précieux au service des besoins métiers à valeur ! 

Pour aller plus loin,

Transformation Data-driven :

Livre Blanc Augmentez la Valeur de vos données!