Le cadre Zachman
Présenté par : Emna Ayadi
Plan
 Présentation générale de la démarche
 La matrice zachman
 La dimension verticale
 La dimension horizontale
 Avantages et inconvénients
 Ce qu'il faut retenir
C'est en 1987 que John Zachman, employé d'IBM, propose
une méthode de représentation de l'architecture système
d'une entreprise. Véritable portail d'accès aux référentiels
de l'entreprise, le cadre Zachman (Zachman Framework).
L'idée étant qu'une entreprise n'a pas qu'une seule
architecture, mais plusieurs suivants différents points de vue
et à différents niveaux. Depuis son premier article, John
Zachman a retravaillé sa représentation.
Donc, 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.
Le framework Zachman
Le Quoi ? (Données) En
quoi est-ce fait ?
C'est la composition du produit.
Dans le cas d'un logiciel, il s'agit
des données. Zachman propose
pour chaque colonne, un modèle
d'illustration. Ici : Objet - relation -
Objet
Le Comment ?
(Fonctions) Comment ça
fonctionne ?
Cette colonne correspond au
fonctionnement et à la
transformation du produit. Le
modèle proposé par Zachman est le
suivant Processus - Entrée/Sortie -
Processus
Le Où ? (Réseau) Où sont
les éléments les uns par
rapport aux autres ?
Cette colonne s'intéresse à
l'emplacement et aux connexions
du produit. Le modèle est : Nœud -
lien - Nœud
Le qui ? (Personnel) Qui
fait quoi ?
Cette colonne correspond au
personnel, aux manuels, aux
procédures qui leur sont utiles pour
faire leurs tâches. Le modèle est
Acteur - Tache - Acteur.
Le quand ? (Temps)
Quand se produisent les
choses ?
Cette colonne concerne les cycles
de vie, les durées et les
programmes qui sont utilisés pour
contrôler l'activité. Le modèle est
Événement - Cycle - Événement.
Le pourquoi ?
(Motivation) Pourquoi les
événements arrivent-ils ?
Cette colonne correspond
aux objectifs, plans et
règles qui guident
l'organisation. Le modèle
est Finalité - Moyens -
Finalité.
Portée
(contextuelle) (Scope
(contextual))
Le point de vue du planificateur
Cette ligne décrit les modèles,
l'architecture et les
représentations qui correspondent
aux limites de l'organisation
concernée.
Modèle métier
(conceptuel) (Business
Model (conceptual))
Le point de vue du propriétaire
Cette ligne décrit les modèles,
l'architecture et les
représentations utilisés par les
propriétaires des process métier.
Elle se concentre sur les
utilisations habituelles d'un
produit.
Modèle système
(logique) (System model
(logical))
Le point de vue du concepteur
Cette ligne décrit les modèles,
l'architecture et les
représentations utilisés par les
ingénieurs, architecte et toutes
personnes qui doivent arbitrer
entre les besoins et ce qui est
techniquement possible de faire.
Modèle de technologie
(physique) (Technology
model (physical))
Le point de vue du constructeur
Cette ligne décrit les modèles,
l'architecture et les
représentations utilisées par les
techniciens, les ingénieurs et les
contractants qui modélisent et
créent les produits.
Représentation détaillée
(hors contexte) (Detailed
representations (Out-of-
Context Perspective)
Point de vue des sous-traitants
Cette partie décrit les différents
éléments inclus dans le produit
final (ex. : composants logiciels).
Pour les développeurs de logiciel,
cette partie correspond à
l'intégration de module ou de
composant en provenance de
l'extérieur.
Le fonctionnement de
l'entreprise (the
functioning enterprise)
Cette partie représente la réelle
mise en œuvre des éléments, c'est
l'existant dans toute sa complexité.
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.
La structuration d'un référentiel processus suppose une
approche selon deux dimensions : le prisme d'analyse et
le niveau de détail. Le prisme définit l'angle selon lequel
on décrit et correspond aux colonnes du modèle de
Zachman, le niveau de détail correspondant globalement
aux lignes. Quand on se place à un niveau macro, le
modèle est forcément orienté métier et se veut
indépendant des outils et technologies mis en œuvre.
Toute cartographie se trouve donc nécessairement au
croisement de ces deux axes, un même modèle ne
pouvant traduire tous les prismes et tous les niveaux de
détail. De ce point de vue, le modèle de Zachman
répond à ce besoin d'organisation du référentiel dans
lequel tout modèle doit pouvoir se situer clairement au
sein du damier.
On notera également qu'en superposant clairement
les niveaux métier, logique et physique, ce cadre est
compatible avec les standards d'urbanisation du
système d'information selon lesquels, les vues
métiers, fonctionnelles, applicatives et techniques
apparaissent comme autant de couches superposées
devant être mises en cohérence.

