Archive for the 'fondements' Category

Aspects et vues

Add a comment
La Topologie du Système Entreprise, le cadre de référence proposé par Praxeme, identifie des aspects. Cette notion a souvent soulevé des questions ou a été confondue avec celle de vue. Le terme “vue” est le plus utilisé dans la littérature méthodologique des deux dernières décennies. Ce billet précise les deux notions et justifie le maintien du terme “aspect” aux fondements de la méthodologie d’entreprise.

Vue

Sources : « vue » et « point de vue » dans IEEE Std 1471-2000. Cigref et Club Urba.
Une vue suppose un acteur qui regarde. Elle donne accès à une partie de la réalité observée, à partir du point de vue de cet acteur. Elle exprime donc la subjectivité : la situation du sujet face au réel. Son avantage réside dans la communication puisque, justement, elle s’établit par rapport aux besoins et au langage d’un certain type d’acteur.

Niveau

La méthodologie, notamment avec Merise, a longtemps parlé en termes de niveaux d’abstraction ou niveaux de préoccupation. Ces niveaux étaient clairement distincts des vues, lesquelles étaient également définies, à la même époque et dans les mêmes méthodes. Alors, les niveaux étaient donnés comme plus fondamentaux, plus essentiels que les vues. Ces méthodes définissaient d’abord les niveaux comme exprimant la structuration interne du système. Les vues étaient ainsi définies secondairement dans leur rapport aux acteurs et pour des besoins de communication. Par exemple, Merise distinguait les « vues externes » du modèle de données : celui-ci donne la structure de données complète et normalisée, tandis que celles-là en présentent un extrait, éventuellement dénormalisé, pour un certain usage.
Le terme « niveau », néanmoins, était malheureux dans la mesure où il infère une certaine idée de hiérarchie donc de valeur.

Aspect

Il est évident, en tout cas, que nous avons besoin de deux notions. Quand nous regardons un cube, par exemple, nous n’en voyons jamais toutes les faces. Nous pouvons nous en former plusieurs représentations, en prendre plusieurs vues et il nous faudra tourner autour de l’objet pour en percevoir toutes les faces.
Quand nous cherchons à nous représenter complètement le cube et à articuler les vues, il est bon de savoir que cet objet possède six faces, même si cette idée ne nous est pas donnée par l’expérience mais par l’entendement. La géométrie vient avant le dessin.
Le cadre de référence au fondement de Praxeme vise l’organisation interne du Système Entreprise, indépendamment de qui l’observe. C’est un préalable pour maîtriser la masse des connaissances, des informations et des décisions qui portent sur cet objet complexe. Nous cherchons à en dégager la logique interne, en préalable à tout développement méthodologique et bien avant de traiter les questions impliquant les acteurs : responsabilité, organisation de la transformation, communication, etc. Ce faisant, Praxeme s’inscrit dans la filiation de Merise par opposition aux méthodes anglo-saxonnes qui, au fil des décennies, n’ont retenu que la notion de vue et se sont focalisées sur la communication au détriment de la logique interne du système.
Pour qualifier ces domaines structurant la réalité de l’entreprise, indépendamment de l’observateur, Praxeme a retenu le terme « aspect ».

Illustration de la différence entre aspect et vue

Cette distinction, essentielle pour la théorie de la connaissance, se révèle dans l’usage des deux termes et dans les qualificatifs qui les accompagnent. Nous l’illustrons, dans ce paragraphe, à propos de l’aspect intentionnel tel qu’il est défini dans la Topologie du Système Entreprise. Cet aspect, le premier dans l’ordre des déterminations, rassemble toutes les expressions de la volonté de l’entreprise : ses valeurs, ses objectifs, les exigences, les indicateurs (souvent intimement associés aux objectifs), son vocabulaire.
Praxeme n’impose pas de structuration de cet aspect. La méthode se contente de distinguer les types d’éléments d’intention, laissant la possibilité de structurer cet aspect comme on l’entend. Il y a donc une décision d’architecture à prendre aussi pour l’aspect intentionnel :

  • soit on le structure par les sources (les émetteurs ou les documents d’origine qui comportent souvent des éléments de plusieurs natures),
  • soit on opte pour un critère propre, avec une notion de domaine comme pour n’importe quel autre aspect.

