Praxademia donne le test d’auto-évaluation

Une nouvelle contribution de Praxademia au fonds public

Le test d’auto-évaluation est prévu dans le schéma de qualification de Praxeme. Il en constitue la première marche, et est un préalable à l’examen pour le certificat “Fondation”.

Praxademia l’a développé, tant dans la forme que pour le contenu. La société l’a livré gracieusement au Praxeme Institute, garant du processus de qualification.

Voir la page “Le test d’auto-évaluation” sur le site web du Praxeme Institute.

Parallèlement, Praxademia travaille sur l’examen pour la certification. La première session se déroulera à la fin du cours “Compétences Praxeme“, programmé du 15 au 17 septembre 2015. Cette formation a été révisée pour :

  • injecter les nouveaux contenus de Praxeme (sur SOA, l’architecture technique, l’élaboration des business models, les nouveaux outils…) ;
  • préparer l’examen et assurer l’obtention du certificat.

 

 

 

 

En quoi la certification peut-elle aider à la transformation des entreprises ?

Si vous ne pensez pas que la situation économique justifie l’attention portée au thème de la transformation, ce billet n’est pas pour vous.

Si vous croyez qu’il suffira d’étiqueter “transformation” tout ce que nous avons l’habitude de faire (projets, stratégies, organisations, architectures…), sans rien changer à nos schémas de pensée, ce billet n’est pas pour vous.

Par rapport aux approches classiques, la transformation d’entreprise exige une approche véritablement interdisciplinaire. Elle doit mobiliser des compétences issues d’univers variés, habituellement assez étanches. Elle doit organiser la circulation entre les silos organisationnels et culturels.

Rien n’est moins naturel ! Dans nos organisations, tout conspire à briser ce bel élan. Les dirigeants le savent mieux que quiconque. Pour sauver la notion même de transformation, il nous faut des repères bien établis.

Les trouverons-nous dans les référentiels de pratiques habituels ? Non, pour une raison très simple : ces référentiels sont, toujours et sans exception, l’expression d’une communauté professionnelle (les architectes pour TOGAF, les analystes pour le BABoK, les managers pour d’autres référentiels, etc.). Ils abordent l’entreprise toujours à partir d’un point de vue particulier et n’en donnent qu’un aperçu incomplet. Par un mouvement naturel – et nécessaire -, chaque corporation sécrète sa propre doctrine. Ces référentiels restent tout à fait utiles et recommandables, mais leur usage reste confiné à une corporation professionnelle. Or, pour servir la transformation, nous sommes à la recherche d’un cadre qui puisse canaliser et ordonner les savoirs d’un vaste ensemble de spécialités. Il s’agit, au moins, de convoquer toutes les disciplines transformationnelles et de les mettre en ordre de marche.

La méthodologie de transformation d’entreprise a, précisément, la mission d’établir ces repères à partager entre tous les acteurs de la transformation. Elle propose un cadre commun qui embrasse toute l’entreprise, dans tous ses aspects. C’est à partir d’un tel cadre que les apports de chacun peuvent se positionner et s’articuler. Au sein d’un programme de transformation, la synergie ne peut s’instaurer que si chacun reconnaît les autres univers culturels et qu’il accepte d’aller vers eux.

Depuis longtemps, les entreprises et les DRH ont recouru aux certifications pour appuyer leurs transitions et leurs exigences en matière de pratiques professionnelles. En effet, la certification oblige à objectiver les compétences et à évaluer les capacités individuelles aussi rigoureusement que possible. Il en résulte une assurance quant aux capacités mobilisées dans l’entreprise et sur ses projets. Toutefois, la transformation d’entreprise change la donne. Parce que la clef de la transformation réside dans l’interdisciplinarité, les certifications développées autour d’un référentiel de pratiques, dans le cadre d’une corporation, ne suffisent pas.

