Urbanisation des Systèmes d'Information

A votre service !

On dit souvent que lors de la mise en place de la SOA, la difficulté consiste en la détermination des Services Métier,

• de leur niveau granularité (trop gros, ils sont trop compliqués, trop petits, ils sont trop nombreux, etc.)
• si on les fait déterminer par la MOA, par la MOE.

Et récemment, lors d’une mission, il m’a été demandé de fournir une définition et des exemples de services métier afin de permettre à chacun de se faire son idée sur la question.

Je commence par expliquer que les Services Métier sont des sortes de « capsules » qu’un système informatique expose à ses systèmes voisins. Ceux-ci peuvent les invoquer, c'est-à-dire poser une question, puis obtenir une réponse, un peu comme sur un distributeur de billet.

C’est alors qu’une personne dans l’assistance explique que cet exposé est destiné à être présenté aux clients finaux du SI et que, si on commence à leur présenter ces concepts, ça ne leur parlera pas et « ce qu’ils attendent ce sont … les Services Métier » (Sic !)
Bon, on creuse pour savoir ce qu’elle entend vraiment par « Service Métier ».

En fait, derrière le mot « service métier » chacun a compris un peu ce qu’il voulait

• l’architecte SOA comprend ce qui est expliqué ci-dessus ;
• le client final comprend « les services (i.e. Fonctionnalités) que va m’apporter le SI pour me permettre d’exercer mon métier ».

L’ambiguïté du mot « service » est très grande.

Ce peut être

• Le résultat fourni par l’entreprise à ses clients, comme une société de services, qui produit des … services ;
• Le résultat fourni par le Système d’Information à ses clients internes, quand on parle par exemple du niveau de service atteint par une application vis-à-vis de ses utilisateurs ;
• Le moyen de partage des informations entre les systèmes du SI préconisé par l’Architecture Orientée Service ;
• Le mot utilisé en Suisse quand on vous rend la monnaie :-))

Pour s’en sortir on doit en permanence rappeler le contexte d’utilisation.

Il est très facile de jouer de l’ambiguïté et du glissement sémantique « Orienté Service = meilleur services pour ses utilisateurs = meilleur services pour ses clients »

Les gens qui font de la SOA ne nous on pas beaucoup aidé en baptisant « service métier » la petite capsule d’invocation … Il faut bien avoir conscience que ce « service métier » est avant tout un service … technique, c'est-à-dire qu’il réalise techniquement un service que le SI s’offre à lui-même, ce service étant à forte valeur ajoutée métier (on l’espère en tout cas) Ce serait déjà mieux si on l’appelais « service applicatif ».

Nous autres, consultants, qui passons notre temps à recommander à nos clients d’ « administrer les données » c’est à dire de créer des dictionnaires de concepts métier partagés, d’enlever les ambiguïtés sémantiques génératrices de non qualité des données, (d’ailleurs, pour être exact, on devrait dire « administrer les informations »), nous pourrions appliquer ce conseil à nous même en l’appliquant au mot « service ».

Ceci étant dit, reprenons la question « faut-il faire déterminer les services métier par la MOA ? ». Cette question est particulièrement ambiguë.

Voilà ma réponse

• la MOA ne détermine pas de « service métier » au sens SOA (elles se fichent royalement de l’intérieur du SI) mais les fonctionnalités qu’elle souhaite sur le SI pour apporter à ses utilisateurs l’automatisation des tâches métier ;
• l’urbaniste / l’architecte fonctionnel détermine : les fonctions du SI, les services métier (au sens SOA) sur lesquels ces fonctions s’appuient, leur localisation sur le SI
• la MOE conçoit chaque système en respectant les éléments précédents

En fait, ce n’est pas étonnant si la SOA est assez peu adoptée : je me mets à la place de dirigeants qui regarde globalement, vue de loin il faut bien l’admettre « ce n’est pas clair » DONC « ça sens l’entourloupe »

Et pourtant je vous assure que, vu de près, ces techniques d’organisation du SI sont redoutablement efficaces.

Christophe Thiry

PS : Ce blog s'efforce de rester dans la limite des choses que l'on peut dire publiquement sans révéler de "secrets de fabrication" : expliquer les concepts, les démarches, leur utilité ... et n'a pas pour but de porter préjudice à la profession.

posted by Christophe Thiry @ 5/31/2006