Rôle de l’architecte de solution dans la gouvernance de projet.

Souvent, le rôle d’un architecte de solution dans le projet est d’utiliser son expérience et son expertise pour évaluer les problèmes et les changements. Cependant, le suivi du changement dans un projet est excessivement simple, en particulier dans Microsoft Power Platform. Par conséquent, l’architecte de solution pourrait devenir trop concentré sur la surveillance du changement plutôt que sur la progression du projet. L’architecte de solution doit donc guider les autres membres de l’équipe de projet dans l’évaluation et l’analyse des problèmes et des changements.

L’un des défis que doivent relever les nouveaux architectes de solution est de quitter le rôle d’exécutant pour celui de dirigeant et de guide. Un architecte de solution doit être disponible pour les autres membres de l’équipe de projet et soutenir leur croissance.

Implication dans la définition de la gouvernance

Dans le cadre des projets Microsoft Power Platform, il peut être simple d’apporter des modifications ; toutefois, l’apport de plusieurs petites modifications et un mauvais processus de gouvernance peuvent faire échouer un projet. Par exemple, l’architecte de solution doit s’assurer que le processus d’évaluation du changement ne prend pas plus de temps que l’implémentation du changement.

Il est impératif que l’architecte de solution participe à la définition des processus et des procédures de gouvernance du projet. Son implication permet de s’assurer que les processus et procédures sont adaptés aux technologies Microsoft Power Platform qui sont utilisées et qu’ils n’entraînent pas de frais généraux inutiles.

Fournir des commentaires concrets

L’architecte de solution est souvent l’intermédiaire entre le client et les membres de l’équipe. Par conséquent, il doit fournir des commentaires aux deux parties. En premier lieu, des commentaires doivent être fournis pour aider à façonner la solution.

Les commentaires peuvent avoir lieu dès la création de l’appel d’offre / du cahier des charges. Cependant, ils doivent être réalisés sur une base continue tout au long du projet.

L’architecte de solution est chargé de s’assurer que les commentaires sont constructifs et exploitables.

Gérer les mauvaises nouvelles

Parfois, l’architecte de solution fournit des commentaires sur un problème qui pourrait ne pas être bien reçu. Les mauvaises nouvelles ne s’améliorent pas avec le temps. L’architecte de solution doit reconnaître et partager les mauvaises nouvelles au début du processus.

Exemples de mauvaises nouvelles que l’architecte de solution ne doit pas retenir :

• Le coût des licences utilisateur augmentera de 87 % si cette exigence est maintenue telle quelle.
• Cette fonctionnalité est obsolète.
• Avec la relation ajoutée, l’importation des données prend désormais 30 jours.
• La migration des données a identifié 200 nouvelles colonnes et, à partir de ces données, trois nouveaux processus non documentés ont été découverts.

L’architecte de solution doit s’assurer que les commentaires, en particulier les mauvaises nouvelles, sont exploitables. Il est inutile d’affirmer que « quelque chose ne va pas » car cela n’incite pas à l’action et le destinataire doit essayer de comprendre quel est le problème. Au lieu de cela, l’architecte de solution doit élaborer un énoncé clair du problème, puis fournir des références et l’impact potentiel sur le projet.

Pensez à des projets auxquels vous avez participé, puis rappelez-vous comment les mauvaises nouvelles ont été traitées et quel effet cela a eu sur le projet.

Aider les gens à arriver à la même conclusion

Bien que l’architecte de solution ait le plus d’expertise, vous devez aider les membres de l’équipe de projet et le client à résoudre un problème. Dire que « cela ne fonctionnera pas » amènera probablement quelqu’un à se sentir sur la défensive. L’architecte de solution doit toujours être constructif et éviter de dire « non » trop souvent. Au lieu de cela, offrez des options ou négociez les exigences.

Vous devriez poser des questions suggestives telles que « Est-ce que cela entraînera l’exécution de 1 000 000 flux de cloud Power Automate avec cette configuration ? » Poser une question suggestive encourage la personne à réfléchir à l’impact de sa proposition. N’oubliez pas que cette personne n’a peut-être pas la même vision globale du projet que l’architecte de solution.

Si vous avez des doutes sur une solution ou un changement proposé, vous devez souligner votre inquiétude mais encourager la personne à y réfléchir et à la résoudre.

Revoir le travail des autres est une tâche clé pour l’architecte de solution. La différence entre examiner ce que quelqu’un a fait et faire le travail soi-même est minuscule. Lorsqu’il examine le travail d’autrui, l’architecte de solution doit se montrer constructif et proposer des suggestions pour trouver des réponses. Par exemple, lorsqu’il n’est pas clair qu’une conception solide a été proposée, l’architecte de solution peut encourager la création d’une preuve de concept ou d’autres tests pour valider la solution proposée.

Essentiellement, le rôle d’un architecte de solution est de parler constamment aux personnes impliquées dans le projet pour s’assurer que la vision du projet est réalisée. Les architectes de solution qui ne réussissent pas se cachent de l’équipe et passent leur temps à mettre à jour leurs conceptions d’architecture plutôt que de collaborer avec l’équipe et de l’aider à trouver des solutions.

L’unité suivante décrit les techniques qu’un architecte de solution peut utiliser sur un projet.