2016/2017

Etude Benchmark sur les différents

Framework d’architecture : TOGAF,
ZACHMAN…

Réalisé par : Encadré par :

Es-sousy Khadija M. Mohammed Ait Youssef
Faiz Abdelhakim
1

Résumé
Aprés une présentation et définition des architectures d'entprerise on se
consacre aux méthodes DoDAF, Zachman et TOGAF où on présente et on
cite en détails les caractéristiques de chacune ainsi que les avantages et
les incovénients ainsi que les critiques puis une comparaison des cadres et
méthodologies d'AE et méta-modèles pour passer aux critères de choix
d'un Framework d'AE.
2

Plan
-Résumé
I-Architecture d’Entreprise............................................ 3
II-les principaux cadres méthodologiques .................... 4
1-La méthodologie TOGAF ............................................ 5
2-Le cadre d’architecture Zachman .............................. 7
3-La méthodologie DoDAF .......................................... 10
III-Comparaison des cadres et méthodologies d’AE et
méta-modèle ............................................................... 11
IV-Critères de choix d’un Framework d’Architecture
d’Entreprise ................................................................. 12
3

I-Architecture d’Entreprise
Avant de constituer une discipline à part entière avec ses cadres méthodologiques,
l’architecture d’entreprise (AE) ou « Entreprise Architecture » (EA) en anglais, est
avant tout un courant de pensée anglo-saxon qui s’est développé pour faire face aux
problématiques d’un environnement concurrentiel, dont les mutations sont en
constante accélération, afin de développer la capacité d’adaptation d’une
organisation, dans son ensemble, au changement. En théorie, son spectre apparaît
donc plus large que celui de l’urbanisation du SI « à la française » puisqu’il englobe
tous les aspects de l’organisation et pas seulement le SI. En pratique, il s’agit de
permettre à l’organisation d’intégrer plus naturellement les changements
technologiques, au regard des changements de stratégie et de l’évolution des besoins
et des usages des utilisateurs, en constituant un référentiel d’entreprise associé à une
gouvernance transverse des projets. Tout comme la démarche d’urbanisation du SI,
l’architecture d’entreprise fournit donc une vision globale et partagée de l’entreprise
afin de faciliter les analyses d’impacts et d’écarts liés aux projets. Elle formalise la
cible et la feuille de route pour réaliser les transformations requises par la stratégie.
Son application assure la cohérence de l’ensemble des projets lors de la mise en
œuvre de la transformation. De plus, elle renforce la synergie entre les processus et
l’outil informatique et participe à l’adaptation du SI à la stratégie métier.
L’architecture d’entreprise concerne toutes les fonctions de l’entreprise (pilotage,
métier et support). Elle vise à réunir l’ensemble des acteurs pour les amener à
dialoguer, à coopérer et à s’approprier leur propre système d’information pour créer
de la valeur et répondre à leurs exigences métier. Elle s’accompagne de la mise en
place d’une gouvernance, avec des responsabilités et rôles pour chacun des acteurs.
Définition de l’architecture d’entreprise La description d’une entreprise par ses
objectifs stratégiques, ses processus métier, ses données, ses acteurs, ses
applications, ses infrastructures techniques, ses ressources, ses opérations, ses
projets et les relations entre tous ces éléments, afin de :
• Documenter les états actuels et futurs des systèmes de l’entreprise, pour rendre le
fonctionnement de l’entreprise compréhensible et transparent,
• Soutenir et intégrer la planification métier et informatique,
• Fournir un contexte métier pour la priorisation et le contenu des projets,
• Tout en mettant les notions de services et de valeur ajoutée au cœur de la
démarche.
4

II-les principaux cadres méthodologiques

