Application de Praxeme dans un contexte SOA limité

2 Comments

Philippe DEQUET, consultant senior et architecte Système d’Information d’Entreprise chez Atos Origin, me soumet des questions sur l’application de Praxeme. Cette note répond au premier groupe de question, portant sur Praxeme appliquée à SOA (service oriented architecture).

Je rappelle que, pour Praxeme, SOA est un style d’architecture logique, c’est-à-dire une certaine façon de structurer les systèmes informatiques.

Philippe écrit :

« Comme je vous l’ai déjà dit, je suis assez convaincu par l’approche SOA vue par la méthodologie Praxeme. Néanmoins actuellement je me pose quelques questions générales (je n’ai pas la réponse actuellement), que pourraient me poser inévitablement certains clients.

Premier groupe de questions

J’ai bien compris, que la topologie du Système Entreprise s’adapte bien à une refonte d’un système d’information, pour faire du SOA en profondeur. Cette refonte peut aussi se limiter à un domaine fonctionnel.

Je me pose quelques questions si je dois réutiliser des composants applicatifs existants (applications spécifiques, progiciels). La mission s’apparente ici à du SOA de surface.

  1. Quel procédé utiliser pour découvrir les services réutilisables utiles dans le périmètre SOA ?
  2. Comment greffer ce procédé dans la Topologie du Système Entreprise ?
  3. Faut-il traiter l’aspect sémantique si celui-ci est mis en œuvre dans le composant existant ?
  4. Comment faire intervenir les experts du métier ?
  5. Faut-il assimiler le composant applicatif existant à une sorte de fabrique logiciel de type boite noir avec lequel tous les échanges (Use-case) sont dans le périmètre SOA ?
  6. Est-il pertinent d’ailleurs d’intégrer les échanges asynchrones inter-applicatifs dans le périmètre SOA ? »

Fin de citation

La méthodologie Praxeme s’est attaquée au problème le plus vaste : la refonte complète des systèmes d’information. La communication du Praxeme Institute et de la communauté S-IT-A, dans les années 2006-2007, a pu amplifier la perception de la méthode comme applicable uniquement dans le champ des grands projets et des refontes. Beaucoup de personnes, comme Philippe, se demandent si et comment Praxeme peut convenir à des interventions plus réduites. Il faut dire, d’ailleurs, que les cas de refontes volontaristes sont rares. Même quand une politique d’urbanisation du SI est affichée, elle se restreint souvent à une administration de l’existant et à une amélioration par petites touches. Le cas de la SMABTP reste exceptionnel et s’explique par la coïncidence de plusieurs facteurs. Il est donc important d’apporter des réponses aux contextes de projets limités soit au périmètre d’un domaine, soit à celui d’une application ou même d’une optimisation technique.

Il se trouve que l’approche SOA permet, sous certaines conditions techniques et organisationnelles, une amélioration progressive des systèmes. Il importe de clarifier ces conditions pour faire des « projets SOA » des succès.

1. « Quel procédé utiliser pour découvrir les services réutilisables utiles dans le périmètre SOA ? »

Ce qui est essentiel à comprendre, c’est la portée de la SOA. La lettre importante dans ce sigle est le ‘A’. Il s’agit d’architecture, donc d’une pensée du système dans son ensemble. La portée de l’effort est nécessairement le système entier. De ce fait, la contradiction apparaît : le projet, par construction, n’a pas et ne pourrait pas avoir cette portée. Pire, presque toujours, le critère de délimitation des projets est fonctionnel. Cela tient non seulement à notre culture profondément fonctionnaliste, mais aussi au mode d’investissement : le budget est alloué pour satisfaire les besoins d’une direction fonctionnelle (DRH, Marketing, Production…). Dans ce cadre, il est impossible de raisonner à l’échelle de l’entreprise, du système dans son ensemble. Il y a contradiction entre le mode projet et l’effort d’architecture. L’appellation même « projet SOA » est paradoxale. La contradiction se résout sous certaines conditions.