C’est ainsi que l’on arrive à l’idée d’une certification bâtie sur la méthodologie de transformation d’entreprise. La difficulté à surmonter tient à l’étendue couverte par la méthode : on ne peut pas mettre, dans un même cerveau, toutes les connaissances relatives à l’entreprise et à sa transformation. L’équation se résout par le schéma de qualification montré ci-dessous. Il comporte un tronc commun qui sensibilise à l’approche holistique de l’entreprise et fournit les repères communs. Ceci correspond au niveau que l’on attend de tous les acteurs d’une transformation, du concepteur au décideur, du stratège à l’informaticien. Ce tronc commun permet de créer les conditions d’une approche collective. Pour autant, il ne faudrait pas négliger les compétences pointues : sur elles reposent l’acuité de la conception et la capacité à réellement innover. Ces compétences font l’objet de certificats spécialisés. Le critère de cette spécialisation n’est autre que l’aspect de l’entreprise. Ce choix va dans le sens indiqué plus haut : si nous avions retenu, comme critère, la fonction ou la discipline des acteurs de la transformation, nous serions retombés dans le réflexe corporatiste qui aurait contrarié la stimulation de l’interdisciplinarité.

L'architecture de la certification

L’architecture de la certification

Commencé en 2013 avec l’APMG International, le développement de la certification a abouti au certificat “Fondations”, le deuxième du tronc commun. L’examen est désormais disponible et proposé à l’issue de la formation “Compétences Praxeme”, sous le contrôle du Praxeme Institute.
La prochaine session se déroulera à Paris, du 15 au 17 septembre.

Plus de détails :

 

Nomination de Loïc Depecker à la Délégation générale de la langue française et des langues de France

Nous ne cessons de répéter que la langue est notre premier outil de modélisation du réel, et qu’en conséquence, nous devons la respecter comme le bon ouvrier affûte ses outils.

C’est donc tout naturellement que Praxademia a adhéré à la Société française de terminologie et qu’elle suit les travaux de son fondateur, Loïc Depecker. Celui-ci, professeur à la Sorbonne et auteurs de nombreux ouvrages, vient d’être nommé Délégué général à la langue française et aux langues de France (en Conseil des Ministres du 20 mai 2015).

Pour plus d’information :

 

Le Petit-Déj’SI® : première séance

Cet événement, qui s’est tenu le 19 mai, visait à réunir un petit cercle de décideurs informatiques, prêts à partager leurs préoccupations sur fond de méthodologie d’entreprise. Cette tentative a été couronnée de succès puisqu’elle a réuni 22 participants, des DSI et des directeurs de départements (études, urbanisation, qualité ou méthodes) venant de tous les horizons.

Le premier thème abordé est introduit dans la présentation commentée “Transformation d’entreprise : reprendre l’initiative“.

Le compte rendu des échanges est diffusé à l’intérieur de ce cercle.

En conclusion, les participants s’accordent pour renouveler l’expérience et décident de se retrouver, deux fois l’an. La prochaine séance portera sur le thème : “Comment promouvoir une démarche d’architecture d’entreprise ?”.

“Data : attention à la panne de sens”

Joël Bizingre, associé chez Conix Consulting, publie un post en relation directe avec le chantier PxData. Il exprime une philosophie que nous partageons : l’exploitation de la technologie des x-data (où x vaut “big”, “open”, “smart”, etc.) suppose toujours un effort de “sémantisation”. Pour le dire plus clairement, la donnée n’est utile que quand on retrouve sa signification.

En pratique, on ne peut pas faire l’économie d’un modèle sémantique. L’idée sera même d’anticiper la disponibilité des données et d’enrichir le modèle sémantique de l’entreprise pour pouvoir accueillir plus facilement les données, quand elles se présenteront.

Les entreprises peuvent facilement acquérir des données externes, pour une dépense modique. Cette dépense est tout de même un gaspillage si l’entreprise ne sait pas comment exploiter ces données. La solution passe par un modèle sémantique qui intègre les concepts manifestés par ces données et qui les relie aux objets connus de l’entreprise.

Voir “Data : attention à la panne de sens“.

Ce papier fixe la philosophie qui préside au chantier PxData. Il mentionne, d’ailleurs, deux des procédés disponibles. Le chantier, accompagné par Praxademia, débouchera sur une contribution du cabinet Conix Consulting à Praxeme.

Site web de Conix Consulting

Les six impasses de la conception de processus

L’importance d’une approche par les processus ne se discute plus. Pourtant, si on évalue les retombées des projets de modélisation des processus, on peut parfois se demander si les promesses en matière de productivité, de simplification ou d’innovation, ont été tenues.