L’architecture d’entreprise dispose aujourd’hui de nombreux cadres
méthodologiques, exclusivement issus du monde anglo-saxon, qui visent à mettre en
œuvre ou développer l’AE. Ces cadres ne sont cependant pas équivalents et se
distinguent dans toutes leurs dimensions : problématiques qu’ils cherchent à
résoudre, résultats obtenus, mécanisme de gouvernance, processus de mise en
œuvre, acteurs clés, livrables, etc. Nous pouvons distinguer 4 grandes catégories de
cadres d’EA : Cadres génériques : cadres construits pour être génériques, réutilisables
et adaptables à plusieurs niveaux de maturité, de contextes et de types d’entreprises.
Le cadre le plus connu, TOGAF, se trouve dans cette catégorie, tout comme le cadre
anglais PEAF. Le cadre de Zachman est également souvent cité, bien que celui-ci ne
soit pas à proprement parler un cadre mais plutôt un tamis d’analyse des différentes
visions de l’entreprise. En France, on peut notamment citer la trame de l’AE issue des
travaux du club Urba-EA, basée sur l’urbanisme du SI tel que décrit depuis 2001 dans
l’ouvrage de Christophe Longépé « Le projet d’urbanisation du SI » ou encore la
méthode libre Praxeme crée en 2004. Cadres spécifiques à un métier : ce sont des
cadres méthodologiques conçus autour de problématiques métiers précises comme
celles de l’administration publiques (FEA pour l’administration américaine) ou de
l’armée (DODAF pour l’armée américaine). En France, on peut citer la méthode
AGATE de la direction générale de l’armement qui comporte des similitudes avec le
cadre DODAF et avec celui de l’OTAN, NAF et plus récemment le CCU ou Cadre
Commun d’Urbanisation du SI de l’état élaboré par la DISIC, qui dote la France depuis
2012 d’un cadre sous-titré « Cadre commun d’Architecture d’Entreprise applicable au
système d’information de l’Etat et à sa transformation ». Cadres « éditeur » : ce sont
des cadres alignés avec les visions et capacités logicielles de solutions développées
par des éditeurs, comme le cadre d’Oracle (Oracle EA) ou bien celui de Microsoft
(Microsoft Entreprise Strategy Program). Ils décrivent la mise en pratique de
l’architecture d’entreprise, selon leurs auteurs, qui permet de tirer le meilleur parti
des solutions qu’ils développent. Cadres « pratiques d’entreprise » : ces cadres
méthodologiques regroupent des pratiques spécifiques d’entreprises reconnues telle
que le Gartner Group, dont le Gartner EA Framework reflète exactement la manière
dont le Gartner Group pratique l’architecture d’entreprise pour lui-même et ses
clients. Ces cadres méthodologiques sont souvent comparés ou rapprochés avec
d’autres référentiels tels qu’ITIL ou COBIT, qui ne sont pas directement des méthodes
d’architecture d’entreprise mais qui fonctionnent plutôt en complémentarité pour
améliorer le fonctionnement et la gestion du système d’information. ITIL s’attache en
effet à décrire les bonnes pratiques permettant de garantir la qualité des SI et des
niveaux de services via une approche processus définie, tandis que COBIT, depuis sa
version 5 en 2012, propose un cadre de gouvernance du SI très étendu qui inclut le
processus d’architecture d’entreprise.
5

En 2007, Roger Sessions, l’un des experts reconnus dans le domaine de l’architecture
d’entreprise et de la complexité des systèmes d’information et également MVP
Microsoft, a fourni une comparaison des quatre principaux cadres américains
d’architectures d’entreprise selon 12 critères et 4 niveaux d’adéquation ou de
satisfaction (de 1 à 4, 4 étant très satisfaisant/adéquat). Bien que ces cadres aient
évolué sensiblement depuis cette étude, ce tableau constitue néanmoins une base
d’analyse et de comparaison intéressante pour illustrer les différentes natures de ces
méthodes. Nous y ajoutons également notre évaluation la méthode « d’AE à la
française », telle que promue par le Club Urba-EA.

Ce tableau montre que, le cadre de Zachman mis à part, chacun des autres cadres
apparaît équivalent globalement mais selon des caractéristiques spécifiques
différentes. La trame d’AE du Club-Urba quant à elle propose une alternative
française pour la démarche d’architecture d’entreprise, sans toutefois atteindre le
niveau de standardisation de TOGAF.

