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.

This entry is filed under fondements. And tagged with , , . You can follow any responses to this entry through RSS 2.0. You can leave a response, or trackback from your own site.

  1. No Comments

You must login to post a comment.