DVau

Georges Garibian, inventeur de l’Arbre de Performance, a versé sa méthode au fonds public Praxeme.

Comment cette approche rigoureuse de la performance s’intègre à la méthodologie d’entreprise ?

Ce sera le thème principal du Symposium 2011, organisé par l’association Praxeme Institute, le 14 décembre, à Paris, dans les locaux du groupe AXA

Interventions de Georges Garibian, Fabien Villard, Dominique Vauquier.

Pour consulter le programme et pour s’inscrire : voir site du Praxeme Institute.

Entrée gratuite, sous réserve d’inscription (les inscriptions sont ouvertes jusqu’au 9 décembre à 17h).

La matinée, réservée aux adhérents, sera consacrée à l’assemblée générale et permettra de faire le point sur les chantiers et les discussions en cours :

• Open Business Concepts,
• méta-modèle,
• outillage,
• terminologie,
• processus,
• Enterprise Architecture et Business Architecture,
• etc.

Ce post répond à une question souvent posée : y a-t-il un processus de développement dans Praxeme ?

Le parti pris de Praxeme est de se focaliser, d’abord, sur le “produit” (l’application, le système, l’entreprise…) plutôt que sur la “production” (le processus de développement, de transformation…).
Ceci s’explique par des raisons logiques autant que tactiques :

• d’une part, il nous paraît nécessaire de savoir ce que l’on fabrique (le “quoi”) avant de décider comment on le fabrique ;
• d’autre part, sans nier l’importance du processus dans la méthodologie, nous constatons que la réflexion méthodologique de ces deux dernières décennies s’est concentrée sur le processus au détriment du produit (RUP, 2TUP,  Scrum mais aussi ISO, ITIL, CMMI, etc. : on ne parle plus que processus jamais que la qualité de ce que l’on produit). Même les référentiels d’architecture (TOGAF, DMBoK…) nous parlent plus de l’activité de leurs affidés que de l’objet de leurs soins. A cela, il y a plusieurs raisons, à rechercher dans notre culture et dans les déterminations sociologiques (que je n’analyserai pas ici).

C’est, en tout cas, pourquoi Praxeme met l’accent sur les techniques de modélisation plutôt que sur les processus de développement. Pour faire référence à Merise, Praxeme se situe donc plus sur l’approche que sur la démarche. Nous concentrons nos faibles moyens sur cette dimension que nous trouvons plutôt négligée ailleurs. Quels sont les modèles dont nous avons besoin ? Qu’est-ce qu’un bon modèle ? Comment passer d’un niveau de représentation à un autre ? Quelles décisions devons-nous prendre en tant que modélisateurs ou aider à prendre par les responsables de l’entreprise ? Voilà quelques-unes des questions qui nous occupent.

Nous avons pourtant des principes qui permettraient de revisiter les processus. Il s’agirait d’appliquer aux projets et programmes le procédé de conception des processus “métier” proposé par Praxeme (voir le “Guide de l’aspect pragmatique”, réf. PxM-20). Un des principaux contributeurs de l’initiative pour une méthode publique avait, d’ailleurs, engager un budget significatif pour un processus de développement, fondé sur ces principes, et qui aurait enrichi le fonds public Praxeme. Malheureusement, ce budget a été détourné par un prestataire qui a pensé que son intérêt était de pousser sa méthode propriétaire, que personne ne connaît, bien sûr. Ce projet a débouché sur un double scandale :

• scandale ordinaire de ces prestataires qui ont détourné le beau nom de “conseil” et qui se contentent d’écumer le marché à la recherche de leurs proies ;
• scandale de ces investissements du secteur public qui débouchent sur des méthodes propriétaires qui dorment au fond des tiroirs.

Nous publierons, un jour, les règles pour bâtir un processus de développement de un processus de transformation, dans l’esprit de Praxeme. Le document existe ; il faut le mettre en forme. Des éléments le complètent comme :

• cycle Pro2 (Produit X Production), comme principe de définition des processus (on le trouve illustré, par exemple, dans la formation Praxeme pour SOA) ;
• les deux portées (projet versus entreprise) ;
• la “dynamique globale”, au niveau de l’entreprise.

Mais tout cela demande un travail de mise en forme et ne sera réalisé que sur opportunité.

Un document de définition de la Business Architecture : “Business Architecture Value Proposal”, histoire de positionner cette discipline avant qu’elle subisse le même sort que l’Enterprise Architecture…
Voir : http://www.praxeme.org/index.php?n=Modus.BusinessArchitecture

