Eugenio Mauri: présentation de TOGAF

TOGAF
Un cadre d’architecture pour industrialiser les
projets
Master Management des Systèmes d’Information et de Connaissance
UE09 : Pratiques de l’entreprise et méthodes d’analyse
Présentation de Dominique Le Mouël et Eugenio Mauri

TOGAF : Un cadre d’architecture pour industrialiser les projets

Sommaire

1 Les grandes lignes .......................................................................................................... 2
2 L’EA et les principaux « Framework » ............................................................................. 2
2.1 Une définition de L’EA ............................................................................................. 2
2.2 Généalogie des « Framework »............................................................................... 3
2.3 Le « Framework de Zachman » ............................................................................... 4
2.4 L’Open Group et la mise en place de TOGAF ......................................................... 6
2.5 TOGAF9 et ses apports .......................................................................................... 6
2.6 L’évolution de l’Enterprise Architecture.................................................................... 7
3 Les grands principes de TOGAF ..................................................................................... 8
4 Présentation de la démarche méthodologique ................................................................ 9
5 L’ADM ............................................................................................................................11
5.1 Principes de l’ADM .................................................................................................11
5.2 Les phases de l’ADM .............................................................................................12
5.2.1 Phase préliminaire ..........................................................................................12
5.2.2 Phase A: Architecture Vision ...........................................................................13
5.2.3 Phase B: Business Architecture ......................................................................14
5.2.4 Phase C: Information Systems Architectures ..................................................15
5.2.5 Phase D: Technology Architecture ..................................................................16
5.2.6 Phase E: Opportunities & Solutions.................................................................16
5.2.7 Phase F: Migration Planning ...........................................................................17
5.2.8 Phase G: Implementation ................................................................................18
5.2.9 Phase H: Architecture Change Management...................................................19
5.3 Le Cœur de l’ADM : la gestion des exigences ........................................................20
5.4 Cycle de vie et utilisation pratique de l’ADM ...........................................................20
5.4.1 Mode itératif ....................................................................................................20
5.4.2 Adaptation au contexte de l’entreprise ............................................................21
6 « ArchiMate language » et TOGAF ................................................................................21
7 Quelques critiques .........................................................................................................22
8 Pour conclure.................................................................................................................22
9 Bibliographie ..................................................................................................................23

eugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 1


1 Les grandes lignes
Cette présentation de TOGAF(The Open Group Architecture Framework) s’inscrit dans le
cadre de l’UE09 de notre Master qui propose d’aborder une problématique de SIC.

De nombreux cadres, méthodes et outils existent sur le marché de l’Enterprise
Architecture (EA)utilisé par les entreprises.

Par la mise en place de telles approches, les entreprises mettent en relief un certain nombre
de difficultés et les surmontent.

De nouvelles problématiques surgissent et restent sans réponse : l’emploi de ces approches
génère de nouveaux risques.

Nous proposerons dans la suite de ce document :

L’EA
o Une définition de l’EA
o Les principes du 1er cadre de référence : « Framework de Zachman »,
o Quelques rappels historiques sur les évolutions de l’EA
Les 4 grands principesretenus par TOGAF
La démarche méthodologiqueutilisée par l’ADM (le cœur de TOGAF)
Quelques critiques cités autour de TOGAF
Des propositions autour des évolutions de l’EA

2 L’EA et les principaux « Framework »

2.1 Une définition de L’EA
La définition retenue de l’Enterprise Architectureque nous donnons ici est celle du
Gartner Group« L’architecture d’entreprise est un processus de transformation de la vision
et de la stratégie en changements effectifs dans l’entreprise en créant, communicant et en
améliorant les principes clés et les modèles qui décrivent la cible à atteindre pour l’ensemble
des ressources de l’entreprise et en rendant possible son évolution ».

L’EA peut aussi être définie comme «un cadre de référence proposant un méta-modèle des
concepts, des règles, une architecture fonctionnelle générique type, une démarche
méthodologique ».

Il est à noter que l’EA - traduite au travers de frameworks- reste indépendant des outils et
technologies utilisées pour la mettre en œuvre.



2.2 Généalogie des « Framework »
Voici un bref aperçu des « Framework » mis en place dont les 2 plus importants souvent
cités sont :

