Fin de ce blog

Ce blog va s'arrêter normalement le 20 octobre, par décision unilatérale du fournisseur. C'est la deuxième fois que Club Internet nous fait le coup. Je chercherai donc une solution plus fiable qui sera annoncée sur le site www.praxeme.org .

Praxeme a été souvent citée, ces derniers temps, dans la presse. On consultera notamment le très bon dossier de 01 Informatique sur SOA ou le blog d'Olivier Rafale.

Le Collège des modélisateurs sémantiques a été lancé le mois dernier. Le groupe de discussion est très actif et prépare la validation du "Guide de l'aspect sémantique".

Nous nous organisons pour traduire le maximum de documents en anglais. C'est une urgence pour répondre à l'attente de groupes multinationaux. Il y a, désormais, une page sur le site Praxeme qui présente les documents disponibles en anglais.

Le Collège des médiateurs (maîtrise d'ouvrage, pré-modélisation : exigences, objectifs, etc.) sera lancé le 7 novembre. Il s'adresse à une population de non informaticiens. En tant que méthodologie d'entreprise, Praxeme cherche à répondre aux besoins de tous les acteurs de l'entreprise.

Novembre est aussi le mois qui verra la parution de l'ouvrage sur l'application de Praxeme à un grand projet de refonte SOA. Cet ouvrage est co-signé par Pierre BONNET, Jean-Michel DETAVERNIER et Dominique VAUQUIER.

En décembre, nous prévoyons l'assemblée générale de l'association Praxeme Institute, avec une partie publique.

Pour suivre l'actualité autour de la méthode publique : www.praxeme.org .

Modélisation sémantique

Hier a été lancé le "Collège des modélisateurs sémantiques".

L'annonce en avait été faite auprès des adhérents qui s'étaient inscrits en masse. Nous n'avons donc pas pu ouvrir cet événement à un plus large public, contrairement à ce que nous avions initialement prévu.

Ce succès montre l'intérêt porté à ce sujet difficile, néanmoins perçu comme vital pour les entreprises.

Les participants (une vingtaine) ont fait le bilan des éléments déjà disponibles sur le sujet, dans le fonds public.

Les prochains travaux prévus :

  • relecture du "Guide de la modélisation sémantique" ;
  • analyse du lien entre MDM et modélisation sémantique ;
  • si possible, session de formation (module "Modélisation sémantique", disponible sur le site).

A noter : la parution prochaine d'un dossier de La Lettre de l'ADELI, consacré à la modélisation et comprenant trois articles liés à Praxeme.

Discussion sur la méthode

Pour ne pas laisser perdre un échange avec Pierre BONNET et pour clarifier certains points de la méthode :

Modélisation logique (conception des services, architecture logique style SOA)

PB : C'est exactement ça. L'essentiel de la programmation est dans le service de la strate "Métier". Si un autre domaine fonctionnel - c'est-à-dire une autre direction - a besoin de sélectionner le contrat, les différences de rôles font que l'interaction a de bonne chance d'être légèrement différente. Donc, même si on se retrouve avec 2 activités élémentaires "sélectionner contrat" dans des domaines fonctionnels différents, on peut parier que leur spécification présente de légères différences.

Dans le cas SMABTP, on a mis « sélectionner contrat » dans le cas d'utilisation « Déclarer sinistre » ce qui pose interrogation à Sogecap car cela donne le sentiment que l'on ne peut pas réutiliser « sélectionner contrat » dans les autres domaines fonctionnels.

Ma réponse : il faut accepter cette contrainte car aller vers une « atomisation » des cas d'utilisation sera fatale en terme d'administration et par ailleurs cela n'enlève pas la réutilisation au niveau sémantique puisque les services métiers invoqués au titre du sélectionner contrat sont réutilisables entre les domaines.

DVAU:

Modélisation pragmatique (structuration en cas d'utilisation et relation au modèle sémantique)

PB :

Dernier point, pour moi cette fois :

- l'orchestration entre les activités des cas d'utilisation et les opérations du sémantique n'apparaisse pas clairement (pas du tout) dans la modélisation Sq/Pg, tu as réfléchi sur ce point ?

DVAU : Le modèle pragmatique (exactement, nous sommes en train de parler de la Vue de l'utilisation, une partie du modèle Pq) devrait avoir deux faces :
  • l'une externe, de spécification fonctionnelle à base de cas d'utilisation et qui va jusqu'aux activités élémentaires ;
  • l'autre interne, de conception, qui dirait pour chaque activité élémentaire quels sont les objets "métier" et opérations qu'elles sollicitent.
Il faut voir, au cas par cas (sur chaque projet), si cet effort apporte de la valeur ajoutée. En effet, cette correspondance peut être évidente, auquel cas on peut la reporter sur la conception logique voire sur le développement. Tout dépend du contexte du projet : difficulté du domaine, compréhension du métier, compétences mobilisées...
Formellement (méta-modèle de la méthode), tout est en place pour établir cette correspondance dès le modèle pragmatique. Une des retombées, si on travaille comme cela, est de déglonfler la spécification fonctionnelle, puisqu'une grande partie de informations et contraintes est déjà exprimée dans le modèle sémantique.
Théoriquement, le plus tôt est toujours le mieux (tant que l'on ne fait pas remonter des considérations de niveau inférieur).
Pratiquement, c'est à vous de voir !

Vieille opposition

Il y a plus de "concret" dans une théorie correcte que dans des pratiques hasardeuses.

Filiations de Praxeme

Nous reconnaissons volontiers notre dette à l'égard de nos prédécesseurs.

Ci-dessous, une tentative pour résumer les sources auxquelles s'abreuve la méthodologie Praxeme.

Filiations

Carte postale... de l'été

La volonté de construire un meilleur système informatique se traduit sous différents vocables :

  • urbanisation du SI ;
  • architecture du SI (fonctionnelle, logique, technique, applicative... choisissez l'adjectif et inventer un nouveau métier) ;
  • Enterprise Architecture ;
  • SOA ;
  • gouvernance de SI...

La qualité du SI s'évalue en fonction d'objectifs très généraux : évolutivité, alignement stratégique, interopérabilité, partage...

On peut penser que cette volonté d'amélioration entraîne la réalisation d'un plan du système à construire. Après tout, puisque l'on parle d'architecture, ne commence-t-on pas par établir un plan de la moindre habitation à construire ? D'ailleurs, il s'agit de plusieurs plans : le plan d'ensemble, le plan des canalisations, le schéma électrique, etc. Les systèmes informatiques étant réputés complexes, on peut s'attendre à trouver des "plans" qui les décrivent précisément, selon plusieurs points de vue.

On parle effectivement de "cartes" ou plutôt de "cartographies". L'usage de ce dernier terme est impropre, la cartographie étant l'art d'établir des cartes et non la carte elle-même. Pour ce procédé, nous avons déjà le terme "architecture". Le résultat de la discipline d'architecture est le plan du système, la carte, le modèle d'ensemble, l'architecture (en tant que produit, non plus en tant que discipline), etc.

La carte, qui décrit un système, peut être générale. Dans ce cas, elle se présente comme une synthèse du système existant ou du système à construire. La synthèse ne vaut que si le détail a été conçu, évalué et qu'il fonctionne, du moins en esprit.

Or, qu'observe-t-on ?

Trop souvent, les entreprises se contentent d'une "cible d'architecture" formulée sous la forme d'un schéma ou d'une diapositive. Il faut faire simple pour communiquer - c'est l'argument. Pourtant, ces cartes sont trop compliquées en ce qu'elles mélangent souvent des considérations de natures différentes :

  • un peu de technique (pour placer quelques gadgets, quelques termes incontournables) ;
  • un peu de logique (parce que l'on a appris ses leçons) ;
  • un peu de métier ou de stratégie (pour montrer que l'on travaille pour l'entreprise).

Bref, la carte est un bric-à-brac. Trop compliquée parce qu'elle ne respecte pas les niveaux d'abstraction (les aspects du Système Entreprise), elle est en même temps trop simple : en effet, elle ne résume rien d'autre qu'elle-même, elle est le départ et l'aboutissement de la réflexion architecturale.

Ce n'est pas une carte qui décrit la géographie du système. Si c'est une carte, c'est plutôt une carte postale !

Ce n'est pas le plan de montage du système, mais une vague ébauche de grands blocs qui n'auront jamais qu'une réalité vague. Evidemment, cette façon de faire présente bien des avantages, à commencer par celui du concensus. Mais peut-on penser sérieusement que ce niveau de description suffit pour guider la construction d'un système, ou d'une fédération de systèmes, sur plusieurs années en impliquant des dizaines ou des centaines de personnes ?

Il n'est pas simple de reconstruire un système informatique, encore moins de faire converger plusieurs systèmes. Si on veut réellement donner du contenu aux voeux de réutilisation, d'agilité, d'interopérabilité, alors cela demande un effort, une pensée architecturale. La carte pourra être présentée, à condition de respecter certaines règles de l'art et de n'arriver qu'au terme d'un travail de conception architecturale. Chaque élément de la carte doit être soupesé, évalué ; l'architecte logique (c'est de lui qu'il s'agit) pense et évalue chacune de ses décisions, à la fois dans la statique et la dynamique du système. La représentation qu'il élabore est, dès le départ, perçue comme devant se prolonger, se détailler par des modèles de plus en plus précis, jusqu'au dernier détail des constituants du système.

Un système réussi suppose, à la fois, une vision d'ensemble et la maîtrise du détail.

On ne peut partir dans cette guerre qu'avec une logistique impeccable, venant appuyer une stratégie volontaire et claire. Il y faut aussi une autorité infaillible et des troupes bien entraînées. C'est une guerre contre l'entropie et la complication stérile. Nous ne devons pas nous tromper d'ennemie : c'est bien contre la complication que nous nous battons, pas contre la complexité - celle-ci, nous la respectons.

Qu'est-ce qu'un "service" ?

Que signifie "service" dans l'expression SOA (service-oriented architecture) ?

La question se pose encore, au moins sur un plan pédagogique. Pour faire vite, disons d'abord qu'avec ce terme, les informaticiens se sont donnés une métaphore pour parler du système informatique. L'exercice de la métaphore recèle quelques pièges. On risque de mélanger les usages courants du terme avec les usages spécialisés... Pour parer à ces déviations, on encourt un risque plus grand encore : celui de compliquer le vocabulaire en forgeant des expressions de plus en plus compliquées... et on finit par se demander comment nommer ce que tous les acteurs de l'entreprise ont toujours nommer "service" !

Pour Praxeme, le terme "service" au sens SOA désigne précisément le "service logique" et appartient à la terminologie de l'aspect logique.

Le texte qui suit, extrait du "Guide de l'aspect logique", précise la notion et tâche d'en analyser les connotations.

Demander un service, c’est attendre que quelqu’un, le fournisseur, réalise une action qui produise un résultat intéressant pour le demandeur. Solliciter et fournir un service sont les deux termes de l’interaction. Le demandeur n’a pas à connaître la façon selon laquelle le fournisseur s’y prendra. Il ne s’intéresse qu’au résultat et aux conditions dans lesquelles il en bénéficiera.

SOA est une approche des systèmes informatiques qui s’est construite sur la base de cette métaphore. Pour respecter celle-ci, le « service » dénote l’action et son résultat. Or, certains discours à teneur technique ont fait glisser le terme qui désigne, aussi, le composant qui fournit le service. C’est le cas, surtout, dans la solution technique des web services. Un web service affiche plusieurs opérations. Praxeme respecte la métaphore et assigne le « service » à l’unité de l’opération, c’est-à-dire au grain le plus petit, à l’atome du système. Si on regarde le contenu d’un service, on atteint la ligne d’instruction, inutile et inutilisable d’un point de vue externe.

La caractéristique majeure de cette approche réside dans l’encapsulation (pour reprendre le terme de l’approche orientée objet). Dire que le service est le grain élémentaire du système, c’est exclure la donnée hors du champ de vision. En effet, pour obtenir une information, dans une architecture de services, il n’est d’autre moyen que de solliciter le service ad hoc. SOA, comme l’approche objet, interdit la manipulation à distance. Pas question que plusieurs programmes attaquent directement les mêmes supports de données : ils demandent les services pour accéder aux données dont ils ont besoin. Ces services, non seulement factorisent les manipulations, mais aussi ils garantissent que toutes les contraintes applicables seront respectées. Cette caractéristique change radicalement la façon de concevoir le logiciel. Elle augmente la qualité.

Nous disons « service logique » pour bien signifier que l’effort de conception et de structuration qui va tirer parti de cette métaphore se joue sur l’aspect logique. Le service n’est pas une solution technique, même s’il existe des solutions dédiées. Nous pouvons concevoir un système informatique à l’aide de cette approche, tout en utilisant des technologies classiques. L’application de la métaphore conduira à améliorer la structure du système. Tandis que l’architecture technique établit les conditions de faisabilité d’une architecture de services, l’architecture logique bâtit la structure et la conception logique trouve les services et détaille leurs spécifications.

L’usage du terme « service » soulève une interrogation : concerne-t-il l’acteur du système, « l’utilisateur » ? Il faut montrer, ici, une grande prudence. Le détournement du nom courant « service » risque de causer

la confusion. On

peut dire, bien sûr, que l’utilisateur attend, du système informatique, des services et on peut, d’ailleurs, en fixer le niveau de qualité (par des SLA[1]). Afficher la synthèse client, rechercher un produit répondant à certains critères, établir l’arrêté des comptes… autant de services que l’on peut attendre d’un système automatisé. Il y a de bonnes chances que l’architecture de services mette en regard de ces besoins des « services logiques » qui portent le même nom. Ce sont les opérations qui réalisent les services. Avec ces exemples, nous sommes à la périphérie du système informatique. Nous y constatons la coïncidence entre :

·        d’un côté, la perception naturelle, externe – le service rendu par le système ;

·        de l’autre, la construction interne, le « service logique » en tant qu’unité de construction du système, dans le style SOA.

Pourtant, cette coïncidence n’est pas essentielle dans l’approche SOA. L’essentiel du message réside dans la généralisation de la métaphore du « service » pour repenser le système informatique, en profondeur. Au-delà de ces services perçus par l’acteur, le système se recompose à base de services, dont beaucoup restent tapis dans ses profondeurs.


[1]  SLA : service level agreement, un accord sur le service rendu à l’utilisateur d’un logiciel.

Cycle en 'Y'

L’intérêt de la démarche en ‘Y’ réside dans le parallélisme entre les deux branches : fonctionnelle et technique.

Si on applique la Topologie du Système Entreprise, on constate que les occasions de paralléliser les travaux sont plus nombreuses, tout en respectant les contraintes intrinsèques de l’objet système.

L’intérêt du parallélisme augmente avec la taille des projets et leur durée.

Autre sujet, un petit inventaire des travers de nos activités (édifiant !) : http://www.scottberkun.com/blog/2007/asshole-driven-development/

Formation

De nouveaux acteurs du monde de l'enseignement et de la formation professionnelle rejoignent l'initiative pour une méthode publique. C'est une excellente chose, car le marché attend des compétences sérieuses dans les diverses disciplines de Praxeme, notamment la modélisation sémantique et la conception des architectures SOA.

Nous organisons, donc, une rencontre des acteurs intéressés par la diffusion de Praxeme :

  • universités et écoles d'ingénieurs ;
  • instituts de formation ;
  • sociétés ou indépendants ayant une activité de formation.

La réunion aura lieu le 12 juillet, à Paris (conditions à préciser). Elle est réservée aux adhérents de l'association Praxeme Institute.

Au programme :

  1. partage des supports de cours disponibles dans le fonds public Praxeme ;
  2. conditions d’exploitation de ce fonds ;
  3. objectifs de diffusion et intérêts de chaque partie prenante ;
  4. si l’agenda le permet, présentation du contenu (au moins, actions pour suite).

Pour plus de précision.

Journée exceptionnelle - résultats

La Journée exceptionnelle "Praxeme appliqué à SOA", le 12 juin, a été un nouveau succès qui confirme l'attente du marché pour une méthodologie d'entreprise. 25 participants, plusieurs adhésions. Un nouveau projet va démarrer en appliquant Praxeme.

L'analyse des évaluations fait apparaître les résultats suivants :

  • Jugement général : 70% "excellent", 30% "bon".
  • Pertinence de la méthode : 95%.

Ces résultats nous encouragent à continuer nos efforts en vue d'élaborer une méthode de référence, complète et libre. Les bénéfices de cette journée permettront à l'association Praxeme Institute d'organiser ses travaux et d'autres événements.

Les supports actualisés seront mis à disposition sur le site : http://www.praxeme.org

Rappel :

Prochain rendez-vous public : la séance inaugurale du "Collège des architectes logiques (SOA)", le 27 juin.