[L. Gamassia – Q. Maurice – D. Thomas – FI 13]

En 1987, John Zachman, salarié chez IBM, propose un méta-modèle architectural ayant pour but de structurer une vision de l’entreprise et d’en gérer la complexité. Son travail prend comme point de départ le système d’information (SI), puis s’étend par la suite sur une description globale de l’entreprise.

Définitions des concepts

Pour comprendre tout l’enjeu de la méthode Zachman et l’intérêt de son application, principalement au coeur de l’architecture logicielle du système d’information d’une entreprise, il est important de définir le cadre de son application en explicitant l’ensemble des bonnes conduites et critères d’analyse d’une architecture logicielle.

Architecture logicielle en entreprise

L’architecture logicielle décrit d’une manière symbolique et schématique les différents éléments d’un ou de plusieurs systèmes informatiques, leurs interrelations et leurs interactions. Contrairement aux spécifications produites par l’analyse fonctionnelle, le modèle d’architecture, produit lors de la phase de conception, ne décrit pas ce que doit réaliser un système informatique mais plutôt comment il doit être conçu de manière à répondre aux spécifications. L’analyse décrit le « quoi faire » alors que l’architecture décrit le « comment le faire ».

Les propriétés d’une bonne architecture logicielle

Une bonne architecture logicielle se doit d’allier complexité et simplicité. Pourtant deux mots strictement contraire, car en effet, l’intérêt se voit réduit de proposer une architecture logicielle pour un SI d’envergure relativement faible. C’est justement la taille de ce SI qui est traduit ici par la complexité, un SI riche et de grosse dimension, qui doit cependant offrir une facilité de compréhension, d’utilisation, et d’intervention. Bien sur d’autre propriétés sont à prendre en compte, la disponibilité et la sûreté, ainsi que l’adaptabilité et la possibilité d’évolutions futures. Toutes ces propriétés, une fois évaluées permettent de statuer en faveur d’une “bonne” architecture logicielle. Bien sur chaque entreprise entendra par bonne l’architecture qui lui convient le mieux par la suite, selon ses besoins et ses attentes.

Critères de qualité logicielle

L’interopérabilité, qui peut être soit intrinsèque, soit extrinsèque, et exprime la capacité du logiciel à communiquer et à utiliser des ressources interne/externes, comme par exemple des documents externes, ou des modules du SI en interne.
La portabilité et la compatibilité, expriment la possibilité de compiler le code source et d’exécuter le logiciel sur des environnements différents, ainsi que sur des environnements plus récents (compatibilité ascendante) ou plus vieux (compatibilité descendante).

La validité exprime la conformité des fonctionnalités du logiciel par rapport à celles décrites dans le cahier des charges, et la vérifiabilité, la simplification de vérification de cette validité.

L’intégrité exprime la faculté du logiciel à protéger ses fonctions et ses données d’accès non autorisés.

La fiabilité exprime la faculté du logiciel à gérer correctement ses propres erreurs de fonctionnement en cours d’exécution, et la maintenabilité la simplicité de correction du logiciel (parfois même à chaud)

La réutilisabilité exprime la capacité de concevoir le logiciel avec des composants déjà conçus tout en permettant la réutilisation simple de ses propres composants pour le développement d’autres logiciels.

L’extensibilité exprime la possibilité d’étendre simplement les fonctionnalités d’un logiciel sans compromettre son intégrité et sa fiabilité.

D’autres critères, comme l’efficacité du logiciel par rapport aux ressources offertes, l’autonomie, la transparence vis à vis de l’humain ou encore la convivialité peuvent être pris en compte pour l’évaluation d’une architecture logicielle.

Intérêt d’une bonne architecture logicielle

Le graphique ci-dessus illustre l’intérêt d’évaluer une architecture logicielle dès le départ. En effet, au cours du temps, et selon plusieurs facteurs (comme la croissance de l’entreprise, l’augmentation de ses besoins) peuvent conduire à des défaillances du logiciel. si celui-ci a été construit en se basant sur une bonne architecture, étudiée au préalable, alors les modifications ne seront que sources de bénéfices pour l’entreprise, dont le logiciel tendra à devenir “parfaitement stable et fonctionnel”. A l’inverse, l’absence architecture cumulée aux effets de bord va alors demander de nombreuses corrections d’erreurs, qui dans la plupart des cas vont conduire à de nouvelles erreurs, jusqu’à aboutir à un logiciel tout à fait non fonctionnelle, et donnera souvent lieu à une refonte complète du SI par exemple, si c’est le but du logiciel.

Le framework Zachman

Le framework de Zachman, c’est une matrice  représentant le SI d’une entreprise à travers six colonnes et six rangs.

En colonne, nous retrouvons les six questions que toute personne se pose en essayant de comprendre un concept : Quoi ? Comment ? Où ? Qui ? Quand ? et Pourquoi ?

Les six rangs sont en réalités six couches allant de la plus conceptuelle (haut) vers la plus concrète et applicative (bas).

Le croisement de chaque colonne et de chaque rang s’appelle un artefact.

 La dimension verticale

Zachman fournit pour chaque colonne un modèle d’illustration.

Le « Quoi ? » : C’est la composition du produit. Dans le cas d’un logiciel, il s’agit des données. Un modèle d’illustration pour le « Quoi ? » peut être : Objet – relation – Objet

Le « Comment ? » : On parle ici du fonctionnement et de la transformation du produit. Le modèle d’illustration est le suivant : Processus – input/output – Processus

Le « Où ? » : Il s’agit de l’emplacement du produit Parle-t-on d’un marche national ? International ?. Le modèle d’illustration est : Nœud – lien – Nœud