Le « Framework de Zachman »  le précurseur
TOGAF



2.3 Le « Framework de Zachman »
Les débuts de l’EA ont été marqués en 1987 par John Zachmancréateur du 1er Framework.

Il présentait un nouveau modèle pour visualiser et communiquer sur les architectures
d’entreprises.

Zachman décrivait son modèle comme un ensemble de représentations pertinentes pour
décrire l’entreprise, qui une fois établies constituent une base de références pour celle-ci.

C’est une approche de représentation de l’architecture d’entreprise organisée suivant
différents points de vue et selon différents concepts (cf. site internet : www.zifa.com)

Il est constitué d’un tableau à 6 lignes et 6 colonnes dans lequel chaque cellule identifie un
type de modèle qui peut être développé pour documenter l’entreprise et son SI.

Cette matrice croisée représente :

En ligne, les points de vue ou perspectives pris par les divers acteurs (ce sont les
lignes de la matrice)
En colonne, les concepts de base pour décrire une architecture qui répond à une
question



Une autre représentation plus graphique.



2.4 L’Open Group et la mise en place de TOGAF
L’Open Group travaille avec des clients, des fournisseurs et d’autres organismes proposant
des normes. Son rôle est principalement de :

Capter, comprendre et aborder les besoins courants des entreprises, établir des
politiques et partager des « best practices »,
Faciliter l’interopérabilité, développer un consensus en intégrant des spécifications et
des technologies Open Source.

La 1ère version de TOGAF a été mise en place par l’Open Group en 1995.

A dernière version est la V9.0 datant de Février 2009.

« TOGAF est une méthode, largement reconnue et utilisée ainsi qu’un ensemble d’outils
pour concevoir, planifier, implémenter et gouverner une architecture d’entreprise.

Cette méthode ne prescrit aucun livrable obligatoire : les architectes peuvent utiliser les
livrables décrits dans TOGAF ou d’autres livrables associés à d’autres frameworks » (cf. C.
Longépé).

TOGAF reste une base de départ pour chaque entreprise, il reste à elle à construire
son propre cadre.

2.5 TOGAF9 et ses apports
Un des apports important de TOGAF9 est le méta model d’architecture. Il s’applique à
toutes les phases du cycle ADM.

TOGAF est modulaire et il ne préjuge ni d’un outil ni d’un formalisme particulier.

TOGAF9fournit de plus, une grille de critères d’évaluation pour choisir un outil.

Sa modularité offre de la souplesse dans le processus d’adoption des entreprises. En effet,
les entreprises ont déjà souvent un voir plusieurs méta model couvrant tout ou partie des
préoccupations d’architecture et passez vers un nouveau méta model en mode big-bang
n’est souvent pas très réaliste.



2.6 L’évolution de l’Enterprise Architecture
Aux USA, avec le Clinger-Cohen Act (en 1996) cette discipline a pris son essor. Cette loi a
imposé aux administrations fédérales américaines l’élaboration d’une Enterprise IT
Architecture.

Depuis toutes les grandes entreprises américaines ont adoptés ce principe.

En 1998, le travail fait sur TAFIM (Technical Architecture Framework for Information
Management) 1a été confié à l’Open Grouppour l’intégrer à TOGAF (The Open Group
Architecture Framework).

En parallèle de l’EA mis en avant dans les pays anglo-saxons, une démarche d’urbanisation
des SI est apparue en France.

Le précurseur de cette démarche reste Jacques Sassoon avec son ouvrage « Urbanisation
des systèmes d'information » paru en 1998 qui pose les bases de la discipline.

Ses principes ont été repris en France par le Club URBA EAfondé en 2000 et par le
CIGREF (Club informatique de grandes entreprises françaises) au travers de leur ouvrage
« Accroitre l’agilité des SI » paru en 2003.

En 2007, la création du CEISAR (Center of excellence for Enterprise Architecture adossé à
l’Ecole Centrale de Paris) permet de rassembler toutes les initiatives et de former tous les
jeunes ingénieurs et permet de perfectionner les ingénieurs expérimentés en matière d’EA.

Nous pouvons citer les principaux standards de l’EA : (source IFEAD, Institute for Enterprise
Architecture Developments) 2

