Cadre Zachman

Introduction

L’architecture d’entreprise (AE) est la discipline qui définit, organise, normalise et documente la structure et les flux de travail d'une organisation afin de créer et de gérer des processus plus efficaces. Spécialité axée autant sur le monde de l'informatique que sur celui des affaires, l'AE introduit des normes pratiques entre les unités et les équipes des départements afin de rationaliser les efforts grâce à un partage intelligent des ressources. 

L'évolution de l’architecture d’entreprise a apporté plusieurs cadres que les architectes peuvent mettre en œuvre lorsqu'ils abordent la discipline ; l'un d'entre eux est le cadre Zachman. Ces cadres décrivent un exemple de taxonomie des types de « vues » architecturales qu'un architecte peut envisager de développer, et fournissent des lignes directrices sur le choix de la vue à développer.

Parmi les autres cadres d’AE, citons TOGAF, FEAF et celui de Gartner.

Qu’est-ce que le cadre Zachman ?

Le cadre Zachman est une ontologie d’architecture d’entreprise qui utilise un schéma organisationnel pour organiser ses artefacts architecturaux (par exemple la conception de documents, des spécifications et des modèles).

Le cadre Zachman pour l'architecture d'entreprise vise à prendre en compte et à mettre en synergie les cibles de l'artefact (responsables de l'entreprise et constructeurs de systèmes) et la question particulière à traiter (par exemple, les données et les fonctionnalités).

La première version de ce cadre a été introduite par John Zachman, auteur de A Framework for Information Systems Architecture dans les années 1980. En 1992, Zachman a proposé six domaines descriptifs (données, fonction, réseau, personnes, temps et motivation) et six perspectives (également appelées « acteurs ») : planificateur, propriétaire, concepteur, constructeur, sous-traitant et entreprise.

« A Framework for Information Systems Architecture » (1987), un précurseur conceptuel du "cadre Zachman", tel qu'il a été publié dans le vol. 26, n° 3 de l'IBM Systems Journal.

C'est la base du cadre moderne de Zachman. Il s'agit également d'un tournant pour l'architecture d'entreprise, car il a permis d'aborder la discipline d'une manière totalement nouvelle.

Zachman a constaté que les systèmes d'information engendraient une complexité qu'il fallait cartographier à l'aide de classifications et d'interfaces plus claires, sous la forme d’un véritable plan, ou « architecture », des composants informatiques d'une entreprise. Depuis lors, l'ontologie d’origine de Zachman a connu plusieurs mises à jour.

Ce cadre, ainsi que quelques autres, est utilisé par les architectes d’entreprise lorsqu'ils abordent les stratégies de développement de l'architecture des systèmes d'information.

Ontologie vs. Méthodologie

Il est important de noter que le cadre Zachman n'est pas une méthodologie, et fonctionne donc différemment. En sciences de l'information, l'ontologie est un moyen de montrer les propriétés d'un domaine et la façon dont elles sont liées. Il s'agit du processus de définition d'un ensemble de concepts et de catégories qui représentent le sujet. 

C'est une structure alors qu'une méthodologie est un processus. Ce sont deux choses différentes. Une structure établit une définition alors qu'un processus fournit une transformation. Ainsi, le cadre (ontologie) est imprévisible et changeant, produisant divers résultats qui ne peuvent être répétés. Une méthodologie est un processus de transformation d'un état à un autre. Le cadre Zachman est une ontologie, ce qui le différencie des autres cadres d'architecture d'entreprise.

Primitives vs. Composites

Une ontologie est la classification de l'ensemble des composantes « primitives » (élémentaires) présentes qui sont importantes pour l'existence d'un objet. Une méthodologie, quant à elle, produit des implémentations « composites » (composées) des primitives. Les primitives sont intemporelles, au contraire des composites. Par exemple, le tableau périodique des éléments est une ontologie (primitive), mais le processus chimique de transformation de l'eau de Javel et de l'alcali en eau salée est un processus, car il repose sur une méthodologie définie avec un résultat prévisible (composite).

Pourquoi Zachman ?

