Zachman Framework : définition, matrice, modèle et exemples

Le cadre Zachman est l’un des modèles d’architecture d’entreprise les plus connus. Nous vous expliquons ici comment il fonctionne, les points qu’il inclut et comment l’appliquer.

Sommaire

1. Qu’est-ce que le cadre Zachman framework ?
2. À quoi sert-il ?
3. Avantages & inconvénients
4. Matrice Zachman
5. Modèle (téléchargement PDF inclus)
6. Exemple
7. Zachman vs TOGAF vs FEAF

Points clés à retenir : le cadre Zachman

• Développé par John Zachman chez IBM en 1987, le framework Zachman est l’un des modèles de référence pour les développeurs d’architecture d’entreprise et les responsables informatiques. Sa version actuelle est la version 3.0.
• Six perspectives et six catégories de questions se croisent pour former 36 cellules offrant une description complète de toute architecture d’entreprise.
• Indépendant de toute technologie et compatible avec des frameworks tels que TOGAF et COBIT.
• Tous les éléments de l’architecture Zachman sont interconnectés, de sorte que tout changement dans une section est immédiatement visible sur l’ensemble du modèle.
• Le tableau de bord de gestion du risque humain de SoSafe permet de mesurer et de gérer le facteur humain au sein de votre architecture de sécurité.

Qu’est-ce que le cadre Zachman framework ? Définition et origines

Pour bien comprendre le Zachman framework, il faut remonter à ses origines. John Zachman a développé son référentiel en 1987 alors qu’il travaillait chez IBM. À cette époque, les systèmes d’information sont de plus en plus complexes et donc, de plus en plus difficile à gérer.

John Zachman s’est alors inspiré des principes de l’architecture classique et de l’ingénierie. Lorsqu’on planifie la construction d’un bâtiment, on envisage simultanément plusieurs perspectives : la structure de l’édifice, l’électricité et l’agencement de l’espace, par exemple. Zachman pensait que l’architecture d’entreprise nécessitait une planification similaire, qui adopte plusieurs perspectives de manière structurée.

Le référentiel qu’il a créé consiste en une matrice de 36 cellules. Sur l’un des axes, il a disposé six catégories de questions, sur l’autre, six perspectives organisationnelles. Ensemble, ces deux axes permettent de décrire les principaux éléments d’une entreprise : les systèmes informatiques, les processus et les données, mais aussi les emplacements géographiques et les objectifs stratégiques.

Dans la version 3.0 du cadre Zachman, la terminologie a été affinée et les frontières entre les différentes perspectives ont été clarifiées. En termes simples, le Zachman Framework se présente comme un modèle de référence décrivant les composants d’une entreprise et leurs relations les uns avec les autres. Ce n’est pas un modèle de processus, mais une manière structurée d’analyser l’architecture d’entreprise.

Comment les entreprises utilisent-elles le cadre Zachman ?

Lorsqu’on veut documenter une architecture d’entreprise, la difficulté réside rarement dans un manque de connaissances, mais plutôt dans un manque de structure. On a tendance à décrire les systèmes séparément. Il existe des processus, mais les responsabilités ne sont pas clairement définies et personne ne sait précisément sur quelles données ils reposent. C’est à ce niveau que le cadre Zachman entre en jeu. Non pas comme un modèle de processus, mais comme un système de classification structuré.

Il pose six questions : What (quoi), How (comment), Where (où), Who (qui), When (quand) et Why (pourquoi). Chaque question est examinée sous six perspectives, de la direction exécutive à l’implémentation technique. Le cadre Zachman n’offre pas une recette toute faite pour l’architecture d’entreprise. Il fournit une grille structurée qui montre à quoi ressemble votre entreprise et où il reste des lacunes importantes à combler.

Les entreprises utilisent généralement le cadre Zachman dans des situations comme celles évoquées ci-dessous :

• Avant les projets de transformation, lorsqu’il est nécessaire de donner des bases solides aux décisions en matière d’architecture.
• Lors de l’introduction de nouvelles technologies, pour éviter de perdre de vue les structures et dépendances existantes.
• Lorsque les exigences réglementaires demandent une documentation complète et traçable.
• Lorsque les équipes informatiques et les unités commerciales ont besoin de se mettre d’accord sur une terminologie commune pour le travail d’architecture.

