Enterprise Transformation Manifesto

Add a comment

Le CESAMES (Centre d’Excellence Sur l’Architecture, le Management et l’Économie des Systèmes)

et l’École Polytechnique

ont signé le manifeste pour la transformation d’entreprise.

Ce papier synthétique  se veut le bréviaire de l’entreprise responsable. Il s’adresse aux décideurs, prend au mot les déclarations sur la transformation, l’innovation, la responsabilité d’entreprise… et repositionne l’architecture d’entreprise.

Nous attendons que les directions générales, de la communication et du marketing s’y intéressent.

En effet, l’intérêt, de leur point de vue, est double :

  • d’une part, fournir une occasion de communication dans la veine « responsabilité d’entreprise » ;
  • d’autre part, en interne, afficher une liste de « golden principles » pour soutenir les initiatives de transformation.

Du point de vue des directions informatiques, des prestataires ainsi que des associations ou organisations professionnelles, l’intérêt réside dans la revalorisation du rôle de l’architecte d’entreprise. Ils peuvent se retrouver, aussi, dans la défense d’une certaine rationalité technique, trop souvent bridée dans l’entreprise.

Ce manifeste propose une définition ambitieuse de l’architecture d’entreprise et indique, à demi-mots, quelques principes et pratiques (dont le détail est à rechercher dans la méthode).

Ce document fournit une plate-forme pour définir les compétences et stimuler la coopération entre le monde de l’entreprise et celui de l’enseignement et de la recherche.

Le dernier ange

Add a comment

Quand tout a reflué
Que l’esprit se délite
Qu’il s’est désenglué
De l’espoir qui l’irrite

Quand la médiocrité
Et les vaines manœuvres
Ont de l’humanité
Ruiné toutes les œuvres

Seul, penché, se tient l’ange
Les ailes éployées
Au-dessus de la fange

C’est la Pensée, foyer
Ultime, vigilance
Et dernière défense

L’enfant d’une nuit d’Idumée

Add a comment

Quand mes nuits d’insomnie
Recyclent l’idée fixe
En boucles infinies
Long délire prolixe

À la longue l’esprit
Que l’ennui tétanise
Fuit le réel aigri
S’étiole et s’hypnotise.

Un sentiment d’étrange
Habite la pensée
L’harasse et la dérange.

Impuissante, offensée,
Réfugiée dans les franges
Elle est le dernier ange

Praxeme et… les langues

Add a comment

Nouvel atelier autour d’un chercheur.

Loïc DEPECKER, professeur à la Sorbonne et à l’École Normale Supérieure, fera le point sur ses travaux en terminologie et sur le thème de la politique linguistique de l’entreprise.

Détail et inscription

L’événement est public et gratuit.

Conférence sur l’urbanisation de SI

Add a comment

La première matinée de la conférence Marcus Evans “Après 10 ans d’urbanisation : l’architecture d’entreprise” (le 8 avril) sera animée conjointement par :

  • Yves CASEAU, DGA Bouygues Telecom ;
  • Philippe DESFRAY, DG Softeam et vice-président du Praxeme Institute ;
  • Dominique VAUQUIER, président du Praxeme Institute.

L’objectif de cette triple intervention est de montrer en quoi la pratique de l’urbanisation des systèmes d’information peut évoluer.

Appuyés sur les apports de la méthode Praxeme, trois messages s’imposent et permettent de renouveler les pratiques :

  1. L’urbanisation de SI doit s’élargir en une discipline qui couvre tous les aspects de l’entreprise. C’est ainsi que nous entendons l’architecture d’entreprise, expression que nous prenons au pied de la lettre plutôt que de la laisser dériver vers une approche spécialisée et réduite à la technologie. De ce point de vue, Praxeme apporte le cadre de référence qui permet d’embrasser et d’articuler tous les aspects de l’entreprise. La Topologie du Système Entreprise permet d’asseoir une telle approche holistique, essentielle pour la transformation de l’entreprise.
  2. Si la représentation et la conception des processus restent un effort nécessaire, nous devons aussi restaurer la représentation des connaissance “métier” qui exige un effort d’abstraction plus important. Nous montrerons en quoi ce recentrage sur les données et la modélisation sémantique peut transformer en profondeur les systèmes d’information et contribuer à leur agilité autant qu’à l’interopérabilité.
  3. A rebours de nos habitudes de travail, nous devons modifier nos pratiques pour concevoir et réaliser des systèmes dans la durée. C’est une chose de dénoncer les “silos” applicatifs, c’en est une autre de modifier nos approches pour échapper aux effets combinés de la culture fonctionnaliste et du mode projet. Dans ce combat contre le court-termisme, l’architecte a un rôle clef à jouer. En a-t-il toujours les moyens ? Au moins, l’existence d’une méthode de référence et l’unité d’un discours lui fournissent une bannière sous laquelle se ranger (voir Enterprise Transformation Manifesto) .