Integrated Architecture Framework (IAF)
Federal EnterpriseArchitecture Framework (FEAF)
Technical Architecture Framework For Information Management (TAFIM)
Computer Integrated manufacturing Open System Architecture (CIMOSA)
…

1
TAFIM (source Wikipédia): is a 1990s reference model for enterprise architecture
development, defined by the United States Department of Defense (DoD) in 1986. Technical
Architecture Framework for Information Management (TAFIM) is a 1990s reference
model for enterprise architecture development, defined by the United States Department of
Defense (DoD) in 1986.

TAFIM provides enterprise-level guidance for the evolution of the DoD Technical infrastructure. It
identifies the services, standards, concepts, components, and configurations that can be used to guide
the development of technical architectures that meet specific mission requirements
2
IFEAD : site internet www.enterprise-architecture.info



3 Les grands principes de TOGAF
L’objectif 1er de TOGAF est de désenclaver le travail des urbanistes en le remettant au
centre de la gouvernance du système d’information.

« Pour être pertinente, la cartographie de l’organisation de l’entreprise, de ses processus, et
de ses systèmes, doit être élaborée de manière à ce que les équipes technique et métier
puissent partager des vues différentes d’un élément unique en fonction de leurs
compétences et leur place dans le projet » 3

TOGAF est une méthodologie destinée à créer une architecture d’entreprise dans le but
d’améliorer les performances lors d’évolutions informatiques au sein d’une entreprise.

Le Framework proposé par TOGAF repose sur quatre couches :

Architecture métier : description de la stratégie métier et des processus métier
supportant les objectifs
Architecture des données : définition de la structure de stockage des données
logiques et physiques et des ressources de gestion des données,
Architecture applicative : description des applications incluant leurs interactions
avec les processus cœur de métier de l’organisation,
Architecture technique : description de l’infrastructure du middleware, des
réseaux,… supportant le déploiement des services métier, données et applications.

3
www.le journal du net



NB : Nous pouvons retrouver ce principe dans les 4 niveaux de l’urbanisme à la française
même si la classification n’est pas complètement identique

4 Présentation de la démarche méthodologique
Les piliers de TOGAF sont :

«Architecture Capability Framework » : Ce composant décrit l’organisation, les
processus, les compétences, les rôles et responsabilités des acteurs requis pour
établir et diriger la fonction d'architecture dansune entreprise,
« Architecture Development Method » (ADM) : C’est la méthode de construction
d’une architecture d’entreprise. ADM est considéré comme le cœur de TOGAF. Elle
consiste en une approche du cycle de vie du développement global de l’entreprise,
« Architecture Content Framework » : C’est un ensemble de guides, de modèles,
d’outils de méthodes … pour aider l’architecte à utiliser ADM. Elle se compose de 4
architectures imbriquées : Business Architecture, Data Architecture, Application
Architecture et Technology (IT) Architecture.
« Enterprise Continuum » and Tools: C’est un référentiel à compléter de modèles
d’architecture du marché ou développés dans l’entreprise et qui peuvent être utilisés
comme point de départ pour bâtir une architecture.

Le continuum d’entreprise constitue une bonne pratique de classification :

o Il s’agit de séparer les architectures et les solutions
o Ranger les éléments (architectures, solutions) suivant leur généricité



TOGAF s’appuie sur :

« Technical reference Model »,

Les deux modèles génériquesde références sont :

o TOGAF Foundation Architecture
o Integrated Information Infrastructure Reference Model (III-RM)
« Open Group’s Standards Information Base » (SIB),
« Building Blocks Information Base (BBIB).



5 L’ADM

5.1 Principes de l’ADM
La démarche de l’ADM est composée de huit phases principales et d’une phase
préliminaire.

Ces phases seront détaillées ci-après.

Chaque phase est divisée en étapes. Des livrables sont générées tout au long du
processus, mais le livrable d’une phase peut être modifié dans une phase ultérieure.



Les points clés d’ADM sont : 4

ADM est une démarche itérative, tout au long du processus, entre les phases et à
l’intérieur d’une phase,
Pour chaque itération, une décision doit être prise sur :
o Le périmètre couvert,
o Le niveau de détail,
o L’horizon visé, y compris le nombre et la portée des jalons intermédiaires,
o Les éléments d’architectures existants de l’Enterprise Continuum, déjà crées
dans les itérations précédentes ou existantes dans l’entreprise,