La traduction anglaise du Guide de l’aspect sémantique :
http://www.praxeme.org/index.php?n=Modus.Product-SemanticAspectGuide?userlang=en

Dans le cadre de la conférence Marcus Evans sur l’urbanisation de SI et l’architecture d’entreprise (16-18 mars 2011) :

“Mise en oeuvre de l’architecture d’entreprise : méthodologie d’entreprise et illustrations”

L’objectif : “Comprendre les facteurs clés de succès d’un projet d’architecture d’entreprise”.

Un mélange de tactique et de vision !

La présentation commentée est disponible sur le site du Praxeme Institute.

Voir aussi les présentations de Fabien VILLARD (“Les disciplines de la transformation“) et Philippe DESFRAY (“Genèse de l’urbanisation et de l’EA“).

Notre initiative pour une méthode publique repose sur les principes d’ouverture et de partage.
Fonder un tel effort sur ce type de morale peut paraître bien naïf, particulièrement dans ce domaine. Pourtant, cela fonctionne dans des cas comme Wikipedia ou les logiciels open source. Il y faut tout de même une condition : la surface. L’échelle mondiale ou américaine (ce qui revient un peu au même) est une condition sine qua non pour disposer des ressources nécessaires et enclencher un mouvement qui comporte sa propre régulation. Sans cette régulation, pas de morale. Sans morale, pas de confiance et, donc, pas de dynamique positive.
Nous ne jouissons sans doute pas d’une telle ampleur. Qui plus est, le marché français, déjà petit par nature, se ratatine encore par l’étroitesse de vue de ses acteurs, leur méfiance innée, le repli sur soi et l’incurie des pouvoirs.

Pas vraiment les conditions propices pour un grand mouvement généreux et créatif !

Fabien VILLARD, dans un post récent, rappelle les bases de la bonne conduite. Quand elles sont bafouées, non seulement l’initiative s’épuise mais les acteurs qui profitent ou pourraient profiter de Praxeme scient la branche sur laquelle ils s’assoient.

Nous voudrions humblement les rappeler à une plus grande lucidité stratégique.

Depuis plusieurs décennies, le framework de Zachman est régulièrement cité (sans doute plus cité qu’utilisé en pratique). Pourtant, si l’on résiste à la séduction qu’exerce son approche matricielle, qu’en est-il vraiment ?

Les notes qui suivent fixent l’exposé qui a été donné lors du Symposium 2010 du Praxeme Institute.

Colonnes « data-functions »

Si les questions “What” et “How” s’imposent d’elles-mêmes, la façon d’y répondre ne va pas de soi. Zachman utilise le couple data-functions, ce qui est une réponse d’informaticien qui nous renvoie aux méthodes des années 80 et à la séparation données-traitements.

Deux arguments s’opposent à cette approche :

1. D’une part, répondre en termes informatiques  à un problème qui est celui de la représentation de l’entreprise n’est sans doute pas la bonne attitude. Toute l’ambiguïté actuelle de l’architecture d’entreprise réside dans cette attitude.
2. D’autre part, même en informatique, cette séparation a été dépassée, par exemple dans l’approche orientée objet.

Une conséquence apparaît déjà dans le tableau. Le modèle sémantique y est mentionné, mais dans la colonne « Data », ce qui le réduit à n’être qu’un modèle de données (ce qu’il est le plus souvent puisque l’appellation “sémantique” est utilisée à tort et à travers). La modélisation sémantique se voit ainsi mutilée : alors qu’elle a vocation a exprimer formellement la connaissance métier, elle est située ici comme une technique de modélisation des données, seulement.

Ligne « Detailed representations »

La description détaillée ne saurait être présentée comme une dimension à part (comme le sont le contexte, le conceptuel, etc.).

Ce que nous attendons d’un framework méthodologique, c’est une identification des objets à analyser. Le framework est une grille de lecture que nous plaquons sur notre objet d’étude : l’entreprise. Il doit donc désigner les éléments de ce système, selon leur nature. Ces éléments peuvent ensuite être identifiés, définis, décrits… progressivement. Le niveau de détail d’une description ne change pas la nature des objets à décrire. Traiter le détail comme une dimension séparée, c’est encourager le refoulement, la paresse qui font que, de plus en plus, on se contente d’une vue « simplifiée »… et que nous voyons de moins en moins de modèles. Nous préférons, au contraire, un effet de zoom : chaque aspect identifié selon sa nature est appréhendé progressivement.