Le cadre Zachman a fourni une nouvelle perspective de l'examen et du développement de l'architecture d'entreprise. Il pose les questions suivantes : quoi, comment, quand, qui, où et pourquoi. C’est l’intégration de ces questions et les réponses à celles-ci qui permettent d’obtenir une vue complète et composite des idées complexes servant à planifier, mettre en œuvre, traiter et évaluer la structure d'entreprise d'une organisation.

Zachman souhaitait que son cadre s'étende à l'ensemble de l'architecture d'entreprise et ne se limite pas à l'architecture de l'information. 

Le cadre Zachman est conçu pour être un outil d'entreprise proactif. Il peut servir à modéliser les fonctions, les éléments, les processus et la structure d'entreprise d'une organisation.

Contrairement à TOGAF et d’autres cadres populaires qui sont organisés autour d'une série de cycles de vie ou d'étapes, l'approche ontologique de Zachman s'articule autour des points de vue des différents « acteurs » d'une organisation, et permet ainsi d'évaluer avec précision l'exhaustivité des modèles de processus de développement logiciel, en fonction des besoins d'information de l'organisation.

SUITE CI-DESSOUS

Structure du cadre Zachman

La structure du cadre Zachman est composée de 36 catégories nécessaires pour décrire presque tout, en particulier les choses complexes comme les produits manufacturés. La structure du cadre est composée de 36 catégories réparties en six lignes et six colonnes qui forment une matrice bidimensionnelle.

La structure finale présente les points de vue et les perspectives de chaque « acteur » impliqué dans le processus de développement du système pour donner une vue d'ensemble complète en fonction de l'acteur qui utilise le cadre.

Colonnes

Les colonnes du cadre Zachman représentent généralement les interrogations (ou questions) auxquelles une entreprise cherche à répondre. Il s'agit des questions Quoi, Comment, Quand, Qui, Où et Pourquoi mentionnées ci-dessus.

• Quoi – un exemple de question serait : quels sont les objets ? Quelles sont les données qui doivent être examinées ?
• Comment – comment fonctionne-t-il ? Quels sont les processus opérationnels ?
• Où – où se trouvent les activités de l'entreprise ?
• Quand – quand ces processus doivent-ils être réalisés ? À quelle fréquence ? etc.
• Pourquoi – pourquoi cette voie ou cette solution a-t-elle été choisie ? Quels sont les processus et les motivations pour parvenir à la solution ?

Les questions seront toujours différentes selon les lignes (voir ci-dessous), qui représentent qui pose la question et dans quel but.

Lignes

Les six lignes, quant à elles, représentent les différents points de vue ou perspectives des « acteurs » (parties prenantes ou points de vue). Il peut s'agir de n'importe qui au sein d'une organisation, notamment des planificateurs, des responsables, des architectes, des chargés de mise en œuvre, etc. Cependant, ils peuvent également être représentés sous forme de points de vue : contexte du champ d'application, concepts commerciaux, logique du système, technologie, etc. 

• Point de vue des planificateurs : contextes d'application - ils définissent l'objectif et la stratégie de l'entreprise.
• Point de vue des propriétaires : concepts d'entreprise - ce point de vue est défini par les personnes qui dirigent une organisation, qui fournissent une description de haut niveau des lignes directrices fondamentales en fonction des questions posées dans les colonnes.
• Point de vue des concepteurs : logique du système - c'est ici que le système et les processus permettront de répondre aux besoins informatiques de l'organisation.
• Point de vue des chargés de mise en œuvre : physique technologique - cela traitera les contraintes de production pendant la mise en œuvre du système.
• Point de vue du sous-constructeur : assemblage des composants - décrit les détails des différents éléments du système qui sont réservés à la mise en œuvre.
• Point de vue de l’utilisateur : classes d'opérations - comment le système fonctionnera dans son environnement opérationnel.

Règles

Zachman a proposé sept règles de base pour son cadre. Ces règles aident les architectes et les responsables informatiques à utiliser l'outil de manière efficace et effective. 