Ces décisions doivent être prises sur la base d’une évaluation pratique des
ressources et des compétences disponibles et sur la valeur attendue pour
l’entreprise de la démarche d’architecture,

En tant que méthode générique, ADM est prévue pour être utilisée dans des contextes très
variés, et peut donc être adaptée à des besoins spécifiques.

L’ADM représente le cycle de développement de la méthodologie TOGAF.

Ses 9 étapes peuvent être réparties en trois sous-catégories :

La 1ère catégorieest composée dela phase préliminaire (Preliminary Phase) étant
donné qu’elle ne rentre pas directement en compte dans le cycle à proprement parler
de TOGAF, elle sera prise en compte et définira les bases,
La 2èmecatégorieest celle du développement des architectures (phases A, B, C, D et
H)
La 3èmecatégorieregroupe les phases E, F et G et tout ce qui est extérieur aux
architectures qui ont été vues.

5.2 Les phases de l’ADM
NB : Seul les étapes et livrables les plus importants sont mentionnés dans chaque phase
référencées.

5.2.1 Phase préliminaire

Cette phase s’apparente à dire « où, pourquoi, qui et comment nous faisons l’architecture ».

Elle met en place le contexte organisationnel, les parties prenantes permettant de créer
l’architecture d’entreprise.

Etapes

Evaluer les organisations de l’entreprise impactées : en effet soit l’entreprise peut
s’inscrire dans la démarche, soit certaines lignes de métiers s’y inscrivent
Définir et établir l’équipe et l’organisation de l’architecture d’entreprise
Identifier et établir les principes de l’architecture
Sélectionner les frameworks de l’architecture et les adapter
Implémenter les outils d’architecture.

4
C.Longépé : Le projet d’urbanisation du SI (page 267-268)



Livrables

Un modèle organisationnel pour l’architecture d’entreprise
Un Framework d’architecture adapté
Un répertoire pour l’architecture initiale, incluant les contenus du Framework

5.2.2 Phase A: Architecture Vision

Cette phase va permettre decréer la vision de l’architecture.
La phase Apermet de définir ce qui est dans et ce qui esthors du champ d’application de
l’effort d’architecture et les contraintes qui doivent être traitées.

Sesobjectifs principaux sont de s'assurer que l’évolution du cycle de développement
d'architecture a lareconnaissance et l'approbation de la gestion d'entreprise, l'appui et
l'engagement nécessaire de l’organisation hiérarchique.
Il s'agit de donner une vision, donc on reste à un niveau relativement macroscopique en
focalisant sur les points structurants pour obtenir un GO en fin de phase.

Etapes

Etablir le projet d’architecture
Identifier les parties prenantes, les préoccupations et les besoins métiers
Confirmer et élaborer les objectifs métiers, les pilotes métiers et les contraintes
S’assurer de l’état de préparation aux changements métier qui peuvent être introduits
par un changement d’architecture
Confirmer et élaborer les principes de l’architecture
Définir les valeurs seuil et les indicateurs de performance clé de l’architecture
cible
Identifier les risques des transformations métier et les activités d’atténuation
Développer les plans de l’architecture et l’état du travail d’architecture.

Livrables

Une déclaration de travail architectural approuvée
Les déclarations des principes métier, les buts métiers et les pilotes métier
raffinés
Les principes de l’architecture
Les évaluations de capacité de l’entreprise
Un Framework d’entreprise adapté
Une vision de l’architecture incluant :
o Les besoins clé des parties prenantes pertinentes raffinés
o Les architectures de bases en version 0.1
o Les architectures cibles en version 0.1.



5.2.3 Phase B: Business Architecture

Cette phase va permettre de créer l’architecture métier,prémices au travail d’architecture
des autres domaines (tel que les données, les applications et les technologies).

C’est donc une architecture « primordiale ».

Elle sert également pour montrer la valeur marchande du travail sur les architectures sous-
jacentes aux parties prenantes clés ainsi que le retour sur investissement qu’auraient celles-
ci en le soutenant et en participant à ces travaux.

Etapes

Sélectionner les modèles de référence, points de vue et outils
Développer les descriptions de l’architecture de base
Développer les descriptions de l’architecture cible
Analyser les lacunes
Définir le plan de charge
Conduire une révision formelle des parties prenantes
Finaliser l’architecture
Créer les documents de définition de l’architecture.

