Préparer l’atelier Examen du blueprint de la solution
En général, l’atelier Examen du blueprint de la solution prend environ deux à huit heures. La durée peut varier en fonction du niveau de détail disponible pour examen et de l’étendue de la solution globale. L’architecte de solution travaillera avec la direction de l’équipe d’implémentation pour planifier l’atelier en fonction des spécificités de la solution examinée.
Avant l’atelier Examen du blueprint de la solution, les participants doivent veiller à connaître autant que possible sa structure, les conditions préalables et les types de sujets qui seront abordés. L’architecte de solution fournira un ordre du jour avec des sujets et des conditions préalables avant l’atelier.
Remarque
L’atelier Examen du blueprint de la solution est essentiellement une discussion ; il ne s’agit pas d’un questionnaire pouvant être rempli et examiné en mode hors connexion. Bien que les conditions préalables soient définies et fournies à l’avance, il n’est pas possible de résumer l’étendue des directions dans lesquelles la conversation peut mener.
L’architecte de solution préparera à l’avance l’atelier en examinant les artefacts de projet existants. Voici des artefacts de projet utiles :
- Catalogues de processus : listes ou hiérarchies de processus, sous-processus et récits utilisateur dans l’étendue de l’implémentation.
- Schémas de flux de processus : schémas pouvant ajouter du contexte au catalogue de processus et décrire le fonctionnement de l’entreprise. Lors de la phase d’examen du blueprint de la solution, les processus généraux de bout en bout sont les plus utiles.
- Schémas d’application : schémas fonctionnels illustrant les différents composants de la solution. Ces schémas peuvent également fournir un contexte lié au mappage des fonctionnalités aux composants d’application ou à la manière dont les composants d’application s’interfacent.
- Besoins relatifs aux écarts : domaines de fonctionnalité connus non considérés comme pris en charge par le système standard.
- Schémas de dataflow : dans une solution comprenant plusieurs applications Dynamics 365, et des services et composants hérités ou externes, il est utile de pouvoir identifier d’où proviennent les données et comment elles se déplacent et sont consommées dans la solution.
- Stratégie de migration de données : documents ou registres présentant les entités à migrer, les sources dont elles proviendront, les volumes, le calendrier et les méthodes de migration. Lors de la phase d’examen du blueprint de la solution, vous devez veiller à disposer d’une étendue (tables et sources).
- Registre d’interfaces : listes d’interfaces avec des besoins non fonctionnels et des modèles de conception documentant l’étendue et l’approche de l’implémentation de ces interfaces.
- Conception d’agrégation de données analytiques : schémas ou registres de sources de données qui seront migrées à des fins d’analyse agrégée.
- Stratégie environnementale : schémas fonctionnels ou de flux décrivant les types d’environnements qui seront approvisionnés et comment et quand ils seront utilisés et comment le code et la configuration y circuleront.
- Profils d’utilisation du système : calendriers des processus opérationnels et pics de volumes transactionnels par type de charge de travail.
- Structure d’entité juridique : schémas ou registres présentant les entités juridiques qui seront modélisées dans la solution et leurs relations les unes avec les autres.
- Emplacements de déploiement : schémas ou registres présentant les emplacements physiques où la solution sera déployée ainsi que les besoins linguistiques et de localisation.
- Charte du projet : document fournissant le contexte du projet, les objectifs et les résultats clés attendus, les parties prenantes, les budgets, les délais et les jalons.
- Plan/calendrier du projet : document ou diagrammes de Gantt décrivant le calendrier global et la dépendance des phases clés du projet et les activités associées.
- Matrice d’affectation des responsabilités : tableau des tâches et des relations des rôles du projet avec ces tâches. Ces relations sont généralement affectées au moyen d’une classification RACI (Réalisateur, Approbateur, Consulté, Informé).
- Plan/stratégie de test : document décrivant les types de tests qui seront effectués tout au long de l’implémentation et comment les tests seront définis, implémentés et mesurés.
Il ne s’agit pas d’une liste exhaustive des livrables du projet, mais c’est un bon point de départ pour l’examen du blueprint de la solution. Le format, la composition et le nom de chaque livrable peuvent varier d’un projet à l’autre. Le format n’est pas le composant crucial : les informations accessibles et acceptées par l’ensemble de l’équipe sont essentielles.
Lorsque vous effectuez un examen du blueprint de la solution au début du projet, nombre de ces documents ne seront pas entièrement formés, ce qui est acceptable dans la plupart des cas. Il est plus important que l’étendue ait été déterminée et qu’un plan conceptuel soit en place pour déterminer comment la solution prendra en charge cette étendue. Si le plan échoue, ces éléments doivent être représentés à un certain niveau dans le cahier des charges fourni par le partenaire consultant contribuant à l’implémentation. Si l’étendue et l’approche de la solution conceptuelle sont en place, l’examen du blueprint de la solution peut se concentrer sur l’approche conceptuelle, et les ateliers approfondis de suivi peuvent se concentrer sur les détails au moment où ils sont disponibles.
Il est acceptable que votre projet utilise différents moyens de gérer ou suivre les informations du projet autres que ceux répertoriés précédemment. En général, le format n’est pas critique si les informations sont facilement accessibles par les membres du projet. Si les informations répertoriées précédemment ne sont pas documentées sur votre projet ou si elles sont documentées de sorte qu’elles ne sont pas facilement accessibles, vous devez privilégier la production des artefacts pertinents.
Nous vous recommandons d’utiliser des schémas et des représentations visuelles pour fournir des résumés généraux, dans la mesure du possible, dans le cadre de l’implémentation. Ces schémas, tableaux et graphiques constituent un moyen de communication facile sur l’ensemble de l’équipe et avec les dirigeants au sujet des plans et des conceptions.
Remarque
L’examen du blueprint de la solution n’est pas destiné à être un examen exhaustif des besoins détaillés ou des documents de conception. L’équipe d’implémentation utilisera des niveaux de détail inférieurs pour façonner et présenter l’architecture globale. Nous partons du principe que l’équipe d’implémentation présentera les principales préoccupations et que les architectes étudieront les sujets problématiques potentiels. L’architecte de solution proposera des ateliers approfondis pour étudier les domaines nécessitant une évaluation supplémentaire.