La colonne « Where »

La case « contextuel » de cette colonne correspond assez bien à ce que nous nommons l’aspect géographique, dans Praxeme. Curieusement, le « conceptuel » et le « business Logistics system » mélangent le géographique et le matériel, alors que ces notions supposent des décisions différentes (en nature et en responsabilité). De plus, l’association des termes « conceptuel » et « géographique » (location) soulève la perplexité.

La colonne « Who »

Ici nous rencontrons un problème de forme : la notion d’unité organisationnelle se retrouve dans deux endroits différents du framework (scope et business model). On n’a aucun mal à anticiper les conséquences pratiques d’une telle situation…

De plus, la notion de rôle apparaît dans cette colonne, sur le niveau logique. Comment la relier à celle de processus « métier », logée dans la colonne « How » de la ligne « business model » ? Le rôle est une notion clef de la conception organisationnelle, au même titre que l’unité organisationnelle. On se demande pourquoi elle a glissé dans la conception informatique, à côté de la notion d’interface.

La colonne « When »

Comment peut-on isoler le temps ? C’est toujours la temporalité de quelque chose. Réciproquement, toute chose est dans la temporalité et montre un comportement dans le temps. Un des défis de la modélisation est justement de bien appréhender cette dimension et d’en donner une expression juste et économique.

Dans la Topologie du Système Entreprise, la question « quand ? » ne débouche pas sur un aspect à part : elle est mêlée à la nature des objets, dans tous les aspects retenus. L’objet « métier » de l’aspect sémantique a un comportement dans le temps : son cycle de vie, au minimum. Avec les processus (aspect pragmatique), le temps est évident (succession, parallélisme, synchronisation, événement, délai…). Tous les aspects embarquent la dimension temporelle, jusqu’au physique et le souci des performances.

On voit qu’il est impossible de détacher cette question. Un modèle limité au temps n’aurait aucune utilité. En revanche, dans chaque modèle (sémantique, organisation, informatique, infrastructure…), les considérations temporelles sont indispensables et la méthode doit les prescrire vigoureusement.

NB : ce n’est pas seulement de la modélisation des éléments qu’il s’agit, mais aussi de l’évolution anticipée des populations de ces éléments.

La colonne « Why »

Cette question est essentielle ; elle doit même précéder toutes les autres. La nuance entre Goal et Objective est toujours aussi subtile (en tout cas, pour un Français). Il faut pourtant qu’elle soit claire dès lors que l’on sépare ces notions dans deux cases du framework.

La réponse au « Pourquoi ? » en termes de règles sur les niveaux techniques est curieuse. Puisque l’on a la stratégie au niveau « scope », pourquoi n’aurions-nous pas la stratégie informatique aux niveaux inférieurs ?

Le framework comme un tout

Pris globalement, le framework de Zachman – du moins cette image – ne répond pas aux questions suivantes :

• Comment les choses se relient entre elles ? (Besoin essentiel en pratique)
• De quels modèles avons-nous besoin ? (Certainement pas les 30 artefacts déduits du framework)
• Pour une chose donnée, il doit y avoir une et une seule place dans le framework, sinon celui-ci faillit à sa vocation qui est de mettre de l’ordre. Où ranger les notions de cas d’utilisation, de business capability, de cycle de vie des objets ou même de business objects, notamment ?

Pour une spécification des propriétés attendues d’un framework méthodologique, voir : Content Framework.

• de passer par un examen critique de leur limites et impact sur la société et l’environnement (pas toujours positif, il faut le reconnaître) ;
• de se garder de l’idéalisme et de l’espèce d’angélisme qui nous masquent une partie essentielle de la réalité (particulièrement évident dans le cas des systèmes organisationnels, quand nos outils – modèles, “méta-règles”… – laissent échapper toute l’épaisseur sociale de la réalité).

Quelques précisions sur Praxeme

