F5 202 : conduire une découverte et relier besoins et solutions

Une découverte doit expliquer quelle activité dépend de l’application, qui l’utilise et ce qui se passe lorsqu’elle ne fonctionne pas. Une demande de load balancer peut cacher un besoin de disponibilité, de visibilité ou de contrôle d’accès. Le produit demandé n’est pas encore la description du problème.

La méthode proposée ici traduit les objectifs du 202 en questions de travail. Distinguez faits fournis par le client, observations et hypothèses à confirmer. Une information publique sur une organisation peut orienter une question ; elle ne prouve pas son architecture interne.

Relevez client, résolution DNS, accès réseau, terminaison TLS, serveurs et dépendances d’identité ou de données. Ajoutez les responsables et les contraintes de changement. Un schéma de la seule façade ne permet pas d’expliquer un parcours utilisateur ni de prévoir sa reprise.

Associez ensuite chaque exigence à une capacité et à une preuve. Une exigence de répartition appelle l’étude des pools et moniteurs ; une exigence d’autorisation appelle l’étude des identités et politiques. Les guides LTM, DNS, ASM et APM décrivent des mécanismes distincts, pas une liste interchangeable de solutions.

Séparez exigences obligatoires, préférences et inconnues. Pour chaque inconnue, définissez un propriétaire et une collecte. Une solution peut répondre techniquement au besoin tout en demandant une compétence ou une fenêtre de maintenance indisponible ; ces contraintes font partie de l’architecture.

Vérifiez les capacités dans les versions et plateformes envisagées. La correspondance besoin-produit n’établit ni licence ni compatibilité. Le dimensionnement et la nomenclature viennent après ce cadrage, avec leurs propres références.

Construisez une fiche de découverte pour une application décrite comme lente et parfois indisponible. Définissez deux parcours utilisateurs, leurs dépendances et trois informations manquantes. Ne proposez pas une migration avant d’avoir établi où apparaissent les délais et les erreurs.

Le livrable attendu contient une carte de flux, des exigences testables et les prochaines observations à collecter. Continuez avec la démonstration et la recette pour transformer ces exigences en scénarios comparables.