Ce blog est la deuxième partie d’une réflexion sur les raisons d’être du business analyst, et sur  la distinction à opérer entre les rôles de business analyst et de functional analyst. La première partie se concentrait sur le business analyst. La présente se concentre sur le functional analyst.

Nous avons insister sur le fait que ces deux fonctions doivent être vues comme étant des rôles, une même personne pouvant, selon la phase du ou des projets en cours, occuper tantôt un de ces deux rôles et tantôt l’autre. La taille de l’organisation est le déteminant principal quant à la distribution ou non de ces deux fonctions sur des personnes distinctes .

Par rapport au processus RUP, nous avons situé les interventions du business analyst dans les phases d’inception et d’elaboration.

Une fois arrivé le temps de la construction phase, il est temps de changer de casquette (ou de faire intervenir les functional analysts, qui agissent alors dans la continuité des business analysts): place à l’analyse fonctionnelle, dont le but est d’entrer dans le détail de ce qui a été fait dans les phases précédentes. Vous l’aurez compris, la phase précédente correspond à une préoccupation de cadrage / définition soignée du projet pour garantir l’alignement business case / projet, au juste niveau de détail.

On entre ici, et selon moi seulement ici, dans le vrai pré carré de l’approche agile, avec la souplesse et la réactivité aux adaptations sur les requirements qui la caractérise.

Il s’agit maintenant de détailler les use cases, de définir les layouts et contenus d’écrans, les règles métiers relatives aux calculs (via langage naturel ou tables de décision), les modèles de données logiques, d’établir les scénarios de test détaillés. Le détail des use cases pourra être élaboré en s’appuyant sur la notion de user stories (voir Visual Paradigm par exemple), concept propre aux méthodes agile, et qui serviront à alimenter le product backlog selon la méthode Scrum.

C’est aussi maintenant que sont spécifiés dans le détail tous les éléments réutilisables (services [called] et librairies [embedded]).

A ce stade la collaboration entre le business analyst et l’enterprise architect est maximale : il s’agit pour ces deux rôles de définir précisément l’architecture SOA à mettre en place , en faisant intervenir les notions de taxonomie et de typologie de services (nous n’entrerons pas dans l’explication de ces notions ici – un autre blog peut-être). J’insiste sur ce point : la réussite de la mise en oeuvre d’une architecture orientée service est d’abord le résultat d’une collaboration réussie entre business analyst(s) et enterprise architect(s).

Au delà de l’architecture de services, business analyst(s) et entreprise architect(s) doivent aussi veiller à établir et à maintenir la cartographie applicative et des données (relevé des applications et des services, alimentation du data dictionnary, …).

Point d’attention : des découvertes effectuées pendant la construction phase peuvent devoir être remontées au niveau des documents produits par la business analysis.

Je voudrais aussi insister dans ce blog sur le parallèle suivant : de la même manière que l’on attribue aujourd’hui, de plus en plus, toute l’importance qu’elle mérite à la gestion du code (naming and coding conventions, structuration des projets, gestion de version, visualisation des différences entre versions, quality metrics, peer review, …) il convient d’en faire autant avec les délivrables de l’analyse (la recommandation n ‘est pas nouvelle !). De ce point de vue, je suis amené à constater que les approches agile tentent à un certain laxisme, pour ne pas dire plus, sur la gestion de la qualité de la documentation.

Les mêmes concepts doivent être d’application pour l’analyse : la documentation doit être standardisée, maintenable, pérenne, comprise par ses destinataires, aujourd’hui et demain aussi. La documentation du niveau business en particulier est LE pilier du transfert et donc du maintien de la connaissance métier dans l’organisation. Le passage de témoin entre les générations de collaborateurs l’exige.

Ceci est d’autant plus important lors de la présence d’intervenants extérieurs : trop nombreux sont ceux qui pratiquent le “freestyle” (à chacun sa(ses) manière(s) de faire), attitude entretenue par la mode agile, quand cela ne correspond pas à un objectif caché de verrouillage sur les connaissances nécessaires pour être à même de piloter les développements IT et se rendre indispensables sur le long terme dans l’organisation.

Au sujet du repository pour les documents d’analyse, les offres cloud permettent de ne pas s’encombrer avec la gestion technique de ceux-ci. Mais il convient alors de prendre les précautions nécessaires en matière de sécurité des données, tous aspects confondus. Et sans oublier que placer dans le cloud des savoir-faire métiers qui offrent des avantages concurrentiels n’est jamais une bonne idée.

Une comparaison pour aider à la compréhension sur la distinction entre les deux rôles de business analyst et de functional analyst : le binôme business analyst / functional analyst est comparable au binôme enterprise architect / application architect. La différence entre ces deux niveaux de fonction relève de l’importance du scope à balayer et consécutivement du niveau de détail moins élevé attendu des deux premières. Business analyst et enterprise architect sont les garants de la prise en compte globale et donc, par extension, de l’optimisation globale et de la réutilisation, sur les données et sur le code.

En conclusion : la prise en considération des distinctions entre ces deux rôles de business analyst et functional analyst est une assurance pour un équilibre judicieux entre l’approche plutôt Waterfall (cadrage et préparation) et l’approche résolument  Agile (réactivité aux changements en cours de développement).

Et dernière réflexion : lors de l’élaboration d’un plan directeur informatique, qui se doit d’avoir pour tout premier objectif l’alignement de l’IT sur le business, les business analysts sont à l’évidence des fournisseurs d’information de tout premier plan. Au même titre que les enterprise architects.