Les données d’un design

Lorsque l’on doit dessiner une architecture ou refaire un design pour un client, il y’a certaines données dont on a absolument besoin. Voici leur descriptions et des exemples pour bien comprendre.

Étendue du projet:
Il est primordial de connaitre l’étendue du projet pour en comprendre les limites, pour éliminer tout dépassement indu.
Le scoping fait partie de ces discussions prioritaires et pas tojours très jojo à avoir avec le client. D’un coté, il veut que l’on fasse tout mais de l’autre il doit être conscient des limites temporelleset/ou financières dans lesquelles il s’embarque.
Il est ainsi important de bien faire comprendre quelles sont les étapes et procéssus qui seront touchés et surtout lesquels ne le seront pas.
Buts:
Les buts sont des objectifs techniques ou d’affaires qui permettent d’évaluer la solution de A à Z.
Ces buts doivent être spécifiques, mesurables et réalisables.
Ex: ëtre a jour vs les manufacturiers, réduire de 50% les couts
Besoins:
Les besoins sont des demandes d’affaires ou techniques qui doivent absolument être comblés pour qualifier le projet de réussite.
Ce sont des impondérables souvent demandés par les décideurs et ils constituent habituellement des challenges techniques qui ont une influence sur tout le projet.

Ex: compatible PCI, séparation physique des environnements
Suppositions:
Traduit de l’anglais « assumptions », les suppositions sont des affirmations par le clients qu’on doit prendre comme des réalités. Il est impossible de tout valider dans les prérequis d’un projet et certains points relevent explicitement des affirmations du client.
Un projet qui contient beaucoup de suppositions est souvent un projet qui apportera son lot de maux de tête dans le futur. Il est important de tout contre-valider.

Ex: Le réseau est assez rapide pour supporter telle charge. Les serveurs que l’on possède déja vont faire l’affaire au site de DR. La haute direction va accepter telle ou telle chose.
Contraintes:
Les contraintes sont les points qui limitent l’architecte dans ses choix. Ce sont des règles, des processus, des points techniques.
On peut les voir comme des embuches dans notre chemin avec lesquels on doit travailler.

Ex: Un seul vendeur possible, doit être compatible avec Cisco, le budget ne doit pas dépasser x$.
Risques:
Les risques sont des problèmes potentiels qui peuvent survenir. Un bon architecte saura les prévoir et trouver des manières de les contourner ou de les éviter entierement.
Il y’a des risques dans tout. Essayons d’en minimiser les conséquences.

Ex: Redondance pour avoir le 99.9% d’uptime, lenteur d’approvisionnement du matériel par le fournisseur.
Comme on a pu voir, toutes les étapes sont cruciales et un bon architecte documentera toutes ses décisions et pourra les défendre, que ca soit pour des questions de budget ou des raisons techniques.