Zachman Framework

369 vues

Publié le

Zachman Framework

Publié dans : Mode de vie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
369
Sur SlideShare
0
Issues des intégrations
0
Intégrations
3
Actions
Partages
0
Téléchargements
3
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Zachman Framework

  1. 1. Le cadre Zachman Présenté par : Emna Ayadi
  2. 2. 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
  3. 3. 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.
  4. 4. 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.
  5. 5. Le framework Zachman
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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.
  10. 10. 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.
  11. 11. 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é.
  12. 12. 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.
  13. 13. 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.
  14. 14. 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.
  15. 15. 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.
  16. 16. 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.
  17. 17. 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é.
  18. 18. 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.
  19. 19. 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.
  20. 20. 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.

×