1-La méthodologie TOGAF

a-Présentation de TOGAF
TOGAF (The Open Group Architecture Framework) est une méthode détaillée et un
ensemble d’outils, indépendant de toute industrie et servant à développer une AE.Il
s’appuie sur un processus de développement itératif, basé sur les meilleures
pratiques. Il permet d’implémenter des solutions ouvertes, de simplifier les processus
associés à la conception, à la planification, à l’acquisition et à l’intégration des
systèmes, et d’aider les directeurs des systèmes d’information (SI) à mieux
communiquer leurs objectifs et stratégies au reste de l’organisation et plus
spécifiquement aux décideurs. TOGAF se compose de trois éléments principaux : The
Architecture Development Method (ADM), The Architecture Content Framework et
The Enterprise Continuum and Tools.
Le premier élément, l’ADM est le cœur de TOGAF. C’est le processus itératif de
développement de l’architecture. L’aspect itératif est fondamental, car il n’y a que
6

trois façons de bâtir une architecture et, toutes trois sont itératives (The Open Group,
2009 : 65) :
− Par essai/erreur
− Commencer de zéro
− Rétro-ingénierie en partant du système existant.

The Architecture Development Method

L’Architecture Development Method (ADM) constitue le cœur de TOGAF. Il s’agit
d’une démarche itérative de conception et de mise en œuvre de l’architecture
d’entreprise centrée sur les exigences (voir ci-dessous). Elle décrit chaque étape avec
les entrées, les sorties et les livrables attendus, ainsi qu’un ensemble de techniques
applicables durant ces étapes, en cohérence avec le cadre de contenu décrit plus loin.
Après une première étape préliminaire d’analyse et d’adaptation de la méthode, les
phases A à D consistent à élaborer la cible à partir de l’existant. Les phases E et F
permettent de choisir des solutions et d’élaborer une feuille de route, tandis que
l’étape G correspond à la mise en œuvre effective. La phase H permet en outre,
d’affiner la méthode avant la prochaine itération.
7

b-Critique de la méthodologie
Le reproche principal souvent fait à TOGAF est l’absence d’un cadre à proprement
parler. Cela est corrigé dans la version 9 avec l’apparition du Architecture Content
Framework. Aussi, le manque d’intégration subsiste comme étant une problématique
majeure. On notera que ce point est discuté par l’Open Group dans l’introduction de
leur recueil : « À l’heure actuelle, l’état de l’art est tel que l’intégration ne peut être
accomplie qu’en bas du spectre d’intégrabilité. Au fur et à mesure que les entreprises
travaillent sur des thèmes similaires comme l’architecture orientée service,
émergeront des modèles de données universels et des structures de données
standard permettant ainsi une intégration facilitée du haut du spectre ».Enfin, les
problématiques d’alignement stratégique sont 17 également un point faible de
TOGAF. En effet, la stratégie est exclue d’ADM en ce sens qu’elle est le point d’entrée
à la méthode, mais que, par conséquent, elle ne se retrouve pas définie, documentée
et modélisée comme les autres concepts de l’AE. L’aspect itératif du processus ne
renseigne pas par la suite sur les mesures à prendre pour rester aligné. En résumé, la
méthodologie TOGAF comporte trois limites importantes : le manque d’intégration
entre les différents artefacts proposés, l’absence d’information sur la maintenance du
cadre et enfin l’exclusion des aspects stratégiques.

2-Le cadre d’architecture Zachman

