Business / IT : la communication

1 Comment

Depuis son origine, la communauté informatique est confrontée à la question : comment communiquer avec les acteurs de l’entreprise, les « métiers » ? C’est-à-dire :

  • d’une part, comment comprendre leur problématique et leurs besoins,
  • d’autre part, comment leur faire comprendre la réalité du système informatique.

Ce deuxième terme importe pour autant que les acteurs de l’entreprise ont besoin d’une compréhension minimale du système et de ses contraintes, afin de participer aux décisions d’investissement.

Il ne semble pas que cette question ait beaucoup progressé dans les dernières décennies et ce ne sont pas les déclarations d’intention et les formules incantatoires sur l’alignement qui amélioreront la situation.

La méthodologie Praxeme répond à ce besoin de communication d’abord en identifiant trois aspects propres au métier : sémantique, pragmatique, géographique – ces aspects donnant lieu à des approches de modélisation. La méthodologie d’entreprise ajoute un espace de « cadrage » (scoping) qui permet de conserver les expressions non formelles venant de l’entreprise ou de son environnement (réglementations, objectifs, exigences, vocabulaires).

Nous ne détaillerons pas ce point ici et nous nous concentrerons sur la question : comment faire comprendre la structure du système informatique ?

Un premier élément de réponse réside dans l’aspect logique, que Praxeme reprend de la tradition méthodologique. Cet aspect se définit comme intermédiaire entre la « vue métier » et la « vue informatique ». C’est donc le lieu de l’échange et de la négociation. Les termes de l’aspect logique se veulent indépendants de la technique, première condition pour communiquer avec les acteurs non informaticiens.

Caractéristiques minimales de l’outil de communication

Avant d’aller plus loin en proposant une représentation qui pourra servir d’outil de communication, résumons les messages que nous devons passer :

1. Cette représentation doit évoquer la structure réelle ou cible du système informatique, faute de quoi l’échange entre « business » et « IT » sera d’emblée faussé.

2. Elle doit permettre à toutes les parties prenantes de discuter des investissements, d’arbitrer sur les priorités, en toute connaissance de cause.

3. Un message central, pour autant que l’on soit prêt à adopter l’approche nouvelle des SI, est l’abandon des « domaines fonctionnels » comme unique critère de décomposition des systèmes d’information. Sans cette décision, la dénonciation des silos restera pure rhétorique.

4. Entre autres principes, la nouvelle architecture met en œuvre l’encapsulation, c’est-à-dire qu’elle cache les détails de réalisation, les ressources (par exemple, les supports de données, les solutions techniques…).

Situation de l’outil de communication

Il s’agit bien de parler du système informatique, non du métier, et d’en parler à des non informaticiens. La représentation se situe, sans conteste, dans l’aspect logique (pour une définition détaillée, voir, par exemple, le Guide général de la méthodologie Praxeme, référence PxM-02).

Ainsi, la représentation – même très simplifiée – sera toujours en conformité avec l’architecture logique. Celle-ci décrit la réalité du système informatique, indépendamment des choix techniques. Cette représentation est essentiellement une vue synoptique du système, éventuellement orientée selon le point de vue ou les préoccupations des parties prenantes (un métier, une fonction, un grand chantier…). En aucun cas, l’outil de communication ne saurait être déconnecté de la réalité sous-jacente. Une représentation outrageusement simplifiée ou infidèle permettrait peut-être de communiquer, mais juste comme un mensonge est un acte de communication.

Premier niveau de structuration

Le premier principe que pose l’architecte logique est le principe de stratification (cf. Guide de l’aspect logique, réf. PxM-40 ou l’article « Quatre idées fortes sur SOA », réf. SLB-15). Dans son aspect logique, le système comporte :

1. un noyau – la strate « Business core » ou « Métier » – qui isole les éléments exprimant les fondamentaux du métier ;

2. une strate qui prend en charge l’organisation, les processus, les contextes de travail, bref, tout ce qui est lié à l’activité ;

3. une périphérie par laquelle le système interagit avec son environnement, à travers tous les canaux imaginables.

Cette structure est très simple. On se tromperait si on voulait la compliquer en y introduisant des considérations techniques. Ces strates logiques ne doivent pas être confondues avec les couches de l’architecture technique. La trame de base pour notre outil de représentation ressemblerait donc à la figure ci-dessous.

Représentation simplifiée des strates de l'architecture logique
Représentation simplifiée des strates

