La MOA pragmatique du SI (Business Analysis, Analyse d'Entreprise, Maitrise d'Ouvrage)

Aller au contenu | Aller au menu | Aller à la recherche

Tag - Praxeme

Fil des billets - Fil des commentaires

dimanche, juin 6 2010

La MOA doit-elle donner son sens ?

Par Olivier Durand le dimanche, juin 6 2010, 23:30 - Spécifier

Mais de quoi parle-t-on ? Définir correctement les termes utilisés dès le début du projet est très important. Cela permet d'éviter les incompréhensions et les ambiguïtés. Voici quelques conseils.

Créer un Glossaire dans votre Wiki

Utiliser un Wiki est idéal pour construire un glossaire. En effet un glossaire doit vivre, tout le monde doit pouvoir y accéder et surtout, tout le monde doit y contribuer. Il doit s'agir d'un tableau simple dans lequel on peut rechercher facilement.

Terme en françaisDéfinitionÉquivalent en anglais
Terme en français (mot ou expression)La définition doit être la plus précise possible. il peut y avoir plusieurs définitions en fonction du contexte.Équivalent en anglais

Hiérarchisez votre glossaire

Il faut créer une hiérarchie pour ce glossaire :

  • Glossaire d'entreprise
  • Glossaire de domaine
  • Glossaire de projet
Un terme peut se retrouver dans chacun des niveaux, en effet, un même terme peut avoir une définition différente d'une entreprise à une autre mais aussi d'un service à un autre ou d'un projet à un autre.

Pensez aux équivalents dans les autres langues utilisées

Si votre projet utilise le français et l'anglais par exemple, pensez à indiquer les équivalents en anglais au terme français. Pour cela, ne comptez pas sur les outils automatiques de traduction. il faut se référer à des dictionnaires métiers. J'utilise par exemple les sites suivants pour trouver des correspondances entre des termes anglais ou français :

Citez vos références

Il n'y a pas de honte à utiliser des références externes, mais pensez à les citer. Et pensez surtout à utiliser plusieurs sources de qualité en plus de vos propres connaissances. Par exemple voici un excellent glossaire des termes utilisés dans la gestion de projet. Vous pouvez l'utiliser comme référence, mais également vous inspirez de sa structure "comparative" :

Ensuite il faut vous construire vos propres références en essayant d'avoir un regard critique sur chacune d'entre elles. Par exemple, pour le monde de la finance, on peut utiliser des glossaires de site dédiés à la finance, de sociétés d'investissement ou même directement des sites des bourses :

Oui, la MOA doit donner du sens aux termes utilisés dans son projet. Certaines méthodologies inclues la sémantique dans leur approche comme par exemple Praxeme. Mais avant d'en arriver aux modèles UML, quelques descriptions textuelles sont déjà un très bon premier rempart face aux risques d'incompréhension ou d'ambiguïté. Car entre le langage propre à chaque entreprise, les niveaux variés en langues étrangères et les niveaux variés de compréhension du fonctionnel, il y a énormément de difficultés à affronter pour parler le même langage.

jeudi, mars 11 2010

La MOA doit elle comprendre SOA ?

Par Olivier Durand le jeudi, mars 11 2010, 20:38 - Etudier

L'architecture orientée services (SOA en anglais) est un ensemble de concepts aujourd'hui matures. Cette démarche est souvent poussée par les acteurs "techniques" du SI. Pourtant un des points clés de la mise en œuvre devrait être selon moi à la main de la MOA : la décomposition en services.

Les services définis doivent être réutilisables, c'est tout l'intérêt de l'architecture SOA. Mais ce ne sont pas de simples composants réutilisables. Un service doit être autonome, remplir une fonction dans sa globalité et être utilisable (ou mieux, utilisé) par plusieurs consommateurs. Différents niveaux de service peuvent être définis : données (services "simples" permettant par exemple de récupérer des clients, d'en créer, d'en rechercher...), métiers (un service complexe qui remplira des fonctions métiers comme calculer le chiffre d'affaire par comptes clients), applicatifs (par exemple un service qui permettra notamment de récupérer tous les chiffres d'affaires agrégés par comptes clients qu'un collaborateur gère afin de l'afficher dans la CRM). On parle de service composite lorsqu'il utilise plusieurs autres services de niveaux inférieurs.

Certaines méthodologies combinent une approche SOA & MDA, par exemple Praxeme. Dans ce cas la définition et la découverte des services va se faire par des itérations de modélisation. Que ce soit dans l'aspect sémantique, pragmatique ou logique, la MOA a un très grand rôle à jouer.

Pour le métier la SOA peut n'être qu'une tactique permettant d'atteindre un objectif d'agilité dans les processus métiers. La mise en place du BPM sera un objectif atteignable et intéressant uniquement si les services sont réutilisables d'un point de vue métier. Et pour cela la MOA a une forte valeur ajoutée afin de déterminer les frontières des différents services et pour anticiper sur les réutilisations métiers possibles.

En tant que MOA nous avons souvent tendance à penser directement à la solution. Il est vrai qu'il est plus naturel de parler des écrans d'une application, d'un batch qui va effectuer des traitements car on se raccroche alors à du concret, de l'existant. Mais c'est aussi rester un peu terre-à-terre. Quitte à prendre de la hauteur, autant essayer de penser services. Par exemple si vous être déjà habitués à travailler sur des exigences et des cas d'utilisation, vous pouvez très bien proposer dans une spécification détaillée un découpage du système en services métiers. Et dans un projet qui porte sur un processus métier, il est encore plus naturel d'identifier les services métiers qui correspondent souvent à une activité de ce processus (en tout cas dans une vision purement métier). Connaître ces services permet à la MOA de dynamiser la réutilisation au sein du SI et de comprendre les problématiques engendrées par la maintenance d'un service qui est utilisé par plusieurs consommateurs et donc de faire les bons choix dans l'utilisation des budgets.