a-Présentation du cadre
Le cadre élaboré par John. A. Zachman est considéré comme étant à l’origine de la
discipline. Ce cadre est le plus comparé et utilisé dans les entreprises. Créé en 1987
(Zachman, 1987), il est rapidement étendu et formalisé.
L’idée principale est qu’un système complexe, qu’il soit ou non un système TI, peut
être efficacement décrit en utilisant un vocabulaire commun et un ensemble de
perspectives prédéfinies et acceptées par l’ensemble des parties. L’objectif est de
bâtir un schéma de classification donnant une vue holistique de l’entreprise, de son
organisation physique et TI par le biais d’un cadre à 30 cellules.
Il se présente sous la forme d’une matrice deux dimensions de 5 lignes (perspectives)
et 6 colonnes (abstractions).Les 30 cellules qui en résultent permettent d’avoir un
point de vue particulier sur le système lorsque l’on considère seulement une ligne, ou
une vue détaillée d’un aspect du système si l’on considère une colonne. La vue
d’ensemble des 30 cases est 10 intégrée et cohérente dans la mesure où chaque
cellule représentée à un niveau n, est une représentation plus détaillée et contenant
plus de contraintes que celle du niveau supérieur n+1.Le cadre Zachman « propose
une structure logique pour classifier et organiser les représentations d’une
8

entreprise, en différentes dimensions et chaque dimension pouvant être considérée

en différentes perspectives »

Les six colonnes correspondent à différentes abstractions ou différentes façons de

décrire une même réalité. Chacune isole un aspect du système à l’étude. Les six
colonnes sont : les données, les fonctions, les réseaux, les acteurs, les moments et les
buts. Elles répondent aux questions « Quoi », « Comment», « Où », « Qui », «
Quand», « Pourquoi ».

-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 marché 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é.
9

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é.

b-Critique du cadre
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 artefacts de la
colonne « Qui ? ».
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.
10

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.

3-La méthodologie DoDAF

a-Présentation de DoDAF
À l’instar de TOGAF, DoDAF (Department of Defense Architecture Framework) ne se
résume pas à un simple EAF ; il englobe des concepts d’architecture, différentes
directives et règles ainsi que les meilleures pratiques et méthodes pour faciliter le
développement d’une architecture capable de soutenir les décisions majeures à
travers l’ensemble des programmes du Département américain de la Défense. Trois
éléments principaux peuvent être retenus : les différents points de vue (ou
viewpoints dans la terminologie DoDAF), les modèles associés à chacun de ces points
de vue et enfin la méthodologie appelée le 6-Step Architecture Development Process.
Les quatre vues originales (All View (AV), Vue Operational (OV), Vue Systems (SV) et
Vue Technical Standards (TV)) de DoDAF ont été revues dans la version 2 pour mieux
répondre à la nouvelle approche centrée sur les données plutôt que sur les
applications. Ainsi, la vue All (AV) décrit les aspects transversaux de l’architecture qui
relient toutes les vues. La vue Capability (CV) articule les besoins en capacité, les
calendriers de livraison ainsi que les capacités de déploiement. La vue Data and
Information (DIV) présente les relations entre les données et les structures pour la
capacité, les requis opérationnels, les processus de réingénierie, les systèmes et les
services. La vue Operational (OV) inclut les scénarii opérationnels, activés et requis
qui supportent les capacités définies dans la vue CV. La vue Project (PV) décrit les
liens et dépendances entre les aspects opérationnels, les requis en capacité et les
projets en eux-mêmes. La vue Services (SvcV) est la représentation et la modélisation
des solutions en y incluant les acteurs, activités, services et échanges provenant des
vues OV et CV. La vue Standards (StdV) renferme un ensemble de règles et de normes
(opérationnelles, d’affaire, techniques, externes, 18 etc.) à mettre en place pour
l’implémentation des systèmes, mais également pour respecter les requis des vues
OV et CV. Enfin, la vue Systems (SV) décrit l’ensemble des systèmes, leurs
interconnexions, leurs compositions et contextes fournissant ainsi un support aux
vues OV et CV.

DoDAF propose également une méthodologie itérative en six étapes aidant à la

construction et la maintenance des vues et des artéfacts. Cette méthodologie est
présentée comme donnant des lignes directrices que pourront suivre, mais surtout
adapter les architectes pour arriver à leurs fins :

− La première étape consiste à déterminer l’objectif de l’AE. Cela passe par la

définition de ces objectifs et besoins exprimés par les utilisateurs
11

− La deuxième étape a pour but de définir l’étendue de l’AE désirée. En effet,