Ainsi, l’aspect intentionnel possède sa propre structure et obéit à ses propres lois qui ne reflètent pas nécessairement les usages. Dès lors, il devient intéressant de définir des vues qui faciliteront la communication avec des acteurs de profils précis, par exemple :

  • une vue éthique, centrée sur les valeurs de l’entreprise et comportant également leurs impacts sur les autres aspects du Système Entreprise ;
  • une vue métrologique, composée des indicateurs, de leurs liens avec les objectifs de transformation et, aussi, de leur projection vers les concepts métier, les activités ou tout autre type d’élément dans les autres aspects ;
  • une vue terminologique, exprimée par le thesaurus de l’entreprise et montrant, outre les termes, les liens de traçabilité qui les relient à d’autres éléments.

Ces sous-produits que sont les vues répondent à des besoins de communication et de manipulation ; elles sont donc associées à des utilisations. La méthode doit satisfaire ces besoins sans altérer la logique de structuration interne du Système Entreprise. C’est ce qu’elle obtient en distinguant les deux notions d’aspect et de vue.

Continue reading ‘Aspects et vuesrgb’

Un modèle de données n’est pas un modèle sémantique

Add a comment

On change plus facilement  les appellations que les pratiques. Aujourd’hui, il est de bon ton d’insister sur les objets métier. C’est une très bonne chose… à condition d’en faire des modèles qui ne soient pas que des modèles de données “à l’ancienne”. Je réponds ci-dessous à une question qui m’a été posée sur ce que change l’utilisation d’UML par rapport à Merise.

Qu’est-ce qui fait, fondamentalement, que les entités de Merise sont distinctes de ce que l’on nomme “objets métier” ? En dehors de la notion d’héritage (et donc de spécialisation dans UML), qu’est-ce qui fait, dans le formalisme et dans les principes, qu’UML est plus adapté que Merise pour représenter les objets métier ? Est-ce-qu’en pratique, ce sont les notions d’agrégation et de composition qui changent tout ?

Tout d’abord, Merise – méthode de conception informatique – ne nous enseigne pas à représenter la connaissance métier mais impose, dès l’abord,  la séparation données-traitements. Le MCD est un modèle de données : c’est dire qu’il ne peut pas représenter toute la connaissance des fondamentaux du métier. Conséquence pratique : certaines informations ne peuvent pas être inscrites sur le modèle, sous prétexte qu’elles sont calculées (ex. l’âge de la personne alors que l’on a la date de naissance). C’est tout à fait justifié pour un modèle de données, ça ne l’est pas pour un modèle sémantique. Du point de vue de l’acteur métier, ces distinctions entre données brutes et données calculées n’ont pas cours : il voit des informations qui font partie du concept.

Plus important encore : la sémantique d’un concept ou d’un objet métier ne s’arrête pas aux propriétés informatives : elle comporte également des propriétés actives (ce que l’objet peut “faire”) et des propriétés transformatives (comment il se comporte ?). Si nous voulons exprimer toute la sémantique, nous devons associer à l’objet métier : les opérations et leurs conditions d’emploi, les contraintes (règles métier), les états (cycles de vie)… bref tout ce qui complique dangereusement nos solutions informatiques faute d’une approche appropriée.
Si la notation UML est bien utilisée, elle peut outiller la modélisation sémantique. Les classes portent les trois types de propriétés : informatives (sous la forme d’attributs, y compris attributs calculés et attributs de portée classe) ; actives (les opérations) ; transformatives (les contraintes et les automates à états).
Évidemment UML est connotée “logiciel” (et est, d’ailleurs, largement sous-exploitée par les informaticiens dont les pratiques de modélisation ont considérablement régressé au cours de ces dernières décennies). Mais il ne faut pas oublier que les notions et axiomes qui forment la logique objet proviennent de la philosophie de la connaissance (de là le terme “classe”) : ce n’est donc pas un hasard si cette logique et les notations qui l’expriment se prêtent aussi facilement à la représentation des connaissances.