Bréviaire pour l’entreprise responsable

Add a comment

Le Praxeme Institute publie un document résumant sa philosophie :

Enterprise Transformation Manifesto

Ce document s’adresse à toutes les fonctions de l’entreprise (au sens large que nous donnons à ce terme), en premier lieu :

  • les directions générales, qui y trouveront un discours unifié et une liste de principes pour guider leurs programmes de transformation ;
  • les directions de la communication ou du marketing, qui verront dans la signature du manifeste une occasion d’affirmer certaines des valeurs de leur entreprise ;
  • les DSI et, en leur sein, plus particulièrement les fonctions transverses qui apprécieront le repositionnement de l’architecture d’entreprise.

Le manifeste intéressera également le monde académique, qu’il interpelle en faveur d’une approche multi-disciplinaire, autour de laquelle organiser les contenus d’enseignement (voir, surtout, le chapitre 7).

Actuellement, deux documents sont disponibles :

  • le manifeste lui-même, liste des principes qui éclairent la transformation de l’entreprise ;
  • le commentaire qu’en donne le Praxeme Institute.

Pour les entreprises qui s’y reconnaîtront, ce texte fournira une occasion de communiquer et d’affirmer leurs valeurs.

Les modalités de l’opération sont indiquées à la fin du manifeste.

Modèle et lingerie

1 Comment

La pratique de la modélisation ressuscite les réflexions scolastiques sur le rapport entre forme et contenu.

Ce rapport prend une dimension collective et économique dans le fonctionnement des projets et la transformation des entreprises. Nous nous heurtons à une difficulté : c’est une certaine population qui possède le contenu, la connaissance “métier”, tandis que la forme et la capacité à bien représenter sont maîtrisées par d’autres personnes.

Il est urgent de trouver la combinaison qui fera que porteurs de contenu et maîtres de la forme puissent travailler efficacement ensemble. Il en va de la qualité de nos solutions et de la possibilité même d’innover et de transformer.

La modélisation, c’est un peu comme la lingerie fine. C’est le contenu qui est intéressant, mais la forme révèle le contenu.

Certaines fois, modéliser c’est un peu laver son linge sale – en famille si possible. En effet, dès que l’on cherche à aller un peu au fond des choses, on révèle vite des incohérences, des contradictions dans l’expression sinon dans la connaissance même. Il faut tout déballer pour ensuite tisser un nouvel arrangement de concepts.

D’autres fois, on s’aperçoit que, sous le manteau de parole, le roi est nu.

Curriculum Vitae

Add a comment

CV mis à jour.

Dernière mission : pilotage d’une initiative dans le cadre du programme Multi-Access chez AXA Group.

Ce projet a permis de réaliser un proof of concept de la méthodologie, sur le périmètre fonctionnel du Lead management (gestion des contacts).

Il a livré un modèle de cette fonction (sémantique et pragmatique) , un Thesaurus (conforme à la technique du “cadrage” ou scoping) et un draft de dossier d’architecture.

Du point de vue de la méthodologie, une nouveauté : la structure type pour un Dossier d’Architecture Générale, selon Praxeme.

Un exercice de modélisation sémantique

Add a comment

Sur la liste des adhérents du Praxeme Institute, nous nous sommes livrés récemment à un petit exercice de modélisation sémantique. En voici le résultat.

Énoncé

L’énoncé est tiré d’une expression d’un besoin “métier” (en fait,une présentation par le Marketing) :

A) The client sets preferred time & place.
B) The company indicates the “closest” available agent.