Zachman Framework

  • 1.
  • 2.
    Plan  Présentation généralede la démarche  La matrice zachman  La dimension verticale  La dimension horizontale  Avantages et inconvénients  Ce qu'il faut retenir
  • 4.
    C'est en 1987que John Zachman, employé d'IBM, propose une méthode de représentation de l'architecture système d'une entreprise. Véritable portail d'accès aux référentiels de l'entreprise, le cadre Zachman (Zachman Framework). L'idée étant qu'une entreprise n'a pas qu'une seule architecture, mais plusieurs suivants différents points de vue et à différents niveaux. Depuis son premier article, John Zachman a retravaillé sa représentation.
  • 5.
    Donc, Le cadreZachman 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.
  • 6.
  • 8.
    Le Quoi ?(Données) En quoi est-ce fait ? C'est la composition du produit. Dans le cas d'un logiciel, il s'agit des données. Zachman propose pour chaque colonne, un modèle d'illustration. Ici : Objet - relation - Objet
  • 9.
    Le Comment ? (Fonctions)Comment ça fonctionne ? Cette colonne correspond au fonctionnement et à la transformation du produit. Le modèle proposé par Zachman est le suivant Processus - Entrée/Sortie - Processus
  • 10.
    Le Où ?(Réseau) Où sont les éléments les uns par rapport aux autres ? Cette colonne s'intéresse à l'emplacement et aux connexions du produit. Le modèle est : Nœud - lien - Nœud
  • 11.
    Le qui ?(Personnel) Qui fait quoi ? Cette colonne correspond au personnel, aux manuels, aux procédures qui leur sont utiles pour faire leurs tâches. Le modèle est Acteur - Tache - Acteur.
  • 12.
    Le quand ?(Temps) Quand se produisent les choses ? Cette colonne concerne les cycles de vie, les durées et les programmes qui sont utilisés pour contrôler l'activité. Le modèle est Événement - Cycle - Événement.
  • 13.
    Le pourquoi ? (Motivation)Pourquoi les événements arrivent-ils ? Cette colonne correspond aux objectifs, plans et règles qui guident l'organisation. Le modèle est Finalité - Moyens - Finalité.
  • 15.
    Portée (contextuelle) (Scope (contextual)) Le pointde vue du planificateur Cette ligne décrit les modèles, l'architecture et les représentations qui correspondent aux limites de l'organisation concernée.
  • 16.
    Modèle métier (conceptuel) (Business Model(conceptual)) Le point de vue du propriétaire Cette ligne décrit les modèles, l'architecture et les représentations utilisés par les propriétaires des process métier. Elle se concentre sur les utilisations habituelles d'un produit.
  • 17.
    Modèle système (logique) (Systemmodel (logical)) Le point de vue du concepteur Cette ligne décrit les modèles, l'architecture et les représentations utilisés par les ingénieurs, architecte et toutes personnes qui doivent arbitrer entre les besoins et ce qui est techniquement possible de faire.
  • 18.
    Modèle de technologie (physique)(Technology model (physical)) Le point de vue du constructeur Cette ligne décrit les modèles, l'architecture et les représentations utilisées par les techniciens, les ingénieurs et les contractants qui modélisent et créent les produits.
  • 19.
    Représentation détaillée (hors contexte)(Detailed representations (Out-of- Context Perspective) Point de vue des sous-traitants Cette partie décrit les différents éléments inclus dans le produit final (ex. : composants logiciels). Pour les développeurs de logiciel, cette partie correspond à l'intégration de module ou de composant en provenance de l'extérieur.
  • 20.
    Le fonctionnement de l'entreprise(the functioning enterprise) Cette partie représente la réelle mise en œuvre des éléments, c'est l'existant dans toute sa complexité.
  • 22.
    Souvent utilisé dansle 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.
  • 24.
    La structuration d'unréférentiel processus suppose une approche selon deux dimensions : le prisme d'analyse et le niveau de détail. Le prisme définit l'angle selon lequel on décrit et correspond aux colonnes du modèle de Zachman, le niveau de détail correspondant globalement aux lignes. Quand on se place à un niveau macro, le modèle est forcément orienté métier et se veut indépendant des outils et technologies mis en œuvre. Toute cartographie se trouve donc nécessairement au croisement de ces deux axes, un même modèle ne pouvant traduire tous les prismes et tous les niveaux de détail. De ce point de vue, le modèle de Zachman répond à ce besoin d'organisation du référentiel dans lequel tout modèle doit pouvoir se situer clairement au sein du damier.
  • 25.
    On notera égalementqu'en superposant clairement les niveaux métier, logique et physique, ce cadre est compatible avec les standards d'urbanisation du système d'information selon lesquels, les vues métiers, fonctionnelles, applicatives et techniques apparaissent comme autant de couches superposées devant être mises en cohérence.