• La Topologie du Système Entreprise a germé de l’application du questionnaire du Quintilien, complété par un jeu sur le Quoi/Comment qui ordonne Système Entreprise, Système d’Information ou de production, Système informatique, comme des poupées russes. Le schéma actuel est une simplification de ce résultat (un petit coup de rasoir d’Occam par-ci par-là). Pour le reste, il faut reconnaître que la justification est plus empirique que scientifique. C’est justement un défaut que je voudrais corriger, même si je dois être le seul à le vouloir !
• L’expression “Système Entreprise” a finalement été retenue parmi d’autres, comme “système d’action”, avec la précaution suivante : elle ne désigne pas seulement l’entreprise au sens de société, mais tout système organisé en vue d’une fin. Il y a eu des applications de Praxeme par exemple chez Thales, dans l’ingénierie amont, ou pour la DGA en partenariat avec Sagem et Dassault. Le framework méthodologique s’applique bien aussi à des systèmes d’armement, à des systèmes de systèmes et, après avoir écouté l’un des intervenants mardi, j’entrevois comment l’appliquer à des systèmes produits.
• C’est sûr que dans mon contexte professionnel et celui de la plupart des Praxemiens, ce n’est pas le chemin qu’il nous est demandé de prendre (nous passons déjà pour des théoriciens, de doux idéalistes ou d’affreux révolutionnaires). En revanche, je crois qu’il nous faut nous organiser comme Pythagore – ou du moins comme la secte pythagoricienne -, en séparant un contenu ésotérique et une communication exotérique. Même si la méthode publique doit être à la portée du plus grand nombre, par définition, elle doit aussi être fondée sur un socle solide et indiscutable. C’est ce que j’attends de notre coopération avec les milieux scientifiques. Cet effort ne servira pas seulement à améliorer la méthode et à garantir les pratiques ; il renforcera aussi le rôle de la méthode publique comme vecteur pour apporter vers l’entreprise les savoirs académiques.
• La correspondance entre les aspects du Système Entreprise et le Pourquoi/Quoi/Comment de CESAMES s’établit très facilement. Il faut y regarder de plus près, bien sûr. En dernier ressort, cela se joue sur le méta-modèle.

Quelques remarques tirées d’échanges sur Praxeme :

La Topologie du Système Entreprise a germé de l’application du questionnaire du Quintilien, complétée par un jeu sur le Quoi/Comment qui ordonne :

Système Entreprise

>  Système d’Information ou de production

>> Système informatique,

comme des poupées russes (cf. annexe du Guide général, PxM-02).

Le schéma actuel est une simplification de ce résultat (un petit coup de rasoir d’Ockham, par-ci par-là).

Pour le reste, il faut reconnaître que la justification est plus empirique que scientifique.

Extrait du Guide général, PxM-02

L’expression “Système Entreprise” a finalement été retenue parmi d’autres, comme “système d’action”, avec la précaution suivante : elle ne désigne pas seulement l’entreprise au sens de société, mais tout système organisé en vue d’une fin. Il y a eu des applications de Praxeme par exemple chez Thales, dans l’ingénierie amont, ou pour la DGA en partenariat avec Sagem et Dassault. Le framework méthodologique s’applique bien aussi à des systèmes d’armement, à des systèmes de systèmes et j’entrevois comment l’appliquer à des “systèmes produits”.

Correspondances avec d’autres frameworks méthodologiques

Sur la liste des adhérents du Praxeme Institute ainsi qu’au sein du groupe AXA dans le cadre de la Group Target Architecture, une discussion est en cours pour confronter la Topologie du Système Entreprise avec d’autres frameworks méthodologiques.

CESAMES

Par exemple, CESAMES structure l’approche des systèmes en trois niveaux : Pourquoi, Quoi et Comment. La correspondance avec les aspects du Système Entreprise s’établit très facilement :

• Le “pourquoi” est pris en charge par l’aspect politique, notamment sous la forme des objectifs. Il irrigue ensuite tous les autres aspects auxquels il fournit les orientations et justifications nécessaires.
• Le “quoi” s’applique récursivement. Tout d’abord, il isole le “métier” par opposition aux équipements qui répondent au “comment” (dont le système informatique). Ensuite, au sein de la description du métier, le “quoi” permet de séparer les fondamentaux, par opposition aux façons de faire, respectivement : l’aspect sémantique et l’aspect pragmatique.
• Le “comment” apparaît du côté du métier, sous la forme des processus et de tout le contenu de l’aspect pragmatique, mais aussi sous la forme de l’aspect géographique (plus exactement : le “Où”).
• Quand on reprend le métier sous la catégorie du “Quoi”, le “Comment” renvoie à ses équipements. Le système informatique en fait partie. On peut le voir comme une des réponses au comment du métier. Maintenant, en ouvrant cette boîte du système informatique, nous reposons les questions “Quoi” et “Comment”. L’aspect logique répond au “Quoi” : que doit contenir le système ? quels services doit-il rendre ? quelle est sa structure optimale ? L’architecture technique se charge du “Comment”. Elle le fait selon plusieurs formes : à travers des dispositifs techniques, mais aussi sous la forme des modes de développement.