Framework Zachman : avantages et limites

Aucun référentiel n’est convient à tous les objectifs. Le cadre Zachman présente des atouts évidents, mais aussi de réelles limites qu’il convient d’examiner avant de l’adopter comme principale référence en matière d’architecture. Il est important que les entreprises connaissent à la fois les avantages et les inconvénients du modèle Zachman pour déterminer comment et à quel niveau elles peuvent l’intègrer dans un travail d’architecture à plus grande échelle.

Avantages

• Ne dépend pas d’une technologie en particulier : ce référentiel peut être appliqué sur différentes plateformes, avec différents outils et dans différents secteurs.
• Propose une matrice de 36 cellules reliées entre elles, permettant aux équipes de visualiser les conséquences qu’un changement apporté dans un domaine peuvent avoir par ailleurs.
• Fournit différentes perspectives sur la même entreprise, du niveau stratégique à l’implémentation opérationnelle.
• Favorise une vue d’ensemble de l’architecture d’entreprise.
• Peut servir pour établir un langage commun entre les unités commerciales et le service informatique.

Limites

• N’offre pas un modèle de processus : ce référentiel ne précise pas de méthode d’organisation pour le travail d’architecture.
• Peut être exigeant au début, surtout si les équipes essaient de remplir les 36 cellules.
• Nécessite des méthodes complémentaires pour traduire la documentation architecturale en implémentation pratique.
• Peut sembler trop complexe ou trop détaillé pour de petites entreprises.
• La matrice peut être difficile à utiliser sans guide ou sans formation.

Il faut une mesure du risque

Réserver une démo

Faites en sorte que le risque humain soit visible, mesurable et plus facile à gérer au sein de votre architecture de sécurité.

La matrice du Zachman Framework : perspectives et questions

Élément central du cadre Zachman, la matrice est constituée de deux axes : l’axe vertical répertorie six perspectives, c’est-à-dire les points de vue des différentes personnes qui examineront l’architecture. L’axe horizontal pose six catégories de questions, qui interrogent sur les points examinés. À chacune des 36 intersections, une cellule permet de décrire précisément une partie de l’architecture.

Les six perspectives (lignes)

Les entreprises qui utilisent ce référentiel vont sélectionner la perspective qui correspond à leur question, qu’il s’agisse du point de vue de la direction exécutive ou de celui des exécutants techniques.

Planner (scope) [Planificateur (portée)] : quel est le contexte général ?
Avant même de commencer à décrire un système, ce niveau aborde la question du pourquoi : quel est le but de l’entreprise et quelle est sa portée globale ? C’est la base de toutes les autres perspectives prévues dans la matrice du framework Zachman.

Owner (business model) [Propriétaire (modèle économique)] : comment l’entreprise se perçoit-elle ?
La direction pense en termes de processus métier, d’objectifs et de responsabilités, rarement en termes d’architecture système. C’est exactement ce tableau que cette perspective cherche à dresser : comment les dirigeants de l’entreprise voient-ils les choses ?

Designer (system model) [Concepteur (modèle système)] : comment peut-on représenter techniquement le modèle économique de l’entreprise ?
À ce niveau, les architectes système traduisent les exigences métier en modèle conceptuel. Le cadre Zachman sépare délibérément la logique métier de l’implémentation technique à ce stade.

Builder (technology model) [Constructeur (modèle technologique)] : que construit-on réellement ?
Les développeurs et les responsables technologiques décrivent comment le modèle de système se traduit en technologies concrètes. Ce niveau permet de matérialiser toutes les plateformes, les interfaces et l’infrastructure.

Subcontractor (detailed representations) [Sous-traitant (représentations détaillées)] : quelles sont les spécifications techniques ?
Les équipes de livraison et les partenaires externes n’ont pas besoin de concepts, mais d’instructions précises. C’est précisément l’objectif de cette perspective : des instructions détaillées pour l’implémentation des différents composants du système.

User (functioning enterprise) [Utilisateur (entreprise en fonctionnement)] : qu’est-ce qui fonctionne dans le monde réel ?
Au bout du compte, l’important n’est pas tant le modèle que le bon déroulement des opérations. Cette perspective montre comment l’entreprise fonctionne au quotidien, y compris là où la réalité diffère de la conception qu’on s’en faisait au départ.