A noter aussi que l’élargissement des possibilités de modélisation (dans un modèle sémantique par rapport à un MCD) n’aboutit pas à un simple ajout de propriétés sur le modèle : il en change la structure. Ce que je veux dire par là, ce n’est pas seulement les éléments visibles qu’apporte UML par exemple (héritage, agrégation…) : ces éléments pouvaient être, en partie, restitués dans l’approche classique. C’est qu’en prenant en compte toutes les propriétés des objets métier et en suivant les exigences de généricité et de factorisation, le modélisateur est conduit à arranger différemment l’ensemble des propriétés. Les conséquences de ces changements de structure sont énormes : si on les suit sur toute la chaîne de transformation (conception des processus, automatisation…) l’enjeu se chiffre en millions d’euros. L’exemple d’école est la notion de Personne (ou client, employé, etc.). En appliquant rigoureusement cette approche, on peut diviser le volume des SI par 2, facilement ! Tout en augmentant le confort d’utilisation parce que l’on aura construit des solutions plus proches des représentations naturelles.

En conclusion, un modèle sémantique est bien plus qu’un modèle conceptuel des données (il le contient et on peut, à tout moment, extraire le modèle des données d’un modèle sémantique. Praxeme propose plusieurs filières de dérivation à partir du modèle sémantique, dont celle qui produit le modèle logique des données).
L’appellation “Business Object Model” a servi un peu trop à désigner des MCD (et parfois, même pas bons : on en a de lamentables exemples sur le marché). Ce qu’on appelle un BOM (par exemple celui d’IBM) ou l’Information Model d’ACORD ne sont que des modèles de données (même pas normalisés). Les conséquences sont dramatiques. Mais c’est une autre histoire…

Ce commentaire ne remet pas en cause l’héritage de Merise. UML est une notation, pas une méthode. Merise est une méthode et beaucoup de ses recommandations non seulement restent d’d'actualité mais encore sont nettement supérieures à ce que l’on trouve dans les méthodes orientées objet et dans les pratiques courantes. Donc, nous avons tout intérêt à faire fructifier notre héritage. Praxeme reconnaît bien volontiers sa filiation avec Merise.

Examen du framework de Zachman

Add a comment

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.

Les frontières du système

Add a comment
C’est un sujet de fond : “quelles frontières et substance donnons-nous aux systèmes  que nous identifions ?” équivaut à “comment percevons-nous le réel ?” et donc à “en quoi sommes-nous capables d’agir intelligemment ?”.
Certes, l’ingénieur et sa rationalité particulière ont un rôle éminent à jouer, mais à condition :
  • 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é).
Ce travail, nous ne pouvons le mener sans le soutien et les apports des sciences humaines.
Dans l’approche Praxeme, nous ne distinguons pas les systèmes par catégories (organisation, informatique, produit…). Nous voyons un objet, massif et plongé dans son environnement (= Système Entreprise ou système d’action), et nous l’attaquons par plusieurs côté, sous plusieurs angles (les aspects). Le postulat est que tout système comporte les 9 aspects (ou plutôt, qu’il se présente sous chacun des 9 aspects). Certes, chacun des aspects est plus ou moins développé selon la nature du système.
En tout cas, nous n’isolons pas arbitrairement des portions (organisation, système technique…) et nous encourageons à l’analyse des dépendances et interactions entre chaque composante (humaine, collective, technique…).

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.

A propos de frameworks

Add a comment

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.