• Règle n°1 : il est important de ne pas ajouter de lignes ou de colonnes au cadre. Si vous êtes en mesure de répondre aux questions Qui, Quoi, Où, Comment et Pourquoi, vous pourrez alors déduire les réponses à toutes les autres questions sur le sujet ou l'objet. L'ajout de colonnes ou de lignes dénormaliserait le système de classification. 
• Règle n°2 : chaque colonne a un modèle générique simple et peut avoir son propre méta-modèle au sein de cette colonne.
• Règle n°3 : le modèle spécifique de toute cellule donnée devra être adapté aux contraintes, à la sémantique, au vocabulaire, aux termes et aux faits de la perspective de la ligne. Chaque cellule se spécialise dans le modèle générique de sa colonne.
• Règle n°4 : le modèle de base de chaque colonne doit être unique. Il doit éviter le chevauchement ou la réplication de données dans toute autre colonne. 
• Règle n°5 : ne créez pas de relations diagonales entre les cellules. Les colonnes peuvent être disposées dans n'importe quel ordre, mais l'ordre doit être descendant, en commençant par la catégorie la plus importante. La matrice doit fournir des réponses claires à des questions complexes de cette manière, et elle est conçue à cet effet. Les parties prenantes n’ont aucun intérêt à créer des relations diagonales entre les cellules.
• Règle n°6 : ne changez pas les noms des lignes et des colonnes, car cela entraînerait une confusion et une mauvaise communication entre les parties prenantes.
• Règle n°7 : la logique est générique et récursive, ce qui signifie qu'elle peut être utilisée pour classer ou analyser tout ce qui a trait à l'architecture d'entreprise.

Zachman vs. TOGAF

Alors que Zachman fournit une approche agile et flexible de l'architecture d'entreprise, TOGAF (The Open Group Architecture Framework) est de facto considéré comme le cadre standard de l'industrie. Ce cadre, qui offre une approche méthodologique de la conception de l'AE, est plus populaire parmi les architectes. 

Le cadre TOGAF fournit une série d'étapes concrètes connues sous le nom d’Architecture Development Method (ADM). L’ADM est une méthodologie générique mais adaptable pour aborder le processus d'architecture d'entreprise. Le cadre TOGAF-ADM fonctionne par cycles de vie aux étapes interchangeables qui visent à mettre en œuvre les choix de décision et produire les modèles souhaités.

Alternative à TOGAF, le cadre Zachman est une ontologie qui utilise diverses perspectives d'entreprise afin de cartographier, définir et planifier des composants complexes dans un système d'entreprise.

Votre approche générale de l'architecture d'entreprise déterminera si vous devez utiliser Zachman ou TOGAF. Cependant, il est possible d’utiliser les deux du fait de leur complémentarité, TOGAF décrivant le processus détaillé de création de l'architecture d'entreprise, et Zachman permettant de catégoriser les artefacts.

Certifications Zachman

Les architectes d'entreprise désireux de développer leur expertise en matière d'AE ont tout intérêt à investir dans le programme Zachman Certified - Enterprise Architect. Ce certificat permet d'acquérir des connaissances de base et une méthode d’application fonctionnelle du cadre Zachman, et de développer ainsi les compétences théoriques et techniques nécessaires à la mise en œuvre de projets d'entreprise.

Le programme Zachman Certified - Enterprise Architecture comporte quatre niveaux:

• Enterprise Architect Associate (Niveau 1)
• Enterprise Architect Practitioner (Niveau 2) 
• Enterprise Architect Professional (Niveau 3) 
• Enterprise Architect Educator (Niveau 4)

Cette certification présente de nombreux avantages pour les ingénieurs et les architectes d'entreprise. Son utilité est reconnue sur le plan professionnel. Elle peut offrir des possibilités d'avancement professionnel et améliorer les possibilités de commercialisation. Pour occuper certains postes, il est indispensable d’obtenir cette certification en sus de la certification TOGAF ou d’une autre équivalente, car elle démontre la capacité d'un architecte à aborder le rôle sous des angles variés et dynamiques. 

Conclusion

Si le cadre Zachman n'est plus aussi populaire qu'il l'était, il reste un outil précieux dans l'arsenal de l’architecture d’entreprise, et utile dans les organisations modernes. En utilisant une ontologie pour cartographier des systèmes d'information et des processus d'affaires complexes, l’efficacité du cadre Zachman est optimisée lorsqu’il est combiné à d'autres méthodologies d’AE plus populaires pour catégoriser les artefacts et spécifier les produits livrables.

Les architectes peuvent ainsi accélérer leur approche de l'architecture d'entreprise, en créant des méthodologies plus agiles et adaptables dans leur approche de la discipline.