Elle ne devrait pas poser de difficulté de compréhension et permet de faire passer un message considérable pour l’avenir de nos systèmes : les trois strates renvoient à des préoccupations différentes et obéissent à des règles de structuration propres. Notamment, si le domaine fonctionnel reste une unité valide pour la strate « Activité », la strate « Métier » sera décomposée en domaines d’objets. Ce message doit être passé aux parties prenantes car il conditionne toute la démarche de restructuration des SI. Les acteurs de l’entreprise sont à même de comprendre les limites de la décomposition fonctionnelle ; ils dénoncent eux-mêmes les silos fonctionnels ; ils admettront parfaitement la nécessité d’isoler la connaissance fondamentale dans un noyau applicatif stable.

Renoncer à faire passer ce message condamne soit à déresponsabiliser les parties prenantes en biaisant la communication, soit à persévérer dans nos erreurs passées en prolongeant l’approche fonctionnaliste.

Deuxième niveau de structuration

Un graphe d’architecture logique montrerait, dans les strates, des constituants logiques sur plusieurs niveaux d’agrégation, dans les termes du procédé SOA de Praxeme : fabrique, atelier, machine et service. Ici, notre outil de représentation peut se séparer des techniques de modélisation utilisées par les architectes logiques et les concepteurs logiques. C’est une question de contexte. Dans certains cas, les acteurs de l’entreprise auront été sensibilisés à la nécessité d’organiser les services « cœur de métier » en domaines d’objets ; on pourra alors les indiquer.

Une autre façon de faire est de représenter :

  • sur la strate « Métier », les objets « métier » au centre du débat (par exemple, Personne, Contrat, Produit…), éventuellement assortis des services majeurs dans la perspective de l’investissement ;
  • sur la strate « Activité », les cas d’utilisation pour montrer les situations de travail concernées ;
  • sur la strate « Interaction », les types d’interface, les canaux de communication par lesquels les acteurs accèdent au cas d’utilisation (ordinateur, Internet, messagerie, mobile, courrier…).
Illustration de l’outil de communication

Cette représentation est moins « pure » que le graphe d’architecture, mais reste compatible puisque les constituants logiques dérivent des éléments que nous venons de nommer.

Elle permet de montrer comment le service rendu par le système, à sa périphérie, s’obtient par des constituants de différentes natures. Ces constituants reprennent les cas d’utilisation connus des « utilisateurs », mais aussi les objets métier, dans le noyau du système.

NB : Les couleurs reprennent celles de la « Topologie du Système Entreprise » (voir messages antérieurs sur ce blog).

L’interopérabilité

Cette représentation permet aussi de discuter de la connexion entre plusieurs systèmes, comme le montre la figure ci-dessous.

Connecter des systèmes
Connecter des systèmes

This entry is filed under méthodologie. And tagged with , , , , , . You can follow any responses to this entry through RSS 2.0. Responses are currently closed, but you can trackback from your own site.

1 Response to “Business / IT : la communication”


  1. acla

    Outre l’outil méthodo, indispensable, il faut également donner des structures permettant au métier d’exercer son pouvoir de décideur.
    La question majeure est : la MOA fait-elle partie de la DSI, ou est-ce une structure responsable rapportant à la DG via un Comité de Pilotage / Comité de Direction ?
    Dans le premier cas de figure, elle va se comporter comme une réunion de key users, experts de leur métier mais sans la hauteur de vue nécessaire à une véritable prise de responsabilité. Le projet reste alors sous la responsabilité entière des IT. Avec tous les inconvénients sur la communication IT – métiers.
    Risques : irresponsabilité, métiers indifférents au devenir du projet (absente des réunions), méthodo mal perçue.
    Dans le deuxième cas, la responsabilité incombe à une équipe, ayant un budget. La MOE (IT) étudie le “combien ça coûte” de la demande, l’impact sur le projet, propose plusieurs solutions. La MOA peut décider, et la nécessité de budgéter incite à analyser et concevoir : l’outil méthodologique Px apporte toute sa pertinence.
    Risque : excès de procédure si le chef de proj informatique n’est pas sûr de lui, s’il n’est pas soutenu par son sponsor, si le chef de proj MOA n’a pas le réel pouvoir de décision (il arrive qu’il n’ait pas l’initiative budgétaire : c’est cata pour le projet).
    Partout où un mode de fonctionnement normé existe, (malheureusement, les cas sont peu nombreux en France), les rapports MOA-MOE sont plus fluides, l’info circule mieux, les CoDir ressemblent à quelque chose. Sans que ce soit la panacée ni la silver bullet.
    Il est temps que le management et la gestion raisonnée refoulent l’idéologie.