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

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

jeudi, mars 11 2010

La MOA doit elle comprendre SOA ?

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.

mardi, mars 2 2010

La MOA est-elle une hôtesse de l'air ?

Le support applicatif métier est difficilement externalisable, contrairement au support sur les applications dites "bureautiques" (gestion des courriers électroniques, traitement de texte...). Plus les applications métiers sont critiques pour l'entreprise, plus l'équipe support applicative doit avoir des profils de haut niveau et des compétences pointues. Ce sont parfois directement les maîtrises d'ouvrage qui exercent le rôle de support applicatif ou support fonctionnel, alors que d'autres organisations mettent en place des équipes dédiées à ce support très proche du métier (équipes que l'on peut considérer alors comme assistance à MOA). La MOA doit donc avoir le sens du service ?

Dans l'article Le « sens du service », une question d'organisation sur scienceshumaines.com l'auteur évoque les travaux d'Arlie Russel Hochschild qui dès 1983, dans The Managed Heart, définit le concept de travail émotionnel pour les hôtesse de l'air consistant à réélaborer leur ressenti et à influer sur celui des passagers, notamment en diffusant un sentiment de sécurité. La maîtrise d'ouvrage serait en fait un steward ou une hôtesse de l'air ? Il est vrai que face à un problème de production important ou face à une forte réticence au changement, la MOA peut avoir ce rôle de travail émotionnel : calmer l'utilisateur si ses craintes ne sont pas fondées, communiquer les informations nécessaires sans créer de panique, et éventuellement expliquer comme accéder aux toboggans de secours si le crash est inévitable !

Ensuite l'auteur de cet article parle des travaux du sociologue américain Ervin Goffman (Asile, 1968) pour définir la compétence de service : la capacité de prendre une décision non prévue par une procédure impérative et de la présenter comme professionnellement justifiée. Une telle décision n'est jamais facile à prendre car elle se prend toujours dans un contexte délicat. Donc plus qu'un sens du service commun une MOA doit avoir cette "compétence de service" afin d'être capable de réagir à des problèmes variés qui attendent des solutions spécifiques.

La notion de support informatique est souvent mal perçue car caricaturée en un centre de service outsourcé en Inde, en Afrique du Nord ou en Irlande, où les opérateurs de ces helpdesks sont notoirement incapables de résoudre un problème, ni même souvent de le comprendre. La faute sûrement aux grands opérateurs télécoms qui ont souvent eu des démarches assez radicales en terme d'outsourcing de ces services. Pourtant faire du support applicatif ou fonctionnel sur des applications très critiques demande des compétences pointues sur le domaine géré et également une grande compétence de service. Il me semble également qu'il est toujours bon pour une MOA même si elle est orientée projet d'être au contact de la production et de ses réalités de terrain, cela permettant de concevoir des solutions fonctionnellement adaptées à la réalité.