L’essentiel se joue dans l’aspect sémantique. En effet, le seul élément lié à l’organisation est le rôle “agent” dans la proposition “B”.

Client

Le rôle “Client” peut apparaître dans le modèle sémantique, sous la forme d’un rôle (au sens UML), c’est-à-dire d’un rôle sur une association (par exemple, vers Contrat ou Commande).

  • La notion de client peut être perçue comme sémantique car elle n’implique aucune hypothèse d’organisation, comme c’est souvent le cas avec les acteurs externes.
  • Cela n’interdit pas de revenir sur le rôle Client dans le modèle pragmatique , puisqu’il y a des décisions d’organisation à prendre : par exemple, droits accordés au client sur certains cas d’utilisation.
  • Il faut surtout éviter de traiter les rôles par la classification (l’héritage). Cela expose au problème de la “mutation”. Une même personne peut être à la fois client et agent. Le principe de modélisation est ici : la substance arrive avant la relation. Les rôles (comme client) sont toujours relationnels, donc à traiter comme tels dans le modèle sémantique (cela n’interdit pas de réifier la notion de rôle dans le modèle pragmatique, puisque c’est justement une notion organisationnelle). La pure substance – ce que nous découvrons en observant le monde sans a priori et sans le reformuler dans une perspective interne -, la substance, dans notre exemple, ce sont les personnes.
  • Le modèle générique (Open Business Concepts, pour reprendre l’expression de Fabien VILLARD) propose déjà la classe Party, laquelle couvre les cas : personnes physiques, personnes morales…

Les classes en jeu

On a donc :

  • Party (d’où nous tirons le client et l’agent).
  • Site, autre classe générique qui permet de traiter la sémantique des lieux comme des moyens de contacts (adresse, téléphone…).
  • Period, également générique. A noter : à bien y regarder, les préférences sur le moment du contact ne sont pas si faciles à exprimer, si on les traite sur le long terme. La personne peut être disponible à certaines heures pour une période donnée et à d’autres heures pour une autre période. Elle peut exprimer des préférences avec des exceptions pour des plages identifiées. Ou encore, elle peut faire référence à un calendrier partagé (congés scolaires, jours fériés…). Il y a là un bon exercice de modélisation, aussi. Supposons cela traité. De toute façon, cela appartient à la sémantique de la période et doit donc être encapsulé dans la classe générique Period.

Réponse à l’énoncé A)

Une fois posées les trois notions – Party, Site, Period -, il nous faut examiner comment l’expression de préférences doit les combiner. Par exemple, on peut indifféremment :

  • se donner P (un client) et T (un créneau), puis rechercher le lieu approprié, S = ce serait le cas pour un rendez-vous téléphonique ;
  • fixer d’abord S, le lieu, et rechercher ensuite un créneau compatible = cas d’une rencontre physique.

Le modélisateur doit se dire, aussi :

  • pour un P et un T, peut-il y avoir plusieurs S ? (oui = téléphone bureau et mobile ; à savoir : le téléphone mobile est traité comme un site)
  • pour un P et un S, combien de T ? (plusieurs, là aussi)
  • bien évidemment, pour un couple S (ex l’agence) et T (horaires d’ouverture), il y a plusieurs P potentiels (on espère : au moins un agent et un client).

De ces considérations s’impose la solution : il nous faut une association ternaire, reliant les trois classes Party, Site et Period.
Pas moyen d’y échapper car ce sont trois degrés de liberté dans la détermination des préférences spatio-temporelles.
Nous pouvons nommer cette association : “locates” (au sens de “répérer”), ce qui permet de respecter la convention pour les noms d’association (verbe à l’indicatif présent, 3ème personne du singulier). A noter : certains outils – et pas des moins populaires – ne vous permettent pas de nommer une association n-aire. Jetez-les !
Cette association doit être réifiée car elle porte des traits comme l’état (voir message de Fabien V.), peut-être le niveau de certitude, un commentaire, etc. Je l’appelle “Localization” (terme qui, en anglais, semble bien rendre la notion dont nous traitons ; ne pas confondre avec “location” qui est déjà placé sur le modèle générique comme rôle de Site dans l’association resides).

Réponse à l’énoncé B)