Livrables

Des versions mises à jour et raffinées des livrables de la vision de l’architecture :
o Déclarations de travail architectural
o Les principes métier, les buts métier et les pilotes métier validés (et mis à
jours si nécessaire)
o Les principes de l’architecture
Une ébauche d’un document de définition de l’architecture incluant :
o L’architecture métier de base
o L’architecture métier cible :
 La structure organisationnelle
 Les buts et objectifs métier
 Les fonctions métier
 Les services métier
 Les rôles métier
 Le modèle de données métier
 La corrélation entre les fonctions et les organisations
Les vues correspondantes aux points de vue adressés par les préoccupations
desparties prenantes clé.



5.2.4 Phase C: Information Systems Architectures

La phase C se décompose en deux sous-parties :

la partie données,
et la partie applications.

La phase C sur les donnéesva permettre de définir les principaux types de données qui
seront nécessaires pour soutenir l’activité métier en cours.

Il faut que ces données soient compréhensibles par les parties prenantes, complètes et
consistantes et enfin il faut qu’elles soient stables. Il est à noter que ceci ne concerne pas
tout ce qui a un rapport avec les bases de données. Le but étant de définir les entités qui
vont servir à l’entreprise, pas de concevoir les systèmes de stockages physiques ou
logiques.

La phase C a pour but de définir les systèmes applicatifs principauxnécessaires pour
traiter les données et soutenir l’activité métier.

Tout comme la partie précédente, cette phase n’est pas concernée par la conception de ces
systèmes applicatifs, ces applications ne sont pas décrites comme des systèmes
informatiques mais comme des groupes logiques capables de gérer les objets définis dans
l’architecture de données et de soutenir l’activité métier.

Les applications et leurs possibilités sont définies sans référence à des technologies
particulières car celles-ci sont stables et finies tandis que les technologies utilisées pour les
mettre en œuvre ne sont quant à elles pas encore arrêtées, elles changeront avec le temps
en fonction des besoins changeant d’activités métier en cours.

Etapes

Sélectionner les modèles de référence, les points de vue et les outils
Analyser les lacunes
Définir les composantes du plan de charge
Résoudre les impacts possibles sur l’ensemble des architectures
Conduire une révision formelle des parties prenantes
Créer un document de définition de l’architecture.

Livrables

Des versions mises à jour et raffinés de la vision de l’architecture incluant :
o Une ébauche du document de définition de l’architecture incluant :
 Les architectures de bases en version 1.0
 Les architectures cibles en version 1.0
 Les vues des architectures correspondant aux points de vue des
préoccupations des parties prenantes clé
Une ébauche des spécifications des besoins de l’architecture comprenant notamment
les besoins techniques pertinents qui seront pris en compte dans l’évolution du cycle
de développement de l’architecture
Les composantes de l’architecture métier du plan de charge architectural.



5.2.5 Phase D: Technology Architecture

La phase D cherche à définir des relations entre les composants applicatifs, définis
dans la phase C correspondante, et un ensemble de composants technologiques qui
représenteront les composants logiciels et matériels disponibles sur le marché ou bien
configurés au sein de l’organisation dans des plateformes technologiques.

Durant cette phase, l’équipe en charge de l’architecture devra considérer que les ressources
pertinentes pour l’architecture technologique sont disponibles dans le dépôt d’architecture
(ou se trouve l’ensemble des informations liées aux architectures).

Étapes :

Développer une description de l’architecture technique de base
Développer une description de l’architecture technique cible
Finaliser l’architecture technique.

Livrables

Vision de l’architecture :
o Principes des technologies validés
Les documents de définition de l’architecture technologique cible :
o Des composants technologiques et leurs relations aux systèmes d’information
o Des plateformes technologiques et leur décomposition montrant les
combinaisons des technologies requises pour réaliser un parc technologique
spécifique
o Localisations et environnements
o Spécifications réseau et matérielles.

5.2.6 Phase E: Opportunities & Solutions

La phase Eest la première phase qui soit directement concernée par la façon dont sera
mise en place l’architecture cible. Elle se concentre sur la façon de fournir l’architecture.