Pour établir la correspondance entre l’approche de CESAMES et Praxeme, il faut certainement y regarder de plus près. En dernier ressort, ces correspondances se jouent et s’expriment à travers le méta-modèle.

TOGAF et EA

Le travail de mise en correspondance est en cours.

Critères attendus d’un framework méthodologique

• Un framework méthodologique ne doit pas seulement être vu, statiquement, comme un schéma identifiant des catégories. Il faut aussi qu’il fonctionne dynamiquement. A cette fin, on n’insistera jamais assez sur l’articulation des éléments identifiés. De nos jours, cette caractéristique revêt une importance pratique et économique, grâce à l’approche MDA (model driven architecture).
• Autre exigence : tout framework se doit de reposer sur un fondement. Ce fondement lui est donné par un méta -modèle, exposé raisonné des catégories de représentation retenues.
• Nous ajouterons le périmètre : il nous semble essentiel que le framework embrasse tous les aspects de l’entreprise. Ce n’est qu’à ce prix qu’il nous aide à mettre en ordre de marche les compétences diverses.

Parmi les qualités recherchées, le framework doit se montrer à la fois économique (rasoir d’Ockham) et efficace :

• économique en ce sens que l’on ne retiendra que les catégories absolument nécessaires (principe du rasoir d’Ockham) ;
• efficace car il doit faciliter l’action à travers ses conséquences pratiques telles la distribution des tâches, la gestion des compétences, la conception de l’outillage, etc.

On le comprend : un framework méthodologique est autre qu’une diapositive bien coloriée. On peut le définir comme une méta-architecture. D’une architecture, il doit présenter toutes les qualités de rigueur et d’anticipation. “Méta-architecture” parce qu’il nous parle de notre propre pensée et de la structure des moyens intellectuels que nous mobilisons pour la transformation des entreprises.

Les définitions de l’architecture d’entreprise, comme les descriptions du poste d’architecte d’entreprise, n’évitent pas l’ambiguïté propre à cette discipline :

théoriquement embrassant tous les aspects de l’entreprise, son côté technologique reste prépondérant, à la fois dans les activités réelles et dans les profils des architectes.

Le plus souvent, on est obligé de constater que, à bien y regarder, l’architecte d’entreprise n’est rien d’autre qu’un architecte informatique.

Encore une illustration du phénomène de l’érosion langagière ? Sans aucun doute. Avec la conséquence déplorable de galvauder une expression qui devait désigner une discipline nouvelle. Cette conséquence est d’autant plus dommageable que les entreprises ont un réel besoin de cette discipline, sans vraiment le reconnaître.

Ma philosophie de l’architecture d’entreprise est exposée dans l’Enterprise Transformation Manifesto.

Conformément à cette approche, l’architecte d’entreprise n’est pas le spécialiste de tel ou tel aspect, mais il est celui qui va embrasser la totalité des aspects de l’entreprise, de la stratégie au déploiement. Ce rôle de médiateur et de passeur est indispensable pour articuler toutes les expertises et les mettre en synergie.

Donc, l’architecte d’entreprise n’est pas un “technologue”, du moins pas plus qu’il n’est sociologue, organisateur, stratège, sémanticien… On ne peut pas lui demander d’être expert dans tous ces domaines, mais d’en connaître suffisamment pour pouvoir exploiter les spécialités et les canaliser dans le projet de transformation.

Cette conception de l’architecture d’entreprise est minoritaire et sera jugée utopique. Même si, en apparence, beaucoup de déclarations vont dans ce sens, il n’est que qu’observer les pratiques ou d’analyser les forums de discussion pour s’apercevoir qu’il y a loin de la coupe aux lèvres. Il est significatif, d’ailleurs, que la fonction d’Enterprise Architecture est presque toujours rattachée à la direction informatique (alors que la Business Architecture peut se trouver rattachée à la direction générale).

(Ce sujet sera développé dans la conférence Enterprise Architecture Management, en novembre à Berlin)

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.