l’étendue de l’architecture (fonctions, délais, activités, etc.) permettra d’éclaircir le
niveau de détail désiré ainsi que les premiers éléments à définir (processus, données,
applications, etc).

− La troisième étape permet de délimiter les besoins en informations à produire dans

le cadre de l’étendue défini précédemment.

− La quatrième étape a pour objectif de collecter, organiser, mettre en corrélation et

stocker des données. Les architectes doivent sélectionner les artefacts à produire.

− La cinquième étape permet de s’assurer de la concordance, pertinence et

conformité des données par rapport aux objectifs fixés à la première étape. Cela peut
permettre de se rendre compte d’un manque d’informations sur l’un des objectifs et
ainsi y remédier avant la production des artefacts.

− Enfin, la sixième étape s’appuie sur les étapes quatre et cinq pour produire les
artefacts et les vues conformément aux données définies et vérifiées précédemment.

b-Critique de la méthodologie
L’un des points importants de DoDAF est l’ensemble des modèles associés à chacune
des vues. Cela vient faciliter le travail des architectes et permettra in fine plus de
cohérence entre les artefacts. En effet, une fois les trois premières étapes effectuées,
les architectes sélectionnent, en lien avec les besoins en données, les modèles
adéquats parmi ceux proposés. Néanmoins, quelques éléments de définitions ou
artefacts sont dépendants du domaine, ce qui rend certains modèles ou processus
peu exploitables.Aussi, selon le Bureau du Secrétariat à la Défense la complexité des
modèles ne permet pas de les présenter à la Haute Direction et aux planificateurs
stratégiques sans modifications préalables. Cette complexité est accentuée par le fait
que le support et les orientations fournies pour l’utilisation d’UML sont limités.

III-Comparaison des cadres et méthodologies d’AE et

méta-modèle
Le tableau suivant a pour but d’aider à comprendre les trois cadres et méthodologies
présentées dans la section précédente à la lumière de la norme ANSI/IEEE 1471-2000.
Il permet de confronter les cadres et méthodologies aux éléments retenus dans la
section 2.2.2. Comme on peut le voir, le cadre Zachman est le seul à respecter tous
les éléments retenus de la norme.
12

IV-Critères de choix d’un Framework d’Architecture

d’Entreprise
I. Un bon framework sera souvent un framework très utilisé, pouvant de ce fait bénéficier
d’une expertise plus étendue, plus accessible, d’un outillage plus large et plus riche, de
formations et d’ouvrages explicatifs plus nombreux. Quel est l'état de popularité des
différents frameworks ? Google Insight for Search donne une tendance.

II. En tant qu'expert de la mise en œuvre de démarches d'architecture d'entreprise, nous

sommes souvent interrogés sur le choix d'un framework d'Architecture d'Entreprise.
Cette question est une bonne question. A condition de ne pas se la poser trop tôt et à
condition de comprendre que la réponse constituera un point de départ et non pas une
solution prête à l'emploi.

Il n'existe pas de démarche d'architecture d'entreprise sans framework. Un framework est

une trame, un espace de langage commun, de coordination et de collaboration pour les
acteurs, à partir duquel chaque entreprise bâtit sa démarche de façon itérative.
Un bon framework est le GPS de la démarche d'architecture d'entreprise. Ce n'est pas lui
13

qui décide de la destination ni de la vitesse et ce n'est pas lui qui conduit. Mais c'est une
aide précieuse pour établir un itinéraire et rester dans la bonne direction.

Revenons à la question "quel framework d'architecture d'entreprise choisir ?". Un

consultant vous dira que tous les frameworks sont bons, ce sont les contextes d'usage qui
changent. Un bon consultant vous donnera quelques critères de choix.

Premier travail : il faut identifier les frameworks existants. Loin d'être une liste exhaustive,
citons Zachman, Gartner, IAF, FEAF, DoDaF - C4ISR, TEAF, EAP, PEAF et Togaf. Pardon aux
absents.

Le premier critère est le spectre couvert : référentiel, processus ou cycle de transformation,