C’est uniquement lors de la phase E que l’analyse d’opportunité est réalisée avec les choix
de solution. Ces choix sont réalisés à partir des travaux des phases B,C et D. Le métier
reste au cœur de la démarche, même pour les choix de solution.

C’est lors de cette phase que l’on commence à identifier les projets d’implémentation, qu’on
identifie une trajectoire (macro planning) et que l’on définit les architectures intermédiaires
(sur les paliers de la trajectoire).

Ses objectifssont donc de passer en revue les capacités et les objectifs métiers cibles, de
consolider les lacunes des phases B à D et d’organiser des groupes de blocs constitutifs
pour gérer ces capacités, de revoir et de confirmer les paramètres courants de l’entreprise
pour mieux absorber les éventuels changements, d’avoir une série d’architectures de
transitions fournissant une valeur ajoutée continue à travers l’exploitation des opportunités,
et de réaliser des blocs constitutifs.



Étapes :

Déterminer/confirmer les changements des attributs clés de l’entreprise
Déterminer les contraintes de l’entreprise vis-à-vis de la mise en œuvre
Révision et consolidation des résultats de l’analyse des lacunes pour les phases B à
D
Révision des besoins des technologies informatiques à partir des perspectives
fonctionnelles
Consolider et réconcilier les besoins d’interopérabilités
Affiner et valider les dépendances afin d’assurer que toutes les contraintes de la mise
en œuvre et des plans de migration aient été identifiées
Confirmer la préparation de l’organisation et les risques pour les transformations
métier
Formuler une implémentation haut-niveau et une stratégie de migration.

Livrables

Une mise à jour et un affinement des versions de la vision de l’architecture, de
l’architecture métier, des architectures des systèmes d’information et de l’architecture
technologique :
Un plan de charge architectural consolidé et validé.
Une architecture de transition version 1.0 incluant :
o Les lacunes, solutions et les évaluations de dépendances consolidées.
o Un recueil des risques version 1.0.
o Une analyse des impacts.
Un plan d’implémentation et de migration version 0.1.

5.2.7 Phase F: Migration Planning

La phase Fcorrespond à la mise en place d’un plan détaillé d’exécution et de migration.

Elle va aussi servir à mettre au point la vision d’architecture ainsi que les documents qui
définissent l’architecture en conformité avec l’approche convenue. Les architectures de
transitions définies dans la phase E avec les parties prenantes vont également être
confirmées.

Finalement, le cycle d’évolution des architectures doit être établi pour assurer que les
architectures restent pertinentes, et que les leçons apprises soient documentées pour activer
un processus d’amélioration continu.

Elle fait ainsi une analyse de la valeur des travaux résultant de la phase E par une analyse
des couts, des bénéfices mais aussi des risques. Elle détaille la trajectoire et les projets
associés.



Étapes :

Confirmer la gestion des interactions du Framework pour les plans de mise en œuvre
et de migration
Assigner une valeur métier à chacun des projets
Estimer les besoins en ressources, les échéances et les moyens de diffusions des
livrables
Hiérarchiser les projets de migration à travers la conduite d’une évaluation des
coûts/bénéfices et valider les risques
Générer la feuille de route de la mise en œuvre de l’architecture et du plan de
migration.

Livrables

Un plan d’implémentation et de migration version 1.0
Un document de définition de l’architecture finalisée
Une spécification des besoins de l’architecture finalisée
Des blocs constitutifs de l’architecture réutilisables
Un modèle de la mise en œuvre de la gouvernance
Des demandes de changement.

5.2.8 Phase G: Implementation

La phase Gcorrespond à la mise en place de la gouvernance, son but est de formuler des
recommandations pour chaque implémentation de projets.

Elle doit également gouverner et gérer un contrat d’architecture couvrant l’ensemble des
processus d’implémentation et de déploiement.

Elle doit assurer que le programme opérationnel est déployé correctement et comme il avait
été prévu dans le programme de travail et que la solution déployée est conforme avec
l’architecture cible.

C’est avec cette phase que toute l’information sur la bonne gestion des différents
projets opérationnels est rassemblée.

Parallèlement à cette phase, il y a l’exécution d’un processus de développement
spécifiqueà une organisation où le développement réel se produit.

Étapes :