Les six catégories de questions (colonnes)

La matrice du cadre Zachman applique six questions à chacune des six perspectives. Il est intéressant de réfléchir aux six colonnes. Le résultat ne sera pas un modèle abstrait mais permet de se faire une idée plus concrète du profil de l’entreprise dans le cadre de la matrice Zachman.

What (data) [Quoi (données)] : quelles données existent dans l’entreprise ?
Ce qu’une organisation sait détermine ce qu’elle peut faire. Cette colonne recense les types de données en présence, leur nom et les rapports qui existent entre eux.

How (function) [Comment (fonction)] : comment les processus fonctionnent-ils ?
Cette colonne ne s’intéresse pas au système, mais à ce qui se passe à l’intérieur. Elle décrit les flux de travail et les fonctions tels que l’entreprise les exécute.

Where (network) [Où (réseau)] : où le travail est-il réalisé ?
Cette colonne s’intéresse aux emplacements des sites, aux réseaux et à la répartition géographique. Elle précise également les liens entre ces différents emplacements.

Who (people) [Qui (personnes)] : qui est responsable de quoi ?
Il ne s’agit pas de réaliser un organigramme, C’est une vue structurée de qui prend quelles décisions et qui est propriétaire de quels processus. Cette colonne est notamment précieuse pour les responsables de la cybersécurité, puisqu’elle permet de visualiser les points d’intersection entre les différents rôles, responsabilités et risques humains au sein de l’architecture d’entreprise.

When (time) [Quand (temps)] : quand les processus sont-ils effectués et qu’est-ce qui les déclenche ?
Cette colonne se concentre sur les structures temporelles : quels déclencheurs entraînent quels processus ? Certains flux de travail suivent un cycle régulier, tandis que d’autres répondent à des événements spécifiques.

Why (motivation) [Pourquoi (motivation)] : quels sont les éléments de motivation au sein de l’entreprise ?
Les objectifs, les stratégies et les fondements des décisions. Cette colonne interroge sur les motifs d’action de l’entreprise sur les six niveaux. Les réponses permettront de poser des bases pour des décisions plus stratégiques en matière d’architecture.

Modèle du Zachman Framework : téléchargez la matrice et lancez-vous

Aucun logiciel dédié n’est nécessaire pour se lancer dans l’utilisation du cadre Zachman. Notre modèle du cadre Zachman fournit une matrice claire avec six perspectives et six catégories de questions. Vous pouvez l’imprimer, le remplir lors d’un atelier ou l’utiliser comme point de départ numérique pour votre travail d’architecture.

Ce PDF sur le cadre Zachman comprend deux pages :

Page 1 : une matrice vide avec les 36 cellules, à être remplie en fonction de la portée de votre projet

Page 2 : un exemple de matrice complétée avec l‘exemple d’une entreprise de commerce de détail, montrant comment indiquer des décisions d’architecture concrètes peuvent dans la matrice

Que vous prépariez un atelier de lancement ou que vous soyez en train de structurer un projet d’architecture, notre PDF vous offre une base de travail claire. Les équipes qui utilisent le cadre Zachman pour la première fois peuvent prendre exemple sur la page 2. Les équipes qui travaillent déjà avec ce cadre peuvent partir directement de la matrice vide.

Il n’est pas nécessaire de remplir les 36 cellules dès le début. Il vaut souvent mieux commencer par les perspectives et les catégories de questions qui correspondent le mieux au projet en cours. Le référentiel lui-même ne définit pas de portée obligatoire.

Si vous avez eu du mal à intégrer le facteur humain dans votre architecture, le tableau de bord de gestion des risques humains de SoSafe peut vous fournir des mesures que vous utiliserez comme point de départ. Il permet de mieux visualiser le risque humain, de le quantifier et donc de le gérer plus facilement dans la perspective de la colonne « Who » du cadre Zachman qui s’intéresse aux personnes.

Votre architecture avec une structure claire

Télécharger le modèle du cadre Zachman

Téléchargez un PDF avec une matrice vide et un exemple de matrice complétée que vous pourrez utiliser comme point de départ pour vos ateliers et vos décisions en matière d’architecture.