Ce bref article examine les six impasses qui réduisent la portée de l’approche par les processus. Un deuxième partie introduit le procédé de conception des processus, proposé par Praxeme.

SOA en quatre messages

1. SOA est un style d’architecture de système informatique

Pour élaborer la structure d’un système informatique, nous recourons toujours à une métaphore : fonction, machine, ville, service, événement, agent… La plus traditionnelle et encore la plus ancrée dans les esprits est celle de l’architecture fonctionnelle, par laquelle nous percevons le système comme un ensemble de fonctions. Elle a montré ses limites puisqu’elle est associée à la décomposition hiérarchique et entraîne un fort taux de redondance. La métaphore la plus actuelle est celle du service, caractéristique de l’approche SOA (service oriented architecture). Elle agrège de nombreuses notions connexes telles que le contrat et l’encapsulation.

Aborder un système par le truchement d’une métaphore est un acte propre à l’architecture logique : la conception d’un système artificiel, dans une relative indépendance par rapport aux choix techniques.

Le premier message de Praxeme pour SOA est l’importance des disciplines d’architecture logique et de conception logique pour tirer parti de l’approche SOA.

Styles

2. Les promesses de SOA ne se concrétisent que quand on consent un effort de restructuration du système

On oppose ainsi :

  • SOA de surface, qui consiste à brancher quelques services sur un système auquel on ne touche pas ;
  • SOA de refonte, qui généralise la métaphore à l’ensemble du système et, progressivement, transforme celui-ci significativement.

Évidemment, si on applique la première approche (on pourrait dire : FOA, la fausse SOA), il ne faudra pas s’étonner que les retombées promises (réutilisation, simplification, interopérabilité, agilité…) n’auront pas été tenues.

FOA versus SOA

3. La mise en place d’une SOA prend son sens dans une stratégie d’urbanisation du système informatique

Cette conclusion découle de la précédente : la conversion d’un système en architecture de services est un processus patient, qui exige une continuité de vision et une grande constance sur le long terme. Tout à fait les caractéristiques de l’urbanisation.

Il convient donc d’articuler soigneusement les deux disciplines de l’urbanisation de SI et de l’architecture logique. Ceci réclame des dispositions pratiques, notamment en ce qui concerne les représentations du système mais aussi en termes d’organisation et de gouvernance SI.

POS versus Graphe d'architecture logique

4. La bonne volonté et l’intuition sont insuffisantes pour mener à bien la transformation d’un système informatique

Il y faut de la rigueur et des techniques précises, conçues pour affronter la complexité propre aux systèmes d’information. Se lancer dans de tels travaux sans méthode serait naïf et suicidaire. On observe encore trop souvent des équipes qui s’écharpent sur la notion de service, qui s’épuisent en vaines considérations sur la granularité ou la typologie des services, ou qui bricolent de prétendus méta-modèles. Aurait-on accepté un tel gaspillage dans les années 80 ? Non, pas au moment où les managers savaient imposer les méthodes à leurs équipes. Certes, cette attitude était facilitée par l’existence de méthodes de référence largement répandues et appuyées par la Puissance publique. Autre temps, autre mœurs !

Il existe néanmoins une réponse toute prête : Praxeme pour SOA, c’est-à-dire, dans la méthodologie de transformation des entreprises, la partie  dévolue à la conception des systèmes informatiques. Élaborée à partir de 2003 et mise au point sur de grands projets, elle a été appliquée de nombreuses fois et a été consolidée. Sa version 2 est diffusée à travers la formation “SOA, conception d’une architecture de services“. Elle sera publiée en fonction des opportunités (guide “Approche de l’aspect logique” et fiches de procédés).

Postionnement de l'aspect logique

Pour aller plus loin…

Ces quatre messages sont développés dans l’article “Quatre idées fortes de Praxeme pour SOA“.

Formaliser la connaissance du métier

Terminologie, ontologie, sémantique