Détermination de la Topologie du Système Entreprise

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.

L’architecture d’entreprise existe-t-elle ?

Add a comment

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)

Les trois dimensions de la méthodologie

Add a comment

La méthodologie s’étend dans un espace à trois dimensions : Produit, Processus, Procédés. Cette structuration du corpus méthodologique est résumée par la formule « PRO3 » (pro-cube). Elle détermine non seulement l’exploitation de la méthode mais aussi la façon de la construire.

Le « Produit » est l’objet à fabriquer ou transformer, dont il faut prendre en compte la structure interne. Selon le domaine d’application, le « Produit » est l’objet système, l’entreprise elle-même (contenant le système d’information, automatisé par le système informatique), un système d’action (système d’armement, par exemple), un élément d’un système comme une organisation, un composant logiciel, une application, etc. La méthodologie examine, d’abord, la dimension « Produit » puisqu’il est logique de répondre d’abord à la question « Quoi ? » avant de se préoccuper du « Comment ? ». Sur quoi agissons-nous ? Que voulons-nous fabriquer ? Quel est la logique interne de cet objet ?

Praxeme analyse le « Produit » en aspects, fixés par la Topologie du Système Entreprise. La méthodologie en déduit les modèles, les articulations entre modèles, les critères d’acceptation et les règles de production.

Le « Processus » répond à la question « comment organiser le travail ? ». Il comporte une définition des rôles, un phasage, des règles d’ordonnancement et le recensement des activités. Nous parlons, ici, du processus de production du système : ce n’est pas un processus « métier », mais l’ensemble coordonné des activités par lesquelles une entreprise, un organisme ou un système se conçoit : c’est-à-dire, à la fois, se pense et se construit. La qualité d’un processus s’évalue par sa simplicité, son niveau de formalisme, sa cohérence interne et son auto-justification : sa logique interne doit être claire.

La dimension des « Procédés » apporte elle aussi des réponses à la question « comment travailler ? », mais au niveau individuel. Comment faire un bon modèle ? Comment trouver les services ? Comment innover sur les processus ? Etc. Il s’agit des modes opératoires, nécessaires pour homogénéiser la qualité du travail et garantir la productivité.

Plus de détail dans : le Livre blanc et le Guide Général, disponibles sur le site www.praxeme.org .

Pour répondre réellement aux questions des opérationnels et pour guider l’action dans tous ses détails, il est nécessaire de couvrir ces trois dimensions.

Elles se trouvent rarement couvertes dans une même méthode. D’ailleurs, depuis une quinzaine d’années, les méthodes ont tendance à se focaliser sur la dimension du processus (UP, TOGAF, ITIL, CMMI, ISO 9000, ISO 12207…). Il semblerait que le processus soit la grande découverte de notre génération. Sans doute cela tient-il à l’évolution du pouvoir dans les entreprises. Le processus est vu et piloté par le manager, lequel décide des investissements. Tout naturellement, cette situation introduit un biais : le décideur porte davantage d’attention à cette dimension organisationnelle et collective qu’aux dimensions plus techniques du produit et des procédés. Celles-ci concernent les opérationnels, au quotidien ; ils ont de réels besoins sur ce plan mais ne sont pas toujours en mesure de les faire valoir.

Praxeme contient des principes directeurs pour le processus de transformation. Nous nommons ainsi l’ensemble des activités par lesquelles une entreprise se pense elle-même et crée ses conditions de production et d’action. Un document sur ce sujet est en préparation, en parallèle avec le chantier de l’armée de terre sur le processus de développement. Le fonds public propose, aussi, une « dynamique globale » qui identifie les macro-activités nécessaires à la conception et à la consolidation de l’objet système (entreprise ou système d’action). Cependant, du fait de la carence dénoncée ci-dessus, les travaux sur Praxeme portent en priorité sur les dimensions du Produit et des Procédés.