Restons sur le cas de la réécriture d’un domaine. S’il s’agit de faire vite, on se condamne à du SOA de surface qui permettra d’enfermer ce domaine comme une boîte noire et de publier des services utilisables par d’autres domaines. C’est un progrès, certes, mais cela n’améliore pas la qualité interne de cette boîte noire, ni ne réduit la redondance à travers l’ensemble du système.

Si on recherche une amélioration générale, tout en limitant l’investissement au périmètre du domaine, il faut compléter le projet par des activités d’architecture. Les architectes portent la vision globale et long terme. Ils ne peuvent pas être attachés à un projet, sinon leur action se subordonne aux objectifs du projet et ils deviennent impuissants à faire prévaloir l’intérêt général. L’architecture est nécessairement une activité transverse. Cela ne veut pas dire que les architectes ne s’impliquent pas dans les projets. Bien au contraire ! Ils interviennent dans les projets pour y apporter la vision et la confronter au terrain.

On ne peut commencer à parler de SOA qu’à partir du moment où un graphe d’architecture logique a été établi, documenté et justifié. Il décrit la cible, ce vers quoi doivent tendre tous les nouveaux investissements – même partiels – sur le système. En regard de cette cible d’urbanisation, l’état actuel du système peut être sérieusement évalué et les parties prenantes peuvent commencer à discuter des « photos » intermédiaires qui vont jalonner la trajectoire d’urbanisation.

Ce graphe d’architecture logique va servir aussi, immédiatement, à refaçonner le système. L’idée est de développer comme une enveloppe qui va emballer le système existant. Cette enveloppe offre les services tels qu’ils se déduisent sans contrainte d’existant. La signature des services, les interfaces des constituants sont conçues dans l’esprit de la cible, non dans la soumission à l’existant. En revanche, le contenu des services dépend de l’existant, puis des versions qui se succèdent le long de la trajectoire d’urbanisation. En respectant le principe d’encapsulation, le contenu « organique » du service pourra changer sans impact sur son interface « fonctionnelle ».

Revenons au cas du projet de réécriture limité à un domaine fonctionnel. Si le graphe d’architecture logique est élaboré conformément aux préconisations de la méthode, le domaine fonctionnel risque d’être méchamment secoué. Il subsistera, sans doute, en tant que « fabrique logique » reprenant les éléments de pragmatique (processus, cas d’utilisation, objets de nature organisationnelle). Mais la nouvelle architecture logique se caractérise par l’apparition des domaines d’objets et leur positionnement dans la strate « Métier » de l’aspect logique (cf. Guide de l’aspect logique ; formation « Modélisation logique »). Cela conduit à vider le « domaine fonctionnel » d’une partie de sa substance.

Par exemple, des objets « métier » très génériques comme la personne, l’adresse, le produit, etc. risquent fort d’être plongés dans le domaine fonctionnel à l’étude(comme dans la plupart des domaines fonctionnels). La cible d’architecture les isole dans des domaines d’objets propres et les rend plus génériques (« personne » plutôt que « client »…). Donc, l’emballage de ce domaine fonctionnel dans une pellicule de services ne fournira pas les services attachés à ces objets « métier ». Il fournira uniquement ceux qui sont liés strictement à la fonction couverte par ce domaine. Les services des objets « métiers » doivent cependant être développés dans le même temps. Ils sont rangés dans les constituants logiques que prévoit le graphe d’architecture cible. De cette façon, ils sont d’emblée « à la bonne place » et on livre un premier germe pour les services de la strate « Métier ». Le contenu de ces services, si le projet est limité au domaine fonctionnel, est programmé dans les termes de l’existant. Il devra évoluer au fil des projets. Notamment, lors de la réécriture d’un deuxième domaine fonctionnel, il se peut que les services sur la machine logique « ML_Personne » doivent chercher les données tantôt dans la base « Clients », tantôt dans le progiciel RH. Dans ce cas, le comportement externe de ces services restent inchangés et reflète la sémantique de la Personne, mais il faut un mécanisme d’indirection dépendant du contexte (le genre de mécanisme qui tirera profit d’un dispositif d’agilité inscrit dans le framework technique ; par exemple, basé sur une solution de MDM comme EBX).