ancrage avec le cycle projet, méthode de modélisation, gouvernance, organisation et
compétences, relations avec les autres domaines (gestion des services, gestion de
portefeuille, budget, gestion des risques....). Attention, il ne s'agit pas de tout couvrir tout
de suite, mais de savoir jusqu'où votre framework pourrait vous accompagner.

Le second critère porte sur le degré de prescription ("la prescrivité"). Certains frameworks
sont très prescriptifs. Ils disent comment faire. D'autres frameworks sont très génériques.
Ils disent quoi faire et vous laissent libre du comment faire. Les frameworks très prescriptifs
peuvent permettre des implémentations plus rapides mais moins flexibles. Les frameworks
très génériques demandent un effort d'implémentation plus grand mais offrent des marges
de manœuvre.

Pour faire simple, plus la maturité de la pratique (ou plutôt de la professionnalisation) est
grande, plus un framework générique est préférable.

Troisième critère : la connectivité du framework. Un bon framework d'architecture

d'entreprise sait se limiter à son domaine. Il sait reconnaître le besoin de coexister avec
d'autres cadres de management et de pilotage. Il doit donc pouvoir se connecter à ces
cadres, souvent associés à d'autres frameworks (Cobit, Itil, PmBok, eScm, CMMI.....). Les
très bons frameworks d'Architecture d'Entreprise savent aussi se connecter avec d'autres
frameworks du domaine.

Ces trois critères permettent déjà de bien filtrer parmi les frameworks du marché.

Plusieurs autres critères sont à envisager : le coût d'accès (rarement problématique en soi),
l'ouverture (c'est-à-dire l'accès à la documentation), l'évolutivité (nombre et vitesse des
versions), l'outillage (le fait que des logiciels viennent supporter le framework),
l'internationalisation (important dans les grands groupes), la neutralité vis-à-vis des
14

technologies et des fournisseurs, le dynamisme (existence d'une communauté large et

active autour du framework).

Parmi les critères à retenir, figure celui de la popularité. En effet, un bon framework sera
souvent un framework très utilisé, pouvant de ce fait bénéficier d'une expertise plus
étendue, plus accessible, d'un outillage plus large et plus riche, de formations et d'ouvrages
explicatifs plus nombreux.

Premier atout : la popularité accroît la probabilité de trouver des professionnels

connaissant ce framework. Autre atout, certes délicat à jouer, un framework populaire
profitera aussi de critiques plus nombreuses. La popularité génère aussi sa contre culture,
ce qui doit être pris comme un facteur de dynamisme et d'amélioration. Plus un framework
suscite de critiques, plus vous choisirez en connaissance de cause.

Donc, si la popularité ne signifie pas la qualité, elle ne peut être négligée lors du choix.
Reste à répondre à la question : comment mesurer la popularité d'un framework ?
Une solution est de se tourner sur Internet. Google offre un outil pour se donner une idée :
Google Insight for Search.

Nous avons essayé l'outil avec quatre frameworks bien connus : Zachman, DoDaF, FEAF et
Togaf. Depuis 2007, Togaf dépasse largement les autres référentiels allant parfois jusqu'à
recueillir 4 fois plus de demandes (schémas sur le site www.architecture-forum.org).

Bien entendu, l'outil de Google comporte des biais. Bien sûr le choix des frameworks à
comparer pourrait être revu. Bien sûr il ne faut pas faire dire à ce graphique ce qu'il ne dit
pas. Mais disons que cela indique une tendance claire. Togaf de l'Open Group est sans
doute le framework d'architecture d'entreprise le plus populaire.

Togaf offre sans doute la meilleure couverture d'une démarche d'architecture d'entreprise.
Il est très générique. Sa connectivité est excellente. Son coût d'accès est très bas. Il est
totalement ouvert, très évolutif (9 versions en 15 ans). Togaf est outillé par tous les grands
éditeurs, il est international (plus de 25 pays représentés dans l'Architecture Forum) et
d'une neutralité bienveillante. La communauté (Architecture Forum) est active (4
conférences des praticiens de l'architecture par an) et croissante (plus de 10 000 certifiés).