Confirmer les possibilités et les priorités pour le déploiement avec la gestion du
développement.
Identifier les ressources de déploiement et les qualifications.
Guider le développement des solutions de déploiement.
Faire la revue de la conformité de l’architecture.
Mettre en œuvre les opérations métier et les technologies informatiques.
Faire une revue post-implémentation et clore la phase de mise en œuvre.



Livrables

Un contrat d’architecture signé
Une évaluation de la conformité
Des demandes de changement
Des solutions d’architectures conformes déployées :
o Le système de l’architecture conforme mis en œuvre
o Le répertoire de l’architecture rempli
o Des recommandations et des dispenses conformes à l’architecture
o Des recommandations sur les besoins de livraisons des services
o Des recommandations sur les métriques de performance
o Les accords de niveau de services
o Une vision de l’architecture mise à jour
o Un document de définition de l’architecture mis à jour
o Une architecture de transition mise à jour
o Des modèles pour le métier et les systèmes d’information pour la
solution mise en œuvre.

5.2.9 Phase H: Architecture Change Management

La phase Hsert principalement à s’assurer que les architectures de base continuent à
être adaptées aux besoins.

Elle va aussi permettre à la fois d’évaluer l’exécution de l’architecture et à émettre des
recommandations pour des changements et évaluer les changements de Framework et de
principes configurés dans les phases précédentes.

Cette phase fera fonctionner le « Framework » de gouvernance.

C’est durant cette phase que le gestionnaire de changement va déterminer en fonction des
changements à apporter s’il faut initier un nouveau cycle d’évolution de l’architecture.

La phase H peut ainsi être à l’origine d’un nouveau cycle d’architecture.

Étapes :

Établir un processus pour exploiter les revenus de l’architecture d’entreprise
Déployer les outils de surveillance
Gérer les risques
Fournir une analyse pour la gestion des changements d’architecture
Développer les besoins de changement pour atteindre les cibles de performances
Gérer les processus de gouvernance
Activer les processus pour mettre en œuvre les changements.

Livrables

Des mises à jour des architectures
Des changements dans le Framework de l’architecture et de ses principes
De nouvelles demandes de travail architectural
Les déclarations de travail architectural mises à jour
Un contrat d’architecture
Une évaluation de la conformité.



5.3 Le Cœur de l’ADM : la gestion des exigences
Enfin, le point central du cycle ADM est la gestion des exigences qui permet de s’assurer
que l’ensemble des phases du cycle ADM s’appuient et valident les exigences métier.

5.4 Cycle de vie et utilisation pratique de l’ADM
Nous venons de décrire les principes d’un cycle ADM.

Confronté à la pratique, les cycles ADM peuvent se décliner de façon différente et TOGAF
définit des modes d’utilisation au travers de bonnes pratiques

5.4.1 Mode itératif

Tout d’abord le déroulement d’un cycle ADM peut être itératif. A titre d’exemple, les
préliminaires et Vision sont souvent assez liées: Donner la vision d’architecture sur un projet
structurant aboutit souvent à faire évoluer les principes d’architecture transverses.

De la même façon, les phases E et F sont très interdépendantes voire même traitées en
même temps dans certains cas

Enfin dans certains cas, des itérations supplémentaires sont à prévoir quand par exemple
l’analyse des couts des bénéfices et des risques réalisés dans la phase F nécessite une
revisite de l’architecture métier cible.



5.4.2 Adaptation au contexte de l’entreprise

Autre cas concret auquel sont confrontées les entreprises est de savoir comment décliner
des cycles ADM pour traiter à la fois et de façon cohérente la définition des architectures
stratégiques (Ex: Schéma Directeur), la définition des architectures d’un domaine métier et
les architectures de solution par essence plus proche des projets.

Ces niveaux d’architecture font intervenir des profils d’architectes différents qui doivent
collaborer à une même cible. Ce schéma illustre 2 modes de mise en œuvre proposés par
TOGAF :

1. Un seul cycle TOGAF dans lequel chaque profil d’architecte apporte sa pierre à
l’édifice. Ce mode est préconisé quand on est dans le cas d’une seule et même
équipe d’architecte qui traite l’ensemble
2. Des cycles imbriqués, plus adaptés à des organisations importantes ou à des gros
programmes de transformation pour lesquels on doit souvent décliner une vision
stratégique, domaines et ensuite projet.

