Accueil🇫🇷Chercher

Cadre Zachman

Le cadre Zachman est un cadre d'architecture d'entreprise qui permet d'une manière formelle et hautement structurée de définir le système d'information d'une entreprise.

Il utilise un modèle de classification à deux dimensions basé sur :

  • six interrogations de base : Quoi, Comment, Où, Qui, Quand, et Pourquoi (What, How, Where, Who, When, Why),
  • qui croisent six types de modèles distincts qui se rapportent à des groupes de parties prenantes : Visionnaire, Propriétaire, Concepteur, Réalisateur, Sous-traitant et Exécutant (visionary, owner, designer, builder, implementer, worker) pour présenter une vue holistique de l'entreprise qui est modélisée.

Origine

Conçu à l'origine par John Zachman chez IBM en 1987, ce cadre est maintenant de facto un standard mondial pour exprimer les éléments de base d'une architecture d'entreprise. Au départ, la dénomination technique complète est Zachman Framework for Information Systems Architecture et a changé au début des années 1990 pour devenir Zachman Framework for Enterprise Architecture.

Cas d'emploi

Avantages et inconvénients

Souvent utilisé dans le cadre d'une revue de l'organisation et des technologies d'une architecture de systèmes au niveau d'une entreprise, c'est un outil très apprécié dans les départements d'architecture informatique. En revanche, il est moins prisé des développeurs ou des communautés d'utilisateurs.

Ce cadre d'architecture d'entreprise peut facilement évaluer l'architecture logicielle d'une entreprise.

Les points forts sont la couverture complète qui est obtenue en abordant chacune des cellules du schéma. L'inconvénient est que cette approche peut quelquefois générer une quantité importante de documentation si elle est appliquée d'une façon trop formelle, en raison même de sa complétude, et des difficultés d'appropriation. Les outils modernes de navigation web peuvent pallier cet inconvénient en rendant cette approche plus conviviale qu'elle ne l'était au moment de sa conception.

L'essentiel est de respecter l'esprit de cette approche.

Mise en évidence d'incohérences

Quoi qu'il en soit, dans certaines circonstances, cette méthode peut mettre en évidence, au premier coup d'œil, d'éventuelles incohérences dans une architecture très complexe. Par exemple, dans le cas d'un cadre d'interopérabilité, on peut vérifier si les modèles de processus sont correctement imbriqués avec les modèles de données correspondants, au niveau approprié, c'est-à-dire aux niveaux contextuel et conceptuel (pas seulement au niveau technique). Dans le cas contraire, les enjeux et les processus deviendraient incompréhensibles pour les dirigeants et les futurs utilisateurs des systèmes, faute d'un vocabulaire adapté à leurs attentes.

Chaque artifact dans une classification (cellule) du schéma doit être aligné avec les cellules immédiatement au-dessus et en dessous. Toutes les cellules dans chaque rang doivent être intégrées avec les autres. En revanche, les cellules n'ont pas besoin d'être mises en cohérence diagonalement.

Exemple sur la première ligne (champ, contexte, frontières, pour le planificateur) :

Le schéma Zachman

Voir dans la Wikipedia anglophone : The Zachman Schema

Quels enjeux le cadre Zachman permet-il de représenter ?

Les colonnes rassemblent les questions sur les éléments de l'architecture. Par exemple la colonne donnée est particulièrement importante dans le cas d'architectures dirigées par les données. En pratique, on peut se demander comment chaque question (quoi, comment, pourquoi…) est reliée à chaque élément (données, fonction…). Les questions ne sont pas toujours objectives malgré les apparences ; par exemple le "comment" d'une personne peut être le "quoi" d'une autre personne, ou encore le "pourquoi" d'une troisième.

Les lignes rassemblent les perspectives dans l'idéal. On peut définir chaque perspective (entreprise, système et technologie) à chaque niveau d'abstraction (haut niveau, niveau moyen et jusqu'au détail le plus fin). Les deuxième, troisième et quatrième lignes correspondent aux niveaux conceptuel, logique, et physique de la méthode MERISE (et de ses équivalents anglosaxons).

  • Les deux premières lignes (contexte, conceptuel) décrivent l'architecture administrative,
  • La troisième ligne décrit l'architecture des systèmes d'information proprement dite,
  • Les quatrième et cinquième lignes décrivent l'architecture de la technologie.

On comprend plus facilement les perspectives en considérant les propriétés spécifiques des artifacts dans la ligne et en s'assurant soigneusement que les concepts (modèles non informatiques) sont clairement séparés du système de représentation logique des concepts (modèle indépendant du type de plate-forme) et de la spécification physique de la technologie à appliquer (modèles neutres par rapport au fournisseur) des configurations des composants nécessaires pour devenir les contenus des éléments qui seront employés opérationnellement par les employés de l'entreprise dans les différents domaines (compétences d'exécution, management intermédiaire, dirigeants, etc.).

On pourrait en conclure qu'il y a en réalité quatre dimensions et pour cela beaucoup de relations à compléter pour comprendre une entreprise complexe, on pourrait aussi trouver que c'est avant de considérer les différents niveaux de granularité auxquels un artifact donné peut être considéré.

Ce cadre est donc simple et interprétable, et pour la plupart, c'est ce qui fait son attrait.

Source

Voir aussi

Liens externes
Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplémentaires peuvent s’appliquer aux fichiers multimédias.