Le « Qui » ? : Cette colonne regroupe personnel et partenaires en leur attribuant un rôle et des fonctions. Le modèle d’illustration est : Acteur – Tache – Acteur.

Le « Quand ? »  En matière de planning on définit dans cette colonne les évènements, leur durée et leur cycle de vie. Le modèle d’illustration est : Événement – cycle – Événement.

Le « Pourquoi ? » : On cherche ici à illustrer la motivation par rapport aux objectifs qui régissent l’entreprise. Le modèle d’illustration est Finalité – moyens – Finalité.

 La dimension horizontale

Nous retrouvons en réalité six couches qui représentent six points de vue différents

 Le  « But » (contexte) – Point de vue du planificateur : Ce rang décrit les limites de l’entreprise en fonction de leurs objectifs. Nous y retrouvons notamment les valeurs de l’entreprise, les secteur géographique où elle opère, les partenaires et le personnel, etc..

Le « Modèle métier » (conceptuel) – Point de vue du propriétaire : Ce rang décrit les modèles, l’architecture et les représentations utilisés par les propriétaires des process métier.  Il se focalise sur les habitudes d’utilisation d’un produit

Le « Modèle système » (logique) – Point de vue du concepteur : Ce rang décrit les modèles, l’architecture et les représentations utilisés par les architectes et ingénieurs. Il est à cheval entre les besoins de l’entreprise et ce qu’il est techniquement possible de faire.

Le « Modèle technologique » (Physique) – Point de vue du constructeur : Avec ce rang, nous rentrons dans le concret. Ce rang décrit les modèles, l’architecture et les représentations utilisées par les techniciens et ingénieurs qui modélisent et créent les produits.

 La « Représentation détaillée » (Hors contexte) – Point de vue du sous-traitant : Ce rang décrit les composants externes à l’entreprise qui seront réutilisés dans le produit final.

 Le « Fonctionnement de l’entreprise » : Ce dernier rang reprend sous forme de synthèse les éléments de chaque couche en exprimant leur réelle mise en œuvre dans toute leur complexité.

Les avantages de Zachman

Zachman est un des seuls modèles qui permet d’introduire une notion temporelle grâce à sa cinquième colonne. Il permet donc de coordonner des éléments selon un planning aussi bien sur le court que sur le long terme.

Zachman permet de mettre en évidence les incohérences de manière aisée : chaque colonne doit contenir des informations différentes certes, mais cohérentes entres-elle. Par exemple, si une personne figure dans l’organigramme d’un artefact de la colonne « Qui ? », elle doit en théorie figurer dans tous les autres artefact de la colonne « Qui ? ».

Les inconvénients de Zachman

Hélas, ce framework reste une vision utopique de l’entreprise qui ne pourra jamais respecter l’intégralité de la matrice et remplir chaque artefact, car la maintenant en matière de documentation est très conséquentes. De plus, les artefacts ne sont pas tous adaptés à tout type d’entreprise. Les sociétés dans le secteur de l’informatique ou du réseau y trouvent plus facilement leur compte.

Zachman est donc plutôt un modèle que l’on essaie d’approcher, consciemment ou inconsciemment, car il représente un ensemble de bonnes pratiques qui permet d’éviter les erreurs, les confusions,  les refontes et qui finalement mène l’entreprise à une cohésion de groupe.

 

TOGAF : Courte definition

Elaboré au milieu des années 1990, le Togaf (pour The Open Group Architecture Framework) est reconnu aujourd’hui comme un standard industriel. Ce cadre d’architecture porté par le consortium Open Group fait l’objet de mises à jour régulières.
Indépendant du secteur d’activité, Togaf n’impose pas de modèle de formalisation d’architecture, mais en recommande en revanche l’utilisation. Sa mise en œuvre n’est donc pas antinomique avec l’utilisation de méthodes de conception d’architecture, comme Zachman ou tout autre infrastructure métier formalisée.
               
Comparaison: Togaf versus Zachman

Les points communs et différences entre Zachman et TOGAF peuvent être exprimés selon plusieurs critères:

Stratégie de l’entreprise :  Chez Zachman, il convient de faire correspondre exigences stratégiques et processus; CHez Togaf, il s’agit du point à analyser en premier.
Méta-Modèle: Relativement simple et formalisé chez Togaf, le méta-modèle de Zachman est quant à lui très exhaustif, mais n’est cependant pas formellement décrit.
Process étape par étape : Le cadre Zachman ne fournit aucune indication pour une mise en oeuvre étape par étape, au contraire de Togaf qui explicite clairement la manière de créer une architecture à travers l’ADM. Ainsi, il est possible de modéliser l’architecture cible chez Zachman, sans toutefois avoir de guide pour une transition du SI, à contrario de Togaf qui propose des guides pour la plannification de la migration et la conduite au changement.
Périmètre de l’entreprise : La méthode Zachman est connue pour son ehaustivité et prend donc en compte l’ensemble des niveaux de l’entreprise. De son côté, Togaf ne prend en compte que 4 niveaux d’abstractions.
Complexité : Qu’il s’agisse du cadre Zachman ou de Togaf, la complexité de mise en oeuvre de ces méthodes nécessite bien souvent l’appui d’experts certifiés, aptes à exploiter ces modèles et les adapter aux SI des entreprises.

Nos sources :

http://www.business-patterns.com/Articles/ZachmanFrameworkRowsDetailed.pdf
 http://pegase.scd.inpl-nancy.fr/theses/2010_CASTRO_ESPIRITU_E.pdf
 Wikipédia