En conclusion, pour répondre à la question : la façon de découvrir les services ne doit pas changer quand on se trouve dans un périmètre réduit pour une SOA. Les « bons » services, c’est-à-dire les services à fort contenu sémantique, se déduisent des aspects « amont », en tout cas pour leur définition et leur signature. Leur contenu (leur programmation interne) peut, elle, reprendre strictement l’existant. On le retouchera lors des projets ultérieurs, quand le champ d’application de ces services s’élargira.

Évidemment, ce principe suppose de réviser soigneusement le processus du projet. Ce processus mêe des activités top-down comparables au cas de la refonte totale, avec des activités bottom-up de prise en compte de l’existant. Finalement, c’est plus délicat que de partir d’une table rase, mais, le périmètre étant restreint, c’est aussi plus maîtrisable.

2. « Comment greffer ce procédé dans la Topologie du Système Entreprise ? »

La réponse à la première question montre que les procédés restent les mêmes dans ce cas :

  • Modélisation sémantique.
  • Modélisation pragmatique.
  • Architecture logique (graphe d’architecture logique, dossier argumenté, quantification…).
  • Conception logique (avec la spécification détaillée des services).

Il faut y ajouter l’analyse de l’existant pour remonter dans la nouvelle structure le code recyclable. Ce procédé n’a pas été décrit pour l’instant dans Praxeme. Il doit prendre en compte le principe exposé par Pierre BONNET dans ses publications : on repère les règles et les variantes pour les diriger vers les dispositifs ad hoc (Agility Chain Management System).

Ce procédé d’analyse se « greffe » sur l’aspect logiciel, mais il produit des éléments qui remontent dans les aspects logique, sémantique et pragmatique. Aussi est-il nécessaire de bien le documenter. Il peut nécessiter la collaboration de plusieurs types de compétences. Par exemple, le développeur isole une séquence d’instruction qu’il pressent comme une règle « métier ». Un modélisateur vérifie ce statut et qualifie la règle pour pouvoir la diriger vers le modèle sémantique ou le modèle pragmatique.

Comme à chaque fois qu’un travail nécessite le concours de plusieurs expertises, ce procédé doit être particulièrement soigné.

3. « Faut-il traiter l’aspect sémantique si celui-ci est mis en œuvre dans le composant existant ? »

Si vous partez d’un domaine fonctionnel existant, il y a nécessairement de la sémantique (puisque les pratiques n’ont pas dissocié sémantique et pragmatique). Il est crucial d’isoler cette sémantique, de la séparer des éléments d’ordre pragmatique (règles d’organisation, pratiques, procédures…), d’extraire les choix contingents (techniques, rafistolages…).

Il faut absolument un modèle sémantique quand on vise une véritable architecture SOA. C’est, en effet, à partir du modèle sémantique que :

  1. Les constituants logiques les plus stables pourront être déduits è qualité structurelle.
  2. Les services les plus réutilisables seront découverts è qualité fonctionnelle.

En l’absence d’effort de modélisation sémantique, nous nous condamnons à réitérer les erreurs du passé, nous aveuglant nous-mêmes simplement en changeant leur nom !

4. « Comment faire intervenir les experts du métier ? »

La question est générale. La seule particularité que je vois dans le contexte que nous discutons ici, réside dans la nouveauté qu’apporte le modèle sémantique. L’effort se caractérise surtout par la généricité. Par exemple, si la réécriture du domaine fonctionnel conduit à dégager une notion générique comme « Personne », c’est peut-être l’occasion de faire le tour des directions de l’entreprise pour mettre au propre la sémantique complète de cette notion. De cette façon, on avancera plus vite sur les fondamentaux et le noyau du système se construira plus vite.

Les experts du métier doivent participer aussi au toilettage des règles détectées dans l’existant. Il y a une dynamique particulière à trouver dans les échanges entre l’expert du métier et le modélisateur. Ce n’est pas nécessairement l’expert qui doit avoir le dernier mot, car il n’adhère pas spontanément aux objectifs de généricité et d’économie qui motivent le modélisateur. Dès lors, il importe de distinguer la pré-modélisation (« cadrage ») et la modélisation. Cette question est explorée dans le cadre du Collège des Médiateurs.