Exemple de cadre Zachman Framework : comment remplir la matrice

Notre exemple de cadre Zachman montre la différence entre la théorie et la pratique. L’exemple ci-dessous montre comment une entreprise de commerce de détail pourrait remplir la matrice du Zachman Framework et fournit une source d’inspiration pour votre propre travail d’architecture.

L’entreprise commercialise différents produits par le biais de magasins physiques, d’un entrepôt central et d’une boutique en ligne. Elle dispose de trois canaux de vente, d’emplacements distribués et de différents groupes de parties prenantes. L’architecture Zachman permet de réaliser un aperçu systématique de ce type de structures pour mieux visualiser les dépendances au sein de l’entreprise.

Voici un exemple d’implémentation du Zachman Framework pour les six catégories de questions :

• What (data) : les principaux objets sont le client, le produit et la commande. Au niveau Planner (planificateur), il peut suffire de nommer ces objets. Au niveau Builder (constructeur), l’équipe définirait des structures de base de données concrètes.
• How (function) : au niveau de l’entreprise, le processus consiste à « recevoir et exécuter les commandes ». Le designer (concepteur) traduit cela en un modèle de système avec une gestion des commandes et une gestion d’entrepôt.
• Where (network) : les magasins, l’entrepôt central et la boutique en ligne sont connectés via une infrastructure cloud partagée. Chaque perspective décrit le même réseau, mais avec des moyens différents et un niveau de détail différent.
• Who (people) : le conseil d’administration et la direction générale détiennent la responsabilité stratégique globale. Plus la matrice est détaillée, plus les attributions sont précisées. Au niveau des sous-traitants, il est par exemple possible d’indiquer le nom des personnes, des équipes et des prestataires de services externes.
• When (time) : l’année commerciale est structurée en cycles de planification saisonniers. Au niveau Builder (constructeur), cela se traduit par un calendrier de publication concret avec des fenêtres de déploiement précises.
• Why (motivation) : au niveau Planner (planificateur), l’objectif stratégique est de protéger les parts de marché et de fidéliser les clients. Les niveaux opérationnels traduisent cela en KPI mesurables et en objectifs de SLA contractuels.

Cet exemple d’implémentation du cadre Zachman montre comment la même entreprise peut être décrite selon six perspectives différentes. Loin d’être contradictoire, le résultat donne de la profondeur aux informations. Chaque perspective ajoute une couche supplémentaire dans la vue d’ensemble que l’on a de l’architecture.

L’exemple complété est inclus dans le PDF disponible en téléchargement gratuit du cadre Zachman.

Comparaison entre le cadre Zachman, TOGAF et FEAF

Les référentiels d’architecture d’entreprise adoptent différentes approches et peuvent guider l’élaboration d’une architecture de sécurité de différentes manières. Le cadre Zachman répertorie les différents points à documenter. TOGAF fournit un processus pour organiser le travail d’architecture par le biais de son ADM. FEAF normalise le travail d’architecture dans les agences fédérales américaines.

Entre les référentiels TOGAF et Zachman, le choix n’est pas binaire. Ces deux cadres peuvent se compléter : Zachman fournit la structure, TOGAF la méthode. En fonction des exigences réglementaires et des objectifs de sécurité, il peut également s’avérer utile de faire appel à des cadres tels que ISO 27001, le NIST Cybersecurity Framework 2.0 ou COBIT.

Zachman, TOGAF et FEAF en un coup d’œil

Pour de nombreuses entreprises, le cadre Zachman est un bon point de départ pour construire une architecture d’entreprise. Il offre une référence structurelle en complément de TOGAF qui guide l’implémentation. Pour les entreprises du secteur privé, les modèles Zachman et TOGAF sont souvent plus faciles à appliquer directement que le référentiel FEAF. FEAF est généralement plus pertinent pour les structures qui travaillent en étroite collaboration avec des clients du secteur public ou des organismes gouvernementaux.

Il faut de la visibilité pour le risque humain

Réserver une démo

Les contrôles techniques protègent les systèmes. SoSafe vous aide à comprendre à quel niveau les comportements, les rôles et les décisions en matière de sécurité affectent le risque.