6 « ArchiMate language » et TOGAF
ArchiMate 1.05 a été mis en place par l’Open Group pour modéliser les principes définis par
TOGAF en explicitant à un niveau plus détaillé le « Business Process » et même
les« Software » au travers de concepts génériques de modélisation applicable à toute
entreprise.

Ce type de langage de modélisation permet à l’architecte d’entreprise de mettre en évidence
les liens entre les domaines :6

Une structure globale pour chaque domaine montrant les éléments principaux et les
liens de dépendance entre domaines dans un langage compréhensible à tous
(parties-prenantes dont les utilisateurs finaux),
De mettre en évidence les relations entre domaines.

5
ArchiMate (d’après Wikipédia) : ArchiMate is a technical standard from the Open Group
and is based on the concepts of the IEEE 1471 standard. It is supported by various tool
vendors and consulting firms. ArchiMate is also a registered trademark of The Open Group.
6
ArchiMate distinguishes itself from other languages such as Unified Modeling Language
(UML) and Business Process Modeling Notation (BPMN) by its well defined metamodel, and
wider enterprise modelling scope



7 Quelques critiques
TOGAF reste difficile à mettre en place au sein des PMEau vu de la complexité de la
méthodeet du niveau d’implication des acteursqui doivent intervenir.

Le cœur de TOGAF (ADM) contient des procès, termes et descriptions en forme textuelles
mais pas de schémas ou diagrammes, qui sont normalement privilégiés par les architectes
quand il s’agit de parler au client.

Le glossaire de TOGAF redéfinit certains termes normalement utilisé en architecture des SI
et cela tends à rendre son appropriation plus difficile.

Il y a beaucoup d’information sur le processus de création d’un « artefact » mais très peu de
détails sur la façon dont les organisations s’en servent et comment ils les mettent en place
(absence d’exemples concrets).

TOGAF ne fournit pas les procédés pour développer les éléments et les livrables de
l'Architecture.

Etant un « Framework » générique, il demande un travail d’adaptation important.

TOGAF fournit peu de conseils pour la création d'un modèle d'architecture complet et
cohérent. Par contre il fait référence aux outils qui fournissent ce support.

Une autre limitation est constituée par le manque d'intégration entre les différents domaines
architecturaux.

8 Pour conclure
L’Enterprise Architecture et notamment TOGAF, servent de point de départ pour mettre en
place des développements en entreprise basé sur une analyse des processus de
l’entreprise.

TOGAF offre un cadre de travail complet couvrant tout le cycle de vie de l'Architecture
d'Entreprise.

Les modèles d’EA servent de point de départ pour développer des systèmes conduit par les
modèles.

« Pour passer de l’Enterprise IT Architecture à l’Enterprise Architecture,
le défi majeur est certainement la mobilisation des acteurs.
L’architecture d’entreprise doit en effet réunir tous les acteurs et tous les
processus de l’entreprise ».7

7
Le projet d’Urbanisation du SI » C. Longépé (page 280).



9 Bibliographie

« Enterprise Architecture at Work » de Marc Lankhorst et al (Springer)
“Le projet d’urbanisation du SI” de Christophe Longépé (Dunod)
TOGAF9 Quick Start Guide for Enterprise Architects de Wolfgang Keller
“Enterprise Architecture, des problèmes pratiques à l’innovation” de Camille Salinesi
et Laure-Hélène Thévenet (CRI Université Paris I, Sorbonne)
www.journaldunet.com (articles sur TOGAF)
« A framework for information systems architecture” de J.A. Zachman dans « IBM
SYSTEMS JOURNAL, VOL 26. NO 3, 1987”
“Atelier de modélisation TOGAF” de Matthieu Aubry/ Université de Nantes
http://www.ceisar.fr/
http://en.wikipedia.org/wiki/ et Wikipédia français
www.enterprise-architecture.info (site IFEAD)
www.opengroup.org/architecture


Eugenio Mauri: présentation de TOGAF

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Eugenio Mauri: présentation de TOGAF

Ähnlich wie Eugenio Mauri: présentation de TOGAF (20)

Mehr von Eugenio Mauri

Mehr von Eugenio Mauri (11)

Eugenio Mauri: présentation de TOGAF