5. « Faut-il assimiler le composant applicatif existant à une sorte de fabrique logiciel de type boîte noire avec lequel tous les échanges (Use-case) sont dans le périmètre SOA ? »

Si vous procédez ainsi, vous risquez de pérenniser la structure actuelle.

Les fabriques et tous les constituants logiques doivent être ceux du graphe d’architecture cible. Leur définition s’inscrit donc dans l’aspect logique et s’alignent sur ce que nous avons appris dans les aspects sémantique et pragmatique.

Le composant applicatif existant, quant à lui, appartient à l’aspect logiciel. Inutile – et même dangereux – de faire remonter, dans l’aspect logique, cet élément contingent.

Mieux vaut voir les choses de la façon suivante : le graphe d’architecture logique devient, quand il est transporté sur l’aspect logiciel, une enveloppe ou un calque plaqué sur le système. Il enveloppe les applications existantes et les nouveaux composants. Le lien entre les deux se fait comme décrit en réponse à la première question.

6. « Est-il pertinent d’ailleurs d’intégrer les échanges asynchrones inter-applicatifs dans le périmètre SOA ? »

C’est notre position, dans Praxeme. Pour un aspect donné, il ne saurait y avoir qu’une architecture. Cette proposition se lit symétriquement comme la définition de l’architecture : l’architecture considère le tout d’un aspect donné. C’est une aberration de parler, par exemple, d’une architecture des communications, etc. (attention à la dérive des spécialisations érigées en chapelles). Il est essentiel d’avoir une vision unifiée du système. L’architecture logique décrit les services dont certains ont un comportement synchrone et d’autres répondent de façon asynchrone.

Le sujet a été discuté en profondeur avec la Cellule Architecture Technique de la SMABTP. Il en est résulté un document qui complète le Guide de l’aspect logique (au titre malencontreux de « Les traitement batch dans l’architecture de services »). Actuellement, dans l’espace réservé aux membres du Praxeme Institute.

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.

2 Responses to “Application de Praxeme dans un contexte SOA limité”


  1. Fab

    Quant au point 6, en tenant compte du fait que SOA n’est qu’un style d’architecture, on doit envisager d’avoir plusieurs styles dans notre besace de concepteur logique.

    J’ai du récemment m’intéresser à l’approche “événements” (comme dans Complex Event Processing) et j’y ai d’abord vu un autre style potentiel. En creusant il s’avère que cette approche n’est pas conflictuelle avec la SOA mise en scène par Praxeme. Au contraire elle pourrait bien être complémentaire et résoudre certains soucis des services (le design pattern pub/sub m’a toujours semble un peu limité en approche services, par exemple). Peut-être qu’un mélange SOA+Events serait intéressant à étudier. Mais il est possible aussi que l’approche Events ne soit qu’une technologie qui n’a pas sa place au niveau logique, et que la notion de message puisse en être l’origine dans l’aspect logique : on peut peut-être dériver les Events des messages de services et les réifier en techno Events dans l’aspect logiciel.

  2. DVAU

    Parfaitement juste.
    Comme souvent dans notre profession, la technologie fournit l’opportunité pour un nouveau “paradigme” (le terme est peut-être un peu fort, ici). Une des conditions est toujours d’en abstraire les principes et de dégager la logique sous-jacente.
    EDA peut, en soit, constituer un nouveau style pour l’architecture logique.
    On peut envisager des styles “composites”, comme en mélangeant EDA et SOA. Mais alors, comme en art, il faut être prudent et éviter de sombrer dans le rococo !
    En conception de SI, les styles composites mettent le concepteur en situation de choisir, pour un besoin donné, entre plusieurs solutions possibles. Dès lors, deux concepteur face au même problème pourront apporter des réponses différentes. Le même pourra changer d’idée au cours du temps…. Bref, cela entraîne des difficultés.
    Il importe donc de fixer des règles claires et de dire dans quel cas choisir l’appel de service, dans quel autre l’émission d’événement.
    Donc, de la méthode !