Quoi que l’on fasse – transformation, innovation, automatisation… -, le point de départ est toujours le même : la connaissance du métier. Non seulement nous devons posséder cette connaissance, mais aussi elle doit se présenter sous une forme telle qu’elle satisfasse à plusieurs critères. Elle doit être :

  • complète, pour éviter les surprises en cours de route,
  • sans ambiguïté, pour empêcher les conflits d’interprétation,
  • précise, pour appuyer une conception pertinente,
  • fidèle, conforme à la réalité,
  • économique, c’est-à-dire exprimée sans redondance, avec le minimum de termes pour dire le maximum de choses,
  • ouverte, affranchie des présupposés qui pourraient réduire sa portée.

Cette qualité d’expression ne se donne pas d’emblée. On ne l’obtient que par de grands efforts et une volonté constante. Elle ne se trouve ni du côté du “métier”, ni du côté de l’informatique. En effet, force est de constater qu’elle n’est pas immédiatement disponible dans l’entreprise. Il suffit de réunir deux experts du métier et de les faire travailler sur des définitions, pour s’apercevoir que les pratiques reposent sur beaucoup de non-dit et que la verbalisation fait voler en éclat l’apparent consensus.

Pour obtenir une bonne expression de la connaissance, nous disposons de plusieurs techniques : la terminologie, les ontologies, la modélisation sémantique. Chacune présente des avantages et des limites. Comment les utiliser ? Peut-on les articuler ? Quel niveau d’exigence viser, selon l’objectif que l’on se donne ?

Voilà quelques-unes des questions abordées dans l’article “Formuler la connaissance“, publié sur le wiki du Praxeme Institute.

Version anglaise : “Formulating Knowledge“.

 

 

Publication d’un article sur le référentiel de description de l’entreprise

Le référentiel de description de l’entreprise

Un dispositif central pour asseoir une approche rationnelle de la transformation d’entreprise

La notion de « référentiel de description de l’entreprise » (RDE) est centrale dans la méthode Praxeme. Elle traduit la volonté de tout dire de l’entreprise et d’encourager une approche interdisciplinaire de la transformation. On se doute que la mise en œuvre de ce concept, pourtant simple, rencontre de nombreux obstacles. Un moyen de les surmonter réside dans les architectures et modèles génériques, aujourd’hui à notre disposition.

 

La livraison n°99 de la Lettre de l’Adeli publie un article demandé à Dominique Vauquier. Cet article présente la notion de référentiel de description, son importance dans la transformation de l’entreprise, puis les modèles génériques qui permettent de construire rapidement ce référentiel et de mettre les projets sur les bons rails.

Article “Le référentiel de description de l’entreprise”

Complexité du système informatique : l’apport de l’architecture logique

Cet article cherche à montrer comment l’architecture logique, en tant que discipline, contribue à la maîtrise des systèmes informatiques. Après quelques rappels sur les règles de cette discipline, il calcule l’impact de ces règles sur la complexité.

Les règles de l’architecture logique

L’architecture logique, en tant que produit, est la structure du système informatique (plus généralement : du système technique), sans le détail des dispositifs techniques. Puisque son objet est un système artificiel, nous pouvons imposer, à cette architecture, des règles structurelles ou contraintes topologiques, dans le but de mieux maîtriser le système. Les plus largement admises sont les suivantes :

  • Prohibition des relations mutuelles : entre deux constituants, il ne peut exister qu’une dépendance, au plus (autrement formulé : les relations entre les constituants sont unidirectionnelles).
  • Stratification (ou architecture en couches) : le système se compose de plusieurs couches ; la communication entre les couches est polarisée. Plus précisément, dans l’approche préconisée par Praxeme, l’architecture logique comprend : une strate « Fondation » qui dérive de l’aspect sémantique (les objets « métier »), une strate « Activation » qui dérive de l’aspect pragmatique (les activités « métier ») et une strate « Interaction », abstraction des composants d’interaction (IHM et communication avec d’autres systèmes). Les seules communications autorisées entre strates vont des constituants de la strate « Interaction » vers ceux de la strate « Activation » et de ces derniers vers la strate « Fondation ». Toutes les autres communications sont prohibées.
  • Prohibition des relations latérales dans la strate « Activation » : les blocs correspondant aux domaines fonctionnels n’entretiennent pas de relations ; ils s’échangent de l’information uniquement à travers la strate « Fondation », le noyau du système. Cette règle résulte de l’importance accordée aux référentiels d’objets dans l’architecture. Ceux-ci, traduisant les domaines d’objets trouvés dans l’aspect sémantique, sont placés dans la strate « Fondation ».
  • Règle de médiatisation : un composant d’interaction échange avec un et un seul composant d’activation principal. Il peut solliciter aussi les services de composants utilitaires ou généraux. Pour un composant d’activation, on peut avoir plusieurs composants d’interaction, un par type de technologie de dialogue.