Faut-il compliquer le modèle pour répondre à la deuxième partie ? Non. L’agent est une personne. Son calendrier sera traité avec la même association. La ternaire permet de couvrir les cas de mobilité et travail à domicile.
Répondre au problème posé, revient donc :

  • à fixer un P – le client ;
  • à examiner ses préférences (couples de T & S trouvés par l’association “locates“) ;
  • pour chaque couple, à déterminer si un agent (Party assumant le rôle) est disponible, en faisant appel à son agenda.

Donc, “B” n’ajoute rien en termes sémantiques. La question est : où placer le mécanisme correspondant ?
Une première réponse consiste à le situer dans un cas d’utilisation. Nous en trouvons un, au moins, dans le domaine Sales, plus précisément pour le Lead management (gestion des contacts).
En y réfléchissant, nous pouvons imaginer de nombreuses autres situations où ce calcul peut se faire (visite d’un expert, rencontre avec un partenaire, contrôle de chantier…). Reconsidérons la requête impliquée par la proposition B. Qu’y a-t-il, là-dedans, qui soit lié à une façon de faire ? à une organisation ? Rien. Nous pouvons donc considérer cette requête comme purement sémantique, plus exactement : appartenant au champ sémantique que nous venons d’étudier. C’est donc sous la forme d’une opération dans le modèle sémantique que nous la formulerons.
Où placer cette opération ? C’est le prochain exercice !

Cardinalités

Nous aurons du “0..*” à chaque extrémité, ce qui est un bon indicateur de la qualité de la solution…

Élargissement

Prenons, maintenant, un peu de recul ! Ce que nous venons de traiter pour des personnes, est-ce que cela ne ferait pas sens pour d’autres objets ? Par exemple : un engin de chantier, un drone, un spectacle… Certes, dans ces cas, il ne s’agit plus de préférences mais de planification. Pourtant, la forme de la détermination est la même. En conséquence, le modélisateur sera tenté de “faire remonter” la branche de l’association ternaire vers la classe Being, superclasse de Party. Le nom de l’association n’a pas à changer (ça tombe bien, nous n’avions pas choisi “Préférence” ; le terme “consultation” est trop lié à un usage donné et déborde le champ sémantique obtenu par la réunion des trois notions). La préférence – par opposition à planification, par exemple – sera traitée comme un état de la classe Localization.
Remarque : une telle généralisation a déjà été réalisée pour l’association “resides“.

Solution

Conclusion

La solution au problème énoncé repose sur l’association ternaire, à laquelle nous attachons une classe associative.
Beaucoup de problèmes apparemment anodins (comme notre énoncé) débouchent sur des solutions bancales ou amputées parce que le concepteur n’a pas vu le faisceau de déterminations. Refuser d’utiliser les relations n-aires (dans un modèle sémantique, s’entend), c’est s’obliger à estropier la représentation du réel. Une telle attitude condamne à développer des solutions inappropriées.
On oppose souvent à cette pratique de l’association n-aire que :

  • elles sont difficiles à comprendre ;
  • elles ne correspondent à rien dans la technologie.

Ces arguments ne tiennent pas. Il n’y a rien de difficile à considérer qu’une notion est déterminée par plusieurs autres. Pour le second point, se reporter à notre guide PxM-41, qui explique comment dériver un modèle sémantique en modèle logique de données.

Si de telles discussions vous intéressent, n’hésitez pas à nous rejoindre en adhérant à l’association.

A partir de cette année, les inscriptions individuelles sont gratuites et se font en lignes : http://friends.praxeme.org/adhesion/

Evaluation de solutions informatiques

Add a comment

Comment apprécier sérieusement une solution ?

Qu’il s’agisse d’une solution du marché (progiciel, ERP, package et autres noms) ou d’une solution interne (développement spécifique, maison), il n’est pas si simple de se faire une idée à peu près juste de la valeur et du comportement d’un logiciel.

Cherchant à mettre au point une méthode d’évaluation, je vous propose un premier jet sous la forme d’une carte qui, après raffinement et commentaire, débouchera sur une grille d’évaluation.

Tous les commentaires ou compléments sont les bienvenus.

Grille d'évaluation d'une solution informatique - Carte MindManager, 1ère version

Grille d'évaluation d'une solution informatique

NB : le code couleur n’a pas été arrêté au hasard !