Réponse.

Dans les projets d'intégration, l'analyste d'affaires doit devenir le lien entre les parties prenantes techniques et non techniques. La principale tâche est d'assurer la compréhension mutuelle des parties, afin que les exigences, les risques et les contraintes soient compris par tous les participants, et que la documentation contienne les détails nécessaires à l'intégration.

Caractéristiques clés :

• Facilitation des réunions : l'analyste structure les processus de communication, aide les participants à converser dans un langage compréhensible pour chacun, explique les détails techniques aux acteurs du métier et transpose les enjeux métiers pour les développeurs.

• Documentation des exigences d'interface : il est important non seulement de décrire les exigences, mais aussi de clarifier les accords sur les formats de données, les canaux de transmission, le traitement des erreurs et la gestion des versions des intégrations.

• Alignement des objectifs et des contraintes du projet : l'analyste identifie les risques cachés, aide à convenir à l'avance des critères de succès et des points de contrôle.

Questions pièges.

Peut-on déléguer complètement à des spécialistes techniques la rédaction des API ?

Non. L'analyste doit s'assurer que les exigences métier sont correctement reflétées dans la documentation de l'interface et que les scénarios réels du métier sont pris en charge par la solution technique.

Est-il suffisant d'approuver uniquement les formats des données entrantes/sortantes ?

Non. Il est crucial de préciser les règles métier, le traitement des situations exceptionnelles (par exemple, que faire si l'intégration n'est pas disponible), les restrictions d'accessibilité, les droits d'accès.

La participation de l'analyste d'affaires est-elle obligatoire lors de la discussion des solutions architecturales ?

Oui, même s'il ne prend pas de décision technique, l'analyste doit s'assurer que les aspects et contraintes métier sont pris en compte dans la conception de l'architecture.

Erreurs typiques et anti-patterns

• L'analyste d'affaires ne participe pas aux réunions techniques, ce qui entraîne une désynchronisation des exigences et des solutions mises en œuvre.
• La traduction "un-à-un" de la documentation du métier vers la technique : le contexte, la spécificité de l'intégration et les scénarios importants de traitement des erreurs sont perdus.

Exemple de la vie

Cas négatif : Lors de l'intégration d'un CRM et d'un service externe, l'analyste ne participait pas à la préparation des spécifications techniques. Avantages : l'équipe technique a développé l'API plus rapidement. Inconvénients : l'intégration ne soutenait pas les règles métier nécessaires, entraînant des pertes de données.

Cas positif : Dans un projet similaire, l'analyste a participé à toutes les étapes de discussion, impliquant l'équipe métier et technique. Avantages : l'intégration a couvert tous les scénarios réels, les tests ont été couronnés de succès. Inconvénients : la phase de clarification des exigences a pris plus de temps.