Cette architecture tolère quelques – rares – dérogations, notamment en ce qui concerne les services utilitaires qui, par construction, doivent avoir une position « transverse ». Mais ces dérogations sont marginales et ne changent pas le raisonnement qui suit, pour le calcul de la complexité.

L’impact sur la complexité du système

Il est facile de montrer comment ces règles d’architecture logique réduisent considérablement la complication du système.

Soit n le nombre d’éléments d’un système. Le nombre maximum de dépendances que l’on peut instaurer entre ces éléments est n².

La prohibition des relations mutuelles réduit ce nombre de moitié.

Le principe de stratification va plus loin. Soient nf, na, ni, les nombres d’éléments de chacune des strates. On a : n = nf + na + ni.

À partir de là, il reste à calculer le nombre maximal de dépendances, autorisé par les contraintes topologiques.

Dans la strate « Fondation », le nombre de dépendances possibles est nf²/2. Les constituants de cette strate ne communiquent pas vers les autres strates.

Dans la strate « Activation », les constituants n’échangent pas entre eux mais « orchestrent » les services de la strate « Fondation ». Au maximum (si chaque constituant d’activation appelle tous les constituants de fondation), le nombre de dépendances est donc : nf. na.

Enfin, les constituants d’interaction ne sont liés qu’à un constituant d’activation. Ceci conduit à ajouter uniquement ni dépendances.

Le raisonnement laisse de côté quelques détails (dérogations, services utilitaires) qui ne changent pas fondamentalement le résultat.

Le simple respect des règles d’architecture logique abaisse donc le nombre de dépendances d’un système de

(nf + na + ni) ²

à

(nf²/2 + nf. na + ni).

La différence est considérable. Si on se place dans le contexte d’un système SOA (service oriented architecture), le nombre de constituants en jeu est de l’ordre de la centaine ou du millier. Pour donner une idée, imaginons un système plutôt simple où nf = na = ni = 100. Sans appliquer les contraintes topologiques, le nombre de dépendances permises est : 90.000. En appliquant les règles, ce nombre tombe à 1.600. Encore n’est-ce là que la valeur maximale autorisée. En réalité, les décisions d’architecture logique vont encore diminuer ce nombre. Par exemple, le « principe de confiance » peut entraîner une réduction de moitié du nombre de dépendances dans la strate « Fondation », en amenant en plus à augmenter l’autonomie des constituants.

La mesure du nombre de dépendances n’est sans doute pas une mesure directe de la complexité mais elle en donne une idée. Elle révèle surtout le couplage, lequel est un des facteurs évidents de la complexité des systèmes artificiels. Notre propos, ici, n’est pas d’élaborer une mesure de la complexité (voir, par exemple, l’article coécrit par Yves Caseau, Daniel Krob et Sylvain Peyronnet), mais de faire sentir l’enjeu d’une vraie pratique d’architecture logique.

Le rôle de l’architecture logique

Ce raisonnement peut paraître théorique. Il ne l’est pas quand l’architecture logique peut réellement s’exercer, et que l’effort de conception permet de reprendre en main le système. Dans les autres cas, on pourrait se dire que la situation n’est pas si critique, que les quelques dizaines d’applications ne peuvent engendrer de tels niveaux de complexité et que le nombre de connexions observées dans le système existant (disons quelques centaines) reste bien inférieur aux nombres évoqués ci-dessus, donc qu’il n’y a pas péril en la demeure. Soyons clairs : c’est faux ! Dans un système constitué d’applications monolithiques, la complexité est cachée. Ce n’est pas parce qu’elle ne se révèle pas à travers les dépendances visibles qu’elle n’existe pas. Dans ces systèmes, la non-application du principe de stratification entraîne une redondance énorme. Cette redondance est une source de complication et un risque effroyable. Elle finit par paralyser les évolutions de nos systèmes, et mobilise des ressources considérables pour une valeur faible.