En pratique, Praxeme se prête à des combinaisons avec d’autres méthodes. De telles combinaisons sont assez naturelles et faciles à réaliser avec des méthodes essentiellement centrées sur le processus, du fait de l’orthogonalité des trois dimensions du schéma PRO3.

Notons tout de même que le terme « dimension » est abusif, ici, car ces trois chapitres de la méthodologie ne constituent pas, à proprement parler, un espace géométrique. Cela n’aurait aucun sens de se positionner à l’aide de coordonnées sur ces trois « axes ». Mieux vaut, plus modestement, parler des trois chapitres de la méthodologie. Il y a bien des articulations, des points de contact et des déterminations entre des éléments de ces trois chapitres, mais ils demandent une analyse plus circonspecte.

Les couleurs normalisées

Add a comment

Code

Rouge

Vert

Bleu

10-Sq

165

0

33

20-Pq

102

0

102

30-Gq

51

102

255

40-Lq

255

153

0

50-Tq

217

217

217

60-Ml

51

153

102

70-Ll

255

255

0

80-Ph

51

102

0

Les couleurs de l’entreprise

Add a comment

La Topologie du Système Entreprise constitue le socle de la méthodologie Praxeme. Elle se range parmi les frameworks méthodologiques, comme le célèbre framework de Zachman et les niveaux d’abstraction de Merise que Praxeme reconnaît dans sa filiation.

L’expression “Topologie du Système Entreprise” est déposée auprès de l’Institut National de la Propriété Industrielle et appartient à l’association Praxeme Institute. Bien sûr, son utilisation est libre comme l’est celle des documents déposés dans le fonds public. Ce fonds est protégé par une licence “creative commons”.

La Topologie du Système Entreprise

La Topologie du Système Entreprise

Souvent, la question a été posée de la signification des couleurs, sur le schéma de la topologie. Cette note fournit les couleurs normalisées et leur explication.

Les couleurs attachées aux aspects de la Topologie du Système Entreprise ont un effet pédagogique. C’est la raison pour laquelle il importe de fixer une fois pour toutes ces couleurs et de leur trouver une justification logique.

Utilité

Ces couleurs normalisées égailleront les modèles et pourront être associées aux stéréotypes dans les profils UML. Les supports de formation, par exemple, pourront reprendre la couleur correspondant aux modules par aspects. Les classes sémantiques et leurs instances pourront être représentées par des rectangles de la même couleur que celle assignée à l’aspect sémantique, etc.

Justification

La version précédente de la TSE exploitait tout le spectre des couleurs. Nous conservons cette idée qui véhicule le message d’une couverture complète du réel par la méthode. Cependant, là où les couleurs tombaient de façon arbitraire, la nouvelle version développe une logique complète :

Le rouge, couleur chaude et la plus présente, symbole d’énergie, est attribué à l’aspect qui caractérise Praxeme et qui requiert le plus d’attention : l’aspect sémantique.

Le bleu, son opposé, évoquant l’espace, est attribué à l’aspect géographique.

L’aspect logiciel se voit affecter la troisième couleur primaire, le jaune.

Les autres couleurs s’obtiennent en mélangeant les couleurs primaires, en tenant compte des dépendances entre les aspects. Ainsi, l’aspect physique combinant logiciel et matériel est peint en vert. Cette couleur, terrestre, convient parfaitement à l’aspect physique.

Les aspects pragmatique et matériel reçoivent la couleur intermédiaire entre celles des aspects voisins.

Au centre du schéma, le mélange des couleurs donnerait du blanc. Nous choisissons le gris pour l’aspect technique.

Pour le cadrage, la situation de pré-modélisation se traduit symboliquement par l’absence de couleur. C’est donc la couleur noir qui lui est attribué.

NB : Les couleurs finales ont été atténuées pour correspondre au goût du jour. Sur le schéma, les liens de dépendances entre les aspects restent en rouge, pour augmenter leur visibilité.