Les 5 étapes pour réussir son projet de Data Visualisation
Vous êtes en charge d’un projet de Data Visualisation mais vous ne savez pas par où commencer ?
Nous avons formalisé pour vous les 5 étapes clés à suivre :
Poser le problème et les besoins métiers
Maquetter les Data Visualisations
Concevoir la solution technique Data
Déployer, industrialiser
Améliorer en continu
Ces différentes étapes sont décrites et accompagnées de fiches pratiques dans notre livre blanc
Principes et Méthodes pour maîtriser vos projets de data visualisation
Les 10 bonnes raisons de rejoindre l’aventure Rhapsodies Conseil
Une bonne ambiance, des teambuildings sportifs, une localisation idéale…
Quels sont tes critères de choix pour trouver LE job qu’il te faut ?
Sans vouloir nous vanter, chez Rhapsodies Conseil, nous cochons beaucoup de cases
Regarde par toi-même
Les actions majeures pour aligner la Gouvernance IT avec les ambitions de la DSI
Votre gouvernance IT n’est pas alignée avec les ambitions de votre DSI ?
Des signaux doivent vous mettre la puce à l’oreillle
Manque de repères sur l’avancée des projets métiers
Collecte d’informations hétérogènes, parfois contradictoires, à intervalles irréguliers
Des projets se lancent en dehors du contrôle de la DSI sur certains métiers ou géographies
…
L’équipe CIO Advisory vous dévoile les 4 grands axes majeurs pour réaligner votre gouvernance IT
Établissez une cartographie des référents métiers par géographie
Mettez en place les instances de gouvernance
Formalisez et partagez les priorités de la DSI
Définissez et partagez les KPI & les risques
4 Bonnes raisons de faire la formation Scrum master
Vous avez du mal à choisir un organisme de formation pour obtenir la certification Scrum Master ?
La première chose à vérifier est la certification Qualiopi de l’organisme: une obligation légale, gage de la qualité des formations proposées
Ca tombe bien, Rhapsodies Conseil est certifié Qualiopi et propose une formation certifiante de Scrum Master
Nous vous présentons ici les avantages à réaliser votre formation à nos côtés
1- Vous comprendrez les réalités du terrain grâce à nos coachs seniors expérimentés
2- Vous aurez des réponses à vos problématiques grâce à un temps consacré pour répondre vos questions
3- Vous enrichirez votre expertise de l’agilité grâce à des REX
4- Vous apprendrez de façon pragmatique avec des mises en situation et cas pratiques concrets
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.
