Date post: | 25-Feb-2018 |
Category: |
Documents |
Upload: | youness-rabaa |
View: | 224 times |
Download: | 2 times |
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 1/177
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 2/177
TOGAFTM VERSION 9 - GUIDE DE POCHE
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 3/177
About the TOGAFTM series
The TOGAFTM series contains the official publications on TOGAF on
behalf of The Open Group, including:- TOGAFTM 2007 Edition (Incorporating 8.1.1)
- TOGAFTM Version 8.1.1 Enterprise Edition – Study Guide
- TOGAFTM Version 8.1.1 Enterprise Edition – A Pocket Guide
- TOGAFTM Version 9
- TOGAFTM Version 9 – A Pocket Guide
For the latest information on TOGAFTM visit www.opengroup.org/togaf
Other publications by Van Haren Publishing
Van Haren Publishing specializes in titles on Best Practices, methods and
standards within IT and business management.These publications are grouped in the following series: ITSM Library,
Best Practice and IT Management Topics. Van Haren Publishing is also
publisher on behalf of ITSMF, HDI, ASL BiSL Foundation, TSO/OGC,
PMI Nederland and Platform Outsourcing Nederland.
For the latest information visit www.vanharen.net
For the latest information on TOGAFTM, visit www.opengroup.org/togaf.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 4/177
TOGAF™ Version 9
G U I D E D E P O C H E
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 5/177
Titre : TOGAF™ Version 9 – Guide de PochePublié par : The Open Group Auteurs: Andrew Josey, The Open Group, Professeur Rachel
Harrison, Stratton Edge Consulting, Paul Homan, IBM,Matthew F. Rouse, EDS, Tom van Sante, Getronics,Mike Turner, Capgemini, Paul van der Merwe, RealIRM
Editeur : Van Haren Publishing, Zaltbommel, www.vanharen.net
ISBN : 978 90 8753 535 3
Edition : Edition originale en anglais, 2nd edition,first impression, January 2009
Edition en français: 2ème edition, 1er tirage, mai 2009
Mise en page et conceptionde la couverture : CO2 Premedia, Amersfoort-NL
Imprimerie : Wilco, Amersfoort – Hollande
Copyright : © 2009, The Open Group
Tous droits réservés.Il est interdit de reproduire, de stocker dans un système de recherche ou de transmettre sousquelque forme ou par quelque moyen (électronique, mécanique, photocopie, enregistrementou autres) que ce soit tout ou partie du présent document (édition originale en anglais) sansautorisation expresse du propriétaire du droit de copie.
Les points de vue exprimés dans ce document ne sont pas nécessairement ceux d’un membre
particulier quelconque de The Open Group.
En cas de désaccord entre le contenu du présent document et la documentation TOGAF9 officielle, la documentation TOGAF 9 fait autorité pour la certification, les examens et àd’autres fins. La documentation TOGAF 9 officielle peut être obtenue en ligne sur le sitewww.opengroup.org/togaf.
Numéro du document (édition originale en anglais) : G092
Publié par The Open Group, janvier 2009
Envoyez vos commentaires sur le contenu de ce document à :The Open GroupThames Tower37-45 Station RoadReading Berkshire, RG1 1LX Royaume Uni
ou par courrier électronique à : [email protected] Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 6/177
Préface A propos de ce document Ce Guide de Poche se base sur TOGAF™ Version 9 Enterprise Edition.
Il a pour but d’aider les architectes à se concentrer sur l’amélioration du
fonctionnement de l’organisme pour lequel ils travaillent et d’aider les
dirigeants à bien comprendre les fondamentaux de TOGAF (The Open
Group Architecture Framework ). Il se décompose comme suit :
• Le Chapitre 1 fournit une présentation générale de TOGAF, del’architecture d’entreprise, du contenu et des concepts fondamentaux de
TOGAF.
• Le Chapitre 2 présente la Méthode de Développement d’Architecture
(ADM— Architecture Development Method ). TOGAF utilise cette
méthode pour développer des architectures d’entreprise.
• Le Chapitre 3 fournit un aperçu général des techniques clés et deslivrables du cycle ADM.
• Le Chapitre 4 fournit un aperçu général des recommandations à suivre
pour adapter l’ADM.
• Le Chapitre 5 introduit la notion de Cadre de Contenu d’Architecture,
métamodèle structuré des éléments d’une architecture.
• Le Chapitre 6 présente le Continuum d’Entreprise, concept dehaut niveau pouvant être utilisé avec l’ADM pour développer une
architecture d’entreprise.
• Le Chapitre 7 présente les modèles de référence TOGAF, parmi
lesquels le Socle d’Architecture TOGAF et le Modèle de Référence
d’Infrastructure d’Information Intégrée (III-RM—Integrated Information
Infrastructure Reference Model ).• Le Chapitre 8 introduit le Cadre de Capacité d’Architecture, constitué
d’un ensemble de ressources permettant de créer et de mettre en œuvre
une fonction d’architecture au sein d’une entreprise.
• L’Annexe A décrit de façon générale les différences entre TOGAF 9 et
TOGAF 8.1.1.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 7/177
6 TOGAF™ Version 9 – Guide de Poche
Ce document intéressera :
• Les architectes d’entreprise, les architectes métiers, les architectes des
systèmes d’information, les architectes des données, les architectessystèmes, les architectes solutions et les dirigeants cherchant une
première introduction à TOGAF.
Il n’est pas nécessaire d’avoir des connaissances sur l’architecture
d’entreprise. Après lecture du document, le lecteur souhaitant obtenir
davantage d’informations pourra consulter la documentation TOGAF 91
disponible en ligne sur www.opengroup.org/architecture/toga9-doc/arch etégalement disponible dans l’ouvrage TOGAF 9 “The Book”.
A propos de TOGAF Version 9
TOGAF 9 couvre toutes les révisions apportées à la spécification TOGAF
et améliore la qualité du cadre TOGAF : il a été conçu en tant qu’évolution
de TOGAF 8.1.1, par ajout de détails et d’explications complémentaires àun existant déjà éprouvé. Les principales nouveautés de TOGAF 9 sont :
Une structure modulaire : TOGAF 9 introduit une structure modulaire.
Le contenu de la base de ressources TOGAF 8.1.1 a été classé et réparti en
plusieurs domaines ayant chacun un but bien précis (par opposition à des
“ ressources génériques ”). La structure modulaire permet :• Une plus grande souplesse d’utilisation—un but bien précis pour
chaque domaine ; une utilisation isolée sous la forme d’un jeu autonome
de recommandations.
• Une adoption incrémentielle de la spécication TOGAF.
Cadre de Contenu : TOGAF 9 comprend un cadre de contenu améliorantla cohérence des divers sortants créés lors de l’application de la Méthode
1 The Open Group Architecture Framework (TOGAF),Version 9 Enterprise Edition (ISBN:
978-90-8753-094-5, G091v) ; consulter www.opengroup.org/bookstore/catalog/g091v.htm.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 8/177
7TOGAF™ Version 9 – Guide de Poche
de Développement d’Architecture (ADM). Le cadre de contenu TOGAF
propose un modèle détaillé des fournitures de l’architecture.
Une meilleure assistance : TOGAF 9 fait appel à un ensemble complet
de concepts et de recommandations conduisant à une hiérarchie
intégrée d’architectures développées par des équipes appartenant à de
grandes organisations et utilisant un modèle universel de gouvernance
d’architecture. On introduit notamment les concepts suivants :
• Le Partitionnement (Partioning ) : On décrit différentes techniquespermettant de partitionner les diverses architectures d’une entreprise.
• Le Référentiel d’Architecture ( Architecture Repository) : Modèle
d’information logique représentant un Référentiel d’Architecture
pouvant être utilisé comme espace de mémorisation intégré pour tous
les sortants produits par exécution de l’ADM.
• Le Cadre de Capacité (Capability Framework ) : définition plus structuréede l’organisation, des compétences, des rôles et des responsabilités exigés
pour mettre en œuvre de façon efficace une capacité d’architecture
d’entreprise. Les nouveautés de TOGAF apportent aussi une aide au
processus pouvant être suivi pour identifier et élaborer une capacité
d’architecture appropriée.
Styles d’architectures : TOGAF 9, dans sa nouvelle Partie III intitulée
Recommandations et Techniques ADM, regroupe un ensemble
d’informations utiles décrivant en détail la façon d’appliquer l’ADM à
certains cas particuliers :
• Les diverses façons d’itérer dans la méthode ADM et les moments où il
convient d’appliquer chaque technique• Les liens entre l’ADM TOGAF et l’Architecture Orientée Service
(SOA—Service Oriented Architecture )
• Les informations spéciques permettant de mettre en œuvre
l’architecture de sécurité au sein de l’ADM
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 9/177
8 TOGAF™ Version 9 – Guide de Poche
• Les divers types de développements d’architectures exigés dans une
entreprise et la façon dont ils sont liés les uns aux autres.
Autres détails concernant l’ADM : TOGAF 9 fournit d’autres
informations détaillées utiles à l’exécution de l’ADM. On peut notamment
citer les améliorations suivantes :
• Le fait que la phase préliminaire offre une assistance étendue à la
création d’un cadre d’architecture d’entreprise et à la planification du
développement d’une architecture.• Les phases Opportunités & Solutions et Planication de la Migration
font appel à une méthode plus particulière et plus robuste permettant de
définir et de planifier une transformation d’entreprise en se fondant sur
les principes de la planification en fonction des capacités.
Conventions utilisées dans ce document :Les conventions suivantes sont utilisées dans l’ensemble du document afin
de pouvoir mieux identifier les informations les plus pertinentes et d’éviter
toute confusion quant à la signification voulue :
• Points de suspension (…)
Indique une continuation, comme par exemple une liste partielle
d’éléments d’un exemple, ou la suite d’un texte précédent.• Gras
Permet de faire ressortir certains termes particuliers.
• Italiques
Permet d’insister sur une expression. Peut également désigner d’autres
documents externes. On utilisera également les italiques pour expliciter
certains acronymes ou termes anglais utilisés dans cette traduction.• Politique sur les acronymes
Les acronymes sont traduits mot à mot et laissés en anglais entre
parenthèses et en italique. Par exemple:
ADM -> Méthode de Développement d’Architecture ( ADM -
Architecture Development Method ).
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 10/177
9TOGAF™ Version 9 – Guide de Poche
TOGAF -> Le Cadre d’Architecture de l’Open Groupe (TOGAF - The
Open Group Architecture Framework ).
• Politique sur les expressions concepts Les expressions concepts sont traduites mot à mot et seront définies
dans le glossaire du Guide de Poche. Ce sont de nouvelles expressions
concepts pour la langue française. Par exemple:
Architecture Content Framework -> Cadre de Contenu d’Architecture
• Business
“Business” n’est pas traduit par un seul mot. Il peut prendre plusieurssens suivant le contexte, à savoir “métier”, “business”, ou encore
“entreprise”.
A propos de l’Open Group
L’Open Group est un consortium indépendant des fabricants et
des technologies. Sa vision du Flux d’Informations Sans Frontières(Boundaryless Information Flow™ ) permettra d’accéder à des informations
intégrées au sein des entreprises et entre des entreprises grâce à l’utilisation
de standards ouverts et à une interopérabilité globale. L’Open Group
collabore avec des clients, des fournisseurs, des consortiums et d’autres
organismes de normalisation. Son rôle est d’évaluer, de comprendre et de
répondre à certaines exigences présentes et à venir, d’établir des règles etde faire partager les bonnes pratiques ; de favoriser l’interopérabilité, de
développer un consensus et de faire évoluer et intégrer les spécifications
et les techniques Open Source ; d’offrir un ensemble exhaustif de services
permettant d’améliorer l’efficacité des consortiums ; et de mettre en œuvre
un service de certification de premier plan pour l’industrie.
A propos de l’AFF (Architecture Forum France)
L’Architecture Forum France a été créé par Arismore en novembre 2007,
représentant officiel de l’Open Group™ en France, afin de fournir aux
communautés d’architectes et aux directions des systèmes d’information
françaises un accès simplifié et localisé aux informations, aux bonnes
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 11/177
10 TOGAF™ Version 9 – Guide de Poche
pratiques, aux ressources et aux certifications offertes par l’Open Group™.
http://www.architecture-forum.org/
D’autres informations concernant l’Open Group sont disponibles sur
www.opengroup.org.
L’Open Group dispose d’une expérience de plus de 15 ans dans le
développement et la mise en œuvre de programmes de certification et
d’une grande expertise dans le développement et l’incitation à l’adoptionpar l’industrie de séries de tests permettant de valider la conformité avec un
standard ou une spécification ouvert.
L’Open Group publie de nombreux documents techniques dont la plupart
concernent le développement de standards et de guides techniques sur
les produits. Parmi ces documents, on trouve aussi des Livres Blancs, desétudes techniques et des ouvrages concernant les entreprises.
Un catalogue est disponible sur www.opengroup.org/bookstore.
Marques déposées
Boundaryless Information Flow™ et TOGAF™ sont des marquesdéposées. Making Standards Work ®, The Open Group®, et UNIX ® sont
des marques déposées par The Open Group aux Etats-Unis et dans d’autres
pays.
Tous les autres noms de marques, d’entreprises et de produits ne sont
utilisés qu’à seule fin d’identification et peuvent être des marques déposéespar leurs propriétaires respectifs.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 12/177
Table des matières
Préface 5
Chapitre 1 Présentation de TOGAFTM 19
1.1 Présentation de TOGAF 9 19
1.2 Structure du Document TOGAF 20
1.3 L’architecture dans le contexte de TOGAF 211.4 Types d’Architectures concernés par TOGAF 21
1.5 Le contenu de TOGAF 22
1.5.1 Le Modèle de Développement d’Architecture (ADM) 23
1.5.2 Recommandations et techniques ADM 24
1.5.3 Le Cadre de Contenu d’Architecture 24
1.5.4 Le Continuum d’Entreprise 251.5.5 Les Modèles de référence TOGAF 25
1.5.6 Le Cadre de Capacité d’Architecture 25
Chapitre 2 La Méthode de Développement d’Architecture 27
2.1 Qu’est-ce que l’ADM ? 27
2.2 Quelles sont les phases de l’ADM? 282.3 L’ADM en détail 31
2.3.1 Phase préliminaire 31
2.3.2 Phase A : Vision de l’Architecture 32
2.3.3 Phase B : Architecture du Business 34
2.3.4 Phase C : Architectures des Systèmes d’Information 37
2.3.5 Phase D : Architecture Technique 412.3.6 Phase E : Opportunités et Solutions 43
2.3.7 Phase F : Planification de Migration 45
2.3.8 Phase G : Gouvernance de la Mise en œuvre 47
2.3.9 Phase H : Gestion du Changement d’Architecture 49
2.3.10 Gestion des Exigences 50
2.4 Définition du périmètre de l’Activité d’Architecture 52Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 13/177
12 TOGAF™ Version 9 – Guide de Poche
Chapitre 3 Techniques et livrables clés du Cycle ADM 55
3.1 Le Cadre d’Architecture Contextualisé 57
3.2 Le Modèle d’Organisation pour l’Architecture d’Entreprise 593.3 Les Principes de l’Architecture 59
3.3.1 Développer des Principes de l’Architecture 60
3.3.2 Dénir les Principes de l’Architecture 60
3.3.3 Qualités des Principes 63
3.3.4 Application des principes de l’architecture 63
3.4 Les Principes du business, buts du business et moteursdu business 65
3.5 Le Référentiel d’Architecture 66
3.6 Les Outils d’Architecture 66
3.7 La Demande de Mise en Chantier d’Architecture 66
3.8 La Dénition du Chantier d’Architecture 67
3.9 La Vision de l’Architecture 683.10 La Gestion des Acteurs Concernés 69
3.10.1 Etapes du Processus de Gestion des Acteurs Concernés 70
3.11 Le Plan de Communication 73
3.12 L’Évaluation de l’état de Préparation à la Transformation
du Business 73
3.13 L’Évaluation des Capacités 743.14 La Gestion du Risque 76
3.15 Le Document de Définition de l’Architecture 77
3.15.1 L’Architecture du Business 78
3.15.2 Les Architectures des Systèmes d’Information 79
3.15.3 L’Architecture Technique 80
3.16 La Spécication des Exigences d’Architecture 803.16.1 Les Exigences de l’Architecture du Business 81
3.16.2 Les Exigences des Architectures des
Systèmes d’Information 82
3.16.3 Les Exigences de l’Architecture Technique 82
3.16.4 Les Exigences d’Interopérabilité 83
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 14/177
13TOGAF™ Version 9 – Guide de Poche
3.17 La Feuille de route de l’Architecture 83
3.18 Les Scénarios Métiers 84
3.19 L’Analyse des Écarts 853.20 Les Points de Vue de l’Architecture 87
3.21 Les Vues de l’Architecture 90
3.21.1 Développement des Vues dans l’ADM 90
3.22 Les Building Blocks de l’Architecture 90
3.23 Les Building Blocks de la Solution 91
3.24 La Planification en Fonction des Capacités 923.25 Les Techniques de Planification de la Migration 93
3.25.1 Matrice d’Évaluation et de Détermination des
Facteurs de Mise en œuvre 93
3.25.2 Matrice des Ecarts Consolidés, des Solutions et des
Dépendances 94
3.25.3 Table des Définitions Architecturales Incrémentées 953.25.4 Table d’Evolution de l’État d’une Architecture
d’Entreprise 95
3.25.5 Technique d’Évaluation des Valeurs métiers 97
3.26 Le Plan de Mise en œuvre et de Migration 98
3.27 L’Architecture de Transition 99
3.28 Le Modèle de Gouvernance de la Mise en œuvre 1013.29 Les Contrats d’Architecture 101
3.30 La Demande de Changement 103
3.31 L’Évaluation de Conformité 104
3.32 L’Évaluation de l’Impact sur les Exigences 105
Chapitre 4 Recommandations pour l’adaptation de l’ADM 1074.1 Introduction 107
4.2 Application des itérations à l’ADM 109
4.3 Application de l’ADM à différents niveaux de l’entreprise 114
4.4 L’Architecture de Sécurité et l’ADM 116
4.5 Utilisation de TOGAF pour Définir et Gouverner les SOA 118
4.5.1 Lectures Supplémentaires 121Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 15/177
14 TOGAF™ Version 9 – Guide de Poche
Chapitre 5 Le Cadre de Contenu d’Architecture 123
5.1 Aperçu général du Cadre de Contenu d’Architecture 123
5.2 Le Métamodèle du Contenu 1255.2.1 Le Cœur et les Extensions 125
5.2.2 Catalogues, Matrices et Diagrammes 127
5.3 Eléments d’Architecture 129
5.4 Livrables de l’Architecture 133
5.5 Les Building Blocks 134
Chapitre 6 Le Continuum d’Entreprise 137
6.1 Aperçu général du Continuum d’Entreprise 137
6.1.1 Le Continuum d’Entreprise et la Réutilisation
d’Architectures 139
6.1.2 Utilisation du Continuum d’Entreprise dans l’ADM 139
6.2 Le Partitionnement de l’Architecture 1406.3 Le Référentiel d’Architecture 141
Chapitre 7 Modèles de Référence TOGAF 145
7.1 Le Socle d’Architecture TOGAF 145
7.1.1 Le Modèle de Référence Technique (TRM) 145
7.2 Le Modèle de Référence d’Infrastructure d’InformationsIntégrées (III-RM) 145
Chapitre 8 Cadre de Capacité d’Architecture 149
8.1 Créer une Capacité d’Architecture 151
8.2 La Gouvernance de l’Architecture 151
8.3 Le Comité d’Architecture 1528.4 Conformité de l’Architecture 153
8.5 Le Cadre des Compétences en Architecture 154
Annexe A - Résumé de la Migration 157
Glossaire 171
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 16/177
A propos des auteurs Andrew Josey, The Open Group Andrew Josey est Directeur des Standards (Director of Standards ) de l’Open
Group. Il est actuellement responsable du processus de normalisation pour
l’Open Group et a récemment dirigé plusieurs projets de développement
de normes pour TOGAF 9, l’IEEE Std 1003.1-2008 (POSIX), et les
caractéristiques principales de la Single UNIX Specification Version 4. Il
avait auparavant dirigé le développement et la mise en œuvre d’un grandnombre de projets de développement de certification de l’Open Group,
parmi lesquels certains programmes de certification industrielle du système
UNIX, de la Linux Standard Base, de TOGAF, et de l’IEEE POSIX. Il est
membre de l’IEEE, de USENIX, de l’UKUUG et de l’Association of Open
Group Enterprise Architects.
Professeur Rachel Harrison, Stratton Edge Consulting
Rachel Harrison est professeur invité en informatique à l’université
de Reading et Directrice de Stratton Edge Consulting. Elle occupait
anciennement les postes de professeur d’informatique, de directrice du
département d’informatique et de directrice de recherche à la School
of System Engineering de l’université de Reading. Elle est titulaired’une maîtrise de mathématiques de l’université d’Oxford, d’un master
d’informatique à l’UCL et d’un PhD d’informatique de l’université de
Southampton. Ses travaux de recherche actuels portent sur l’architecture
d’entreprise, l’évolution des systèmes, la métrique logicielle, l’ingénierie
des exigences et la modélisation des processus. Ses services de conseil
comprennent la préparation pour l’Open Group du guide d’étude TOGAFet les supports de formation qui l’accompagnent. Le professeur Harrison
est membre de l’IEEE Computer Society, de l’ACM, du BCS et est
également Ingénieur Agréé (Chartered Engineer ).
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 17/177
16 TOGAF™ Version 9 – Guide de Poche
Paul Homan, IBM
Paul Homan est consultant en stratégie technologique au sein des Global
Business Services d’IBM. Il est architecte informatique certifié, spécialisé enarchitecture d’entreprise avec plus de 20 ans d’expérience en informatique.
Paul est un passionné ayant une grande expérience pratique dans les
domaines de l’architecture, de la stratégie, de l’autorité de conception et de
la gouvernance. Il s’intéresse plus particulièrement à la direction des travaux
d’architecture d’entreprise, à la gestion des exigences et à l’architecture
business. Il est entré chez IBM venant du monde de l’utilisateur final, aprèsavoir été architecte en chef au UK Post Office et au Royal Mail. Il a non
seulement créé certaines pratiques d’architecture d’entreprise, mais il a
également pu en voir les résultats !
Matthew F. Rouse, EDS
Matthew Rouse est membre de l’EDS Global Architecture Capability.Matthew possède une expérience en informatique de plus de 20 ans dans
les domaines du développement d’applications, des architectures systèmes,
de la stratégie informatique et de l’architecture d’entreprise. Il apporte son
expertise dans la planification stratégique et l’architecture informatique
et aide les entreprises à aligner leurs investissements informatiques sur
leurs objectifs métiers. Matthew est un professionnel de l’informatiqueagréé membre de la British Computer Society, il est Master Certified IT
Architect et est membre de l’IEEE Computer Society.
Tom van Sante, Getronics
Tom van Sante est consultant principal chez Getronics. Il a commencé sa
carrière en informatique il y a plus de 25 ans après avoir fait des étudesd’architecture à l’université technique de Delft. Ayant occupé divers postes
allant des opérations au management, il a toujours travaillé aux frontières
entre le business et l’informatique. Il a participé à l’introduction et au
développement en Hollande d’ITL/ASL/BiSL. Tom van Sante a effectué de
nombreuses missions pour le compte de l’UE et des ministères hollandais,
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 18/177
17TOGAF™ Version 9 – Guide de Poche
lors desquelles il a travaillé sur l’utilisation de l’informatique dans les
sociétés modernes. Il est actuellement responsable de l’introduction et du
développement de TOGAF chez Getronics.
Mike Turner, Capgemini
Mike Turner est architecte d’entreprise chez Capgemini et, au cours des six
dernières années, s’est exclusivement consacré à l’architecture d’entreprise.
Mike aide certains organismes à développer des capacités d’architecture
d’entreprise et leur apporte son assistance dans la mise en œuvre dechangements stratégiques par utilisation de l’architecture d’entreprise.
Mike possède une compréhension approfondie des cadres d’architecture
d’entreprise. Il dirige l’activité de développement de TOGAF Version 9
chez Capgemini et est également membre de l’équipe de base qui est à
l’origine du cadre d’architecture d’entreprise SAP (initiative conjointe entre
Capgemini et SAP).
Paul van der Merwe, Real IRM
Paul van der Merwe, directeur Consulting et Training chez Real IRM,
est l’un des experts en architecture d’entreprise les plus dynamiques et
visionnaires d’Afrique du Sud. Grand théoricien, il est à l’origine de
nombreux progrès réalisés dans les domaines dans lesquels il s’est spécialisé,parmi lesquels le développement de logiciels, la veille stratégique et
l’architecture d’entreprise. Il a donné le premier cours de certification
TOGAF en Afrique du Sud. Il a souvent donné des conférences sur
l’architecture d’entreprise, le cadre Zachman et la gouvernance, et a mis
en place des formations dans ces disciplines sur trois continents. Paul est
également un universitaire renommé et donne un cours de troisième cycledans le département d’informatique de l’université de Pretoria.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 19/177
18 TOGAF™ Version 9 – Guide de Poche
RemerciementsL’Open Group souhaite remercier :• Les anciens et nouveaux membres de l’Architecture Forum de l’Open
Group qui ont développé TOGAF (The Open Group Architecture
Framework),
• Capgemini et SAP pour leurs diverses contributions,
• Les relecteurs de ce document :
– Bill Estrem– Henry Franken
– Judith Jones
– Henk Jonkers
– Kiichiro Onishi
– Roger Reading
– Saverio Rinaldi– Robert Weisman
– Nicholas Yakoubovsky
Pour la traduction, l’AFF (Architecture Forum France) souhaite remercier :
• ARISMORE et IBM pour leur participation active à la traduction des
concepts clés et à la relecture du document traduit,• Peter Golé pour la traduction de l’anglais vers le français,
• Les relecteurs du document traduit :
– Alain Carasso
– Bernard Henri Le Goff
– Sylvain Licheron
– François Maître– Jean-Christophe Mestres
– Renaud Phélizon
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 20/177
Chapitre 1
Présentation de TOGAFTM
Ce chapitre présente TOGAF 9.
Les sujets abordés sont :
• Présentation de TOGAF
• TOGAF, sa structure et son contenu
• Les types d’architectures traités par TOGAF
1.1 Présentation de TOGAF 9TOGAF est un cadre d’architecture – Le Cadre d’Architecture de
l’Open Group (The Open Group Architecture Framework ). En quelques
mots, TOGAF est un outil d’aide à l’appropriation, à la production, à
l’utilisation et à la maintenance des architectures. Il se fonde sur un modèlede processus itératifs faisant appel aux bonnes pratiques et à un actif
architectural réutilisable.
TOGAF est développé et maintenu par l’Architecture Forum de l’Open
Group. La première version de TOGAF, développée en 1995, était
fondée sur le Cadre d’Architecture Technique pour la Gestion des
Informations (TAFIM - Technical Architecture Framework for InformationManagement) du Ministère de la Défense américain. S’appuyant sur ces
solides fondations, l’Architecture Forum de l’Open Group a introduit
à intervalles réguliers de nouvelles versions de TOGAF en les rendant
publiques sur le site Web de l’Open Group.
Le présent document porte sur la version 9 de TOGAF, appelée ci-après
“TOGAF 9”. TOGAF 9 a été introduit en janvier 2009. TOGAF 9 est uneévolution de TOGAF 8.1.1. Une description des modifications est fournie
à l’Annexe A.
TOGAF 9 peut être utilisé pour développer une large gamme
d’architectures d’entreprise. TOGAF complète d’autres cadres conceptuels
( frameworks ) et peut s’utiliser conjointement avec eux. Ces autres cadres
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 21/177
20 TOGAF™ Version 9 – Guide de Poche
correspondent plus étroitement à des livrables spécifiques de certains
secteurs verticaux tels que gouvernement, télécommunications, industrie,
défense et finance. Le concept clé de TOGAF est la méthode, ou plusprécisément, la Méthode de Développement d’Architecture TOGAF
(ADM – Architecture Development Method), qui permet de développer
une architecture d’entreprise répondant à des besoins métiers.
1.2 Structure du Document TOGAF
Le document TOGAF 9 se décompose en sept parties résumées dans letableau 1 ci-après.
Tableau 1 : Structure du document TOGAF
Partie I : Introduction Cette partie fournit une introduction générale
aux concepts clés de l’architecture d’entreprise,
notamment à la démarche TOGAF. Elle définit les
termes utilisés par TOGAF et contient les notesde mise à jour détaillant les différences entre cette
version de TOGAF et la précédente.
Partie II : Méthode
de Développement
d’Architecture
Cette partie est au cœur de TOGAF. Elle décrit
la Méthode de Développement d’Architecture
TOGAF (ADM - Architecture Development Method ),
une démarche pas-à-pas pour le développement
d’une architecture d’entreprise.
Partie III :
Recommandations et
techniques ADM
Cette partie contient un ensemble de
recommandations et de techniques utilisables pour
l’application de l’ADM.
Partie IV : Cadre de
Contenu d’Architecture
Cette partie décrit le cadre de contenu de TOGAF,
qui comprend un métamodèle structuré des
éléments d’architecture, l’utilisation de Building
Blocks d’architecture réutilisables (ABB - Architecture
Building Blocks ) et un aperçu général d’exemples
types de livrables d’architecture.
Partie V : Continuum
d’Entreprise et Outils
Cette partie analyse les taxinomies et les outils
permettant de catégoriser et de stocker les sortants
d’une activité de développement d’architecture au
sein d’une entreprise.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 22/177
21TOGAF™ Version 9 – Guide de Poche
1.3 L’architecture dans le contexte de TOGAFL’ISO/IEC 42010:20072 définit “ l’architecture ” comme étant :
“ L’organisation fondamentale d’un système, mis en œuvre par ses composants,
par les relations que ces derniers ont entre eux et avec l’environnement et par les
principes qui en régissent la conception et l’évolution ”.
TOGAF reprend et élargit cette définition. Selon TOGAF, “ l’architecture ”
a deux significations suivant le contexte :
1. La description formalisée d’un système, ou bien, au niveau d’un
composant, sa description détaillée permettant sa mise en œuvre.
2. La structure des composants, accompagnée des relations entre lescomposants, et les principes et recommandations déterminant leur
conception et leur évolution au cours du temps.
1.4 Types d’Architectures concernés par TOGAFTOGAF 9 permet de développer quatre types d’architectures apparentés.
Ces quatre types d’architectures sont habituellement considérés commeétant des sous-ensembles d’une architecture d’entreprise globale, tous pris
en charge par TOGAF. Le tableau 2 en fournit une liste.
Partie VI : Modèles de
Référence TOGAF
Cette partie propose deux modèles de référence
d’architecture, à savoir le Modèle de Référence
Technique (TRM - Technical Reference Model )
TOGAF, et le Modèle de Référence d’Infrastructure
d’Information Intégrée (III-RM - Integrated
Information Infrastructure Reference Model ).
Partie VII : Cadre de
Capacité d’Architecture
Cette partie traite de l’organisation, des processus,
des compétences, des rôles et des responsabilités
exigés pour créer et faire fonctionner une pratique
d’architecture au sein d’une entreprise.
2 ISO/IEC 42010:2007, Systems and Software Engineering – Recommended Practice
for Architectural Description of Software-Intensive Systems, Edition 1 (techniquement
identique à la norme ANSI/IEEE Std 1471-2000).
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 23/177
22 TOGAF™ Version 9 – Guide de Poche
1.5 Le contenu de TOGAFTOGAF reflète la structure et le contenu de la Capacité d’Architecture au
sein d’une entreprise, comme illustré sur la figure 1.
La Méthode de Développement d’Architecture (décrite dans la partie II
de TOGAF 9) est l’élément central de TOGAF. La capacité d’architecture
(décrite dans la partie VII de TOGAF 9) met en œuvre la méthode. Laméthode fait appel à plusieurs recommandations et techniques (décrites
dans la partie III de TOGAF 9). Il en résulte un contenu qui est ensuite
stocké dans le référentiel (repository ) (décrit dans la partie IV de TOGAF 9)
après classification conformément au Continuum d’Entreprise (décrit dans
la partie V de TOGAF 9). Le référentiel est initialement peuplé de modèles
de référence TOGAF (TOGAF Reference Models - TRM) (décrits dans lapartie VI de TOGAF 9).
Tableau 2 : Types d’Architectures pris en charge par TOGAF
Type Architecture Description
Architecture du
Business
Stratégie du business, gouvernance, organisation et processus
métiers clés
Architecture des
Données3
Structure des actifs de données logiques et physiques d’une
organisation et ressources de gestion des données.
Architecture des
Applications
Plan général destiné au déploiement des applications,
décrivant leurs interactions et leurs relations avec les
principaux processus métiers de l’entreprise.
ArchitectureTechnique Capacités des logiciels et des matériels nécessaires audéploiement de services métiers, données et applications.
Cela comprend l’infrastructure informatique, le middleware,
les réseaux, les communications, les moyens de traitement et
les standards.
3 Certains organismes désignent l’Architecture des données sous le nom d’Architecture
d’informations
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 24/177
23TOGAF™ Version 9 – Guide de Poche
1.5.1 Le Modèle de Développement d’Architecture(ADM)L’ ADM ( Architecture Development Model ) décrit la façon d’élaborer une
architecture d’entreprise devant répondre aux exigences métiers spécifiques
d’une organisation. L’ADM est le principal composant de TOGAF et
assiste les architectes à plusieurs niveaux :
Les besoins du business déterminant les aspectsnon architecturaux du fonctionnement d'une entreprise
Les leçons tirées du fonctionnementdu business créent de nouveaux besoins
Les besoins dubusiness interagissent
avec la méthodeidentifiant ainsi lesproblèmes à traiter
La méthode affine lacompréhension des besoins du business
Le Continuumd'Entreprise et le
Référentielinforment l'entreprise
de l'état instantanédu développement
La méthodeproduit un contenu
qui sera stockédans le Référentiel et
classé selon leContinuum d'Entreprise
ADM & Cadre
de contenu TOGAF
Capacitésdu business
Vision duBusiness etMoteurs de
Business
Cadre de Capacitéd'Architecture
(Partie VII)
Méthode deDéveloppementd'Architecture
(Partie II)
Continuumd'Entreprise
et Outils (Partie V)
Cadre deContenu
d'Architecture(Partie IV)
Modèles deRéférence
TOGAF (Partie VI)
Recommandationset Techniques
ADM (Partie III)
La méthode délivrede nouvelles
solutions pourle business
Les modificationsopérationnelles
mettent à jour lecontinuumd'entreprise
et le Référentiel
La Capacité d'Architecturemet en œuvre une méthode
Renseigne surla taille,la
structure et laculture des capacités
Le fonctionnementeffectif des Capacités
d'Architecturegarantit la réalisation
de la Vision du business
Les degrés de maturitédes Capacitésd’Architecture
sont tirés par lesCapacités du business
Fixe les objectifs,les KPI, les plans et
les budgets pour lesrôles d'architecture
Cadre de Capacité TOGAF
Continuum d'Entreprise et Outils TOGAF
Figure 1 : Synoptique du contenu de TOGAF
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 25/177
24 TOGAF™ Version 9 – Guide de Poche
• Elle propose un certain nombre de phases d’un cycle de
développement d’architecture (Architecture du Business, Architectures
des Systèmes d’Information, Architecture Technique), sous la formed’un modèle de processus global destiné à l’activité de développement
d’architectures.
• Elle fournit un descriptif de chaque phase de l’architecture,
présentant ses objectifs, sa démarche, ses entrants, ses étapes et ses
sortants. Les parties concernant les entrants et les sortants définissent la
structure du contenu d’une architecture et les livrables (une descriptiondétaillée des entrants de phase et des sortants de phase est fournie dans
le Cadre de Contenu d’Architecture).
• Elle fournit des récapitulatifs de l’ensemble des phases couvrant la
gestion des exigences.
L’ADM est décrite plus en détail au Chapitre 2.
1.5.2 Recommandations et techniques ADMLe chapitre Recommandations et techniques ADM décrit un certain
nombre de recommandations et de techniques aidant à l’application de
l’ADM. Ces recommandations indiquent comment adapter l’ADM à
différents cas d’utilisation comme divers styles de processus (utilisant parexemple des itérations) ou certaines architectures spécialisées (telles que la
sécurité). Les techniques interviennent dans certaines tâches inhérentes à la
méthode ADM (comme les principes fondamentaux, les scénarios métiers,
l’analyse d’écart, la planification de migration, la gestion du risque, etc.).
Les recommandations ADM sont détaillées au chapitre 4. Les techniques ADM sont détaillées au chapitre 3 en association avec les livrables clés.
1.5.3 Le Cadre de Contenu d’ArchitectureLe Cadre de Contenu d’Architecture propose un modèle détaillé des
fournitures de l’architecture, parmi lesquelles les livrables, les éléments
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 26/177
25TOGAF™ Version 9 – Guide de Poche
contenus dans les livrables, et les Building Blocks d’Architecture (ABB—
Architecture Building Blocks ) que représentent les livrables.
Le Cadre de Contenu d’Architecture est décrit plus en détail au Chapitre 5.
1.5.4 Le Continuum d’EntrepriseLe Continuum d’Entreprise est un modèle permettant de structurer
un référentiel virtuel. Il fournit des méthodes permettant de classer des
éléments d’architecture décrivant des principes ou des solutions et illustre
la façon dont évoluent les différents types d’éléments d’architecture et lafaçon dont on peut les exploiter et les réutiliser. Ce continuum se fonde
sur des architectures et des solutions (modèles, patterns , descriptions
d’architectures, etc.) présentes au sein de l’entreprise ou de l’industrie en
général, et accumulées par l’entreprise tout au long du développement de
ses architectures.
Le Continuum d’Entreprise est détaillé plus avant au Chapitre 6.
1.5.5 Les Modèles de référence TOGAFTOGAF propose deux Modèles de référence pouvant être incorporés à
un Continuum d’entreprise particulier, à savoir le Modèle de Référence
Technique (TRM – Technical Reference Model ) TOGAF et le Modèle de
Référence d’Infrastructure d’Information Intégrée (III-RM - IntegratedInformation Infrastructure Reference Model ).
Les Modèles de référence TOGAF sont détaillés plus avant au chapitre 7.
1.5.6 Le Cadre de Capacité d’Architecture
Le Cadre de Capacité d’Architecture est un ensemble de ressources, derecommandations, de modèles, d’informations d’arrière-plan, etc., aidant
l’architecte à établir une pratique d’architecture au sein d’une organisation.
Le Cadre de Capacité d’Architecture est détaillé plus avant au chapitre 8.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 27/177
26 TOGAF™ Version 9 – Guide de Poche
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 28/177
Chapitre 2
La Méthode de Développe-ment d’ArchitectureCe chapitre décrit la Méthode de Développement d’Architecture (ADM),
ses relations avec le reste de TOGAF et certaines considérations abstraites
quant à son utilisation. Il comporte également un résumé de chaque phasede l’ADM.
Les sujets abordés dans ce chapitre comprennent :
• Une présentation de l’ADM
• Les phases de l’ADM
• Les objectifs, étapes, entrants et sortants des phases de l’ADM• La gestion des exigences pendant le cycle ADM
• La dénition du périmètre de l’activité architecturale
2.1 Qu’est-ce que l’ADM ?L’ADM, qui est le fruit des contributions d’un grand nombre d’architectes,
est le cœur de TOGAF. Il s’agit d’une méthode permettant d’élaborerdes architectures d’entreprise propres à chaque organisation. Elle est
spécifiquement conçue pour répondre aux exigences de l’entreprise.
L’ADM décrit :
• Une démarche able et éprouvée permettant de développer et d’utiliser
une architecture d’entreprise
• Une méthode de développement d’architectures à des niveaux différents4
(business, applications, données, technique) qui permettent à l’architecte
de bien prendre en compte un jeu complexe d’exigences.
• Des recommandations concernant les outils utilisés dans le
développement d’une architecture
4 Dans TOGAF on les désigne sous le nom d’ensemble de domaines de l’architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 29/177
28 TOGAF™ Version 9 – Guide de Poche
2.2 Quelles sont les phases de l’ADM?L’ADM est constituée d’un certain nombre de phases organisées
cycliquement en plusieurs domaines de l’architecture qui permettentà l’architecte de répondre de façon adéquate à un ensemble complexe
d’exigences. La structure de base de l’ADM est représentée sur la figure 2.
Figure 2 : Cycle de la Méthode de Développement d’Architecture
Gestion desExigences
Phasepréliminaire
A.Vision de
l'Architecture
E.Opportunitéset Solutions
F.
Planificationde la migration
G.Gouvernance de
la Miseen Œuvre
H.Gestion du
Changementd'Architecture
B.Architecturedu Business
C.Architecturedes Systèmesd'Information
D.Architectures
Techniques
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 30/177
29TOGAF™ Version 9 – Guide de Poche
L’ADM est appliquée de façon itérative tout au long du processus, entre les
phases, et au sein même de celles-ci. Pendant tout le cycle ADM, on doit
prendre soin de valider régulièrement les résultats par rapport aux exigencesinitiales, aussi bien celles du cycle ADM dans son ensemble, que celles
d’une phase particulière du processus. Ces validations devront réévaluer le
périmètre, les détails, les planifications et les jalons.
Chaque phase doit prendre en compte les actifs produits par les itérations
précédentes du processus et d’autres actifs disponibles sur le marché, par
exemple d’autres cadres ( frameworks ) ou modèles.
L’ADM utilise le concept d’itération à trois niveaux différents :
• Les cycles de l’ADM : L’ADM peut être représenté par un cercle
qui indique que l’achèvement d’une phase du chantier d’architecture
alimente directement les phases suivantes du chantier d’architecture.
• Itération entre les phases : TOGAF décrit le concept d’itération entrephases (par exemple le retour à l’Architecture du Business une fois
l’Architecture Technique achevée).
• Les cycles au sein d’une même phase : TOGAF permet de répéter
l’exécution des activités réalisées au sein d’une même phase ADM. Cette
technique permet d’élaborer le contenu de l’architecture.
D’autres informations concernant les itérations sont indiquées dans lapartie III de TOGAF 9 : Recommandations et Techniques de l’ADM
(Chapitre 4).
Tableau 3 : Les activités de l’ADM phase par phase
Phase ADM Activité
Phase préliminaire Préparer l’organisation pour la réussite des projets
d’architecture TOGAF. Entreprendre les activités depréparation et de démarrage nécessaires pour aligner les
recommandations métiers pour une nouvelle architecture
d’entreprise, incluant la définition d’un cadre d’architecture
et d’outils propres à l’organisation, avec la définition des
principes.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 31/177
30 TOGAF™ Version 9 – Guide de Poche
Phase ADM Activité
Gestion des
exigences
Chaque stade d’un projet TOGAF fait appel à des exigences
du métier et valide ces dernières.
Les exigences sont identifiées, stockées et délivrées comme
entrants et sortants des phases ADM concernées, qui
manipulent, traitent et hiérarchisent ces exigences.
A. Vision de
l’Architecture
Définir le périmètre, les contraintes et les attentes d’un
projet TOGAF. Créer une Vision de l’Architecture. Définir
les acteurs concernés. Valider le contexte du métier et
créer la Définition du Chantier d’Architecture. Obtenir les
approbations.
B. Architecture du
Business
C. Architectures
des Systèmes
d’Information
D. Architecture
Technique
Développer les architectures à trois niveaux :
• Business
• Systèmes d’Information (Applications et Données)
• Technique
Dans chaque cas, développer les Architectures Initiale et
Cible et analyser les écarts.
E. Opportunités et
Solutions
Effectuer une première planification de mise en œuvre et
une première identification des modalités de livraison pour
les Building Blocks identifiés lors des phases précédentes.
Identifier les principaux projets de mise en œuvre et les
regrouper en Architectures de Transition.
F. Planification de
la Migration
Analyser les avantages et les risques financiers. Développer
un plan détaillé de Mise en œuvre et de Migration.G. Gouvernance de
la Mise en œuvre
Assurer la supervision de la mise en œuvre par l’architecture.
Préparer et diffuser les Contrats d’Architecture (Comité de
Gouvernance de la Mise en œuvre). Vérifier que le projet de
mise en œuvre respecte l’architecture.
H. Gestion du
Changement
d’Architecture
Assurer un suivi continu et prévoir un processus de gestion
des changements garantissant que l’architecture réponde aux
besoins de l’entreprise et rende maximale la valeur ajoutée del’architecture pour le métier.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 32/177
31TOGAF™ Version 9 – Guide de Poche
2.3 L’ADM en détailLes tableaux suivants récapitulent les objectifs, les étapes et les entrants et
sortants5
de chaque phase du cycle ADM.
2.3.1 Phase préliminaireLa Phase Préliminaire prépare une organisation donnée à la réalisation de
projets d’architecture d’entreprise réussis.
Cette phase peut-être récapitulée de la façon suivante :
5 Les numéros de version correspondant à des livrables particuliers ont été omis de ce
Guide de Poche car TOGAF dénit le mode de numérotation ADM à seule titre d’exemple,
celui-ci devant être adapté selon les circonstances.
Objectifs Etapes
Analyser le contexte de l’organisation pour réaliser
une architecture d’entreprise
Identifier les acteurs concernés, leurs exigences et
leurs priorités
Vérifier l’engagement des acteurs concernés
Identifier et définir le périmètre des éléments des
organisations d’entreprise qui sont affectés et
définir les contraintes et les hypothèses ; cela est
très important pour les grandes organisations
dans lesquelles il peut exister un environnement
d’architecture fédérée
Définir “la place et le poids de l’architecture” d’une
organisation ; c’est-à-dire les personnes responsables
de la réalisation du chantier d’architecture, leur
situation géographique et leurs responsabilités
Définir le cadre et le détail des méthodologies qui
vont être utilisées pour développer l’architecture
d’entreprise dans l’organisation ; il s’agit
typiquement d’une adaptation de l’ADM
Définir le périmètre des
organisations d’entreprise
concernées
Vérifier les cadres de
gouvernance et de support
Définir et établir l’équipe
et l’organisation de
l’architecture d’entreprise
Identifier et établir des
principes d’architecture
Sélectionner et adapter
un ou des cadre(s)
d’architecture
Mettre en œuvre des outils
d’architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 33/177
32 TOGAF™ Version 9 – Guide de Poche
2.3.2 Phase A : Vision de l’Architecture
La Phase A concerne l’établissement d’un projet et déclenche une itérationdu cycle de développement de l’architecture, en définissant le périmètre,
les contraintes et les attentes correspondant à cette itération. Elle est exigée
pour valider le contexte du métier et pour créer la Définition du Chantier
d’Architecture approuvée.
Objectifs Etapes
Etablir un cadre de gouvernance et de support
assurant la gouvernance du processus et de
l’architecture du business tout au long du cycle
ADM ; cela permettra de vérifier la bonne
adéquation et l’efficacité à un instant donné de
l’Architecture Cible ; cela inclut normalement un
projet pilote initial
Sélectionner et mettre en œuvre des outils de support
et d’autres infrastructures venant en soutien de
l’activité d’architectureDéfinir les principes d’architecture contraignants
Entrants Sortants
TOGAF
Autre(s) cadre(s) d’architecture
Principes du business, buts du business et moteurs
du business
Stratégie de gouvernance d’architectureStratégie informatique
Modèle organisationnel existant pour l’architecture
d’entreprise
Cadre d’architecture existant, s’il y en a
Principes d’architecture existants, s’il y en a
Référentiel d’Architecture existant, s’il y en a
Modèle d’organisation pour
l’architecture d’entreprise
Cadre d’Architecture
Personnalisé, y compris les
principes d’architectureRéférentiel d’Architecture
Initial
Principes du business, buts
du business et moteurs
du business redéfinis ou
utilisés tels quels
Demande de Mise enChantier de l’Architecture
Cadre de gouvernance
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 34/177
33TOGAF™ Version 9 – Guide de Poche
Objectifs Etapes
Obtenir un engagement du management
pour ce cycle particulier de l’ADM
Définir et organiser un cycle de
développement de l’architecture
Valider les principes, les buts, les
moteurs et les indicateurs clés de
performances (KPI – Key Performance
Indicators ) du business
Définir, cadrer et hiérarchiser les tâches
architecturales.Identifier les acteurs concernés, leurs
préoccupations et leurs objectifs
Définir les exigences et les contraintes
du business
Elaborer une Vision de l’Architecture et
évaluer les propositions de réponse aux
exigences et aux contraintesCréer un plan global aligné avec les
cadres de gestion du projet ayant été
adoptés par l’entreprise
Obtenir une approbation formelle pour
poursuivre
Comprendre l’impact sur et produit
par d’autres cycles de développementparallèles de l’architecture
Etablir le projet d’architecture
Identifier les acteurs concernés, les
préoccupations et les exigences du
métier
Fixer et élaborer des buts du business,
des moteurs du business et des
contraintes
Évaluer les capacités du business
Estimer l’état de préparation à la
transformation du businessDéfinir le périmètre
Fixer et élaborer des principes
d’architecture, y compris les principes
du business
Développer une Vision de l’Architecture
Définir les propositions de valeurs et les
KPI de l’Architecture CibleIdentifier les risques associés à la
transformation du business et les
activités d’atténuation des risques
Développer des plans d’architecture
d’entreprise et une Définition du
Chantier d’Architecture ; obtenir une
approbation
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 35/177
34 TOGAF™ Version 9 – Guide de Poche
2.3.3 Phase B : Architecture du BusinessLa phase B concerne le développement d’une Architecture du Business qui
va venir en support d’une Vision de l’Architecture acceptée.
Entrants Sortants
Demande de Mise en Chantier de
l’Architecture
Principes du business, buts du business
et moteurs du business
Modèle d’organisation pour
l’architecture d’entreprise
Cadre d’Architecture Contextualisé, y
compris les principes d’architecture
Référentiel d’Architecture Peuplé ;
ou documentation de l’architectureexistante (descriptif des cadres,
descriptifs d’architecture, descriptifs de
l’existant initial, etc.)
Approbation du Chantier d’Architecture
Proposé
Définitions précisées des principes du
business, des buts du business et des
moteurs du business
Principes d’architecture
Évaluation des capacités
Cadre d’Architecture Contextualisé
Vision de l’Architecture, cela
comprenant :– Un affinement des principales
exigences abstraites des acteurs
concernés
– Architecture Initiale du Business
(vision)
– Architecture Initiale des Données
(vision)– Architecture Initiale des Applications
(vision)
– Architecture Technique Initiale
(vision)
– Architecture Cible du Business
(vision)
– Architecture Cible des Données(vision)
– Architecture Cible des Applications
(vision)
– Architecture Technique Cible (vision)
Plan de Communication
Contenu Supplémentaire peuplant le
Référentiel d’Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 36/177
35TOGAF™ Version 9 – Guide de Poche
Objectifs Etapes
Décrire l’Architecture Initiale du
Business
Développer une Architecture Cible
du Business
Analyser les écarts entre les
Architecture Initiale et Cible
Sélectionner des points de vue
de l’architecture pour montrer
comment les préoccupations des
acteurs concernés sont prises encompte dans l’Architecture du
Business
Sélectionner des outils et des
techniques correspondant à ces
points de vue
Sélectionner des modèles, des points de vue
et des outils de Référence
Développer une Description de
l’Architecture Initiale du Business
Développer une Description de
l’Architecture Cible du Business
Effectuer une analyse des écarts
Définir les composants de la Feuille de
route (roadmap)
Résoudre les impacts sur tout le Paysage del’Architecture
Passer en revue de façon formelle les acteurs
concernés
Finaliser l’Architecture du Business
Créer un Document de Définition de
l’Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 37/177
36 TOGAF™ Version 9 – Guide de Poche
Entrants Sortants
Demande de Mise en Chantier de
l’Architecture
Principes du business, buts du
business et moteurs du business
Évaluation des Capacités
Plan de Communication
Modèle d’organisation pour
l’architecture d’entreprise
Cadre d’Architecture Contextualisé
Approbation du Chantierd’Architecture
Principes d’Architecture, y compris
les principes du business, lorsqu’ils
préexistent
Continuum d’Entreprise
Référentiel d’Architecture
Vision de l’Architecture, y compris :– Les exigences clés des acteurs
concernés précisées à haut niveau
– Architecture Initiale du Business
(vision)
– Architecture Initiale des Données
(vision)
– Architecture Initiale des Applications (vision)
– Architecture Technique Initiale
(vision)
– Architecture Cible du Business
(vision)
– Architecture Cible des Données
(vision)
– Architecture Cible des
Applications (vision)
– Architecture Cible Technique
(vision)
Définition du Chantier d’Architecture, mise
à jour si nécessaire
Validation des principes du business,
des buts du business et des moteurs du
business
Elaboration des Principes de l’Architecture
du Business
Document Provisoire de Définition de
l’Architecture comprenant des mises à jour
du contenu :– Architecture Initiale du Business
(détaillée), si nécessaire
– Architecture Cible du Business (détaillée)
– Vues correspondant à des points de
vue sélectionnés prenant en compte les
préoccupations clés des acteurs concernés
– Spécifications provisoires des exigencesl’Architecture, comprenant les mises à
jour du contenu :
– Résultats de l’analyse des écarts
– Exigences techniques
– Mises à jour des exigences du métier
Composants d’Architecture du Business
dans une feuille de route d’Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 38/177
37TOGAF™ Version 9 – Guide de Poche
2.3.4 Phase C : Architectures des Systèmesd’Information
La phase C documente l’organisation fondamentale des systèmesinformatiques d’une organisation, ceux-ci étant par exemple les principaux
types d’information et les systèmes d’applications qui les traitent.
Cette phase comprend deux étapes qui peuvent être développées soit
séquentiellement, soit simultanément :
• l’Architecture des Données
• l’Architecture des Applications
2.3.4.1 Architecture des Données
Objectifs Etapes
Définir de façon compréhensible par
les acteurs concernés les types et les
sources de données dont a besoin lebusiness
Sélectionner des modèles, des points de
vue et des outils de Référence
Développer une Description Initiale del’Architecture des Données
Développer une Description de
l’Architecture Cible du Business
Effectuer une analyse des écarts
Définir les composants de la feuille de
route
Résoudre les impacts sur tout le paysagede l’Architecture
Passer en revue de façon formelle les
acteurs concernés
Finaliser l’Architecture des données
Créer un Document de Définition de
l’Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 39/177
38 TOGAF™ Version 9 – Guide de Poche
Entrants Sortants
Demande de Mise en Chantier de
l’Architecture
Évaluation des Capacités
Plan de Communication
Modèle d’organisation pour
l’architecture d’entreprise
Cadre d’Architecture Contextualisé
Principes concernant les données
Définition du Chantier d’Architecture
Vision de l’ArchitectureRéférentiel d’Architecture
Document Provisoire de Définition de
l’Architecture contenant :
– l’Architecture Initiale du Business
(détaillée)
– l’Architecture Cible du business
(détaillée)– l’Architecture Cible des Données
(vision)
– l’Architecture Initiale des
Applications (détaillée ou vision)
– l’Architecture Cible des Applications
(détaillée ou vision)
– l’Architecture Technique Initiale(vision)
– l’Architecture Technique Cible
(vision)
Spécification Provisoire des Exigences
de l’Architecture, avec :
– Les résultats de l’analyse des écarts
– Les exigences techniques pertinentes
Composants de l’Architecture du
Business dans une Feuille de route
d’Architecture
Définition du Chantier d’Architecture,
mise à jour si nécessaire
Principes validés concernant les données
ou nouveaux principes concernant les
données
Document Provisoire de Définition de
l’Architecture, comprenant des mises à
jour du contenu :
– Architecture Initiale des données
– Architectures Cible des données– Vues de l’architecture des données
correspondant aux points de vue
sélectionnés et tenant compte des
préoccupations des acteurs clés
– Spécifications Provisoires des Exigences
de l’Architecture, comprenant les mises
à jour du contenu :– Résultats de l’analyse des écarts
– Exigences d’interopérabilité des
données
– Exigences techniques pertinentes
devant s’appliquer à cette évolution
du cycle de développement de
l’architecture– Contraintes sur l’Architecture
Technique
– Mise à jour des exigences du métier
– Mise à jour des exigences des
applications
Composants de l’Architecture des
Données dans une Feuille de route
d’Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 40/177
39TOGAF™ Version 9 – Guide de Poche
2.3.4.2 Architecture des Applications
Objectifs Etapes
Définir les types de systèmes
d’application nécessaires au traitement
des données et utiles au business
Sélectionner des modèles, des points de
vue et des outils de Référence
Développer la Description de
l’Architecture Initiale des Applications
Développer la Description de
l’Architecture Cible des Applications
Effectuer l’analyse des écarts
Définir les composants de la Feuille deroute
Résoudre les impacts sur tout le Paysage
de l’Architecture
Effectuer un passage en revue formel des
acteurs concernés
Finaliser l’Architecture des Applications
Créer un Document de Définition del’Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 41/177
40 TOGAF™ Version 9 – Guide de Poche
Entrants Sortants
Demande de Mise en Chantier de
l’Architecture
Évaluation des Capacités
Plan de Communication
Modèle d’organisation pour
l’architecture d’entreprise
Cadre d’Architecture Contextualisé
Principes des applications
Définition du Chantier d’Architecture
Vision de l’ArchitectureRéférentiel d’Architecture
Document Provisoire de Définition de
l’Architecture contenant :
– Architecture Initiale du Business
(détaillée)
– Architecture cible du Business
(détaillée)– Architecture Initiale des Données
(détaillée ou vision)
– Architecture Cible des données
(détaillée ou vision)
– Architecture Initiale des Applications
(vision)
– Architecture Cible des Applications(vision)
– Architecture Technique Initiale
(vision)
– Architecture Technique Cible
(vision)
Spécification Provisoire des Exigences
de l’Architecture, y compris :
– Résultats d’analyse des écarts
– Exigences techniques pertinentes
Composants des Architectures du
Business et des Données dans une
Feuille de route d’Architecture
Définition du Chantier d’Architecture,
mise à jour si nécessaire
Principes d’application validés, ou
nouveaux principes d’application
Document Provisoire de Définition de
l’Architecture, comprenant des mises à
jour du contenu :
– Architecture Initiale des Applications
– Architecture Cible des Applications
– Vues de l’Architecture des Applicationscorrespondant aux points de vue
sélectionnés, prenant en compte les
préoccupations des acteurs clés
– Spécifications Provisoires des Exigences
de l’Architecture, comprenant les mises
à jour du contenu :
– Résultats de l’analyse des écarts– Exigences d’interopérabilité des
applications
– Exigences techniques pertinentes
devant s’appliquer à cette évolution
du cycle de développement de
l’architecture
– Contraintes imposées à l’ArchitectureTechnique
– Mise à jour des exigences du métier
– Mise à jour des exigences concernant
les données
Composants de l’Architecture des
Applications dans une Feuille de route
d’Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 42/177
41TOGAF™ Version 9 – Guide de Poche
2.3.5 Phase D : Architecture TechniqueLa phase D consiste à documenter l’organisation fondamentale des
systèmes informatiques, à savoir les matériels, les logiciels et les techniquesde communication.
Objectifs Etapes
Développer une Architecture
Technique Cible qui constituera le
point de départ de la mise en œuvre et
de la planification de migrations quis’ensuivront
Sélectionner des modèles, des points de
vue et des outils de Référence
Développer une Description de
l’Architecture Technique InitialeDévelopper une Description de
l’Architecture Technique Cible
Effectuer une analyse des écarts
Définir les composants de la Feuille de
route
Résoudre les impacts sur tout le Paysage
de l’ArchitectureEffectuer un passage en revue formel des
acteurs concernés
Finaliser l’Architecture Technique
Créer un Document de Définition de
l’Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 43/177
42 TOGAF™ Version 9 – Guide de Poche
Entrants Sortants
Demande de Mise en Chantier de
l’Architecture
Évaluation des Capacités
Plan de Communication
Modèle d’organisation pour
l’architecture d’entreprise
Cadre d’Architecture Contextualisé
Principes techniques
Définition du Chantier d’Architecture
Vision de l’ArchitectureRéférentiel d’Architecture
Document Provisoire de Définition de
l’Architecture contenant :
– Architecture Initiale du Business
(détaillée)
– Architecture Cible du Business
(détaillée)– Architecture Initiale des Données
(détaillée)
– Architecture Cible des données
(détaillée)
– Architecture Initiale des Applications
(détaillée)
– Architecture Cible des Applications(détaillée)
– Architecture Technique Initiale
(vision)
– Architecture Technique Cible
(vision)
Spécification Provisoire des Exigences
de l’Architecture, y compris :
– Résultats de l’analyse des écarts
– Exigences techniques pertinentes
Composants des Architectures
du Business, des Données et des
applications dans une Feuille de route
d’Architecture
Définition du Chantier d’Architecture,
mise à jour si nécessaire
Principes techniques validés ou nouveaux
principes techniques (s’ils sont générés
à ce stade)
Document Provisoire de Définition de
l’Architecture, comprenant des mises à
jour du contenu :
– Architecture Technique Initiale
– Architectures Techniques Cibles– Vues de l’Architecture Technique
correspondant aux points de vue
sélectionnés, prenant en compte les
préoccupations des acteurs clés
– Spécifications Provisoires des Exigences
de l’Architecture, comprenant les mises
à jour du contenu :– Rapport d’analyse des écarts
– Exigences en sortie des phases B et C
– Mises à jour des exigences techniques
Composants de l’Architecture Technique
dans une Feuille de route d’Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 44/177
43TOGAF™ Version 9 – Guide de Poche
2.3.6 Phase E : Opportunités et SolutionsLa phase E est la première phase concernant directement la mise en œuvre.
Elle décrit le processus consistant à identifier la forme des livrables (projets,programmes ou portefeuilles) qui délivrent l’Architecture Cible identifiée
lors des phases précédentes.
Objectifs Etapes
Passer en revue les objectifs et les
capacités cibles du business, consolider
les écarts des phases B à D, puisorganiser des groupes de building
blocks pour prendre en compte ces
capacités
Vérifier si l’entreprise pourra s’adapter à
un changement
En déduire une série d’Architectures
de Transition qui produiront enpermanence de la valeur métier (par
exemple des paliers de capacités)
par exploitation d’opportunités
permettant de réaliser les building
blocks
Dégager et aboutir à un consensus sur
une Stratégie Générale de Mise enœuvre et de Migration
Déterminer/vérifier les principaux
attributs d’un changement d’entreprise
Déterminer les contraintes du businessimposées à la mise en œuvre
Passer en revue et consolider les résultats
de l’analyse des écarts des phases B à D
Analyser d’un point de vue fonctionnel
les exigences de l’informatique
Consolider et réconcilier les exigences
d’interopérabilité Affiner et valider les dépendances
Vérifier l’état de préparation et les
risques associés à une transformation
du business
Formuler une Stratégie de Mise en œuvre
et de migration à haut niveau
Identifier et regrouper des lots de travail(work packages )
Identifier les Architectures de Transition
Créer des chartes de portefeuilles et de
projets et mettre à jour les architectures
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 45/177
44 TOGAF™ Version 9 – Guide de Poche
Entrants Sortants
Information sur les Produits
Demande de Mise en Chantier de
l’Architecture
Évaluation des Capacités
Méthodologies de Planification
Modèle d’organisation pour
l’Architecture d’entreprise
Cadre d’Architecture Contextualisé
Définition du Chantier d’Architecture
Vision de l’ArchitectureRéférentiel d’Architecture
Document Provisoire de Définition de
l’Architecture
Spécification Provisoire des Exigences
de l’Architecture
Demandes de changement de
programmes et de projets existants
Définition du Chantier d’Architecture,
éventuellement mise à jour
Vision de l’Architecture, éventuellement
mise à jour
Document Provisoire de Définition de
l’Architecture, y compris les mises à jour
du contenu pour :
– L’Identification des Paliers
– Les exigences d’interopérabilité et de
coexistence– La Stratégie de Mise en œuvre et de
Migration
– L’Inclusion de la liste de projets et des
chartes de projets
Spécification Provisoire des Exigences
de l’Architecture, éventuellement mise
à jourÉvaluation des capacités, y compris les
mises à jour concernant :
– Le profil de maturité de l’Architecture
d’entreprise
– Le rapport de Préparation à la
Transformation
Architectures de Transition, comprenant :– Ecarts Consolidés, Solutions et
Évaluation des Dépendances
– Registre des Risques
– Analyse d’impact - liste de projets
– Rapport d’Analyse des Dépendances
– Évaluation des Facteurs de Mise en
œuvre et Matrice de Détermination
– Plan de Mise en œuvre et de Migration
(grandes lignes)
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 46/177
45TOGAF™ Version 9 – Guide de Poche
2.3.7 Phase F : Planification de MigrationLa phase F concerne la planification de la migration ; c’est-à-dire la façon
de passer de l’Architecture Initiale à l’Architecture Cible en finalisant unPlan de Mise en œuvre et de Migration.
Objectifs Etapes
S’assurer de la coordination entre
le Plan de Mise en œuvre et de
Migration et les divers cadres de
gestion utilisés par l’entrepriseHiérarchiser tous les lots de travail,
les projets et les building blocks en
affectant à chacun d’entre eux une
valeur métier et en conduisant une
analyse du coût ou du business
Finaliser les documents de Vision
de l’Architecture et de Définitionde l’Architecture, dans le sens de la
démarche choisie pour la mise en
œuvre
Confirmer les Architectures de
Transition définies à la phase E en
accord avec les acteurs concernés
Créer, faire évoluer et surveiller le
Plan détaillé de Mise en œuvre et
de Migration, en fournissant les
ressources nécessaires pour permettre
la réalisation des Architectures de
Transition, comme défini à la phase E
Confirmer les interactions entre les cadres
de gestion pour le Plan de Mise en
œuvre et de Migration
Affecter une valeur métier à chaque projetEstimer les exigences en ressources, la
chronologie des projets et la disponibilité
ou la forme des livrables
Hiérarchiser les projets de migration en
conduisant une évaluation du coût/
bénéfice et une validation des risques
Vérifier les paliers/phases del’architecture de Transition et mettre
à jour le Document de Définition de
l’Architecture
Générer la Feuille de route de la Mise
en œuvre de l’Architecture (avec sa
chronologie) et le Plan de Migration
Etablir le cycle de vie de l’architecture
et documenter les leçons qui ont pu
être tirées
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 47/177
46 TOGAF™ Version 9 – Guide de Poche
Entrants Sortants
Demande de Mise en Chantier de
l’Architecture
Évaluation des Capacités
Plan de Communication
Modèle d’organisation pour
l’architecture d’entreprise
Modèles et Cadres de Gouvernance
Cadre d’Architecture Contextualisé
Définition du Chantier d’Architecture
Vision de l’ArchitectureRéférentiel d’Architecture
Document Provisoire de Définition de
l’Architecture, y compris :
– le Plan Stratégique de Migration
– l’analyse d’impact - liste et chartes
de projets
Spécification provisoire des exigencesde l’Architecture
Demandes de changement de
programmes et de projets existants
Feuille de route consolidée et validée de
l’architecture
Architectures de Transition
Plan de Mise en œuvre et de Migration(grandes lignes)
Plan de Mise en œuvre et de migration
(détaillé)
Document finalisé de Définition de
l’Architecture,
Spécification Finalisée des Exigences de
l’Architecture
Cadre d’Architecture Finalisé
Architecture de Transition
Building Blocks Réutilisables de
l’ArchitectureDemandes de Mise en Chantier
d’Architecture pour les aspects de
l’architecture concernant les (éventuels)
projets de mise en œuvre
Contrats d’Architecture pour les projets
de mise en œuvre
Modèles de Gouvernance de la Mise enœuvre
Demandes de Changement résultant des
leçons qui ont pu être tirées
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 48/177
47TOGAF™ Version 9 – Guide de Poche
2.3.8 Phase G : Gouvernance de la Mise en œuvreLa phase G définit la façon dont l’architecture contraint les projets de mise
en œuvre, en assure le suivi pendant sa construction et produit un Contratd’Architecture signé.
Objectifs Etapes
Formuler des recommandations sur
chaque projet de mise en œuvre
Gouverner et gérer un Contrat
d’Architecture couvrant l’ensembledu processus de mise en œuvre et de
déploiement
Exécuter des fonctions de gouvernance
adéquates pendant la mise en œuvre et
le déploiement du système
S’assurer de la conformité des projets
de mise en œuvre et autres projets avecl’architecture définie
S’assurer du bon déploiement du
programme de solutions, à la façon
d’un programme de travail planifié
S’assurer de la conformité de la solution
déployée avec l’Architecture Cible
Mobiliser les opérations de support
qui seront à la base de la future vie
de fonctionnement de la solution
déployée
Vérifier le périmètre et les priorités
du déploiement tout en gérant le
développement
Identifier les ressources et les compétencesde déploiement
Guider le développement de solutions de
déploiement
Effectuer des analyses de conformité de
l’architecture d’entreprise
Exécuter des opérations au niveau du
métier et de l’informatiqueEffectuer une analyse post-mise en œuvre
et clore la mise en œuvre
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 49/177
48 TOGAF™ Version 9 – Guide de Poche
Entrants Sortants
Demande de Mise en Chantier de
l’Architecture
Évaluation des Capacités
Modèle d’organisation pour
l’Architecture d’entreprise
Cadre d’Architecture Contextualisé
Définition du Chantier d’Architecture
Vision de l’Architecture
Référentiel d’Architecture
Document de Définition del’Architecture
Spécification des Exigences de
l’Architecture
Feuille de route de l’Architecture
Architecture de Transition
Modèle de Gouvernance de la Mise
en œuvreContrat d’Architecture
Demande de Mise en Chantier de
l’Architecture identifiés aux phases
E et F
Plan de Mise en œuvre et de Migration
Contrat d’Architecture (signé)
Evaluations de Conformité
Demandes de Changement
Analyse des Impacts - Recommandations
de Mise en œuvre
Déploiement de solutions conformes à
l’architecture, cela comprenant :
– Le système mis en œuvre en
conformité avec l’architecture
– Le Référentiel d’Architecture Peuplé– Des Recommandations et des
dérogations de conformité avec
l’architecture
– Des Recommandations concernant les
exigences de prestations de services
– Des Recommandations concernant la
métrique de performances– Des Contrats de Niveau de Service
(SLA – Service Level Agreements )
– La Vision de l’Architecture mise à jour
après mise en œuvre
– Un Document de Définition
d’Architecture, mis à jour après mise
en œuvre– L’Architecture de Transition, mise à
jour après mise en œuvre
– Des modèles de fonctionnement du
métier et de l’informatique pour la
solution mise en en œuvre
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 50/177
49TOGAF™ Version 9 – Guide de Poche
2.3.9 Phase H : Gestion du Changement d’ArchitectureLa phase H a pour but de gérer de façon maîtrisée les modifications
apportées à l’architecture.
Objectifs Etapes
Faire en sorte que les Architectures
Initiales restent en bonne adéquation
Evaluer les performances de
l’architecture et faire des
recommandations de modificationsÉvaluer les changements du cadre et
des principes établis lors des phases
précédentes
Etablir un processus de gestion du
changement d’architecture pour
la nouvelle architecture initiale
d’entreprise telle qu’obtenue à la fin de
la phase G
Rendre maximale la valeur métier
résultant de l’architecture et des
opérations en cours
Appliquer le Cadre de Gouvernance
Etablir un processus de Réalisation de
Valeur
Déployer des Outils de Suivi
Gérer les Risques
Assurer l’analyse de la Gestion duChangement d’Architecture
Développer des Exigences de
Changement permettant d’atteindre les
Performances Cibles
Gérer le Processus de Gouvernance
Activer le processus de mise en œuvre du
changement
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 51/177
50 TOGAF™ Version 9 – Guide de Poche
2.3.10 Gestion des ExigencesLe processus de gestion des exigences de l’architecture s’applique à
toutes les phases du cycle ADM. Le processus de Gestion des Exigencesest un processus dynamique qui a pour but d’identifier les exigences de
l’entreprise, de les mémoriser puis de les livrer en entrée et en sortie des
phases correspondantes de l’ADM. Comme illustré sur la figure 2, ce
processus est le principal moteur de l’ADM.
Entrants Sortants
Demande de Mise en Chantier de
l’Architecture identifiés lors des phases
E et F
Modèle d’organisation pour
l’architecture d’entreprise
Cadre d’Architecture Contextualisé
Définition du Chantier d’Architecture
Vision de l’Architecture
Référentiel d’Architecture
Document de Définition del’Architecture
Spécification des exigences de
l’Architecture
Feuille de route de l’Architecture
Demandes de Changement dues à des
changements techniques
Demandes de Changement dues à deschangements business
Demandes de Changement résultant
des leçons ayant pu être tirées
Architectures de Transition
Modèle de Gouvernance de la Mise
en œuvre
Contrat d’Architecture (signé)Évaluations de Conformité
Plan de Mise en œuvre et de Migration
Mises à jour de l’architecture
Modifications du cadre et des principes
de l’architecture
Nouvelles Demandes de Mise en
Chantier d’Architecture, qui vont
déclencher un autre cycle de l’ADM
Définition du Chantier d’Architecture,
éventuellement mise à jour
Contrat d’architecture, éventuellement
mis à jourÉvaluations de Conformité,
éventuellement mises à jour
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 52/177
51TOGAF™ Version 9 – Guide de Poche
La possibilité de prendre en charge les éventuelles modifications des
exigences est une caractéristique essentielle de l’ADM car l’architecture,
du fait de sa nature même, s’adapte à l’incertitude et au changement, etcomble ainsi l’écart entre les aspirations des acteurs concernés et ce que
permet d’obtenir une solution pratique.
Objectifs Etapes
Développer un processus permettant de
gérer les exigences de l’architecture lors
de chacune des phases du cycle ADMIdentifier les exigences de l’entreprise,
les stocker et les délivrer en entrée et
en sortie des phases correspondantes
de l’ADM, celles-ci manipulant,
prenant en compte et hiérarchisant les
exigences
Identifier/documenter les exigences
Exigences initiales
Assurer le suivi des Exigences initialesIdentifier les exigences modifiées ;
éliminer, ajouter, modifier et redéfinir
les priorités
Identifier les exigences modifiées et
enregistrer les priorités ; identifier
et résoudre les conflits ; créer des
définitions d’impacts des exigencesEvaluer l’impact des exigences modifiées
sur les phases présentes et précédentes
de l’ADM
Mettre en œuvre les exigences résultant
de la phase H
Mettre à jour le référentiel des exigences
Mettre en œuvre les changements de laphase présente
Evaluer et réviser l’analyse des écarts pour
les phases précédentes
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 53/177
52 TOGAF™ Version 9 – Guide de Poche
2.4 Dénition du périmètre de l’Activitéd’ArchitectureL’ADM définit une séquence recommandée pour les diverses phases et
étapes intervenant lors du développement d’une architecture d’entreprise
correspondant à l’ensemble d’une organisation, mais l’ADM ne peut pas
définir le périmètre : celui-ci doit l’être par l’organisation elle-même.
La nécessité de contraindre (ou de restreindre) le périmètre de l’activité
architecturale a de nombreuses raisons. Pour la plupart, celles-ci sont liées
aux limites imposées :
• Au responsable en charge de l’organisation au sein de l’équipe
produisant l’architecture
• Par les objectifs et les préoccupations formulés par les acteurs concernéset qui doivent être pris en compte dans l’architecture
• Par la disponibilité des personnes, des nancements et autres ressources
Le périmètre choisi pour l’activité d’architecture devra idéalement
permettre de gouverner et d’intégrer efficacement les interventions de tous
les architectes de l’entreprise. Cela requiert un ensemble de “partitions
Entrants Sortants
Les entrants du processus de Gestion
des Exigences sont les sortants
dépendant des exigences de chaque
phase ADM
Les premières exigences abstraites sont
produites en tant que parties de la
Vision de l’Architecture
Chaque domaine architectural génère
ensuite des exigences détaillées. Les
livrables des phases ADM ultérieuresont des relations de correspondance
avec de nouveaux types d’exigences (par
exemple des exigences de conformité).
Exigences modifiées
Évaluation de l’Impact des Exigences,
celle-ci identifiant les phases de l’ADM
qu’il est nécessaire de redéfinir pour
prendre en compte les éventuelles
modifications. La version finale doit
comprendre l’ensemble des implications
des exigences (comme les coûts, les délais
et les métriques métiers).
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 54/177
53TOGAF™ Version 9 – Guide de Poche
d’architecture” alignées qui évitent les conflits ou les doublons entre les
travaux effectués par les architectes. Cela exige également la définition
de relations de réutilisation et de conformité entre les diverses partitionsde l’architecture. Ce découpage de l’entreprise et son activité liée à
l’architecture est traitée dans TOGAF 9, Partie III : Recommandations et
Techniques ADM (Chapitre 4).
Le tableau 4 indique les quatre dimensions suivant lesquelles on peut
définir et délimiter le périmètre d’activité.Tableau 4 : Dimensions suivant lesquelles on délimite le Périmètre de l’Activité
d’architecture
Dimension Considérations
Périmètre ou
focalisation de
l’entreprise
Quelle est le périmètre total de l’entreprise et sur quelle
partie de ce périmètre devront se focaliser sur les efforts
d’architecture? Beaucoup d’entreprises sont de très grande tailleet sont en réalité une fédération d’entités organisationnelles
dont chacune peut elle-même être considérée comme une
entreprise.
L’entreprise moderne s’étend de plus en plus au-delà de ses
frontières traditionnelles, et englobe une combinaison mal
délimitée d’entreprises exerçant des métiers traditionnels en
association avec des fournisseurs, des clients et des partenaires.
Domaines de
l’Architecture
La description complète d’une architecture d’entreprise doit
englober la totalité des quatre domaines de l’architecture
(Business, Données, Applications, Technique), mais les
réalités imposées par les ressources et les contraintes de temps
se traduisent souvent par des délais, des financement ou des
ressources ne permettant pas de construire une description
d’architecture complète, de haut en bas et englobant la totalité
des quatre domaines architecturaux, même si l’on choisit unpérimètre d’entreprise inférieur à celui de l’entreprise dans sa
globalité.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 55/177
54 TOGAF™ Version 9 – Guide de Poche
Dimension Considérations
Périmètre vertical
ou niveau de
détail
Jusqu’à quel niveau de détail doit aller l’effort architectural ?
A partir de quand une architecture est-elle considérée comme
“suffisante” ?
Quelle est la délimitation idéale entre l’effort d’architecture et
d’autres activités associées (conception des systèmes, ingénierie
des systèmes, développement des systèmes) ?
Période de temps Quelle est la période de temps devant servir de base à la Vision
de l’Architecture, et est-il raisonnable (du point de vue de
la faisabilité et des ressources) que la description détaillée de
l’architecture couvre la même période de temps ? Si cela n’estpas le cas, combien d’Architectures Cibles intermédiaires
doivent être définies et sur quelles périodes de temps ?
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 56/177
Chapitre 3
Techniques et livrablesclés du Cycle ADMCe chapitre vous aidera à comprendre les techniques et livrables clés
du cycle ADM. Le Tableau 5 explicite ce chapitre sous la forme d’une
feuille de route constituée de chacune des phases de l’ADM et indique lestechniques et les livrables qui y sont principalement utilisés. Pour chaque
point, on présente les faits essentiels.
Tableau 5 : Feuille de route suivie par le Chapitre 3
Phase ADM Référence(s)
Phase
préliminaire
Section 3.1, Le Cadre d’Architecture Contextualisé
Section 3.2, Le Modèle d’Organisation pour l’Architectured’Entreprise
Section 3.3, Les Principes de l’Architecture
Section 3.4, Les Principes du business, buts du business et
moteurs du business
Section 3.5, Le Référentiel d’Architecture
Section 3.6, Les Outils d’Architecture
Section 3.7, La Demande de Mise en Chantier d’Architecture
A. Vision de
l’Architecture
Section 3.4, Les Principes du Business, Buts du Business et
Moteurs du Business
Section 3.8, La Définition du Chantier d’Architecture
Section 3.9, La Vision de l’Architecture
Section 3.10, La Gestion des Acteurs Concernés
Section 3.11, Le Plan de Communication
Section 3.12, L’Évaluation de l’État de Préparation à laTransformation du Business
Section 3.13, L’Évaluation des Capacités
Section 3.14, La Gestion du Risque
Section 3.18, Les Scénarios Métiers
Section 3.20, Les Points de Vue de l’Architecture
Section 3.21, Les Vues de l’Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 57/177
56 TOGAF™ Version 9 – Guide de Poche
Phase ADM Référence(s)
B. Architecture
du Business
Section 3.15, Le Document de Définition de l’Architecture
Section 3.16, La Spécication des Exigences d’Architecture
Section 3.17, La Feuille de route de l’Architecture
Section 3.18, Les Scénarios Métiers
Section 3.19, L’Analyse des Écarts
Section 3.20, Les Points de Vue de l’Architecture
Section 3.21, Les Vues de l’Architecture
Section 3.22, Les Building Blocks de l’Architecture
Section 3.23, Les Building Blocks de la Solution
C. Architecture
des systèmes
d’Information
Section 3.15, Le Document de Définition de l’ArchitectureSection 3.16, La Spécication des Exigences d’Architecture
Section 3.17, La Feuille de route de l’Architecture
Section 3.18, Les Scénarios Métiers
Section 3.19, L’Analyse des Écarts
Section 3.20, Les Points de vue d’Architecture
Section 3.21, Les Vues de l’Architecture
Section 3.22, Les Building Blocks de l’ArchitectureSection 3.23, Les Building Blocks de la Solution
D. Architecture
Technique
Section 3.15, Le Document de Définition de l’Architecture
Section 3.16, La Spécication des Exigences d’Architecture
Section 3.17, La Feuille de route de l’Architecture
Section 3.18, Les Scénarios Métiers
Section 3.19, L’Analyse des Écarts
Section 3.20, Les Points de Vue de l’ArchitectureSection 3.21, Les Vues de l’Architecture
Section 3.22, Les Building Blocks de l’Architecture
Section 3.23, Les Building Blocks de la Solution
E. Opportunités
et Solutions
Section 3.13, L’Évaluation des Capacités
Section 3.17, La Feuille de route de l’Architecture
Section 3.19, L’Analyse des Ecarts
Section 3.22, Les Building Blocks de l’ArchitectureSection 3.23, Les Building Blocks de la Solution
Section 3.24, La Planification en Fonction des Capacités
Section 3.25, Les Techniques de Planification de la Migration
Section 3.26, Le Plan de Mise en œuvre et de Migration
Section 3.27, L’Architecture de Transition
Section 3.28, Le Modèle de Gouvernance de la Mise en œuvre
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 58/177
57TOGAF™ Version 9 – Guide de Poche
3.1 Le Cadre d’Architecture ContextualiséLa sélection et la contextualisation d’un cadre sont pratiquement
le point de départ d’un projet d’architecture. Partir de TOGAF
plutôt que de créer un cadre en partant de rien offre plusieurs
avantages.
• Cela évite la panique du début, lorsqu’on découvre l’immensité de latâche à réaliser.
• L’utilisation de TOGAF est systématique au sens où il s’agit d’un “bon
sens codifié”.
• TOGAF prote des éléments découverts et fonctionnant déjà dans le
monde réel.
• TOGAF dispose d’un ensemble de ressources de base pouvant êtreréutilisées.
• TOGAF dénit deux architectures de référence dans le Continuum
d’Entreprise.
Phase ADM Référence(s)
F. Planification
de la Migration
Section 3.17, La Feuille de route de l’Architecture
Section 3.24, La Planification en Fonction des Capacités
Section 3.25, Les Techniques de Planification d’une Migration
Section 3.26, Le Plan de Mise en œuvre et de Migration
Section 3.27, L’Architecture de Transition
Section 3.28, Le Modèle de Gouvernance de la Mise en œuvre
G. Gouvernance
de la Mise en
œuvre
Section 3.28, Le Modèle de Gouvernance de la Mise en œuvre
Section 3.29, Les Contrats d’Architecture
Section 3.30, La Demande de Changement
Section 3.31, L’Évaluation de Conformité
H. Gestion du
Changement
d’Architecture
Section 3.28, Le Modèle de Gouvernance de la Mise en œuvre
Section 3.29, Les Contrats d’Architecture
Section 3.30, La Demande de Changement
Section 3.31, L’Évaluation de Conformité
Section 3.32, L’Évaluation de l’Impact sur les Exigences
Phasepréliminaire
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 59/177
58 TOGAF™ Version 9 – Guide de Poche
Cependant, avant de pouvoir utiliser TOGAF dans un projet
d’architecture, une contextualisation à plusieurs niveaux est indispensable
au cours de la phase Préliminaire.
En premier lieu, il est nécessaire de contextualiser le modèle TOGAF afin
de pouvoir l’intégrer à l’entreprise. Cette contextualisation comprend
l’intégration de cadres de management des projets et des processus,
l’adaptation de la terminologie au contexte concerné, le développement
de styles de présentation, le choix, la configuration et le déploiementd’outils d’architecture, etc. Le formalisme et le détail de tous les cadres
adoptés devront également s’aligner sur d’autres facteurs contextuels de
l’entreprise, par exemple la culture de l’entreprise, les acteurs concernés, les
modèles disponibles du commerce permettant d’élaborer une architecture
d’entreprise, et le niveau présent des capacités d’architecture.
Une fois que le cadre a été adapté à l’entreprise, une contextualisation
supplémentaire est nécessaire pour ajuster le cadre sur un projet
d’architecture particulier. La contextualisation effectuée à ce niveau
permettra de sélectionner les livrables et les éléments d’architecture voulus
pour répondre aux besoins du projet et des acteurs concernés.
Les contenus suivants sont représentatifs de ce que l’on peut trouver dansun Cadre d’Architecture Contextualisé :
• Une méthode d’architecture contextualisée,
• Un contenu d’architecture contextualisé (livrables et éléments
d’architecture),
• Des outils congurés et déployés,
• Des interfaces d’échange avec des modèles de gouvernance et d’autrescadres,
– Le Cadre de Gestion de l’Architecture d’Entreprise,
– Le Cadre de Gestion des Capacités,
– Le Cadre de Gestion des Portefeuilles,
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 60/177
59TOGAF™ Version 9 – Guide de Poche
– Le Cadre de Gestion des Projets,
– Le Cadre de Gestion des Opérations.
3.2 Le Modèle d’Organisation pourl’Architecture d’Entreprise
Un livrable important produit par la phase Préliminaire est le
Modèle d’Organisation pour l’Architecture d’Entreprise
Pour que l’utilisation d’un cadre d’architecture soit couronnée de succès,celui-ci doit être soutenu au sein de l’entreprise par l’organisation, les rôles
et les responsabilités adéquats. Il est très important de bien délimiter les
frontières entre les différents praticiens de l’architecture d’entreprise et les
relations de gouvernance qui franchissent ces frontières.
Les contenus types d’un modèle d’organisation de l’Architecture
d’Entreprise sont les suivants :• Le périmètre des organisations concernées
• L’évaluation de la maturité, les écarts et la démarche permettant d’y
remédier
• Les rôles et les responsabilités de la ou des équipe(s) d’architecture
• Les contraintes imposées au chantier d’architecture
• Les exigences budgétaires• La gouvernance et la stratégie de support
3.3 Les Principes de l’ArchitectureCet ensemble de documentations est un sortant initial de
la phase Préliminaire. Il s’agit d’un ensemble de règles et de
recommandations générales concernant l’architecture en coursde développement. On se référera à TOGAF 9, Partie III, Principes de
l’Architecture, qui décrit ces recommandations et un ensemble détaillé de
principes génériques concernant l’architecture. Ce document contiendra de
préférence les principes du business, les principes des données, les principes
des applications et les principes techniques.
Phasepréliminaire
Phasepréliminaire
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 61/177
60 TOGAF™ Version 9 – Guide de Poche
3.3.1 Développer des Principes de l’ArchitectureC’est normalement à l’Architecte en Chef qu’il revient, en association avec
le Directeur du Système d’Information, avec le Comité d’Architecture etavec d’autres acteurs clés de l’entreprise, de développer les principes de
l’architecture.
Les points suivants influencent généralement le développement des
principes de l’architecture :
• Mission et plans de l’entreprise : mission, plans et infrastructureorganisationnelle de l’entreprise ;
• Initiative stratégique de l’entreprise : caractéristiques de l’entreprise,
par exemple ses forces, ses faiblesses, ses opportunités et les menaces
auxquelles elle est exposée, et les initiatives qu’elle prend à l’échelle de
l’entreprise (par exemple l’amélioration des processus et la gestion de la
qualité) ;• Contraintes externes : facteurs imposés par le marché (impératifs liés au
temps de mise sur le marché, attentes de la clientèle, etc.) ; législations
existantes et potentielles ;
• Systèmes et technologies actuels : ensemble de ressources
informatiques déployées au sein de l’entreprise, parmi lesquelles la
documentation des systèmes, les inventaires des équipements, lesdiagrammes de configuration des réseaux, les règles et les procédures ;
• Tendances de l’industrie informatique : Prédictions concernant
l’utilisation, la disponibilité et le coût des techniques de l’information
et des télécommunications, obtenues auprès de sources crédibles
combinées aux bonnes pratiques en cours.
3.3.2 Définir les Principes de l’ArchitectureSelon le type d’organisation, il est possible d’établir des principes aux trois
niveaux suivants :
• Les principes de l’entreprise constituent une base pour la prise de
décision et imposent la façon dont l’organisation remplit sa mission.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 62/177
61TOGAF™ Version 9 – Guide de Poche
Ces principes sont généralement en vigueur dans les organismes d’état et
les organisations à but non lucratif, mais sont également présents dans
des organismes à but commercial, et constituent un moyen permettantd’harmoniser la prise de décision. Il s’agit d’éléments clés pour la réussite
d’une stratégie de gouvernance d’architecture.
• Les principes du système d’information donnent des conseils sur
l’utilisation et le déploiement de l’ensemble des ressources et des
actifs informatiques dans l’entreprise. Ils ont pour but de rendre la
distribution d’informations aussi productive et rentable que possible.• Les principes de l’architecture sont un sous-ensemble des principes
du système d’information qui concernent le chantier d’architecture.
Ils sont le reflet d’un consensus global au niveau de l’entreprise et sont
représentatifs de l’esprit de l’architecture d’entreprise. Les principes de
l’architecture peuvent être subdivisés en :
– Des principes qui gouvernent le processus d’architecture, et quiaffectent le développement, la maintenance et l’utilisation de
l’architecture d’entreprise
– Des principes qui gouvernent la mise en œuvre de l’architecture.
TOGAF définit une procédure normalisée de description des principes.
En plus d’un énoncé de la définition, on associe à chaque principe les justificatifs et les indications des implications possibles, tant pour favoriser
la compréhension et l’acceptation des principes eux-mêmes que pour aider
à la mise en œuvre de ces principes lorsqu’on cherche à expliquer et à
justifier la raison pour laquelle certaines décisions ont été prises.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 63/177
62 TOGAF™ Version 9 – Guide de Poche
Tableau 6 : Modèle de Dénition des Principes
Nom Doit représenter la nature profonde de la règle mais doit aussi
en faciliter la mémorisation. Aucune plate-forme technologique
particulière ne doit être mentionnée dans le nom ou l’énoncé d’unprincipe. Eviter les mots ambigus dans le nom et dans l’énoncé
comme par exemple : “support”, “ouvert”, “considérer”, et faire
tout pour éviter le mot “éviter” lui-même. Faire attention à
“manage(ment)”, et éviter les adjectifs et les adverbes inutiles (mots
superflus).
Déclaration Doit faire ressortir de façon succincte et sans ambiguïté la règle
fondamentale. La plupart des énoncés des principes destinés àla gestion de l’information se ressemblent d’une organisation à
l’autre. Il est essentiel que l’énoncé des principes ne présente aucune
ambiguïté.
Justification Doit mettre en évidence les avantages que peut tirer l’entreprise
du respect du principe en question, en utilisant la terminologie du
métier. Insister sur la ressemblance entre les principes concernant
l’information et la technique, et les principes gouvernant l’activitéde l’entreprise. Décrire également la relation établie avec d’autres
principes et la façon d’aboutir à une interprétation équilibrée.
Décrire des situations dans lesquelles on confère à un principe une
plus grande priorité ou un plus grand poids qu’à un autre lors d’une
prise de décision.
Implications Doit mettre en évidence les exigences, tant en ce qui concerne
l’entreprise que le système d’information, pour l’application duprincipe (en termes de ressources, de coûts et d’activités/tâches).
Il arrive souvent qu’on découvre que les systèmes, les standards ou
les pratiques utilisés sont incompatibles avec le principe lors de son
adoption. L’impact sur le business et les conséquences de l’adoption
d’un principe doivent être clairement présentés. Le lecteur devra
pouvoir répondre à la question : “Comment cela m’affecte-t-il ?”. Il
est important de ne pas simplifier à l’excès, et de ne pas banaliser ou
surestimer l’importance de cet impact. Certaines des implications
seront identifiées comme n’étant que de simples impacts potentiels,
et peuvent être spéculatives plutôt que décrites de façon très
détaillée.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 64/177
63TOGAF™ Version 9 – Guide de Poche
3.3.3 Qualités des PrincipesCinq critères distinguent un bon ensemble de principes. Ils sont indiqués
dans le Tableau 7.
3.3.4 Application des principes de l’architectureLes principes de l’architecture sont utilisés pour assimiler les règles
fondamentales concernant la façon dont l’entreprise va utiliser et déployer
Tableau 7 : Critères recommandés pour les Principes de Qualité
Critères Description
Intelligibilité L’idée de base d’un principe doit pouvoir être saisie ou comprise
rapidement par n’importe quelle personne de l’organisation.
L’intention du principe est claire et non ambiguë, cela minimisant
les risques de non-respect, volontaire ou non
Robustesse Les principes doivent permettre la prise de bonnes décisions quant
aux architectures et aux planifications, et la création de règles
et de standards faciles à appliquer. Chaque principe doit être
suffisamment clair et précis pour permettre une prise ce décision
cohérente dans des situations complexes et potentiellement
conflictuelles.
Complétude Chaque principe potentiellement important et qui gouverne la
gestion des informations et des technologies de l’organisation est
défini. Les principes couvrent chaque situation envisageable.
Cohérence Le respect strict d’un principe peut nécessiter une interprétation
approximative d’un autre principe. L’ensemble des principes
doit être exprimé d’une manière qui permette un équilibre entre
les diverses interprétations. Les principes ne doivent pas être
contradictoires au point où le respect d’un principe conduit à
la violation de l’esprit d’un autre principe. Chaque terme d’un
énoncé de principe doit être soigneusement choisi pour permettre
une interprétation unique mais néanmoins souple.
Stabilité Les principes doivent être durables mais permettre néanmoins des
modifications. Un processus d’amendement devra être établi pour
ajouter, retirer ou modifier les principes ratifiés.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 65/177
64 TOGAF™ Version 9 – Guide de Poche
ses ressources et actifs informatiques. Les principes sont utilisés de plusieurs
façons différentes :
1. Comme cadre au sein duquel l’entreprise peut commencer à prendredes décisions en toute connaissance de cause quant à son système
d’information
2. Comme guide permettant d’établir des critères d’évaluation pertinents
et ainsi d’exercer une forte influence sur le choix des produits ou
des architectures de produits aux stades ultérieurs de la gestion de la
conformité avec l’architecture des systèmes informatiques3. Comme moteurs permettant de définir les exigences fonctionnelles de
l’architecture
4. Comme entrant permettant d’évaluer à la fois l’existant en matière
de systèmes d’information et d’informatique et le futur portefeuille
stratégique du point de vue de la conformité avec les architectures
définies ; ces évaluations donneront un aperçu utile sur les activitésde transition nécessaires à la mise en œuvre d’une architecture, afin
d’atteindre les buts et les priorités de l’entreprise
5. Les énoncés de Justification mettent en avant la valeur de l’architecture
pour l’entreprise et par conséquent, constituent une base permettant de
justifier les activités d’architecture
6. Les énoncés d’Implications donnent un aperçu général des tâches etdes ressources clés, ainsi que des coûts potentiels pour l’entreprise
du respect du principe en question ; elles fournissent aussi certains
entrants indispensables aux initiatives de transition et aux activités de
planification à venir
7. Les principes sont utiles aux activités de gouvernance de l’architecture
car– Ils jouent le rôle de “butée infranchissable” pour les évaluations
normalisées de la Conformité de l’Architecture, qui pourraient exiger
une certaine interprétation,
– Ils viennent à l’appui d’une décision visant à lancer une demande
de dérogation dans les cas où les implications d’un amendement
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 66/177
65TOGAF™ Version 9 – Guide de Poche
particulier de l’architecture ne peuvent pas être déterminées par une
procédure locale.
Les principes sont interdépendants et doivent être appliqués en bloc. Les
principes peuvent parfois se concurrencer les uns les autres ; c’est par
exemple le cas des principes “d’accessibilité” et de “sécurité”. Chaque
principe doit être envisagé “toutes choses égales par ailleurs”. Il sera parfois
nécessaire de prendre des décisions quant à la précédence d’un principe
vis-à-vis d’une question particulière. Les justifications de ces décisionsdevront toujours être documentées. Le fait qu’un principe semble aller
de soi ne signifie pas que ce principe sera effectivement respecté dans une
organisation, même lorsqu’il est accepté verbalement. Bien qu’aucune
pénalité particulière ne soit prévue dans l’énoncé des principes, le non-
respect des principes pose souvent des problèmes opérationnels et empêche
l’organisation de remplir sa mission.
3.4 Les Principes du business,buts du business et moteursdu business
L’énoncé des principes, des buts et des moteurs du
business a normalement déjà été rédigé par l’entreprise avant le lancementde l’activité d’architecture. Ces principes sont redéfinis à la sortie de
la phase Préliminaire et réanalysés en tant que partie de la Phase A : la
Vision de l’Architecture. L’activité de la Phase A consiste à garantir que les
définitions soient correctes et claires à un instant donné. Dans TOGAF
9, Partie III, Recommandations et Techniques de l’ADM, on décrit un
exemple d’ensemble de huit principes du business qui sont utilisablescomme point de départ.
Il n’y a pas de contenu défini pour ce livrable puisque son contenu et sa
structure vont nécessairement considérablement varier d’une organisation
à l’autre.
Phasepréliminaire
A.
Vision de
l'Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 67/177
66 TOGAF™ Version 9 – Guide de Poche
3.5 Le Référentiel d’Architecture
Le Référentiel d’Architecture ( Architecture Repository ) joue lerôle d’espace de rangement pour tous les projets de l’entreprise
qui sont liés à l’architecture. Le référentiel permet aux projets de gérer
leurs livrables, de localiser les actifs réutilisables et de publier des sortants
destinés aux acteurs concernés et à d’autres parties intéressées. On se
référera à la section 6.2 qui fournit une description du contenu d’un
Référentiel d’Architecture. Les contenus suivants sont représentatifs de ceque l’on peut trouver dans un Référentiel d’Architecture :
• Cadre d’Architecture ;
• Base d’informations sur les standards ;
• Paysage de l’Architecture ;
• Architectures de Référence ;
• Minutes de la Gouvernance ;
3.6 Les Outils d’Architecture Au cours de la phase Préliminaire l’architecte sélectionne et
utilise des outils qui facilitent l’activité d’architecture. TOGAF
ne nécessite ou ne recommande pas d’outils particuliers. TOGAF propose
un ensemble de critères d’évaluation permettant de sélectionner lesoutils d’architecture utilisés pour développer les divers modèles et vues
d’architecture exigés. Ceux-ci sont documentés dans TOGAF 9, Partie V,
Chapitre 42.
3.7 La Demande de Mise en Chantier
d’ArchitectureIl s’agit d’un document envoyé par les sponsors à l’organisation
responsable de l’architecture pour lancer un cycle de développement
d’architecture. Il est produit avec l’assistance de l’organisation responsable
de l’architecture en tant que sortant de la phase Préliminaire. Des
Phasepréliminaire
Phasepréliminaire
Phasepréliminaire
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 68/177
67TOGAF™ Version 9 – Guide de Poche
Demandes de Mise en Chantier d’Architecture seront également créées en
tant que résultats de Demandes de Changement d’Architecture approuvées
ou en tant qu’éléments de référence pour des travaux d’architecturerésultant d’une planification de migration.
En général, toutes les informations contenues dans ce document devront
être présentées à un niveau suffisamment abstrait. On suggère les contenus
suivants pour ce document :
• Sponsors de l’organisation ;• Enoncé de mission de l’organisation ;
• Buts du business (et changements associés) ;
• Plans stratégiques du business ;
• Contraintes de temps ;
• Changement d’environnement du business ;
• Contraintes organisationnelles ;• Informations budgétaires, contraintes nancières ;
• Contraintes externes, contraintes du business ;
• Description du business system courant ;
• Description de l’Architecture et du système d’information courants ;
• Description de l’organisation en cours de développement ;
• Description des ressources disponibles pour développer l’organisation.
3.8 La Dénition du Chantierd’Architecture
La Définition du Chantier d’Architecture est un livrable de
la Phase A et est en fait un contrat entre l’organisation responsable de
l’architecture et le sponsor du projet d’architecture. Ce document constitueune réponse à la Demande de Mise en Chantier de l’Architecture fournie
en tant que document d’entrée (Section 3.6). Il doit normalement décrire
un plan global destiné à répondre à la demande de mise en chantier
A.
Vision de
l'Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 69/177
68 TOGAF™ Version 9 – Guide de Poche
et fournir une proposition décrivant comment les problèmes ayant
été identifiés seront résolus par le processus architectural. On suggère
d’introduire dans ce document les contenus suivants :• Titre du chantier ;
• Demande et contexte du projet ;
• Description et périmètre du projet ;
• Descriptif général de la Vision de l’Architecture ;
• Approche managériale ;
• Modication des procédures de dénition du périmètre ;• Responsabilités et livrables ;
• Critères et procédures d’appropriation ;
• Plan et chronologie du projet ;
• Support du Continuum d’Entreprise (réutilisation) ;
• Approbation par signature.
3.9 La Vision de l’ArchitectureLa Vision de l’Architecture est créée lors de la Phase A et fournit
une vue abstraite idéale du produit final de l’architecture. Le
but de cette vision est de s’accorder dès le départ sur le résultat souhaité
de l’architecture afin que les architectes puissent ensuite se concentrer sur
les points bloquants afin d’en valider la faisabilité. La mise à dispositiond’une Vision de l’Architecture favorise également la communication avec
les acteurs concernés en leur proposant une version sous forme de note de
synthèse de la Définition d’Architecture complète.
Les scénarios d’un métier particulier constituent une technique appropriée
et importante pouvant être utilisée en tant que processus d’élaborationd’un document décrivant la Vision de l’Architecture.
On peut suggérer les contenus suivants :
• La description du problème,
– Acteurs concernés avec leurs préoccupations ;
– Liste des questions ou scénarios devant être traités ;
A.
Vision de
l'Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 70/177
69TOGAF™ Version 9 – Guide de Poche
• Les détails des objectifs,
• Les modèles d’environnement et de processus,
– Description des processus ;– Etapes des processus mises en relation avec l’environnement ;
– Etapes des processus mises en relation avec les personnes ;
– Flux d’informations ;
• Les acteurs et leurs rôles et responsabilités,
– Acteurs humains et rôles ;
– Acteurs et rôles informatiques ;– Exigences ;
• Les modèles d’architecture qui en résultent,
– Contraintes ;
– Principes informatiques,
– Architecture en soutien des processus ;
– Exigences mises en relation avec l’architecture.
3.10 La Gestion des Acteurs ConcernésLa gestion des acteurs concernés est une discipline importante
pouvant être exploitée par les architectes souhaitant fédérer les
énergies. Elle permet de garantir le succès de leurs projets là où
d’autres échoueraient. Cette technique est à utiliser pendant la Phase A afind’identifier les principaux intervenants et aussi d’être tenu au courant tout
au long de chaque phase. Le sortant de ce processus construit le point de
départ du Plan de Communication (Section 3.11).
Les bénéfices que l’on tire d’une bonne gestion des acteurs concernés sont
les suivants.
• Les acteurs les plus importants peuvent être identiés de façon précoceet les données qu’ils fournissent peuvent alors être utilisées pour
façonner l’architecture ; cela garantit leur soutien et améliore la qualité
des modèles produits.
A.
Vision de
l'Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 71/177
70 TOGAF™ Version 9 – Guide de Poche
• Le soutien fourni par les acteurs les plus importants favorisera
l’obtention d’un plus grand nombre de ressources du fait de cet
engagement ; cela augmente les chances de succès de cet engagementarchitectural.
• En communiquant dès le début et fréquemment avec les acteurs
concernés, l’équipe responsable de l’architecture s’assurera de la bonne
compréhension par eux du processus architectural et des bénéfices
qu’ils peuvent tirer de l’architecture d’entreprise ; par conséquent, ces
acteurs pourront apporter un soutien plus actif à l’équipe responsable del’architecture lorsque cela sera nécessaire.
• L’équipe responsable du chantier d’architecture pourra déterminer plus
efficacement les réactions prévisibles face aux modèles et aux rapports
d’architecture ; elle pourra planifier plus facilement les mesures à
prendre pour tirer profit de toutes les réactions positives mais évitera en
même temps d’avoir à répondre aux réactions négatives.
3.10.1 Etapes du Processus de Gestion des ActeursConcernés
Etape 1 : Identifier les Acteurs Concernés
La première tâche consiste à déterminer quels sont les principaux acteurs
concernés par l’architecture d’entreprise.On peut distinguer cinq catégories générales d’acteurs, comme illustré
figure 3.
Etape 2 : Classer les Postes des Acteurs Concernés
Développer une bonne compréhension des acteurs les plus importants et
consigner cette analyse (comme illustré dans l’exemple du tableau 8) pourpouvoir s’y référer et la mettre à jour pendant le projet.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 72/177
71TOGAF™ Version 9 – Guide de Poche
Etape 3 : Déterminer la Démarche de Gestion des Acteurs Concernés
Cette étape permet à l’équipe de prévoir qui sont les acteurs pouvant
bloquer ou critiquer le processus et quels acteurs pourraient apporter leursoutien et défendre l’initiative en cours.
Figure 3 : Catégories d’acteurs concernés
Décideurs
Sécurité
d'entreprise
DirigeantsDirigeants
EncadrementEncadrement
Experts en Processus
Métiers/Fonctionnels
Spécialiste Produit
Spécialiste Technique
Fournisseurs Organismes de
Réglementation
Gestion des Services
Informatiques
Service d'accueil
aux utilisateurs
Gestion des
Applications
Gestion de
l'Infrastructure
Communications
Données/Voix
Propriétaires
des Données
Experts Métiers
Organisation
"utilisateur final"
Organisation
du Projet
Gestion des
Opérations
Bureau de gestion
des programmes
Groupes Assurance
Qualité/Normalisation Approvisionnement RH
Fonctions d'entreprise
Acteurs Externes
Tableau 8 : Exemple d’Analyse des Acteurs Concernés
Groupe
d’acteursconcernés
Acteurs
concernés
Susceptible de
s’opposer auchangement
Compré-
hensionactuelle
Compré-
hensionrequise
Enga-
gement actuel
Enga-
gement requis
Soutien
requis
DirecteurInformatique
JeanDupont
E* M E F* M E
DirecteurFinancier
PierreBrun
M* M M F M M
* E=Elevé, M=Moyen, F=Faible
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 73/177
72 TOGAF™ Version 9 – Guide de Poche
Essayer d’apprécier le pouvoir de chaque personne concernée, son influence
et l’intérêt qu’elle manifeste, de façon à se concentrer sur l’engagement
véritable des individus clés vis-à-vis de l’architecture d’entreprise. Onpourra répartir ces personnes sur une grille pouvoir/intérêt qui permet
également d’adopter la stratégie la meilleure pour communiquer avec elles.
La Figure 4 représente un exemple de la grille des pouvoirs.
Etape 4 : Contextualiser les livrables contractuels
Identifiez les points de vue, les matrices et les vues que la mission
d’architecture doit produire et valider avec chaque groupe d’acteurs
concernés pour livrer un modèle d’architecture utile.
Il est important de faire particulièrement attention à l’intérêt manifesté par
les acteurs clés en définissant des points de vue, des matrices et des vues
particulières du modèle d’architecture d’entreprise. Cela permet de bien
faire comprendre l’architecture à tous les acteurs concernés et leur permet
de s’assurer du fait que l’initiative d’architecture de leur entreprise répondrabien à leurs préoccupations.
CDoit rester satisfait
Elevé
P o u v o i r
FaibleA
Effort minimal
B
Doit rester informé
ElevéFaible
Niveau d'intérêt
DActeurs clés
Figure 4 : Grille des Pouvoirs
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 74/177
73TOGAF™ Version 9 – Guide de Poche
3.11 Le Plan de Communication
Les architectures d’entreprise renferment de grands volumesd’informations complexes et mutuellement dépendantes.
La transmission efficace d’informations ciblées aux bons acteurs et au
bon moment sera un facteur clé de la réussite du travail d’architecture
d’entreprise. Le développement d’un Plan de Communication pour
l’architecture lors de la Phase A permettra de mener à bien cette
communication par un processus convenablement planifié et bien géré.
Un Plan de Communication contiendra typiquement :
• Une identication des acteurs concernés et leur regroupement en
fonction des exigences de communication,
• Une identication des besoins de communication, des messages clés en
relation avec la Vision de l’Architecture, des risques de communicationet des Facteurs de Réussite Essentiels (CSF - Critical Success Factors ),
• Une identication des mécanismes qui seront utilisés pour
communiquer avec les acteurs concernés pour leur permettre d’accéder
à des informations d’architecture. Par exemple : réunions, lettres
d’information, référentiels, etc.,
• Une identication d’un calendrier des communications montrantquelles communications seront effectuées avec quels groupes d’acteurs, à
quelle date et à quel endroit.
3.12 L’Évaluation de l’état de Préparationà la Transformation du Business
La technique connue sous le nom d’Évaluation de l’État dePréparation à la Transformation de l’Entreprise (Business Transformation
Readiness Assessment ) est mise en œuvre lors de la Phase A et est utilisée
pour évaluer et quantifier l’état de préparation d’une organisation à
un changement. La bonne compréhension de l’état de préparation de
A.
Vision de
l'Architecture
A.
Vision de
l'Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 75/177
74 TOGAF™ Version 9 – Guide de Poche
l’organisation afin qu’elle accepte un changement, l’identification des
questions pouvant se poser puis leur résolution, sont des éléments essentiels
pour la réussite d’une transformation d’architecture. Il est préférable quecette évaluation soit un effort conjoint entre les personnels de l’entreprise,
les responsables de secteurs d’activité et les planificateurs informatiques.
Les activités recommandées consistent à :
• Déterminer les facteurs de préparation qui auront un impact sur
l’organisation,• Présenter les facteurs de préparation à l’aide de modèles de maturité,
• Evaluer les risques pour chaque facteur de préparation et identier les
actions d’amélioration permettant d’atténuer ces risques.
Documenter toutes les observations dans le Document d’Évaluation des
Capacités (Section 3.13), puis intégrer les actions à effectuer dans le Plande Mise en œuvre et de Migration.
3.13 L’Évaluation des Capacités Avant de procéder à une Définition d’Architecture
détaillée, il est utile de bien comprendre les niveaux
initiaux et ciblés des capacités de l’entreprise. CetteÉvaluation des Capacités est démarrée lors de la Phase A puis est mise à
jour au cours de la Phase E. Elle peut être examinée à plusieurs niveaux.
• Quel est le niveau de capacité de l’entreprise dans son ensemble ; sur
quels points l’entreprise souhaite-t-elle augmenter ou optimiser ses
capacités ?
• Quels sont les domaines sur lesquels l’architecture devra se concentrerpour aller dans le sens du développement souhaité par l’entreprise ?
• Quel est le niveau de capacité ou de maturité de la fonction
informatique au sein de l’entreprise ? Quelles sont les implications
probables liées à la conduite du projet d’architecture en termes de
gouvernance de la conception, de gouvernance opérationnelle, de
A.
Vision de
l'Architecture
E.
Opportunitéset Solutions
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 76/177
75TOGAF™ Version 9 – Guide de Poche
compétences, et de structure organisationnelle ? Quel est le style, quel
est le niveau de formalisme et quel est le degré de détail du projet
d’architecture qui correspondront à la culture et aux capacités del’organisation informatique ?
• Quelles sont la capacité et la maturité de la fonction d’architecture au
sein de l’entreprise ? Quels sont les actifs architecturaux disponibles ?
Sont-ils maintenus et détaillés ? Quels standards et quels modèles de
référence doivent être pris en compte ? Sera-t-il possible de créer des
actifs architecturaux réutilisables au cours du projet ?• Lorsqu’il existe des écarts de capacité, dans quelle mesure l’entreprise
est-elle prête à se transformer pour atteindre la capacité cible ? Quels
sont les risques vis-à-vis de la transformation, quelles sont les barrières
culturelles et autres considérations devant être prises en compte au-delà
de l’écart de capacité de base ?
Les contenus suivants sont représentatifs de ce que l’on peut trouver dans
un livrable de l’Évaluation des Capacités.
• Évaluation des Capacités du Business, comprenant :
– Les Capacités du Business,
– L’évaluation du niveau de performances initial pour chaque capacité,
– Le niveau de performances futur souhaité pour chaque capacité,– L’évaluation de l’état initial du mode de mise en œuvre de chaque
capacité,
– L’état futur souhaité du mode de mise en œuvre de chaque capacité.
• Évaluation des capacités informatiques, comprenant :
– Les niveaux de maturité initial et cible du processus de changement,
– Les niveaux de maturité initial et cible des processus opérationnels,– L’évaluation des capacités et des possibilités initiales,
– L’évaluation des impacts probables sur l’organisation de
l’informatique de l’exécution du projet d’architecture.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 77/177
76 TOGAF™ Version 9 – Guide de Poche
• Évaluation de la Maturité de l’Architecture, comprenant :
– Les processus de gouvernance d’architecture, l’organisation, les rôles
et les responsabilités,– L’évaluation des compétences en architecture,
– L’étendue, la profondeur et la qualité de la définition de l’état
cartographique dans le Référentiel d’Architecture,
– L’étendue, la profondeur et la qualité de la définition des standards
dans le Référentiel d’Architecture,
– L’étendue, la profondeur et la qualité de la définition des modèles deréférence dans le Référentiel d’Architecture,
– L’évaluation du potentiel réutilisable.
• Évaluation de l’État de Préparation à la Transformation du Business,
comprenant :
– Les facteurs de préparation,
– Une vision pour chaque facteur de préparation,– Des classements des états de préparation présents et cibles,
– Les risques liés à l’état de préparation.
3.14 La Gestion du RisqueL’identification des risques liés à la transformation du business
et des activités visant à les atténuer est déterminée en premierlieu lors de la phase A. La gestion du risque, documentée
dans TOGAF 9, Partie III, Chapitre 31, est une technique permettant
d’atténuer les risques lors de la mise en œuvre d’un projet d’architecture.
Elle comprend un processus permettant de gérer les risques mettant en
œuvre les activités suivantes :
• Classication des risques,• Identication des risques,
• Évaluation initiale des risques,
• Atténuation des risques et évaluations des risques résiduels,
• Suivi du risque.
A.
Vision de
l'Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 78/177
77TOGAF™ Version 9 – Guide de Poche
Il est recommandé d’inclure les activités d’atténuation des risques dans la
Définition du Chantier d’Architecture.
3.15 Le Document de Dénition del’Architecture
Le Document de Définition de l’Architecture est le
livrable qui contiendra les éléments constituant le cœur
de l’architecture et qui ont été créés au cours d’un projet.
Le Document de Définition de l’Architecture couvre tous les domaines del’architecture (Business, Données, Applications et Technique) et analyse
également tous les états importants par lesquels passe l’Architecture (état
initial, état(s) intermédiaire(s) et état cible).
Il est créé lors de la Phase B et est initialement peuplé d’informations liées
à l’Architecture du Business. Il est ensuite mis à jour avec des Informationsconcernant l’Architecture des systèmes d’Information, lors de la Phase C,
puis avec les informations concernant l’Architecture Technique, lors de la
phase D.
Le Document de Définition de l’Architecture accompagne les spécifications
des Exigences d’Architecture avec certains objectifs complémentaires.• Le Document de Dénition de l’Architecture fournit une vue qualitative
de la solution et des buts, qui permet de faire comprendre l’intention
des architectes.
• La Spécication des Exigences d’Architecture donne une vue
quantitative de la solution, indiquant certains critères mesurables qui
doivent être respectés pendant la mise en œuvre de l’architecture.
Le document de Définition de l’Architecture contiendra généralement les
éléments suivants :
• Le périmètre,
• Les buts, objectifs et contraintes,
B.
Architecture
du Business
C.
Architecture desSystèmes
d'Information
D.
ArchitecturesTechniques
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 79/177
78 TOGAF™ Version 9 – Guide de Poche
• Les principes de l’Architecture,
• L’Architecture Initiale,
• Les modèles d’Architecture (pour chaque état à modéliser),– Les modèles d’Architecture du Business,
– Les modèles d’Architecture des Données,
– Les modèles d’Architecture des Applications,
– Les modèles d’Architectures Techniques,
• La logique et la justication de la démarche architecturale choisie,
• La mise en relation avec le Référentiel d’Architecture,– Mise en relation avec le Paysage de l’Architecture,
– Mise en relation avec les modèles de référence,
– Mise en relation avec les standards,
– Evaluation des possibilités de réutilisation,
• Analyse des écarts,
• Évaluation d’impact,
Les sections suivantes présentent de façon plus détaillée chacune de ces
architectures.
3.15.1 L’Architecture du Business
L’Architecture du Business est développée lors de la phase B. Les sujetsdevant être abordés dans le Document de Définition de l’Architecture en
relation avec l’Architecture du Business sont les suivants :
• L’Architecture Initiale du Business, si nécessaire (description de
l’Architecture du Business existante),
• L’Architecture Cible du Business, comprenant,
– La structure de l’organisation (identification des différents sitesde l’entreprise et de leurs relations avec les différentes entités de
l’organisation),
– Les buts et les objectifs du business (pour l’entreprise et chaque entité
organisationnelle),
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 80/177
79TOGAF™ Version 9 – Guide de Poche
– Les fonctions du business (étape détaillée récursive faisant intervenir
une décomposition progressive des principaux secteurs fonctionnels
en des sous-fonctions),– Les services métiers, les services rendus par l’entreprise et par chaque
entité de l’entreprise à ses clients, tant en interne qu’en externe,
– Les processus métiers, cela comprenant les mesures et les livrables,
– Les rôles métiers, cela comprenant le développement et la
modification des compétences exigées,
– Le modèle de données du métier,– La corrélation entre organisation et fonction - établir un lien entre les
fonctions métiers et les entités organisationnelles sous la forme d’un
rapport matriciel,
– Les vues correspondant aux points de vue sélectionnés en réponse aux
préoccupations des acteurs clés.
3.15.2 Les Architectures des Systèmes d’InformationLes Architectures des systèmes d’information sont développées lors de la
phase C. Les sujets devant être abordés dans le Document de Définition de
l’Architecture en rapport avec les architectures des Systèmes d’Information
sont les suivants :
• L’Architecture Initiale des Données, si nécessaire,• L’Architecture Cible des Données, qui comprend
– Un modèle de données du métier,
– Un modèle de données logique,
– Des modèles de processus de gestion des données,
– Une matrice entités de données/fonctions métiers,
• Des vues d’Architectures de Données correspondant aux points de vuesélectionnés répondant aux préoccupations des acteurs clés,
• L’Architecture Initiale des Applications, si nécessaire,
• L’Architecture Cible des Applications, qui comprend
– Un modèle d’organisation des processus,
– Un modèle d’organisation spatiale,
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 81/177
80 TOGAF™ Version 9 – Guide de Poche
– Un modèle d’organisation chronologique,
– Un modèle des relations humaines,
• Des vues d’Architectures des Applications correspondant aux points devue sélectionnés pour répondre aux préoccupations des acteurs clés.
3.15.3 L’Architecture TechniqueL’Architecture Technique est développée en tant que partie de la Phase
D. Les sujets ayant un rapport avec l’Architecture technique devant être
abordés dans le Document de Définition de l’Architecture sont les suivants:• L’Architecture Technique Initiale, si nécessaire,
• L’Architecture Technique Cible, qui comprend
– Les composants techniques et leurs relations avec les systèmes
d’information,
– Les plates-formes techniques et leur décomposition qui fera apparaître
les combinaisons de technologies exigées pour réaliser une “pile”technique particulière,
– Des environnements et des lieux - regroupement des techniques
exigées en des environnements informatiques (par exemple pour le
développement et la production),
– La charge de traitement attendue et la répartition de la charge entre
les divers composants techniques,– Les communications physiques (réseau),
– Les spécifications des matériels et des réseaux,
• Des vues correspondant aux points de vue sélectionnés et répondant aux
préoccupations des acteurs clés.
3.16 La Spécication des Exigencesd’ArchitectureLa Spécification des Exigences fournit un ensemble
d’énoncés quantitatifs qui définissent les grandes lignes
de ce que doit faire un projet de mise en œuvre pour se
conformer à l’architecture. Une Spécification des Exigences d’Architecture
B.Architecture
du Business
C.
Architecture desSystèmes
d'Information
D.
ArchitecturesTechniques
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 82/177
81TOGAF™ Version 9 – Guide de Poche
sera typiquement un composant majeur du contrat de mise en œuvre ou
d’un contrat de définition d’architecture plus détaillé.
Comme mentionné ci-dessus, une Spécification des Exigences de
l’Architecture accompagne le Document de Définition de l’Architecture
avec pour objectif complémentaire de fournir la vue quantitative.
La Spécification des Exigences de l’Architecture contiendra typiquement les
éléments suivants :• Des mesures de réussite,
• Des exigences de l’Architecture,
• Des contrats de services métiers,
• Des contrats de services applications,
• Des recommandations de mise en œuvre,
• Des spécications de mise en œuvre,• Des standards de mise en œuvre,
• Des exigences d’interopérabilité,
• Des contraintes,
• Des hypothèses.
3.16.1 Les Exigences de l’Architecture du BusinessLes exigences de l’Architecture du Business qui remplissent la Spécification
des Exigences d’Architecture sont les suivantes :
• Les résultats de l’analyse des écarts,
• Les exigences techniques,
• Un ensemble initial d’exigences techniques devra être créé en sortie de la
Phase B (Architecture du Business). Il s’agit des moteurs qui vont tirerle chantier d’Architecture Technique et qui devront identifier, catégoriser
et hiérarchiser les implications sur les réalisations effectuées dans les
autres domaines de l’architecture ; par exemple au moyen d’une matrice
de dépendance/priorité (compromis d’orientation entre la vitesse du
traitement des transactions et la sécurité), on établit la liste des modèles
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 83/177
82 TOGAF™ Version 9 – Guide de Poche
spécifiques que l’on prévoit de produire (qui sont par exemple exprimés
sous la forme de primitives du Cadre de Zachman).
• La mise à jour des exigences métiers• La technique des scénarios métiers est utilisée pour faire apparaître et
documenter les exigences métiers.
3.16.2 Les Exigences des Architectures des Systèmesd’Information
Les exigences des Architectures des systèmes d’Information remplissantla Spécification des Exigences de l’Architecture lors de la Phase C
comprennent :
• Les résultats de l’analyse des écarts
• Les exigences d’interopérabilité pour les données
• Les exigences d’interopérabilité pour les applications
• Les domaines dans lesquels il pourrait s’avérer nécessaire de modierl’Architecture du Business afin qu’elle respecte les modifications
apportées à l’architecture des Données et/ou des Applications
• Les contraintes imposées à l’Architecture Technique devant entrer en
phase de conception
• Les exigences métiers, éventuellement mises à jour
• Les exigences des applications, éventuellement mises à jour• Les exigences des données, éventuellement mises à jour
3.16.3 Les Exigences de l’Architecture TechniqueLes exigences de l’Architecture Technique remplissant la Spécification des
Exigences de l’Architecture lors de la Phase D comprennent :
• Les résultats de l’analyse des écarts• Les exigences techniques mises à jour
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 84/177
83TOGAF™ Version 9 – Guide de Poche
3.16.4 Les Exigences d’InteropérabilitéLa détermination de l’interopérabilité se fait tout au long du cycle de
l’ADM. Un jeu de recommandations est proposé dans TOGAF 9, PartieIII, Chapitre 29, pour définir et établir les exigences d’interopérabilité.
3.17 La Feuille de route del’Architecture
La Feuille de route de l’Architecture ( Architecture
Roadmap) établit la liste des incrémentations individuellesdes changements et les organise de façon chronologique
afin de mettre en évidence le passage de l’Architecture Initiale (Baseline
Architecture ) à l’Architecture Cible (Target Architecture ). La Feuille de route
de l’Architecture est le composant clé des Architectures de Transition et est
élaborée de façon incrémentale tout au long des Phases B, C, D, E et F au
sein de l’ADM.
La Feuille de route de l’Architecture comprend généralement les éléments
suivants :
• Une liste de projets
– Nom, description et objectifs de chaque projet
– Liste hiérarchisée des projets permettant de mettre en œuvrel’architecture proposée
• Un Plan de Migration orienté chronologiquement
– Bénéfices de la migration proposée (comprenant la mise en relation
avec les exigences du business)
– Estimatif des coûts des diverses options de migration
• Des recommandations de mise en œuvre– Critères/mesures de l’efficacité des projets
– Risques et problèmes
– Building Blocks des Solutions (SBB - Solution Building Blocks ) :
description et modèle
B.
Architecture
du Business
C.
Architecture desSystèmes
d'Information
D.
ArchitecturesTechniques
E.
Opportunitéset Solutions
F.
Planificationde la migration
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 85/177
84 TOGAF™ Version 9 – Guide de Poche
3.18 Les Scénarios Métiers
L’ADM possède sa propre méthode (ou une“méthode dans la méthode”) permettant d’identifier
et de formuler les exigences du business mises en jeu dans une nouvelle
fonctionnalité métier afin de remédier aux problèmes posés par les
principaux moteurs du business, et les exigences que cela implique pour
l’Architecture. Ce processus est connu sous le nom de “scénarios métiers”.
Un scénario métier est une description d’un problème métier qui permet
de visualiser les exigences les unes par rapport aux autres dans le contexte
du problème dans sa globalité. Sans cette description qui sert de contexte,
la valeur apportée au business par la solution proposée pour résoudre le
problème n’apparaît pas clairement, la pertinence des solutions potentielles
n’est pas claire et la solution proposée risque de se fonder sur un jeud’exigences inadaptées.
Les clés du succès d’un grand projet sont son étroite relation avec les
exigences du business et le fait qu’il aide clairement l’entreprise à atteindre
ses objectifs métiers. Les scénarios métiers sont des techniques importantes
permettant d’identifier et de bien comprendre les besoins du business.Cette technique peut être utilisée de façon itérative, à différents niveaux de
détail de la hiérarchie de l’Architecture du Business. Le processus générique
d’un scénario métier se décompose de la façon suivante :
• Identier, documenter et classer le problème qui tire le projet
• Documenter, sous forme de modèles d’Architecture abstraits, les
environnements métiers et techniques dans lesquels le problème se pose• Identier et documenter les objectifs à atteindre ; les résultats obtenus
lorsque les problèmes ont pu être résolus
• Identier les acteurs humains et leur place dans le modèle d’entreprise,
parmi les participants humains et leurs rôles
A.
Vision de
l'Architecture
B.
Architecture
du Business
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 86/177
85TOGAF™ Version 9 – Guide de Poche
• Identier les acteurs de l’informatique et leur place dans le modèle
technique, parmi les éléments informatiques, et leurs rôles
• Identier et documenter les rôles, les responsabilités et les mesures deréussite pour chaque acteur, les rôles devant être joués par chaque acteur
et les résultats que l’on attend d’une bonne gestion du problème
• Vérier si le chantier d’architecture qui va en découler est en bonne
adéquation et ne l’affiner que si nécessaire
3.19 L’Analyse des ÉcartsLa technique connue sous le nom d’analyse des écarts
est très souvent utilisée dans l’ADM pour valider
une architecture en cours de développement. Il s’agit
généralement de la dernière étape d’une phase. L’idée de
base est de faire ressortir l’éventuel décalage (le “gap”) entre l’Architecture
Initiale et l’Architecture Cible ; c’est-à-dire les éléments ayant étédélibérément omis, accidentellement laissés de côté ou non encore définis.
Les étapes sont les suivantes :
• Concevoir une matrice comportant tous les Building Blocks
d’Architecture (ABB – Architecture Building Blocks ) de l’Architecture
Initiale sur l’axe vertical et tous les ABB de l’Architecture Cible sur l’axehorizontal.
• Ajouter sur l’axe de l’Architecture Initiale une dernière ligne désignée
“Nouveaux ABB” et sur l’axe de l’Architecture Cible une dernière
colonne désignée “ABB éliminés”.
• Là où un ABB est disponible à la fois dans les Architectures Initiale
et Cible, le signaler en ajoutant “Inclus” dans la cellule située àl’intersection.
• Là où un ABB de l’Architecture de Référence est absent de l’Architecture
Cible, chacun des ABB doit être réexaminé. Si l’élimination n’est pas
une erreur, le signaler dans la cellule correspondante en indiquant
“Eliminé”. Si cela n’est pas le cas, vous avez mis en évidence une
B.Architecture
du Business
C.
Architecture desSystèmes
d'Information
D.
ArchitecturesTechniques
E.
Opportunitéset Solutions
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 87/177
86 TOGAF™ Version 9 – Guide de Poche
omission accidentelle dans votre Architecture Cible. Il faut donc y
remédier en redéfinissant le bloc ABB lors de l’itération suivante du
développement de l’architecture. Le signaler dans la bonne cellule“Eliminé”.
• Lorsqu’un ABB appartenant à l’Architecture Cible n’apparaît pas dans
l’Architecture Initiale, le signaler à l’intersection avec la ligne “Nouveau”
comme un écart devant être comblé soit en développant, soit en
obtenant ce Building Block .
Lorsque l’exercice est terminé, tout ce qui apparaît sous “Services Eliminés”
ou “Nouveau Service” constitue un écart. Il faudra soit expliquer qu’il a
bien été éliminé, soit signaler qu’il nécessite un travail de redéfinition ou de
développement/obtention de la fonction manquante.
Le tableau 9 illustre des exemples d’écarts entre l’Architecture Initiale etl’Architecture Cible ; dans ce cas, les éléments manquants sont les “services
de diffusion” et les “services d’écran partagé”.
Tableau 9 : Exemple d’analyse des écarts
Architecture
Cible→
ArchitectureInitiale ↓
Services de
Visioconférence
Services
de téléphonie
évolués
Services de
Liste de
Diffusion
Services
Eliminés ↓
Services de
Diffusion
Eliminé
Intentionnellement
Services de
VisioconférenceInclus
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 88/177
87TOGAF™ Version 9 – Guide de Poche
La technique d’analyse des écarts doit être utilisée lors des phases B, C, D
et E de l’ADM.
3.20 Les Points de Vue de
l’ArchitectureL’architecte utilise lors des Phases A et D des vues et
des points de vue du cycle ADM pour développer des
architectures correspondant à chaque domaine (Métier,
Données, Applications, Technique). Une “vue” est ce que l’on voit.
Un “point de vue” est l’endroit d’où l’on observe ; c’est-à-dire le point
d’observation ou la perspective qui détermine ce que l’on voit (un pointde vue peut également être considéré comme étant un schéma). Les points
de vue sont génériques et peuvent être stockés dans des bibliothèques
de manière à pouvoir être réutilisés. Une vue est toujours propre à
l’architecture pour laquelle elle a été créée. A chaque vue est associé un
point de vue qui la décrit, du moins implicitement.
Services de
Téléphonie
Evolués
Concordance
Potentielle
Services de
Partage d’Ecran
Involontairement
exclus -
écart par rapport à
l’Architecture Cible
Nouveau→
Écart :
Services
Evolués à
développer ou
à produire
Écart :
Services
Evolués à
développer
ou à
produire
A.
Vision de
l'Architecture
B.
Architecture
du Business
D.
ArchitecturesTechniques
C.
Architecture desSystèmes
d'Information
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 89/177
88 TOGAF™ Version 9 – Guide de Poche
La norme ISO/IEC 42010:2007 encourage les architectes à définir les
points de vue de façon explicite. Il pourrait sembler a priori que cette
distinction entre contenu et schéma d’une vue conduise à un supplémentde travail superflu, mais ce mécanisme permet en fait de réutiliser des
points de vue dans plusieurs architectures différentes.
Pour mieux illustrer les concepts de vues et de points de vue, on
considérera l’Exemple 1 ci-après. Il s’agit d’un système d’aéroport très
simple comportant deux acteurs principaux différents : le pilote et lecontrôleur aérien.
Exemple 1 : Vues et Points de vue pour un système d’aéroport simple
Vues et Points de vue dans un système d’aéroport simple
Le pilote possède une vue du système et le contrôleur aérien, une autre. Aucune de ces deux vues ne représente l’ensemble du système en raison
du fait que la perspective de chaque acteur principal impose (et réduit)
la façon dont chacun d’eux voit l’ensemble du système.
La vue du pilote contient certains éléments qui ne sont pas vus par le
contrôleur, par exemple les passagers et le carburant, tandis que la vue
du contrôleur comprend d’autres éléments que ne voit pas le pilote, parexemple les autres avions. Il existe également certains éléments partagés
entre les vues, comme le modèle de communication entre le pilote et
le contrôleur, et les informations vitales concernant l’avion proprement
dit.
Un point de vue est un modèle (ou une description) des informations
contenues dans une vue. Dans cet exemple, un point de vue décrit lafaçon dont le pilote voit le système et l’autre point de vue, la façon dont
le contrôleur voit ce système.
Les pilotes décrivent le système selon leur propre perspective, en
utilisant un modèle de leur position et un vecteur allant vers ou à
l’opposé de la piste. Tous les pilotes utilisent ce modèle et le modèle
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 90/177
89TOGAF™ Version 9 – Guide de Poche
Pour résumer l’exemple 1, on peut noter qu’une vue peut être considérée
comme un sous-ensemble du système défini sous l’angle de vue de l’acteur
concerné, par exemple le pilote plutôt que le contrôleur. Ce sous-ensemble
peut être décrit par un modèle abstrait appelé point de vue, par exemple
un modèle de plan de vol plutôt qu’un modèle d’espace aérien. Cette
description de la vue est documentée dans une langue partiellementspécialisée, par exemple un “jargon de pilote” plutôt qu’un “jargon de
contrôleur”. Certains outils sont utilisés pour aider les acteurs concernés,
et s’interfacent l’un avec l’autre au travers de la langue correspondant à
chaque point de vue. Lorsque les acteurs concernés utilisent des outils
communs (la liaison radio entre pilotes et contrôleurs par exemple), une
langue commune est indispensable.
possède son propre langage, qui est utilisé pour identifier certaines
informations et peupler le modèle. La façon dont les contrôleurs
décrivent le système est différente : ils utilisent un modèle de l’espaceaérien et les positions et les vecteurs des aéronefs à l’intérieur de
cet espace aérien. Ici encore, tous les contrôleurs utilisent une
langue commune dérivée du modèle commun afin d’identifier et de
transmettre les informations correspondant à leur point de vue.
Heureusement, lorsque les contrôleurs parlent au pilote, ils utilisent
une langue de communication commune (en d’autres termes, lesmodèles représentant leurs points de vue individuels se recouvrent
partiellement). Une partie de cette langue commune est utilisée pour
décrire la position et les vecteurs des aéronefs, cela étant essentiel
pour la sécurité. Par conséquent, chaque point de vue constitue
fondamentalement un modèle abstrait représentant la façon dont tous
les acteurs principaux d’un type particulier (tous les pilotes ou tous lescontrôleurs) voient le système d’aéroport. L’interface avec l’utilisateur
humain d’un outil est généralement proche du modèle et du langage
associé au point de vue. Les outils uniques dont se sert le pilote sont
le carburant, l’altitude, la vitesse et les indicateurs de position. L’outil
principal du contrôleur est le radar. L’outil commun est la liaison radio.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 91/177
90 TOGAF™ Version 9 – Guide de Poche
3.21 Les Vues de l’ArchitectureLes vues de l’architecte sont des représentations de
l’architecture globale qui ont une signification pour unou plusieurs acteurs du système. L’architecte choisit et
développe un ensemble de vues du cycle ADM au cours
des phases A à D. Cela permet de bien faire comprendre l’architecture à
tous les acteurs concernés de façon qu’ils puissent s’assurer du fait que le
système répondra bien à leurs préoccupations. Les concepts présentés à la
section 5.3 sont d’une importance capitale pour l’utilisation des vues del’architecture dans TOGAF.
3.21.1 Développement des Vues dans l’ADMLe choix des vues d’architecture particulières à développer est l’une des
décisions clés que devra prendre l’architecte.
L’architecte a pour responsabilité de s’assurer du caractère exhaustif de
l’architecture (de sa bonne adéquation), en ce sens qu’elle doit bien
répondre aux préoccupations principales des acteurs concernés ; et de
l’intégrité de l’architecture, en ce sens qu’elle doit relier entre elles la
totalité des diverses vues en réconciliant au mieux les desiderata souvent
contradictoires des différents acteurs concernés et en faisant apparaître lescompromis ayant dû être faits (par exemple entre sécurité et performances).
3.22 Les Building Blocks del’Architecture
Les Building Blocks de l’Architecture (ABB) sont des
documentations et des modèles d’architecture tirés duRéférentiel d’Architecture de l’entreprise et classés en
conformité avec le Continuum d’Architecture (Chapitre 6). On les dénit
et on les sélectionne pendant qu’on applique l’ADM (cela se faisant
principalement lors des Phases A, B, C et D). Les caractéristiques des ABB
sont les suivantes :
A.
Vision de
l'Architecture
B.
Architecture
du Business
D.
ArchitecturesTechniques
C.Architecture desSystèmes
d'Information
B.
Architecture
du Business
C.
Architecture desSystèmes
d'Information
D.
ArchitecturesTechniques
E.
Opportunitéset Solutions
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 92/177
91TOGAF™ Version 9 – Guide de Poche
• Ils se fondent sur les exigences de l’architecture, par exemples aux
exigences métiers, données, applications et techniques.
• Ils orientent et guident le développement des Building Blocks deSolutions (SBB - Solution Building Blocks ).
• Le contenu des spécications des ABB comprend au minimum les
éléments suivants :
• Des fonctionnalités et des attributs fondamentaux pouvant être
sémantiques, ne devant pas être ambigus et devant inclure la possibilité
et la capacité de gestion des aspects sécurité• Interfaces : ensemble choisi, fourni (API, formats de données,
protocoles, interfaces matérielles, normes)
• Interopérabilité et relations avec les autres Building Blocks
• Building Blocks dépendants ayant la fonctionnalité requise et des
interfaces utilisateur nommées
• Mise en relation avec des entités et des réglementations propres aumétier ou à l’organisation.
Chaque bloc ABB doit comporter un énoncé de tous les documents et
modèles d’architecture issus du Référentiel d’Architecture de l’entreprise
qui pourraient être réutilisés pendant le développement de l’architecture.
La spécification des building blocks utilisant l’ADM est un processusévolutif et itératif.
On se reportera à la section 5.5 qui fournit d’autres informations.
3.23 Les Building Blocks de la
SolutionLes Building Blocks de Solutions (SBB – Solution Building
Blocks ) décrivent le Continuum de Solutions. Ce sont des
formes de réalisation des architectures identifiées dans le
Continuum d’Architecture de l’entreprise et peuvent soit être obtenus de
l’extérieur, soit être développés. Les SBB apparaissent au cours de la Phase
B.
Architecture
du Business
C.
Architecture desSystèmes
d'Information
D.
ArchitecturesTechniques
E.
Opportunitéset Solutions
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 93/177
92 TOGAF™ Version 9 – Guide de Poche
E de l’ADM lors de laquelle on prend en compte pour la première fois des
Building Blocks propres aux produits. Les SBB définissent les produits et les
composants qui mettront en œuvre une fonctionnalité donnée, définissantainsi la forme de réalisation. Ils répondent aux exigences métiers et sont
conçus en fonction des produits ou des fabricants. La spécification d’un
bloc SBB contient au minimum les éléments suivants :
• Fonctionnalité et attributs spéciques
• Interfaces ; l’ensemble mis en œuvre
• Les SBB exigés ayant été utilisés avec une fonctionnalité requise et lesnoms des interfaces utilisées
• Mise en relation des blocs SBB avec la topologie informatique et les
règles opérationnelles
• Spécications d’attributs partagés, par exemple sécurité, facilité de
gestion, aptitude à la localisation et évolutivité
• Performances, facilité de conguration• Moteurs et contraintes de la conception, y compris l’architecture
physique
• Relations entre blocs SBB et ABB
3.24 La Planication en Fonction
des CapacitésLes Phases E et F font appel à une méthode
précise permettant de définir et de planifier une
transformation d’entreprise se fondant sur les principes de la planification
en fonction des capacités, technique de planification du business qui se
focalise sur les résultats du business. Elle est mue et dirigée par le business
et combine les efforts de tous les secteurs d’activité pour atteindre lacapacité souhaitée. Elle s’adapte à la plupart sinon à la totalité des modèles
d’entreprise et est particulièrement utile dans des organisations dans
lesquelles une certaine capacité de réponse latente (par exemple un service
de préparation aux urgences) est requise et où des ressources identiques
E.
Opportunitéset Solutions
F.
Planificationde la migration
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 94/177
93TOGAF™ Version 9 – Guide de Poche
sont utilisées dans plusieurs capacités. Il arrive souvent qu’on découvre et
qu’on affine ce besoin de capacités à l’aide de scénarios métiers.
La figure 5 illustre la relation entre la planification en fonction des
capacités, l’architecture d’entreprise et la gestion de portefeuilles/projets.
3.25 Les Techniques dePlanication de la Migration
On dispose de plusieurs techniques d’assistance à laplanification d’une migration lors des phases E et F.
Elles sont décrites aux sections suivantes.
3.25.1 Matrice d’Évaluation et de Détermination desFacteurs de Mise en œuvre
La technique de création d’une Matrice d’Evaluation et de Déterminationde Facteurs de Mise en œuvre est utilisée lors de la Phase E pour
documenter les facteurs ayant une influence sur le Plan de Mise en
œuvre et de Migration de l’Architecture. Cette matrice doit comporter
une liste de tous les facteurs, de leurs descriptions et des déterminations
Figure 5 : Relations entre Capacités, Architecture d’Entreprise et Projets
Plan Stratégique d'EntrepriseButs et Objectifs de
Transformation Métiers
Capacité(orientée résultats)
Vision de l'Architecture(Phase A)
Portefeuilles deProjets d'Entreprise
Projets d'entreprise(entre portefeuilles)
Incrémentations deProjets d'entreprise (entre portefeuilles)
Solutions
d'Incrémentationdes Capacités
à la base de
à la base de
Sedécompose e
à la base de
Lots deTravail
Lots deTravail
Basis for Constitués de
Ont pourlivrables
Ont toutespour livrables
Définition del'Architecture(Phase B, C, D)
Architectures deTransition (Phase E, F)
Building Blocks de
l'Architecture(Phases A-D) et desSolutions (Phase E)
Incrémentation de Capacité
Crée et Gère
Constituées de
Désigne
Building Blocks
(livrables)
E.
Opportunitéset Solutions
F.
Planificationde la migration
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 95/177
94 TOGAF™ Version 9 – Guide de Poche
(conclusions) ayant pu être faites, indiquant les actions ou les contraintes
devant être prises en compte lors de la formulation des plans.
Un exemple de matrice est illustré dans le tableau 10.
3.25.2 Matrice des Ecarts Consolidés, des Solutions etdes Dépendances
La technique de création d’une Matrice des Ecarts Consolidés, des
Solutions et des Dépendances permet à l’architecte, pour chaque domaine,
de regrouper les Ecarts identifiés dans les résultats de l’analyse des écarts
des architectures et d’évaluer certaines solutions potentielles ainsi queles dépendances vis-à-vis d’un ou plusieurs de ces écarts. Le tableau 11
en fournit un exemple. Cette matrice peut être utilisée comme outil de
planification lors de la création de lots de travail (work packages ). Les
dépendances identifiées sont les moteurs de la création des projets et de la
planification de migration lors des Phases E et F.
Tableau 10 : Matrice d’Evaluation et de Détermination des Facteurs de Mise en œuvre
Matrice d’Evaluation et de Détermination des Facteurs de Mise en œuvre
Facteur Description Détermination
<Nom du Facteur> <Description du
Facteur>
<Impact sur le Plan de
Migration>Changement de
Technique
Arrêt des centres de
messagerie, conduisant
à une économie de
main d’œuvre de 700
personnes, et les faire
remplacer par un
système de courrierélectronique.
Besoin de formation et de
réaffectation des personnels
Le courrier électronique
conduit à d’importantes
réductions de main d’œuvre
et doit être considéré comme
prioritaire.
Consolidation des services ... ...
Introduction d’un
Nouveau Service
Clientèle
... ...
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 96/177
95TOGAF™ Version 9 – Guide de Poche
3.25.3 Table des Définitions ArchitecturalesIncrémentées
La technique de création d’une Table des Définitions ArchitecturalesIncrémentées permet à l’architecte de planifier une série d’Architectures de
Transition qui font apparaître l’état de l’architecture d’entreprise à certains
moments précis. On devra créer une table telle que celle illustrée par le
tableau 12, qui devra fournir la liste des projets. On répartira ensuite les
livrables définis de façon incrémentielle entre les diverses architectures de
transition.
3.25.4 Table d’Evolution de l’État d’une Architectured’EntrepriseLa technique consistant à créer une Table d’Evolution de l’État de
l’Architecture d’Entreprise permet à l’architecte de faire ressortir à divers
niveaux l’état proposé des architectures en utilisant le Modèle de Référence
Technique (TRM - Technical Reference Model ).
Tableau 11 : Matrice des Ecarts Consolidés, des Solutions et des Dépendances
Matrice des Ecarts Consolidés, des Solutions et des Dépendances
No Architecture Ecart Solutions Potentielles Dépendances
1 Métier Nouvelle
Commande
Processus deTraitement
Utiliser un traitement
par un progiciel sur
étagèreMettre en œuvre une
solution sur mesure
Pilote
l’Application
No 2
2 Application Nouvelle
Commande
Application de
Traitement
Progiciel sur étagère X
Développement
propriétaire
3 Informations Based’information
de Clientèle
Consolidée
Utiliser une base declientèle préexistante
Développer un mini-
entrepôt de données
de clientèle
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 97/177
96 TOGAF™ Version 9 – Guide de Poche
On crée une table qui indique les services issus du TRM utilisés dans
l’entreprise, les Architectures de Transition, et les transformations
proposées, comme le montre le tableau 13.
On décrira tous les Building Blocks de Solutions (SBB) du point de
vue de leur mode de livraison et de leur(s) impact(s) sur ces services. Ils
devront également être signalés de façon à faire apparaître l’évolution de
l’architecture d’entreprise. Dans l’exemple proposé, on a atteint la capacité
cible et on l’indique en précisant “nouveau” ou “retenu” ; lors d’une
Tableau 12 : Exemple de Table d’Incrémentation de Dénitions d’Architecture
Définition d’Architecture : Objectifs du Projet pour chaque incrémentation
Projet
Avril
2007/2008
Avril
2008/2009
Avril
2009/2010
Commentaires
Architecture de
Transition 1 :
Préparation
Architecture de
Transition 2 :
Capacité
Opérationnelle
Initiale
Architecture
de Transition
3 :
Avantages
Capacité
e-Services
d’entreprise
Formation
et Processus
Métiers
Capacité
de licence
électronique
Avantages du
télétravail
Formulaires
électroniques
pour
l’informatique
Conception et
construction
Informatique
Environnement
d’InformationsElectroniques
Conception et
Construction
d’unEnvironnement
d’Information
Données
communes
clientèleContenu Web
Conception et
Construction
Données
communes
d’entrepriseGestion des
documents
Conception
et
construction
... ... ... ... ...
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 98/177
97TOGAF™ Version 9 – Guide de Poche
transition de la capacité vers une nouvelle solution, cela est signalé par
“transition” ; et lorsqu’une capacité doit être remplacée, on le signale en
indiquant “remplacement”.
3.25.5 Technique d’Évaluation des Valeurs métiersLa technique permettant d’évaluer une valeur métier consiste à créer une
matrice dont l’une des dimensions est l’indicateur de valeur et dont l’autre
dimension est l’indicateur de risque. Un exemple en est fourni sur la figure
6. L’indicateur de valeur doit recouvrir certains critères tels que le respectdes principes, les contributions financières, l’alignement stratégique et la
position vis-à-vis de la concurrence. L’indicateur de risque doit englober
des critères tels que la taille et la complexité, la technique, la capacité
organisationnelle et l’impact d’un éventuel échec. A chaque critère doit être
affecté un poids individuel.
L’indicateur et ses critères et poids doivent être déterminés et approuvés par
la direction de l’entreprise. Il est important d’établir les critères de prise de
décision avant prise de connaissance des options.
Tableau 13 : Exemple de Table d’Evolution de l’État d’une Architecture d’Entreprise
État Architectural défini à partir du Modèle de Référence Technique
Sous-Domaine Service
Architecture
de Transition
1
Architecture
de Transition
2
Architecture
de Transition
3
Applicationsd’Infrastructure Servicesd’Echange
d’Informations
Système deSolutions A
(remplacer)
Système deSolutions B-1
(transition)
Système deSolutions B-2
(nouveau)
Services
de Gestion de
Données
Système de
Solutions D
(retenir)
Système de
Solutions D
(retenir)
Système de
Solutions D
(retenir)
... ...
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 99/177
98 TOGAF™ Version 9 – Guide de Poche
3.26 Le Plan de Mise en œuvre etde Migration
Le Plan de Mise en œuvre et de Migration est mis
au point au cours des Phases E et F et propose une
chronologie de la mise en œuvre de la solution décrite par une Architecturede Transition. Le Plan de Mise en œuvre et de Migration comprend la
chronologie, les coûts, les ressources, les avantages et les jalons de la mise
en œuvre.
On y trouve typiquement :
• La Stratégie de Mise en œuvre et de Migration :– La direction stratégique de mise en œuvre
– La démarche séquentielle de mise en œuvre
• Les interactions avec d’autres cadres de gestion :
– La démarche d’alignement de l’architecture sur la planification du
business
Figure 6 : Matrice d’Evaluation des Valeurs métiers
Valeur
Risque
Conforme au plan
Projet A
Projet B
Projet C
Projet F
Projet G
Projet E
Projet D
Projet H
En risque
En difficulté
(Taille du projet symbolisée par la dimension du cercle).
E.
Opportunitéset Solutions
F.
Planificationde la migration
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 100/177
99TOGAF™ Version 9 – Guide de Poche
– La démarche d’intégration des efforts d’architecture
– La démarche d’alignement de l’architecture avec la gestion des
portefeuilles ou des projets– La démarche d’alignement de l’architecture avec la gestion des
opérations
• Les chartes de projets :
– Les capacités apportées par les projets
– Les lots de travail inclus
– La valeur pour le business– Les risques, problèmes, hypothèses et dépendances
• Le plan de mise en œuvre :
– La décomposition en phases et volets d’exécution des efforts de mise
en œuvre
– L’attribution de lots de travail à chaque phase et à chaque volet
d’exécution– Les jalons et la chronologie
– La décomposition des tâches
– Les exigences et coûts en ressources
3.27 L’Architecture de Transition
Une ou plusieurs Architectures de Transition sontdéfinies en tant que sortants de la Phase E. Une
Architecture de Transition montre l’entreprise
à différents stades incrémentiels qui correspondent aux périodes de
transition de l’Architecture Initiale à l’Architecture Cible. Les Architectures
de Transition permettent de regrouper des lots de travail et des projets
individuels sous forme de portefeuilles gérés et de programmes, illustrant lavaleur métier obtenue à chaque stade.
E.
Opportunitéset Solutions
F.
Planificationde la migration
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 101/177
100 TOGAF™ Version 9 – Guide de Poche
Une Architecture de Transition contiendra typiquement :
• Un portefeuille d’opportunités :
– Evaluation des écarts consolidés, des solutions et des dépendances– Description des opportunités
– Evaluation des avantages
– Capacités et incrémentations de capacité
– Exigences d’interopérabilité et de coexistence
• Un portefeuille de lots de travail :
– Description des lots de travail (nom, descriptif, objectifs, livrables)– Exigences fonctionnelles
– Dépendances
– Relation avec opportunité
– Relations avec le Document de Définition d’Architecture et la
Spécification des Exigences de l’Architecture
• Les jalons et les Architectures de Transition aux jalons :– Définition des états de transition
– Architecture du Business pour chaque état de transition
– Architecture des Données pour chaque état de transition
– Architecture des Applications pour chaque état de transition
– Architecture Technique pour chaque état de transition
• Matrice d’Évaluation et de Détermination des Facteurs de Mise enœuvre, comprenant :
– Les Risques
– Les Problèmes
– Les Hypothèses
– Les Dépendances
– Les Actions• Matrice des Ecarts Consolidés, des Solutions et des Dépendances,
comprenant :
– Le Domaine de l’Architecture
– L’Ecart
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 102/177
101TOGAF™ Version 9 – Guide de Poche
– Les Solutions potentielles
– Les Dépendances
3.28 Le Modèle de Gouvernance dela Mise en œuvre
Une fois qu’une architecture a été définie, il est nécessaire
de planifier la façon dont l’Architecture de Transition sera
gouvernée pendant la mise en œuvre de l’architecture.
Dans les organisations qui ont créé des fonctions d’architecture, il estprobable qu’un cadre de gouvernance soit déjà présent, mais il se peut qu’il
soit nécessaire de définir des processus, des organisations, des rôles, des
responsabilités et des mesures spécifiques, et cela projet par projet.
Le Modèle de Gouvernance de la Mise en œuvre, qui est un sortant de
la Phase F, fait en sorte qu’un projet passant en phase de mise en œuvreévolue aussi en douceur vers une bonne gouvernance d’architecture (pour
la Phase G).
Un Modèle de Gouvernance de la Mise en œuvre contiendra typiquement :
• Des processus de Gouvernance
• Une structure d’organisation de la gouvernance• Des rôles et des responsabilités dans la gouvernance
• Des points de vérication et des critères de réussite/échec de la
gouvernance
3.29 Les Contrats d’Architecture
Les Contrats d’Architecture sont produits lors de laPhase G :
Gouvernance de la Mise en œuvre. Les Contrats
d’Architecture sont des accords de partenariat entre les partenaires et les
sponsors d’un développement, qui portent sur les livrables, la qualité et la
bonne adéquation d’une architecture. Ces accords conduiront à la réussite
E.
Opportunitéset Solutions
F.
Planificationde la migration
G.
Gouvernance
de la Mise
en Œuvre
H.
Gestion duChangement
d'Architecture
G.
Gouvernance
de la Mise
en Œuvre
H.
Gestion duChangement
d'Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 103/177
102 TOGAF™ Version 9 – Guide de Poche
d’une mise en œuvre grâce à une architecture efficace. En mettant en
œuvre une démarche gouvernée pour gérer les contrats, on pourra garantir
:• Un système de suivi continu permettant de vérier l’intégrité, les
changements et les prises de décision, et de faire un audit de toutes les
activités liées à l’architecture au sein de l’organisation
• Le respect des principes, des standards et des exigences des architectures
existantes et en cours de développement
• L’identication des risques liés à tous les aspects du développement et dela mise en œuvre de la ou des architecture(s) lors d’un développement
en interne dans le respect des standards, des règles, des techniques et des
produits déjà acceptés, et liés aux aspects opérationnels des architectures,
de façon que l’organisation puisse poursuivre son activité au sein d’un
environnement adaptable
• Un ensemble de processus et de pratiques qui garantissent laresponsabilisation et la discipline lors du développement et de
l’utilisation de tous les éléments d’architecture.
• Une compréhension formelle de l’organisation de la gouvernance qui
est responsable du contrat, de son niveau d’autorité et du périmètre de
l’architecture soumise à la gouvernance de cette entité
TOGAF 9 identifie les deux exemples de contrat suivants :
• Le Contrat de Conception et de Développement d’Architecture
• Le Contrat d’Architecture auprès des Entités Métiers
Les contenus types d’un Contrat de Conception et de Développement
d’Architecture sont les suivants :• Introduction et contexte
• Nature de l’accord
• Périmètre de l’architecture
• Architecture et principes et exigences stratégiques
• Exigences de conformité
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 104/177
103TOGAF™ Version 9 – Guide de Poche
• Processus et rôles de développement et de gestion de l’architecture
• Mesures de l’Architecture Cible
• Phases dénies pour les livrables• Plan de travail de partenariat hiérarchisé
• Fenêtre(s) de tir
• Métriques utilisées pour les livrables et les métiers
Un contrat type d’architecture des Utilisateurs Métiers produit par la Phase
G contiendra :• Une introduction et un contexte
• La nature de l’accord
• Le périmètre
• Les exigences stratégiques
• Les exigences de conformité
• Les utilisateurs auxquels est destinée l’architecture• Une fenêtre de tir
• Des métriques métiers de l’architecture
• Une architecture des services (comprenant le Contrat de Niveau de
Service (SLA – Service Level Agreement ))
Ce contrat est aussi utilisé pour gérer les modifications apportées àl’architecture d’entreprise lors de la Phase H.
3.30 La Demande de ChangementLes demandes de Changement d’Architecture
sont traitées lors de la Phase H : Gestion des
Changements d’Architecture.
Durant la mise en œuvre d’une architecture, à mesure que le nombre de
faits connus augmente, il peut arriver que la définition et les exigences
de l’architecture initiale soient inadaptées ou insuffisantes pour mener
à bien la mise en œuvre d’une solution. Dans ces circonstances, on doit
G.
Gouvernance
de la Mise
en Œuvre
H.
Gestion duChangement
d'Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 105/177
104 TOGAF™ Version 9 – Guide de Poche
faire en sorte que les projets de mise en œuvre s’écartent de la démarche
architecturale suggérée, ou bien demander un élargissement du périmètre.
De plus, certains facteurs externes (par exemple des facteurs liés au marché,des changements de stratégie de l’entreprise et de nouvelles opportunités
techniques) peuvent ouvrir de nouvelles opportunités permettant d’étendre
et d’affiner l’architecture.
Dans ces circonstances, une Demande de Changement peut être proposée
pour lancer un nouveau cycle du travail d’architecture.
Une Demande de Changement contiendra typiquement :
• Une description du changement proposé
• Une justication du changement proposé
• Une évaluation de l’impact du changement proposé, cela comprenant :
– Une référence à des exigences particulières– Les priorités des exigences vis-à-vis des acteurs concernés à l’instant
considéré
– Les phases à revoir
– La phase à prendre en compte pour hiérarchiser les exigences
– Les résultats des analyses de phase et de révision des priorités
– Des recommandations sur la gestion des exigences• Le numéro d’identication du référentiel d’entreprise
3.31 L’Évaluation de ConformitéUne fois qu’une architecture a été définie, il est
nécessaire de la conduire à travers les phases de
la mise en œuvre de telle manière que la Visiond’Architecture initiale soit convenablement appliquée et que toutes les
leçons tirées de cette application soient répercutées dans le processus. Des
analyses périodiques de conformité des projets de mise en œuvre de Phase
G permettent d’évaluer le déroulement d’un projet et de faire en sorte que
la conception et la mise en œuvre se déroulent dans le sens des objectifs
stratégiques et architecturaux que l’on s’est fixés.
G.
Gouvernance
de la Mise
en Œuvre
H.
Gestion duChangement
d'Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 106/177
105TOGAF™ Version 9 – Guide de Poche
Une Evaluation de Conformité comprendra typiquement :
• Un aperçu général de la progression et de l’état d’un projet
• Un aperçu général de l’architecture ou de la conception d’un projet• Le remplissage de check-lists de l’architecture :
– Check-list des matériels et des systèmes d’exploitation
– Check-list des services logiciels et des middleware
– Check-list des applications
– Check-list de la gestion des informations
– Check-list de sécurité– Check-list pour la gestion des systèmes
– Check-list concernant l’ingénierie système
– Check-list des méthodes et outils
3.32 L’Évaluation de l’Impact sur les
ExigencesTout au long de l’ADM, de nouvelles informations concernant
l’architecture sont collectées. A mesure que ces informations sont
rassemblées, de nouveaux faits peuvent être mis en lumière qui invalident
certains aspects existants de l’architecture. Une évaluation de l’Impact sur
les Exigences permet d’évaluer les exigences et les spécifications actuelles
d’une architecture afin d’identifier certains changements devant êtreeffectués et les implications qu’auront ces changements.
Cela consiste à documenter l’évaluation des changements et les
recommandations de modifications devant être apportées à l’architecture. Il
est suggéré que ce document contienne :
• Une référence à des exigences particulières• Les priorités des exigences vis-à-vis des acteurs concernés à l’instant
considéré
• Les phases à revoir
• La phase à prendre en compte pour hiérarchiser les exigences
• Les résultats des analyses des phases et des priorités revues
H.
Gestion duChangement
d'Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 107/177
106 TOGAF™ Version 9 – Guide de Poche
• Des recommandations sur la gestion des exigences
• Le numéro d’identication du référentiel d’entreprise
Ces éléments sont souvent fournis en réponse à une Demande de
Changement.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 108/177
Chapitre 4
Recommandations pourl’adaptation de l’ADMCe chapitre fournit les recommandations à suivre pour adapter l’ADM.
4.1 IntroductionL’ADM est une méthode générique de développement d’architectures
qui est conçue pour répondre à la plupart des exigences des systèmes et
des organisations. Cependant, il sera souvent nécessaire de modifier ou
de compléter l’ADM pour l’adapter à certains besoins particuliers. Avant
d’appliquer l’ADM il faut analyser le processus impliqué et ses sortants
pour vérifier qu’ils puissent bien être utilisés, puis les adapter du mieux quel’on peut aux circonstances d’une entreprise particulière. Cette activité peut
conduire à une ADM “spécifique de l’entreprise”.
On peut souhaiter adapter l’ADM aux particularités d’une entreprise pour
plusieurs raisons. Certaines de ces raisons sont explicitées ci-après.
1. Il est important de tenir compte du fait que l’ordre des phases de l’ADMdépend dans une certaine mesure du niveau de maturité de l’architecture
au sein de l’entreprise concernée. Par exemple, si la définition
d’architecture n’est pas perçue comme essentielle, il est indispensable
de créer une Vision de l’Architecture, qui doit être suivie par une
Architecture Business détaillée afin de définir les cas d’études pour les
éléments d’architecture restants tout en s’assurant de la participationactive des acteurs clés dans ce travail.
2. L’ordre des phases peut aussi être fixé par les principes du business et
de l’architecture utilisés par l’entreprise. Par exemple, les principes du
business peuvent imposer à l’entreprise sa préparation aux modifications
de ses processus business afin de répondre aux besoins d’une solution
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 109/177
108 TOGAF™ Version 9 – Guide de Poche
globale qui pourra être mise en œuvre rapidement et conduira à
une réponse immédiate aux évolutions du marché. Dans ce cas,
l’Architecture du Business (ou du moins sa réalisation) peut très bien secalquer sur la réalisation de l’Architecture des Systèmes d’information.
3. Une entreprise peut souhaiter utiliser ou adapter l’ADM en association
avec un autre cadre d’architecture d’entreprise qui comporte un
ensemble précis de livrables propres à un secteur vertical particulier :
Gouvernement, Défense, e-Business, Télécommunications, etc.
4. L’ADM est l’un des nombreux processus d’entreprise qui font partiedu modèle de gouvernance d’une entreprise. L’ADM complète et vient
à l’appui d’autres processus classiques de gestion des programmes.
L’entreprise adaptera l’ADM de façon à ce que celle-ci soit le reflet
des relations et des dépendances établies avec d’autres processus de
management.
5. L’utilisation de l’ADM est sous-traitée à un maître d’œuvre ou à unsous-traitant, dans le cadre d’une sous-traitance, et doit pouvoir être
contextualisée afin d’établir un compromis entre la façon de travailler du
sous-traitant et les exigences de l’entreprise donneuse d’ordre.
6. L’entreprise est une petite ou moyenne entreprise et souhaite utiliser
une version “réduite” de l’ADM qui s’accommode mieux du niveau de
ressources réduit et de la complexité des systèmes qui sont typiques decet environnement.
7. L’entreprise est une très grande entreprise pouvant être complexe,
englobant de nombreuses “filiales” distinctes bien qu’associées au sein
d’un cadre de business collaboratif global, et la méthode architecturale
doit être adaptée à cette situation. De telles entreprises ne peuvent
généralement pas être traitées de façon adéquate en tant qu’entité uniqueet nécessitent une approche plus fédérative.
Le processus ADM peut également être adapté de façon à prendre en
compte un certain nombre de scénarios d’utilisation différents, parmi
lesquels des styles de processus différents (par exemple le fait d’utiliser des
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 110/177
109TOGAF™ Version 9 – Guide de Poche
itérations) ainsi que des architectures spécialisées spécifiques (telles que la
sécurité). Ces aspects sont analysés dans les sections suivantes.
4.2 Application des itérations à l’ADML’ADM prend en charge un certain nombre de concepts que l’on pourrait
considérer comme des itérations. On peut en effet s’attendre à ce que :
• Les équipes projets réitèrent plusieurs fois la totalité du cycle ADM,
et démarrent une nouvelle activité de vision comme résultat du
Management d’un Changement d’Architecture ;• Les équipes projets peuvent répéter plusieurs phases ADM selon des
cycles planifiés recouvrant plusieurs phases (par exemple l’Architecture
du Business, l’Architecture des Systèmes d’Information et l’Architecture
Technique) ;
• Les équipes projets peuvent revenir à des phases précédentes et répéter
un cycle afin de mettre à jour des fournitures d’architecture avec denouvelles informations ;
• Plusieurs équipes projets peuvent parcourir leurs cycles ADM
indépendamment mais en même temps et des relations peuvent exister
entre les différentes équipes. Par exemple, une équipe d’architecture
peut lancer une demande de mise en chantier destinée à une autre
équipe d’architecture.
Toutes ces techniques sont des applications valables de l’ADM et peuvent
être utilisées pour faire en sorte que la démarche de développement
architectural soit suffisamment souple pour s’accommoder d’autres
méthodes et cadres conceptuels.
TOGAF 9 prend en compte les facteurs organisationnels qui ont une
influence sur le nombre d’itérations utilisées par l’ADM, les différents
cycles d’itération et la correspondance entre les phases ADM et les cycles
d’itération prévus au moment de la définition de l’architecture.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 111/177
110 TOGAF™ Version 9 – Guide de Poche
Un cycle d’itération suggéré qui couvre de multiples phases de l’ADM est
représenté sur la figure 7.
• Les itérations sur le Contexte de l’Architecture permettent la
mobilisation initiale de l’activité d’architecture par la définition de la
démarche, des principes et du périmètre.
Figure 7 : Cycles d’Itération
Gestion desExigences
Phasepréliminaire
Itération sur laGouvernance del'Architecture
Itération surla Planificationde la Transition
Itération surle Contexte del'Architecture
Itération surla Définitionde l'Architecture
A.Vision de
l'Architecture
E.Opportunitéset Solutions
F.Planification de
la migration
G.Gouvernance de la
Mise en Œuvre
H.Gestion du
Changementd'Architecture
B.Architecturedu Business
C.Architecturedes Systèmesd'Information
D.ArchitectureTechnique
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 112/177
111TOGAF™ Version 9 – Guide de Poche
• Les itérations sur la Définition de l’Architecture permettent de créer
du contenu en parcourant de façon cyclique les phases d’Architecture du
Business, des Systèmes d’Information et Technique.• Les itérations sur la planification de la Transition permettent de créer
des feuilles de route formelles décrivant les changements.
• Les itérations sur la gouvernance de l’Architecture favorisent la
progression de la gouvernance des changements vers une Architecture
Cible bien définie.
TOGAF 9 définit deux styles de définition de l’architecture :
• Commencer par l’ Architecture Initiale : Si l’on utilise ce style, on
évalue tout d’abord l’Architecture Initiale. Ce processus convient
lorsqu’on n’a pas encore une bonne compréhension de la solution cible.
• Commencer par l’Architecture Cible : Si l’on utilise ce style, on
élabore l’Architecture Cible en détail, puis on la fait remonter jusqu’àl’architecture initiale afin de préciser l’activité de changement. Ce
processus convient lorsqu’il a été possible de s’accorder sur un état cible
aux niveaux les plus élevés de l’entreprise et lorsque l’entreprise souhaite
éviter une prolifération des pratiques courantes du business vers la cible.
TOGAF 9 met en correspondance ces deux styles avec les cycles d’itération,comme illustré sur les figures 8 et 9.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 113/177
112 TOGAF™ Version 9 – Guide de Poche
C o n t e x t e d e
l ’ A r c h i t e c t u r e
D é fi n i t i o n d e l ’ A r c h i t e c t u r e
P l a n i fi c a t i o
n d e l a
T r a n s i t i o n
G o u v e r n a n c e d e
l ’ a r c h i t e c t u
r e
P h a s e T O G A F
I t é r a t i o n
i n i t i a l e
I t é r a t i o n 1
I t é r a t i o n 2
I t é r a t i o n n
I t é r a t i o n 1 I t é r a t i o n n
I t é r a t i o n 1
I t é r
a t i o n n
P h a s e p r é l i m i n a i r
e
C œ u r
I n f o r m e l
I n f o r m e l
I n f o r m e l
L é g
e r
V i s i o n d ’ A r c h i t e c t u r e
C œ u r
I n f o r m e l
I n f o r m e l
I n f o r m e l
I n f o r m e l
I n f o r m e l
L é g
e r
A r c h i t e c t u r e d u
B u s i n e s s
I n i t i a l e
I n f o r m e l
I n f o r m e l
L é g e r
C œ u r
I n f o r m e l
I n f o r m e l
L é g
e r
C i b l e
I n f o r m e l
I n f o r m e l
C œ u r
C œ u r
I n f o r m e l
I n f o r m e l
L é g
e r
A r c h i t e c t u r e d e s
A p p l i c a t i o n s
I n i t i a l e
I n f o r m e l
I n f o r m e l
L é g e r
C œ u r
I n f o r m e l
I n f o r m e l
L é g
e r
C i b l e
I n f o r m e l
I n f o r m e l
C œ u r
C œ u r
I n f o r m e l
I n f o r m e l
L é g
e r
A r c h i t e c t u r e d e s
D o n n é e s
I n i t i a l e
I n f o r m e l
I n f o r m e l
L é g e r
C œ u r
I n f o r m e l
I n f o r m e l
L é g
e r
C i b l e
I n f o r m e l
I n f o r m e l
C œ u r
C œ u r
I n f o r m e l
I n f o r m e l
L é g
e r
A r c h i t e c t u r e
T e c h n i q u e
I n i t i a l e
I n f o r m e l
I n f o r m e l
L é g e r
C œ u r
I n f o r m e l
I n f o r m e l
L é g
e r
C i b l e
I n f o r m e l
I n f o r m e l
C œ u r
C œ u r
I n f o r m e l
I n f o r m e l
L é g
e r
O p p o r t u n i t é s e t S
o l u t i o n s
I n f o r m e l
L é g e r
L é g e r
L é g e r
C œ u r
C
œ u r
I n f o r m e l
I n f o
r m e l
P l a n i fi c a t i o n d e l a M i g r a t i o n
I n f o r m e l
L é g e r
L é g e r
L é g e r
C œ u r
C
œ u r
I n f o r m e l
I n f o
r m e l
M i s e e n œ u v r e d e l a
G o u v e r n a n c e
I n f o r m e l
I n f o r m e l
C œ u r
C œ
u r
G e s t i o n d u C h a n g
e m e n t
I n f o r m e l
I n f o r m e l
I n f o r m e l
I n f o r m e l
C œ u r
C œ
u r
C œ u r : F o c a
l i s a t i o n p r i n c i p a l e d e l ’ a c t i v i t é d ’ i t é r a t i o n
L é g e r : F o c a
l i s a t i o n s e c o n d a i r e d e l ’ a c t i v
i t é d ’ i t é r a t i o n
I n f o r m e l : A
c t i v i t é p o t e n t i e l l e d ’ i t é r a t i o n n o n f o r m e l l e m e n t m e n t i o n n é e d a n s l a m é t h o d e
F i g u r e 8 : A c t i v i t é p a r i t é r a t i o n l o r s d e l a P r e m i è r
e D é n i t i o n d e l ’ A r c h i t e c t u r e
I n i t i a l e
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 114/177
113TOGAF™ Version 9 – Guide de Poche
F i g u r e 9 : A c t i v i t é p a r I t é r a t i o n l o r s d e l a P r e m i è r
e D é n i t i o n d e l ’ A r c h i t e c t u r e
C i b l e
C o n t e x t e d e
l ’ A r c h i t e c t u r e
D é fi n i t i o n d e l ’ A r c h i t e c t u r e
P l a n i fi c a t i o
n d e l a
T r a n s i t i o n
G o u v e r n a n c e
d e
l ’ a r c h i t e c t u
r e
P h a s e T O G A F
I t é r a t i o n
i n i t i a l e
I t é r a t i o n 1
I t é r a t i o n 2
I t é r a t i o n n
I t é r a t i o n 1 I t é r a t i o n n
I t é r a t i o n 1
I t é r
a t i o n n
P h a s e p r é l i m i n a i r e
C œ u r
I n f o r m e l
I n f o r m e l
I n f o r m e l
L é g
e r
V i s i o n d ’ A r c h i t e c t u r e
C œ u r
I n f o r m e l
I n f o r m e l
I n f o r m e l
I n f o r m e l
I n f o r m e l
L é g
e r
A r c h i t e c t u r e d u
B u s i n e s s
I n i t i a l e
I n f o r m e l
I n f o r m e l
C œ u r
C œ u r
I n f o r m e l
I n f o r m e l
L é g
e r
C i b l e
I n f o r m e l
C œ u r
L é g e r
C œ u r
I n f o r m e l
I n f o r m e l
L é g
e r
A r c h i t e c t u r e d e s
A p p l i c a t i o n s
I n i t i a l e
I n f o r m e l
I n f o r m e l
C œ u r
C œ u r
I n f o r m e l
I n f o r m e l
L é g
e r
C i b l e
I n f o r m e l
C œ u r
L é g e r
C œ u r
I n f o r m e l
I n f o r m e l
L é g
e r
A r c h i t e c t u r e d e s
D o n n é e s
I n i t i a l e
I n f o r m e l
I n f o r m e l
C œ u r
C œ u r
I n f o r m e l
I n f o r m e l
L é g
e r
C i b l e
I n f o r m e l
C œ u r
L é g e r
C œ u r
I n f o r m e l
I n f o r m e l
L é g
e r
A r c h i t e c t u r e
T e c h n i q u e
I n i t i a l e
I n f o r m e l
I n f o r m e l
C œ u r
C œ u r
I n f o r m e l
I n f o r m e l
L é g
e r
C i b l e
I n f o r m e l
C œ u r
L é g e r
C œ u r
I n f o r m e l
I n f o r m e l
L é g
e r
O p p o r t u n i t é s e t S o l u t i o n s
I n f o r m e l
L é g e r
L é g e r
L é g e r
C œ u r
C
œ u r
I n f o r m e l
I n f o
r m e l
P l a n i fi c a t i o n d e l a
M i g r a t i o n
I n f o r m e l
L é g e r
L é g e r
L é g e r
C œ u r
C
œ u r
I n f o r m e l
I n f o
r m e l
M i s e e n œ u v r e d e
l a
G o u v e r n a n c e
I n f o r m e l
I n f o r m e l
C œ u r
C œ u r
G e s t i o n d u C h a n g e m e n t
I n f o r m e l
I n f o r m e l
I n f o r m e l
I n f o r m e l
C œ u r
C œ u r
C œ u r : F o c a l i s a t i o n p r i n c i p a l e d e l ’ a c t i v i t
é d ’ i t é r a t i o n
L é g e r : F o c a l i s a t i o n s e c o n d a i r e d e l ’ a c t i v i t é d ’ i t é r a t i o n
I n f o r m e l : A c t i v i t é p o t e n t i e l l e d ’ i t é r a t i o n
n o n f o r m e l l e m e n t m e n t i o n
n é e d a n s l a m é t h o d e
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 115/177
114 TOGAF™ Version 9 – Guide de Poche
4.3 Application de l’ADM à différents niveauxde l’entreprise
L’ADM est destinée à être utilisée comme modèle apportant un soutienlors de la définition et de la mise en œuvre d’une architecture à plusieurs
niveaux au sein d’une entreprise. Comme il n’est pas possible de développer
une seule architecture répondant aux besoins de tous les acteurs concernés,
l’entreprise doit être partitionnée en différentes zones dont chacune peut
être prise en charge par des architectures. Les architectures d’entreprise sont
généralement partitionnées en fonction du Sujet, de la Période de Temps etdu Niveau de Détail, comme illustré sur la figure 10.
TOGAF 9 décrit les types de contrats sur lesquels les architectes peuvent
s’engager et comment l’ADM peut être utilisée pour coordonner les
activités de diverses équipes d’architectes travaillant à différents niveaux. Il
Figure 10 : Résumé d’un Modèle de Classication du Paysage de l’Architecture
Architecture
d'une Capacité
Architecture
d'une Capacité
Période de temps
Subject
Matter
N i v e a u
d e D é t a i l
Architecture Stratégique Point de Vue 1 (v0.1, 0.2, ...), Point de Vue 2 (v0.1, 0.2,...),....
Architecture d'un SegmentPoint d Vue 1 (v0.1, 0.2, ...),Point d Vue 2 (v0.1, 0.2,...),....
Architectured'un SegmentPoint d Vue 1(v0.1, 0.2, ...),Point d Vue 2
(v0.1, 0.2,...),....
Architecture
d'une Capacité
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 116/177
115TOGAF™ Version 9 – Guide de Poche
propose également deux stratégies permettant d’utiliser l’ADM en tant que
processus permettant de prendre en charge des hiérarchies d’architectures :
• Des Architectures peuvent être développées à différents niveaux aumoyen d’itérations au sein d’un même processus ADM. Par cette
démarche, comme illustré sur la figure 11, la phase de Vision de
l’Architecture peut être utilisée pour développer une vue stratégique
de l’architecture. Les phases B, C et D fournissent alors une vue
plus détaillée et formelle du paysage de l’architecture pour différents
segments ou différentes périodes de temps. Les phases E et F permettentalors de développer un Plan détaillé de la Migration qui peut inclure des
Architectures de Capacités encore plus détaillées et spécifiques.
Figure 11 : Itération au sein d’un même cycle ADM
Phase
préliminaire
Pratique et Contexte
de l'Architecture
Architecture
StratégiqueA.
Vision de
l'Architecture
B.
Architecture
du Business
C.
Architecture
des Systèmes
d'Information
D.
Architectures
TechniquesE.
Opportunités
et Solutions
F.
Planification
de la migration
G.
G. Gouvernance
de la Mise
en Œuvre
H.
Gestion du
Changement
d'Architecture
Gestion des
Exigences
Architecture(s)
des Capacités
Architecture(s)
des Segments
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 117/177
116 TOGAF™ Version 9 – Guide de Poche
• Dans les cas où des architectures de plus grande échelle doivent être
développées par plusieurs équipes d’architecture différentes, l’ADM
peut être appliquée de façon plus hiérarchisée. Cette façon d’utiliserl’ADM fait appel à la phase de Planification de la Migration d’un cycle
ADM pour initier de nouveaux projets qui conduiront également
au développement d’architectures. Différents niveaux d’architecture
peuvent être développés au travers d’une hiérarchie de processus ADM
exécutés simultanément, comme illustré sur la figure 12.
4.4 L’Architecture de Sécurité et l’ADMTOGAF 9 constitue un guide sur les aspects sécurité qu’il est nécessaire
de prendre en compte pendant l’application de l’ADM. Il aide l’architecte
d’entreprise déployant l’ADM à informer l’architecte responsable de
la sécurité des changements qui devront être apportés à l’architecture
de sécurité. Il joue également le rôle de guide évitant que l’architected’entreprise néglige une préoccupation de sécurité cruciale.
Tous les groupes d’acteurs d’une entreprise ont des besoins spécifiques
de sécurité qui peuvent ne pas être immédiatement visibles tant que
l’architecte n’a pas pris connaissance de leur nature. Il est recommandé de
faire en sorte que l’architecte de la sécurité soit informé du projet dès quepossible. Tout au long des phases ADM, TOGAF propose son assistance
concernant certaines des informations de sécurité qu’il est nécessaire de
recueillir, les étapes qui doivent être exécutées et les éléments devant être
créés. Les décisions d’architecture propres à la sécurité, tout comme les
autres, doivent pouvoir être ramenées à des décisions du business et de
réglementation qui doivent résulter d’une analyse des risques. Les domainesde préoccupation généralement reconnus par l’architecte de la sécurité sont
les suivants :
• Authentication : Établissement par une méthode quelconque de
l’identité d’une personne ou d’une entité liée au système ;
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 118/177
117TOGAF™ Version 9 – Guide de Poche
• Autorisations : Dénition et mise en application des capacités autorisées
à une personne ou à une entité dont l’identité a été établie.
• Audit : Aptitude à fournir des données auditables attestant du fait que lesystème a été utilisé en conformité avec des règles de sécurité déclarées.
Phasepréliminaire
Architecture des Segments
Architecture des Capacités
Architecture Stratégique
A.
Vision del'Architec-ture B.
Architec-ture duBusiness
C. Architecturedes Systèmesd'Information
D. ArchitectureTechnique
E.
Opportunitéset Solutions
F. Planification
de la
migration
G.
Gouvernance
de la Mise
en Œuvre
H.Gestion du
Changementd'Architecture
Gestion desExigences
Phasepréliminaire
A.
Vision del'Architec-
ture B.Architec-ture duBusiness
C. Architecturedes Systèmesd'Information
D. Architecture
TechniqueE.Opportunités
et Solutions
F. Planification
de la
migration
G.
Gouvernance
de la Mise
en Œuvre
H.Gestion du
Changementd'Architecture
Gestion desExigences
Phasepréliminaire
A.Vision del'Architec-
ture B.Architec-ture duBusiness
C. Architecture
des Systèmesd'Information
D. Architecture
TechniqueE.Opportunitéset Solutions
F. Planification
de lamigration
G.
Gouvernance
de la Miseen Œuvre
H.Gestion du
Changementd'Architecture
Gestion desExigences
Figure 12 : Exemple de hiérarchie des processus de l’ADMCopyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 119/177
118 TOGAF™ Version 9 – Guide de Poche
• Assurance : Possibilité de tester et de prouver que le système dispose des
attributs de sécurité nécessaires pour répondre aux exigences des règles
de sécurité établies ;• Disponibilité : Aptitude du système à fonctionner sans interruption ni
dégradation de service malgré la survenue d’événements anormaux ou
frauduleux ;
• Protection des Actifs : Protection de l’information contre toute perte
ou divulgation involontaire, et ressources résultant d’une utilisation
frauduleuse et involontaire.• Administration : Possibilité d’ajouter ou de modier des règles de
sécurité, d’ajouter ou de modifier des méthodes de mise en œuvre de
règles du système et d’ajouter ou de modifier des personnes ou des
entités liées au système ;
• Gestion du risque : Attitude et tolérance de l’organisation face aux
risques.
Comme éléments types de l’architecture de sécurité, on peut citer :
• Des règles du business concernant la manipulation des données ou des
actifs informationnels ;
• Des règles de sécurité écrites et publiées ;
• La propriété et l’hébergement d’actifs codiés de données oud’information;
• La documentation concernant l’analyse des risques ;
• La documentation concernant les règles de classication des données.
4.5 Utilisation de TOGAF pour Dénir et
Gouverner les SOA TOGAF 9 décrit l’Architecture Orientée Service en tant que type
d’architecture, la façon dont l’architecture d’entreprise prend en charge
les SOA, et la correspondance entre les terminologies SOA et TOGAF, et
propose des recommandations quant à la façon de définir un contrat de
service.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 120/177
119TOGAF™ Version 9 – Guide de Poche
Le SOA, en tant que style architectural, a pour but de simplifier le
business et l’interfonctionnement de ses diverses parties constitutives,
en structurant les capacités sous la forme de services granulaires biendéfinis par opposition à des unités métiers verticales et opaques. Elle
permet d’identifier les capacités fonctionnelles d’une organisation et par
conséquent, offre la possibilité de diminuer les risques de duplication.
En normalisant le comportement et l’interfonctionnement des services,
il devient possible de limiter l’impact des changements et de planifier
également l’impact des changements à venir.La discipline d’architecture d’entreprise offre les outils et les techniques
suivantes pour aider les organisations lors de l’utilisation des SOA :
• L’architecture d’entreprise dénit des représentations structurées
et traçables du business et des techniques qui lient les actifs de
l’informatique au business qu’elle soutient, d’une façon bien définie et
mesurable. Ces modèles permettent quant à eux d’évaluer l’impact et lagestion des portefeuilles dans un contexte beaucoup plus riche ;
• L’architecture d’entreprise dénit des principes, des contraintes, des
cadres conceptuels, des patterns et des standards qui constituent la base
des règles de conception et assurent l’alignement des services, leurs
interopérabilités et leurs réutilisations ;
• L’architecture d’entreprise établit des liens entre les diverses façonsd’aborder un même problème métier (métier, données, applications,
technique, abstrait, concret, etc.) en proposant un modèle cohérent
destiné à résoudre divers aspects d’un problème et une batterie étendue
de tests de complétude.
• L’architecture d’entreprise propose des abstractions cohérentes de
stratégies de niveau élevé et de livrables des projets, permettant deregrouper les sortants créés tout aussi bien de bas en haut que de haut en
bas dans un référentiel partagé supportant la planification et l’analyse.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 121/177
120 TOGAF™ Version 9 – Guide de Poche
Grâce à ces techniques, l’architecture d’entreprise devient une fondation
permettant le déploiement d’une certaine forme de SOA au sein d’une
organisation, car :• Elle établit un lien entre les divers acteurs concernés par le SOA,
garantissant la satisfaction des besoins de chaque communauté d’acteurs
et l’information de chaque communauté d’acteurs concernés à propos
du contexte correspondant ;
• Elle établit entre business et technologie de l’information un lien qui
peut être utilisé pour justifier des coûts induits par la reconfiguration desservices informatiques en rapport avec la valeur métier.
• Elle montre quels services doivent être construits et comment les
réutiliser.
• Elle met en évidence la façon dont les services doivent être conçus et le
mode d’interfonctionnement des plates-formes ;
• Elle constitue un référentiel destiné à conserver et à maintenir à longterme des informations liées à la conception.
TOGAF propose un certain nombre de concepts apparaissant dans le
métamodèle du contenu TOGAF (chapitre 5) qui aident à modéliser les
concepts SOA.
• Fonction : Une fonction est ce que fait un métier. Les servicessupportent des fonctions, ils sont des fonctions et remplissent des
fonctions, mais les fonctions ne sont pas nécessairement des services. Les
services sont soumis à des contraintes plus spécifiques que les fonctions.
• Services Business : un service business est ce que fait un business et
possède une interface définie et mesurée ayant conclu des contrats avec
des consommateurs du service. Un service business est pris en charge pardes combinaisons de personnes, de processus et de techniques.
• Le Service du Système d’Information : un service du système
d’information est une chose réalisée par un système d’information et
possède une interface définie et mesurée ayant conclu des contrats avec
des consommateurs du service. Les services du système d’information
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 122/177
121TOGAF™ Version 9 – Guide de Poche
sont directement pris en charge par des applications et sont associés à
des interfaces de services SOA.
• Composants d’Application : un composant d’application est un systèmeconfiguré et déployé, ou une partie gouvernée indépendamment d’un
système configuré et déployé. Les composants d’applications offrent
des services du système d’information. Les composants d’applications
peuvent être des applications physiques ainsi que des applications
logiques qui regroupent entre elles des applications de types semblables.
• Composant Technique : Un composant technique est un logiciel ou unmatériel que l’on peut se procurer auprès d’un fournisseur interne ou
externe. Les composants techniques sont configurés, combinés, étendus
et déployés afin de produire des composants d’applications.
Cela est résumé sur la figure 13.
4.5.1 Lectures SupplémentairesLe groupe de travail “Open Group SOA Work” travaille actuellement
à développer un Guide Pratique qui permettra à un praticien certifié
TOGAF de l’utiliser pour développer une architecture orientée services.
Des informations plus détaillées sont fournies sur le SOA Working Group
et ses projets sur www.opengroup.org/projects/soa.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 123/177
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 124/177
Chapitre 5
Le Cadre de Contenud’ArchitectureCe chapitre introduit le concept de Cadre de Contenu d’Architecture qui
est un métamodèle structuré des éléments d’architecture.
5.1 Aperçu général du Cadre de Contenud’Architecture
L’exécution de l’ADM a pour résultat des sortants tels les flux de processus,
les exigences architecturales, les plans des divers projets, des évaluations
de conformité de ces projets, etc. Pour pouvoir rassembler et présenter ces
fournitures majeures de manière cohérente et structurée, on doit pouvoirles positionner dans un Cadre de Contenu d’Architecture. On peut ainsi
s’y référer plus facilement et ainsi disposer d’une classification standardisée.
Cela permet la structuration des relations entre les divers éléments fournis
formant ce que l’on a l’habitude de nommer “Architecture d’Entreprise”.
Le Cadre de Contenu d’Architecture défini dans TOGAF 9 permetd’utiliser TOGAF comme un cadre d’architecture autonome au sein
d’une entreprise. Cependant, comme il existe d’autres cadres de contenu
(par exemple les cadres ArchiMate et Zachman), certaines entreprises
préfèreront utiliser un cadre externe en association avec l’ADM. Dans ce
cas, le Cadre de Contenu d’Architecture TOGAF constitue une référence
et un point de départ permettant la mise en correspondance d’un contenuTOGAF avec les métamodèles d’autres cadres conceptuels.
Pour simplifier la classification des nouvelles fournitures d’architecture et
aider à répondre aux besoins potentiels de liens avec les autres cadres de
contenu (qui incluent éventuellement les fournitures d’architecture déjà
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 125/177
124 TOGAF™ Version 9 – Guide de Poche
classées), le Cadre de Contenu d’Architecture fait intervenir trois catégories
pour décrire les types de fournitures architecturales dans leurs contextes
d’utilisation :
• Un livrable (deliverable ) est une fourniture d’architecture formelle qui
est spécifiée de façon contractuelle et doit normalement être examinée
puis faire l’objet d’un contrat signé par les acteurs concernés. Les
livrables représentent souvent les sortants de projets.
• Un élément d’architecture (artifact ) est une fourniture plus granulairequi décrit une architecture sous un angle de vue particulier. Il peut
s’agir de choses telles que la spécification de scénarios d’utilisation, une
liste d’exigences architecturales ou un diagramme de flux. Les éléments
d’architecture sont généralement classés soit en tant que catalogues (liste
d’items), soit en tant que matrices (mettant en évidence les relations
entre items), soit en tant que diagrammes (images d’items). Un livrablepeut contenir de nombreux éléments d’architecture.
• Un Building Block (potentiellement réutilisable) représente soit un
composant business, soit un composant informatique, soit le composant
d’une capacité qui peut être combiné à d’autres Building Blocks afin de
livrer des architectures et des solutions.
Les Building Blocks peuvent être définis à divers niveaux de détail et
peuvent être à la fois liés aux “architectures” et aux “solutions”. En effet, les
Building Blocks de l’Architecture (ABB) décrivent généralement la capacité
requise pour mettre en forme les Building Blocks des Solutions (SBB) qui
peuvent représenter des composants à utiliser pour mettre en œuvre la
capacité exigée. Ces points sont évoqués plus en détail dans la Section 5.5.
Les relations entre livrables, éléments d’architecture et Building Blocks sont
illustrés sur la figure 14.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 126/177
125TOGAF™ Version 9 – Guide de Poche
5.2 Le Métamodèle du ContenuLe Cadre de Contenu de l’Architecture se fonde sur un métamodèle
standard qui définit tous les types de Building Blocks pouvant exister au seind’une architecture. Un aperçu schématique du métamodèle de contenu
est illustré figure 15. Le métamodèle formalise la façon dont ces Building
Blocks peuvent être décrits et la façon dont ils sont liés les uns aux autres.
Lors de la création et de la gestion des architectures, il faut prendre
en compte divers aspects tels que les services métiers, les acteurs, lesapplications, les entités de données et la technique. Le métamodèle du
contenu fait apparaître ces préoccupations, met en évidence leurs relations
et identifie les éléments d’architecture permettant de les représenter de
manière cohérente et structurée.
Par ailleurs, le métamodèle du contenu peut être utilisé comme guide partoutes les organisations souhaitant mettre en œuvre leur architecture à
l’aide d’un outil.
5.2.1 Le Cœur et les ExtensionsLa structure du modèle a été conçue pour prendre en compte le cœur des
contenus et leurs éventuelles extensions. Le cœur du métamodèle fournitun ensemble minimal de contenus architecturaux assurant la traçabilité
entre éléments, alors que les extensions facilitent des modélisations plus
spécifiques ou approfondies.
Les extensions sont regroupées de façon logique en catalogues, matrices
et diagrammes, permettant de se focaliser sur des domaines d’intérêtspécifiques. Tous les modules d’extension sont facultatifs et doivent être
sélectionnés pendant la phase Préliminaire des diverses itérations de l’ADM
afin de répondre aux besoins de l’organisation. Les extensions décrites dans
TOGAF le sont à titre de recommandation et peuvent être ajoutées ou
contextualisées en fonction des besoins.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 127/177
126 TOGAF™ Version 9 – Guide de Poche
F i g u r e 1 4 : R e l a t i o n e n t r e
L i v r a b l e s ,
E l é m e n t s d ’ A r c h i t
e c t u r e e t B u i l d i n g
B l o c k s
L i v r a b l e d e l ' A r c h i t e
c t u r e
B u i l d i n g B l o c k s r é u t i l i s a b l e s
L i v r a b l e s d e l ' A r c h i t
e c t u r e
A u t r e s l i v r a b l e s
C a t a l o g u e s
M a t r i c e s
D i a g r a m m e s
B u i l d i n g B l o c k s
C a t a l o g u e s
M a t r i c e s
D i a g r a m m e s
B
u i l d i n g B l o c k s
E l é m e n
t s
d ' A r c h i t e c t u r e
L i v r a b l e s d e
l ' A r c h i t e c t u r e
Q u i s o n t
D é c r i v a n t
D é c r i v a n t
R é f é r
e n t i e l d ' A r c h i t e c t u r e
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 128/177
127TOGAF™ Version 9 – Guide de Poche
5.2.2 Catalogues, Matrices et DiagrammesBien que le métamodèle de contenu aide à structurer les informations
architecturales, les acteurs concernés ne souhaitent généralement pasconnaître les détails du cadre de contenu d’architecture ainsi défini.
L’utilisation de catalogues, de matrices et de diagrammes a donc été
introduite pour faciliter la présentation des informations architecturales
afin qu’on puisse les utiliser plus facilement à des fins de référence et de
gouvernance.
Les catalogues sont des listes de Building Blocks de type particulier oude types liés entre eux, les matrices sont des grilles qui font apparaître
les relations entre deux ou plusieurs entités et les diagrammes sont des
représentations graphiques de contenus architecturaux.
En résumé, les résultats d’une architecture développée conformément
à l’ADM sont constitués de plusieurs ABB bien définis peuplant descatalogues de l’architecture, avec des relations spécifiées entre Building
Blocks dans des matrices de l’architecture, puis présentés sous la forme de
diagrammes de communication qui montrent de façon précise et concise ce
qu’est l’architecture.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 129/177
128 TOGAF™ Version 9 – Guide de Poche
F i g u r e 1 5 : A p e r ç u G
é n é r a l d u M é t a m o d è l e d e C o
n t e n u
P r i n c i p e s ,
V i s i o n e
t E x
i g e n c e s d e
l ' A r c h
i t e c t u r e
E
x i g e n c e s
d e
l ' A r c h
i t e c t u r e
P h a s e
P r é
l i m i n a i r
e
P r i n c i p e s
d e
l ' A r c h
i t e c t u r e
P r i n
c i p e s ,
O b j e c t i f s e
t
M o
t e u r s
d u
M é t i e r
A c t e u r s
C o n c e r n
é s
S t r a t é g
i e M é t i e r
S t r a t é g
i e T e c h n
i q u e
V i s i o n
d e
l ' A r c h i t
e c t u r e
V i s i o
n d e
l ' A r c h
i t e c t u r e
E x
i g e n c e
s
C o
n t r a i n t e s
E c a r t s
H y p o
t h è s e s
R é a
l i s a t i o n
d e
l ' A r c h i t e c t u r e
G o u v e r n a n c e
d e
l a m
i s e e n œ u v r e
O p p o r t u n i t
é s ,
S o
l u t i o n s e
t P l a n
i f i c a t i o n
d e
l a M i g r a
t i o n
S t a n
d a r d s
R e c o m m a
n d a
t i o n s
S p
é c i f i c a
t i o n s
C a p a c i t é s
L o
t s d e
T r a v a
i l
C o
n t r a t s d ' A r c h
i t e c t u r e
O r g a n
i s a t i o n
O r g a n
i s a t i o n
L i e u
A c t e u r ,
R ô l e
F o n c t i o n
S e r v
i c e s m
é t i e r s ,
C o n
t r a t s , Q u a
l i t é s
d e
S e r v
i c e
P r o c e s s u s ,
É v
é n e m e n
t s ,
C o n
t r ô l e s ,
P r o
d u
i t s
F o n c t i o
n s
M o
t i v a
t i o n
A r
c h i t e c t u r e
d u
B u s i n e s s
A r c h
i t e c t
u r e
d e s
S y s t è m e s
d ' I n f o r m a
t i o n
M o
t e u r s
B u
t s
O b j e c t i f s
M e
s u r e s
D o n n
é e s
E n
t i t é s
d e
D o n
n é e s
C o m p o s a n t s
d e
D o n n
é e s
l o g i
q u e s
C o m p o s a n t s
d e
D o n n
é e s
P h y s
i q u e s
A p p
l i c a t i o n
s
S e r v
i c e s
d e s
S y s t
è m e s
d ' I n f o r m a
t i o
n
C o m p o s a n t
s
d ' A p p
l i c a t i o n s
L o g
i q u e s
C o m p o s a n t
s
d ' A p p
l i c a t i o
n
P h y s i q u e s
A r c h
i t e c t u r e
T e c h n
i q u e
S e r v
i c e s
d e
P l a t e f o r m e s
C o m p o s a n t s
T e c h n
i q u e s
L o g
i q u e s
C o m p o s a n t s
T e c h n
i q u e s
P h y s i q u e s
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 130/177
129TOGAF™ Version 9 – Guide de Poche
5.3 Eléments d’ArchitectureTOGAF 9 décrit un ensemble de fournitures élémentaires qui sont créées
lors du développement d’une architecture conformément à l’ADM.Ces fournitures sont étiquetées en tant qu’éléments d’architecture. Elles
forment un modèle individuel représentant un système, une solution ou
l’état d’une entreprise. Ce modèle pourrait le cas échéant être réutilisé dans
divers autres contextes.
Un élément d’architecture est différent d’un livrable qui, lui, est un sortantcontractuel d’un projet. Dans la plupart des cas, les livrables contiennent
des éléments d’architecture et chacun de ces éléments peut se retrouver
dans de nombreux livrables. Les concepts et la terminologie de base utilisés
dans la présente section se fondent sur la norme ISO/IEC 42010:2007,
décrite dans le Tableau 14 et illustrée sur la gure 166.
TOGAF 9 propose un ensemble d’exemples de points de vue de
l’architecture, résumés dans le tableau 15, qui peuvent être adoptés,
améliorés et combinés afin de produire des vues décrivant une architecture.
6 Reproduit avec la permission de l’IEEE Std 1471-2000, Systems and Software Engineer-
ing—Recommended Practice for Architectural Description of Software-intensive Systems,
Copyright © 2000, de IEEE. L’IEEE décline toute responsabilité liée à la présentation et à
l’utilisation de ces éléments.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 131/177
130 TOGAF™ Version 9 – Guide de Poche
Concepts Définition
Système Un système est une collection de composants organisés de façon à
remplir une fonction ou un ensemble de fonctions spécifiques
Architecture L’architecture d’un système est l’organisation fondamentale du
système, mise en œuvre sous la forme de ses composants, de leurs
relations les uns avec les autres et avec l’environnement, et des
principes guidant sa conception et son évolution.
Description
Architecturale
Une description architecturale est une collection d’éléments
d’architecture qui documentent une architecture. Dans TOGAF,
les vues de l’architecture sont les éléments clés d’une descriptionde l’architecture.
Acteurs
concernés
Les acteurs concernés sont des personnes jouant des rôles clés
dans le système ou fortement concernées par celui-ci ; il s’agit
par exemple des utilisateurs, des développeurs ou des managers.
Des acteurs différents jouant des rôles différents dans le système
auront des préoccupations différentes. Les acteurs concernés
peuvent être des individus, des équipes ou des organisations (oudes classes de ceux-ci).
Préoccupations Les préoccupations sont les intérêts fondamentaux qui revêtent
une importance cruciale pour les acteurs concernés par le système,
et déterminent l’acceptabilité du système. Les préoccupations
peuvent concerner un aspect quelconque du fonctionnement, du
développement, ou de l’exploitation d’un système, cela incluant
les performances, la fiabilité, la sécurité, la distribution et lespossibilités d’évolution.
Vue Une vue est une représentation globale d’un système sous la
forme d’un ensemble cohérent de préoccupations. Lorsqu’il
évalue ou lorsqu’il représente la conception de l’architecture d’un
système, l’architecte crée généralement un ou plusieurs modèles
d’architecture en utilisant le cas échéant différents outils. Une
vue comprendra certaines parties sélectionnées d’un ou plusieursmodèles, choisies de façon à montrer à un acteur particulier ou à
un groupe d’acteurs concernés que leurs préoccupations sont bien
prises en compte dans la conception de l’architecture du système.
Tableau 14 : Concepts Liés aux Vues de l’Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 132/177
131TOGAF™ Version 9 – Guide de Poche
Figure 16 : Concepts de Base pour une Description de l’Architecture
Bibliothèquede Points
de Vue
VuePoint de vuePréoccupation
JustificationActeur
concerné
ArchitectureSystèmeEnvironnement
Mission
Modèle
Remplit 1...*
A une
Comporte 1...*Est important pour 1...*
Identifie 1...*
Est adressé à 1...*
Décrite par 1
Fournit
Participe à
Participeà 1...*
Est constituéde 1...*
Agrège 1..*
Etablit desméthodes pour 1...*
Est hébergé
A 1...* Identifie 1...* Sélectionne 1...*
Se conforme à
Utilisé pourcouvrir 1...*
A pour source 0...1
Influence
Description
Architecturale
Organisée par 1...*
Concepts Définition
Point de Vue Un point vue définit l’angle de prise de vue. Plus précisément,
un point de vue définit la façon dont on construit et utilise
une vue (au moyen d’un schéma ou d’un modèle approprié) ;
les informations devant apparaître dans la vue ; les techniques
de modélisation permettant d’exprimer et d’analyser les
informations ; et un justificatif de ces choix (en décrivant par
exemple le but et l’audience à laquelle est destinée la vue).
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 133/177
132 TOGAF™ Version 9 – Guide de Poche
Phase de l’ADM Point de Vue
Points de vue de la
Phase Préliminaire
Catalogue des principes
Points de vue de la
Phase A
Matrice de Relations entre Acteurs Concernés
Diagramme de la Chaîne de Valeurs
Diagramme des Concepts de Solutions
Points de vue de la
Phase B
Catalogue des Organisations/Acteurs
Catalogue des Moteurs/Buts/Objectifs
Catalogue des Rôles
Catalogue des Services/Fonctions MétiersCatalogue des Lieux
Catalogue des Processus/Événements/Contrôles/Produits
Catalogue des Contrats/Mesures
Matrice des Interactions entre Métiers
Matrice des Acteurs/Rôles
Diagramme de la Place et du Poids du Business
Diagramme des Services/Informations du BusinessDiagramme de Décomposition Fonctionnelle
Diagramme du Cycle de vie des Produits
Diagramme des Buts/Objectifs/Services
Diagramme des Cas d’Usage
Diagramme de Décomposition de l’Organisation
Diagramme des Flux
Diagramme d’ÉvénementsPoints de vue de la
Phase C, Architecture
des Données
Catalogue des Entités de Données/Composants de
Données
Matrice des Entités de Données/Fonctions Métiers
Matrice des Systèmes/Données
Diagramme des Classes
Diagramme de Dissémination des Données
Diagramme de Sécurité des DonnéesDiagramme de Hiérarchie des Classes
Diagramme de Migration des Données
Diagramme du Cycle de Vie des Données
Tableau 15 : Exemples de Points de vue par phase de l’ADM
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 134/177
133TOGAF™ Version 9 – Guide de Poche
5.4 Livrables de l’Architecture
TOGAF 9, Partie IV, Chapitre 36 propose une base de référence typiquepour des livrables de l’architecture permettant de mieux définir les activités
requises par l’ADM. Elle peut devenir pour une organisation le point
de départ d’une personnalisation. Pour plus de détails, on se référera au
Chapitre 3.
Phase de l’ADM Point de Vue
Points de vue de la
Phase C,
Architecture des
Applications
Catalogue des Portefeuilles d’Applications
Catalogue des Interfaces
Matrice des Systèmes/Organisations
Matrice des Rôles/Systèmes
Matrice des Systèmes/Fonctions
Matrice des Interactions inter-applications
Diagramme des Communications inter-applications
Diagramme de localisation des Applications et des
Utilisateurs
Diagramme des cas d’usage des SystèmesDiagramme de l’Administrabilité de l’Entreprise
Diagramme de Réalisation des Processus/Systèmes
Diagramme de l’Ingénierie Logicielle
Diagramme de la Migration des Applications
Diagramme de Distribution des Logiciels
Points de vue de la
Phase D
Catalogue des Standards Techniques
Catalogue des Portefeuilles TechniquesMatrice Systèmes/Techniques
Diagramme des Localisations et des Environnements
Diagramme de Composition des Plateformes
Diagramme des Traitements
Diagramme de l’infrastructure matérielle/réseau
Diagramme de l’Ingénierie des Télécommunications
Points de vue de laPhase E
Diagramme de Contextes des ProjetsDiagramme des Avantages
Points de Vue pour la
Gestion des Exigences
Catalogue des Exigences
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 135/177
134 TOGAF™ Version 9 – Guide de Poche
5.5 Les Building BlocksLe Cadre de Contenu de l’Architecture explique le concept de Building
Blocks (blocs de construction), en s’appuyant sur des exemples fictifsprésentant des Building Blocks dans une architecture. TOGAF utilise des
Building Blocks d’architecture (ABB) et des Building Blocks de solutions
(SBB).
Le terme “Building Blocks ” est omniprésent dans l’ADM et plus
généralement dans TOGAF. Un Building Block est simplement unensemble de fonctionnalités définies pour répondre à des besoins de
l’entreprise. Les modes d’assemblage des fonctionnalités, des fournitures
et des développements sur mesure sous forme de Building Blocks peuvent
fortement varier d’une architecture à l’autre. Chaque organisation choisit
elle-même la meilleure configuration de ses Building Blocks . Des Building
Blocks bien choisis peuvent améliorer l’intégration des systèmes existants,l’interopérabilité et la souplesse de création de nouveaux systèmes et de
nouvelles applications.
Les systèmes sont construits à partir de collections de Building Blocks , de
manière qu’ils soient interopérables entre eux pour la plupart. Chaque fois
que cela se vérifie, il est important que les interfaces d’un Building Blocksoient publiées et soient suffisamment stables.
Les Building Blocks peuvent être définis à divers niveaux de détail, selon le
stade de développement de l’architecture.
A titre d’exemple, lors d’un premier stade, un Building Block peutsimplement être constitué d’un groupement de fonctionnalités, comme
une base de données de clients ou certains outils d’extraction. Les Building
Blocks correspondant à ce niveau de définition fonctionnelle sont décrits
dans TOGAF en tant que Building Blocks de l’Architecture (ABB) ;
on se reportera à la Section 3.22. Des produits ou des développements
spécifiques vont plus tard venir se substituer aux définitions de cesCopyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 136/177
135TOGAF™ Version 9 – Guide de Poche
fonctionnalités, les Building Blocks étant alors décrits sous la forme de
Building Blocks de Solutions (SBB), comme l’explique la Section 3.23.
On résume ci-dessous les phases et les étapes clés de l’ADM lors desquelles
les Building Blocks sont spécifiés et amenés à évoluer. Elles sont illustrées
figure 17.
Lors de la Phase A, les premières définitions des Building Blocks débutentsous la forme d’entités relativement abstraites de la Vision de l’Architecture.
Lors des Phases B, C et D, les Building Blocks correspondant aux
architectures Business, Données, Applications, et Technique sont amenés à
évoluer ensemble par étapes successives.
Figure 17 : Building Blocks de l’Architecture et leur utilisation dans le Cycle de l’ADM
A.Vision de
l'ArchitectureB.
Architecturedu Business
C.Architecturedes Systèmesd'Information
D.ArchitecturesTechniques
E.Opportunitéset Solutions
F.Planification
de lamigration
G.Gouvernance
de la Miseen Œuvre
H.Gestion du
Changementd'Architecture
Gestion desExigences
B. Architecture du BusinessC. Architecture des Données/ApplicationsD. Architecture TechniqueEtape 1 : Sélectionner des Modèles, des Pointsde vue et des Outils de RéférenceEtape 2 : Développer une Description del'Architecture Initiale■ Modèle abstrait des Building Blocks existants, réutilisant les définitions trouvées dans le référentiel d'architecture lorsqu'elles sont disponiblesEtape 3 : Développer la Description de l'Architecture Cible■ Développer une vue des Building Blocks requis en créant des catalogues, des matrices, des diagrammes de l'Architecture■ Documenter entièrement chaque Building Block ■ Justification documentée des décisions relatives aux Building Blocks dans le document d'architecture■ Identifier les Building Blocks concernés en les comparant à une bibliothèque de Building Blocks du référentiel d'Architecture si possible en
les réutilisant■ Si nécessaire, définir de nouveaux Building Blocks■ Définir des standards pour chaque Building Blocks en réutilisant autant que possible des modèles de référence sélectionnés dans le Continuum d'Architecture■ Documenter les correspondances finales entre les Building Block et le Paysage Architectural■ A partir des Building Blocks sélectionnés, identifier ceux qui pourraient être réutilisés et les publier en tant que standards ou modèles de référence via le référentiel d'architectureEtape 4 : Effectuer l'analyse des écarts■ Identifier des Building Blocks repris■ Identifier les Building Blocks éliminés■ Identifier les nouveaux Building Blocks■ Identifier les écarts et déterminer le mode de réalisation (devant par exemple être développée ou acquis)Etape 5 : Définir les Composants de la Feuille de routeEtape 6 : Résoudre les Impacts sur tout lePaysage ArchitecturalEtape 7 : Passage en revue formel des Acteurs ConcernésEtape 8 : Finaliser l'ArchitectureEtape 9 : Créer le Document de Définition de l'Architecture
A. Vision de l'Architecture■ Modèle abstrait des Building Blocks candidats
E. Opportunités et Solution■ Associer les écarts entre Building Blocks aux lots de travail qui permettront de combler ces écarts
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 137/177
136 TOGAF™ Version 9 – Guide de Poche
Enfin, lors de la Phase E, les Building Blocks intègrent des éléments de mise
en œuvre à mesure que les SBB intègrent les éléments nécessaires pour
combler les écarts identifiés.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 138/177
Chapitre 6
Le Continuumd’EntrepriseCe chapitre fournit une introduction au Continuum d’Entreprise.
Les sujets traités dans ce chapitre fournissent :
• Une explication du Continuum d’Entreprise et de sa nalité• L’utilisation du Continuum d’Entreprise pour développer une
architecture d’entreprise
• Un aperçu général des caractéristiques qui permettent de classer et de
partitionner les architectures
• Un aperçu général d’un cadre structurel utilisé dans un Référentiel
d’Architecture
6.1 Aperçu général du Continuum d’EntrepriseLe Continuum d’Entreprise illustré sur la figure 18 est un modèle
permettant de structurer un référentiel “virtuel” pouvant accueillir
les architectures et leurs solutions (modèles, patterns , descriptions
d’architecture, etc.). Ces actifs et ces solutions peuvent être issus del’entreprise elle-même ou de l’industrie au sens large et être utilisés pour
construire de nouvelles architectures.
Une distinction est établie entre les architectures et leurs solutions
possibles, cela créant par conséquent un Continuum d’Architecture et un
Continuum des Solutions. Comme le montre la figure 18, le lien entre ceséléments joue le rôle de guide et d’aide pour l’architecte.
Le Continuum d’Entreprise sous-tend deux concepts : la réutilisation
lorsque cela est possible, pour éviter notamment d’avoir à tout réinventer,
et une aide à la communication. Les actifs qui sont présents tant dans le
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 139/177
138 TOGAF™ Version 9 – Guide de Poche
Continuum d’Architecture que dans le Continuum des Solutions sont
structurés à plusieurs niveaux, du générique au spécifique. On dispose ainsi
d’un langage cohérent permettant de faire ressortir les différences entre lesarchitectures. Comprendre où l’on se situe dans le continuum permet une
communication plus efficace.
L’utilisation du Continuum d’Entreprise permet d’éviter les ambiguïtés
lorsqu’on évoque certains concepts et certains éléments entre différentsdépartements d’une même organisation ou même entre différentes
organisations construisant des architectures d’entreprise. La compréhension
Figure 18 : Le Continuum d’Entreprise
Référentielsd'Entreprise
(comprenant leRéférentiel des
Exigences,le Référentiel
d'Architecture,les Mémoires
de Concepts et la CMDB7 )
Le Continuumd'Entreprise fournit
une structureet une classification
des actifs dansles Référentiels
d'Entreprise
Les Référentielsd'Entreprise
fournissent desressources pouvant
être classéesdans le Continuum
d'Entreprise
Les Solutions sont instanciéesà chaque déploiement
Les Solutions déployées deviennent le Contexte de l'Architecture
Le contexte façonnel'architecture
ArchitecturesSpécifiques
ArchitecturesGénériques
Solutionsspécifiques
SolutionsGénériques
Guides et supports
Guides et supports
Guides et supports
Guides et supports
Des facteurs externesconstituent le contexte
Adaptation au contexte d'utilisation
Adaptation au contexte d'utilisation
Continuum d'Architecture
Continuum des Solutions
Contexte et Exigences de l'Architecture
Généralisation pour réutilisation future
Généralisation pour réutilisation future
Continuum d'Entreprise
Solutions Déployées
7 Conguration Management Database : Base décrivant les caractéristiques techniques de
tous les composants des systèmes informatiques
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 140/177
139TOGAF™ Version 9 – Guide de Poche
de l’architecture aide à mieux comprendre la solution. Pouvoir expliquer
le concept général sur lequel se fonde une solution facilite la résolution
d’éventuels conflits.
Comme l’utilisation du Continuum d’Entreprise s’accompagne
généralement d’une augmentation des actifs d’architecture et des solutions
associées, les organisations en bénéficieront directement.
6.1.1 Le Continuum d’Entreprise et la Réutilisationd’ArchitecturesComme exemples d’actifs “issus de l’entreprise”, on peut citer les livrables
de chantiers antérieurs d’architecture, rendus ainsi réutilisables. Comme
exemples d’actifs “issus de l’industrie informatique au sens large”, on peut
mentionner une grande variété de modèles de référence et de patterns
architecturaux qui existent déjà dans l’industrie et régulièrement rendusdisponibles sur le marché, dont certains sont très génériques (comme
le Modèle de Référence Technique TOGAF (TRM)) ; d’autres sont
spécifiques à certains aspects des systèmes d’information (par exemple,
une architecture pour services Web) ; d’autres encore sont spécifiques de
certains types de traitements de l’information (comme le e-Commerce) ;
et enfin certains sont spécifiques d’industries verticales (tels que le modèlede données ARTS créé par l’industrie de la vente de détail). Les décisions
que doit prendre une entreprise quant aux actifs d’architecture qu’elle
envisage d’intégrer à son Continuum d’Entreprise, relèvent normalement
de la fonction de gouvernance de l’architecture à l’échelle de l’entreprise
concernée.
6.1.2 Utilisation du Continuum d’Entreprise dansl’ADM
Dans l’ADM, on décrit un processus consistant à passer du Socle
d’Architecture TOGAF à une architecture (ou à un ensemble
d’architectures) spécifique d’une organisation. Ce Socle d’Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 141/177
140 TOGAF™ Version 9 – Guide de Poche
est une description très générale de services et de fonctions génériques
qui constituent le socle sur lequel on peut construire des architectures
spécifiques et des Building Blocks d’Architecture (ABB) en ajoutantdes architectures existantes, des composants et des Building Blocks
d’Architecture appropriés et issus du Continuum d’Entreprise. A certains
endroits pertinents de l’ADM, des aide-mémoire indiquent à l’architecte
quels actifs d’architecture il serait préférable d’utiliser. En plus de son
Socle d’Architecture, TOGAF propose un autre modèle de référence
que l’on peut envisager d’inclure dans le Continuum d’Entreprise d’uneorganisation : le Modèle de Référence d’Infrastructure d’Informations
Intégrées (III-RM).
6.2 Le Partitionnement de l’ArchitectureDans une entreprise typique, de multiples architectures sont déjà
disponibles à un moment donné. Certaines d’entre elles répondent à desbesoins spécifiques ; d’autres sont plus générales. Certaines s’intéressent
aux détails ; d’autres donnent un aperçu général. De même, de nombreuses
solutions peuvent être utilisées ou être simplement envisagées pour
répondre aux besoins de l’entreprise.
Cela met en évidence un besoin de partitionnement des architectures car :
• Il est trop complexe de résoudre tous les problèmes à l’aide d’une seulearchitecture.
• Différentes architectures peuvent entrer en conit les unes avec les autres
(par exemple, lorsque l’état de l’entreprise varie au cours du temps et
lorsqu’une architecture correspondant à une certaine période de temps
entre en conflit avec une architecture provenant d’une autre période de
temps).• Différentes personnes doivent travailler en même temps sur des
éléments d’architecture différents, les partitions permettant alors à des
groupes d’architectes spécifiques de disposer de certains segments de
l’architecture et de les développer.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 142/177
141TOGAF™ Version 9 – Guide de Poche
• Une réutilisation efcace de l’architecture nécessite des segments
architecturaux modulaires pouvant être utilisés et incorporés à des
architectures et à des solutions plus étendues.
Une façon de partitionner l’architecture est d’utiliser comme ligne
directrice le périmètre ou l’objet de l’architecture, comme indiqué
dans la Section 4.3. Une autre caractéristique prise en compte dans le
partitionnement est le point de vue ou le type d’architecture, que l’on peut
globalement classer dans les catégories business, métiers/fonctionnelles,données, applications et technique, comme indiqué dans la Section 1.4.
Les architectures, qui décrivent des solutions, des bonnes pratiques, des
patterns, sont développées (ou acquises) et partagées dans toute l’entreprise
sous la forme de modèles de référence. La classification de ces modèles
de référence peut également aider au partitionnement de l’architecture.La figure 19 représente un modèle permettant de classer les modèles
de référence et les architectures associées sur la base de leur niveau
d’abstraction ou de leur pertinence vis-à-vis d’une organisation particulière.
6.3 Le Référentiel d’ArchitectureLe concept du Référentiel d’Architecture apporte un soutien au
Continuum d’Entreprise et peut être utilisé pour mémoriser différentes
classes de sortants architecturaux à divers niveaux d’abstraction, après
Socles
d'ArchitectureSujet 1, Point de Vue 1
Sujet 1, Point de Vue 2
Sujet 2, Point de Vue 1.....
…
Niveau croissant d'Abstraction
Architectures des
systèmes CommunsSujet 1, Point de Vue 1
Sujet 1, Point de Vue 2
Sujet 2, Point de Vue 1.....
…
Architectures
de l'Industrieet 1, Point de Vue 1
Sujet 1, Point de Vue 2
Sujet 2, Point de Vue 1.....
…
Architectures
Spécifiques
de l'Organisationset 1, Point de Vue 1
Sujet 1, Point de Vue 2
Sujet 2, Point de Vue 1.....
…
Figure 19 : Résumé d’un Modèle de Classication des Modèles de Référence de l’Architecture
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 143/177
142 TOGAF™ Version 9 – Guide de Poche
leur création par l’ADM. TOGAF facilite ainsi la compréhension et la
coopération à différents niveaux entre les acteurs concernés et les praticiens.
Grâce au Continuum d’Entreprise et au Référentiel d’Architecture,
les architectes sont incités à tirer parti de toutes les autres ressources
architecturales pouvant être utiles lors du développement d’une
Architecture Spécifique de l’Organisation.
Dans ce contexte, on peut considérer que l’ADM décrit le cycle de vied’un processus intervenant à de multiples niveaux dans de l’organisation,
opérant au sein d’un cadre de gouvernance holistique et produisant
des sortants alignés qui résident dans un Référentiel d’Architecture. Le
Continuum d’Entreprise constitue un contexte très utile permettant de
bien comprendre les modèles architecturaux : il fait apparaître les Building
Blocks et leurs relations mutuelles, ainsi que les contraintes et exigencesimposées à un cycle de développement de l’architecture.
La structure du Référentiel d’Architecture TOGAF est représentée sur la
figure 20.
Les principaux composants d’un Référentiel d’Architecture sont lessuivants:
• Le Métamodèle d’Architecture décrit l’application d’un cadre
d’architecture contextualisé à l’organisation et comprenant un
métamodèle du contenu de l’architecture.
• La Capacité d’Architecture définit les paramètres, les structures et
les processus qui interviennent dans la gouvernance du Référentield’Architecture.
• Le Paysage de l’Architecture représente une vue architecturale
des Building Blocks qui sont utilisés à un moment donné au sein de
l’organisation (par exemple, une liste des applications déployées). Le
paysage va vraisemblablement varier aux différents niveaux d’abstraction
selon les divers objectifs de l’architecture.Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 144/177
143TOGAF™ Version 9 – Guide de Poche
• La Base d’Information de Standards (SIB – Standards Information
Base ) contient les standards que doivent respecter de nouvelles
architectures. Cela peut comprendre des standards industriels, desproduits et des services sélectionnés disponibles chez des fournisseurs ou
des services partagés déjà déployés au sein de l’organisation.
• La Bibliothèque de Référence contient des recommandations, des
modèles, des patterns et d’autres formes d’informations de référence dont
on peut profiter pour accélérer la création de nouvelles architectures
destinées à l’entreprise.• Les Minutes de la Gouvernance conservent l’historique de l’activité de
gouvernance dans l’ensemble de l’entreprise.
Figure 20 : Structure du Référentiel d’Architecture de TOGAF
La conformitéest gouvernée
Le paysageest gouverné
Les standards ontdes réalisations
de référence
Les Standardssont respectés
Modèles deRéférence
adoptés parl'Entreprise
Comitéd'Architecture
Standardsexternes
Modèles deRéférenceexternes
Visibilité etescalade
Le Comité
d'Architecturedirige et gère
la capacité
Les standardsont des
réalisationsde référence
La Bibliothèquede Référenceest gouvernée
Adopté parl'Entreprise
Based'informationsde standards
Les bonnespratiquescréent desstandards
Paysage del'Architecture
Bibliothèquede Référence
Référentiels d'Architecture
Métamodèle d'Architecture
Capacité d'Architecture
Minutes de la gouvernance
Les élémentsd'architecture du
paysage sont structurésen fonction dumétamodèle
Les bonnes pratiquesfondent
l'Architecturede Référence
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 145/177
144 TOGAF™ Version 9 – Guide de Poche
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 146/177
Chapitre 7
Modèles de RéférenceTOGAFCe chapitre introduit brièvement les Modèles de Référence TOGAF.
7.1 Le Socle d’Architecture TOGAFLe Socle d’Architecture TOGAF est une architecture qui forme la base
sur laquelle on peut construire des architectures et des composants
architecturaux spécifiques. Ce socle d’architecture est mis en œuvre dans
le Modèle de Référence Technique (TRM). Le TRM est applicable de
façon universelle et peut donc être utilisé pour construire n’importe quelle
architecture système.
7.1.1 Le Modèle de Référence Technique (TRM)Le TRM, illustré sur la figure 21, fournit le modèle et la taxinomie de
services de plateformes génériques. La taxinomie définit la terminologie
et propose une description cohérente de ses composants. Son but est de
fournir une description conceptuelle d’un Système d’Information. Lemodèle TRM est aussi une représentation graphique de la taxinomie et est
une aide à la compréhension.
7.2 Le Modèle de Référence d’Infrastructured’Informations Intégrées (III-RM)
Tandis que le Socle d’Architecture décrit l’environnement d’uneplateforme d’une application type, le deuxième modèle de référence inclus
dans le Continuum d’Entreprise, c’est-à-dire le Modèle de Référence
d’Infrastructure d’Informations Intégrées (III-RM), se focalise sur l’espace
des logiciels applicatifs. Le III-RM est une “Architecture des Systèmes
Communs”, selon la terminologie utilisée pour le Continuum d’Entreprise.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 147/177
146 TOGAF™ Version 9 – Guide de Poche
Le III-RM est représenté sur la figure 22 et est un sous-ensemble du TRM
de TOGAF du point de vue de son périmètre global, mais il prolonge
également certaines parties du TRM, notamment dans des applicationsmétiers et certaines parties des applications liées à l’infrastructure.
Le III-RM apporte une aide lorsqu’un architecte d’entreprise veut relever
l’un des principaux défis auxquels il doit faire face aujourd’hui : le besoin
de conception d’une infrastructure d’informations intégrées permettant un
Flux d’Informations sans Frontières.
Figure 21 : Modèle de Référence Technique (TRM)
Q u a l i t é s
Q u al i t é s
Qualités
Qualités
Applicationsmétiers
Applicationsd'infrastructure
Interface de la plateforme d'application
Services des systèmes d'exploitation
Services réseaux
Infrastructure de communication
Interface des infrastructures de communication
Gr a ph i q u e s e t i m a g e
I n t er f a c e u t i l i s a t e ur
G e s t i on d e s s y s t è m e s
e t r é s e a ux
I n g é ni er i el o gi c i el l e
S é c ur i t é
T r ai t em en t d e s t r an s a c t i on s
S i t e s e t r é p er t oi r e s
O p é r a t i on s i n t er n a t i on al e s
E c h an g e d e s d onn é e s
G e s t i on d e s d onn é e s
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 148/177
147TOGAF™ Version 9 – Guide de Poche
Figure 22 : Détail du Modèle III-RM
RépertoireRéférencement/
DéréférencementNommage
EnregistrementPublication
AbonnementDécouverte
Format des messagesd'applications
Messagerie d'applicationServices de communication
inter-applicationsIntégration des
appli. d'entreprise
PrésentationTransformation
Services de navigationPortail et
PersonnalisationMéta Indices
Accès aux informations
Mise en correspondancedes transformations
Distributiondes requêtesAgrégationRecherche
Services de fichiersServices Web
Qualités
Qualités
Applications fournissant des informations
Applications de MédiationOutils de DéveloppementOutils de modélisation
du businessOutils de conception
Outils de ConstructionLangages et Bibliothèques
Utilitaires de Gestion
Sécurité
Contrats SLA de performance
Mobilité
Règles de Gestion
Format des informations
Services d'e-FormulairesServices de messagerie instantanée
Contrôle des processuset des flux d'informations
Médiation Messagerie/Evénements
Flux Audiovisuel
Applications consommatrices d'informations
MédiateursIntégrateurs d'Application
MoniteursUtilitaires d'exécutionGestionnaires de copie
Accès aux informations
Visioconférencesur PC
Courriel Téléphone/Fax
Portail Web
Audiovisuel en flux continu Accès aux informations
Visioconférencesur PC
Courriel Téléphone/Fax
Portail Web
LanguesBibliothèquesRegistres
Signatures NumériquesDétection d'intrusionGestion de clésPare-feuCryptageAAAcSSD
Plateforme d'application
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 149/177
148 TOGAF™ Version 9 – Guide de Poche
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 150/177
Chapitre 8
Cadre de Capacitéd’ArchitectureCe chapitre introduit le Cadre de Capacité d’Architecture.
TOGAF9, Partie VII : Cadre de Capacité d’Architecture fournit unensemble d’informations décrivant comment créer cette fonction.
Un résumé du contenu de TOGAF 9 Partie VII est indiqué dans le Tableau
16. La structure globale d’un Cadre de Capacité d’Architecture est illustrée
sur la figure 23.
Tableau 16 : Résumé du Contenu de la Partie VII de TOGAF 9
Chapitre Description
Créer une Capacité
d’Architecture
Recommandations pour créer une Capacité d’Architecture
au sein d’une organisation
Comité
d’Architecture
Recommandations pour la création et le fonctionnement
d’un Comité d’Architecture d’entreprise
Conformité de
l’Architecture
Recommandations permettant de garantir la conformité
d’un projet avec l’Architecture
Contrats
d’Architecture
Recommandations pour la définition et l’utilisation de
Contrats d’Architecture
Gouvernance de
l’Architecture
Cadre conceptuel et recommandations pour la gouvernance
de l’Architecture
Modèles de Maturité
de l’Architecture
Techniques permettant d’évaluer et de quantifier la maturité
d’une organisation du point de vue de l’architecture
d’entreprise.
Cadre de
compétences
d’Architecture
Ensemble de normes relatives aux rôles, aux compétences
et à l’expérience des personnels réalisant les travaux
d’architecture d’entreprise.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 151/177
150 TOGAF™ Version 9 – Guide de Poche
F i g u r e 2 3 : C a d r e d e C a p a c
i t é d ’ A r c h i t e c t u r e
C a p a c i t é d u
B u s i n e s s p o u r l ' A r c h i t e c t u r e
( O p é r a n t à u n n i v e a u d o n n é d e m a t u r i t é )
D i r i g e n t
F i x a n t d e s p r i o r i t é s e t
l e s p o i n t s f o c a u x
M e s u r e d e
l a r é u s s i t e
R é s e r v e d e C o m p é t e n c e s
E x i g e
E x i g e
A f f e c t é s
P o s s è d e n t
P o s s è d e n t
A m é l i o r e
A m
é l i o r e
F o r m a t i o n
C o m p é t e n c e s
C o n n a i s s
a n c e s
P r o f e s s i o n n e l s d e
l ' a r c h i t e c t u r e
R ô l e s
e t
r e s p o n s a
b i l i t é s
( A l a f
o i s
g é n é r i q u e s
e t s p é c i f
i q u e s
à u n p r
o j e t
p a r t i c u
l i e r )
P e u p l a n t l e
r é f é r e n t i e l
G o u v e r n
a n c e d e s
p r o j e t s / p o r t e f e u i l l e s
P r o j e t s / p
o r t e f e u i l l e s
L i v r a n t d e s s o l u t i o n s a l i g n é e s
F i x a n t l e s p r i o r i t é s
e t l e s p o i n t s f o c a u x
P r o j e t s /
p o r t e f e u i l l e s
g o u v e r n é s e u
é g a r d à l e u r s
c o n t r a t s
R é u t i l i s a n t d e s B u i l d i n g
B l o c k s e t r e s p e c t a n t
l e s s t a n d a r d s
C o n
t r a t
P a r t i c i p e n t à P a r t i c i p e n t à
O p é
r a t i o n s
b u s i n e s s
R
é f é r e n t i e l d ' A r c h i t e c t u r e
I n s t a n c e s d e g o u v e r n a n c e
C o n t i n u u m d
' E n t r e p r i s e ( u t i l i s
é p o u r c l a s s e r l e s e n t r a n t s e t l e
s s o r t a n t s d u R é f é r e n t i e l )
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 152/177
151TOGAF™ Version 9 – Guide de Poche
8.1 Créer une Capacité d’ArchitectureLa mise en œuvre de toute capacité au sein d’une organisation nécessite
de concevoir les architectures des quatre domaines : Business, Données, Applications et Technique. L’établissement de la pratique de l’architecture
au sein d’une organisation nécessite donc la conception de :
• l’Architecture du Business, qui met au premier plan la gouvernance
d’architecture, les processus de l’architecture, la structure
organisationnelle de l’architecture, les besoins en informations de
l’architecture, les livrables de l’architecture, etc.• l’Architecture des Données, qui dénit la structure du Continuum
d’Entreprise et du Référentiel d’Architecture de l’organisation,
• l’Architecture des Applications, qui spécie la fonctionnalité et/ou les
services applicatifs nécessaires à la mise en pratique de l’architecture,
• l’Architecture Technique, qui spécie les exigences en ce qui concerne les
infrastructures.
8.2 La Gouvernance de l’ArchitectureLe Cadre de Capacité d’Architecture contient un cadre conceptuel et des
recommandations utiles à la gouvernance de l’architecture. La gouvernance
de l’architecture est la pratique consistant à gérer et contrôler des
architectures d’entreprise et d’autres architectures au niveau de l’ensemblede l’entreprise. Elle comprend :
• La mise en œuvre d’un système qui pilote la création et le suivi de tous
les composants et de toutes les activités d’architecture, pour garantir
l’introduction effective, la réalisation et l’évolution des architectures au
sein de l’organisation,
• La mise en œuvre d’un système garantissant le respect des standards etobligations réglementaires internes et externes,
• L’établissement de processus qui favorisent la gestion efcace des
processus mentionnés ci-dessus dans le respect des paramètres
contractuels,
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 153/177
152 TOGAF™ Version 9 – Guide de Poche
• L’établissement et la documentation de structures décisionnelles qui
ont une influence sur l’architecture d’entreprise ; cela inclut les acteurs
intervenant lors des prises de décision,• Le développement de pratiques qui font en sorte que des comptes soient
rendus à une communauté bien définie d’acteurs concernés, tant à
l’intérieur qu’à l’extérieur de l’organisation.
8.3 Le Comité d’Architecture
Une architecture d’entreprise est plus qu’une simple collection d’élémentsd’architecture produits lors de l’application du processus ADM. Un cadre
de décision bien défini est nécessaire pour que l’organisation se comporte
en accord avec les principes énoncés dans l’architecture. Le Cadre de
Capacité d’Architecture propose un ensemble de recommandations pour
établir et mettre en œuvre le Comité d’Architecture d’une entreprise. Le
Comité d’Architecture est responsable des aspects opérationnels et doitêtre en mesure de prendre des décisions dans des situations pouvant être
conflictuelles et doit être responsable de cette prise de décision. Il devra
donc être représentatif de l’ensemble des acteurs clés de l’architecture, et
comprendra typiquement un groupe de dirigeants chargés de l’analyse et
de la maintenance de l’architecture à un niveau global. Il est important que
les membres du Comité d’Architecture s’intéressent aux domaines de lagestion de l’architecture, du business et des programmes.
Le Comité d’Architecture sera responsable de :
• La cohérence des diverses sous-architectures,
• L’identication de composants réutilisables,
• La souplesse de l’architecture d’entreprise lui permettant de répondreaux besoins du business et d’exploiter de nouvelles technologies,
• La mise en application de la conformité de l’architecture,
• L’amélioration du niveau de maturité de la discipline architecturale au
sein de l’organisation,
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 154/177
153TOGAF™ Version 9 – Guide de Poche
• L’adoption de la discipline consistant à effectuer les développements à
base d’architecture,
• La fourniture d’une référence pour la prise de décisions concernant lesmodifications de l’architecture,
• Met en place une capacité véritable d’escalade sur les décisions
douteuses.
Le Comité d’Architecture est également responsable des aspects
opérationnels tels que le suivi et le contrôle des Contrats d’Architecture(Section 3.29), des aspects concernant la gouvernance, comme le fait de
produire des informations utilisables pour la gouvernance.
Les tâches importantes à réaliser sont:
• D’attribuer les tâches d’architecture,
• D’approuver formellement les livrables de l’architecture,
• De résoudre les conits architecturaux.
8.4 Conformité de l’ArchitectureL’utilisation de l’architecture pour structurer un développement
informatique dans une organisation implique que les projets informatiques
respectent la feuille de route de l’architecture. Si cela n’est pas le cas, il faut
alors pouvoir l’expliquer.
Pour déterminer si cela est le cas, on doit adopter une stratégie
de Conformité de l’Architecture faisant appel à des mesures
spécifiques garantissant la conformité avec l’architecture. Le Cadre
de Capacité d’Architecture comprend un ensemble de processus et de
recommandations, ainsi qu’une check-list permettant de vérifier que leprojet est bien conforme à l’architecture, cela comprenant :
• Des Evaluations des Impacts du Projet, qui illustrent l’impact de
l’architecture d’entreprise sur les principaux projets développés au sein
d’une organisation,
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 155/177
154 TOGAF™ Version 9 – Guide de Poche
• Le processus d’Analyse de Conformité de l’Architecture (gure 24), qui
est un processus formel permettant d’analyser la conformité des projets
avec l’architecture d’entreprise.
8.5 Le Cadre des Compétences en ArchitectureLe Cadre de Capacité d’Architecture propose un ensemble de normes
concernant les rôles, les compétences et les expériences des personnels
entreprenant des travaux d’architecture d’entreprise.
Les termes “Architecture d’Entreprise” et “Architecte d’Entreprise” sont
aujourd’hui largement répandus mais leur définition n’est pas très claire
dans l’industrie de l’informatique. Ils servent à désigner diverses pratiques
et compétences s’appliquant dans une grande variété de domaines
architecturaux. Une meilleure classification de ces termes serait souhaitable
et permettrait une compréhension plus implicite du type d’architecte/architecture que l’on décrit.
Ce manque d’uniformité pose des problèmes aux organisations qui
souhaitent recruter ou affecter/promouvoir son personnel à des postes
d’architecture. En raison des différentes acceptions de ces termes, on se
heurte souvent à un défaut de compréhension et de communication entre
ceux qui cherchent à recruter et ceux qui souhaitent se faire embaucher surces divers postes d’architecte.
Le Cadre de Compétence d’Architecture de TOGAF a pour but de
répondre à ce besoin en proposant des définitions des compétences
d’architecture et des niveaux de qualification demandés aux personnels,
tant internes qu’externes, qui vont jouer les divers rôles d’architecture
définis dans le contexte de TOGAF.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 156/177
155TOGAF™ Version 9 – Guide de Poche
D e m a n d e
d ' a n a l y s e d e
l ' A r c h i t e c t u r e
( c o m m e l ' i m p o s e n t
l e s r è g l e s e t l e s
p r o c é d u r e s d u
C o m i t é d e
G o u v e r n a n c e d e
l ' I n f o r m a t i q u e /
A r c h i t e c t u r e )
R a p p o r t / R é s u m é
d ' E v a l u a t i o n
I d e n t i f i e r
' O r g a n i s a t i o n
R e s p o n s a b l e
I d e n t i f i e r
l ' A r c h i t e c t e
e n C h e f
D é
t e r m i n e r
l e P é r i m è t r e
d e
l ' A n a l y s e
( D é c o u v e r t e )
C o n t e x
t u a l i s e r
l e s C h e c k - l i s t s
P l a n i f i e r
l e s
R é u n i o n s
d ' A n a l y s e d e
l ' A r c h i t e c
t u r e
C o o r d i n a t e u r d e
l ' A n a l y s e d e
l ' A r c h i t e c t u r e :
• I d e n t i f i e r l ' u n i t é
m é t i e r r e s p o n s a b l e
• I d e n t i f i e r l e s c h e f s
d e p r o j e t s
C o
o r d i n a t e u r
d e
l ' A n a l y s e d e
l ' A
r c h i t e c t u r e
C o o r d i n a t e u r d e
l ' A n a
l y s e d e
l ' A r c h
i t e c t u r e :
•
I d e n t i f i e r d ' a u t r e s
u n i t é s m é t i e r s
i m p
l i q u é e s
• C o m
p r e n d r e e n
q u o
i l e s y s t è m e s ' a d a p t e
a u c
o n t e x t e d e l ' e n t r e p r i s e
A r c h i t e c t
e e n C h e f :
• D é t e r m
i n e r l e s
q u e s t i o n s à
i n t r o d u
i r e d a n s
l a c h e c k - l i s t
C o o r d i n a t e u
r d e
l ' A n a l y s e d e
l ' A r c h i t e c t u r
e :
• C o l l a b o r e r
p o u r
o r g a n i s e r l e s
R é u n i o n s
A c c e p t e r ,
A n a l y s e r
e t C o n c l u r e
P r é s e n t e r l e s
R é s u l t a t s d e
l ' A n a l y s e
R é
d i g e r u n
R
a p p o r t
d ' A
n a l y s e d e
l ' A r
c h i t e c t u r e
A n a l y
s e r l e s
c h e c k - l i s t s
f i n a l i s é e s
I n t e r r o g a
t i o n
d e s C h e
f s
d e P r o j e t s
C o m i t é
d ' A r c h i t e c t u r e ,
C l i e n t
A r
c h i t e c t e e n C h e f :
• A
u c l i e n t
• A
u C o m i t é d ' A r c h i t e c t u r e
A r c h i t e c t e e n C h e f
A r c h i t e c t
e e n C h e f :
• A n a l y s e
r e u é g a r d
a u x s t a n d a r d s d e
l ' e n t r e p
r i s e
• I d e n t i f i e r e t
r é s o u d r
e l e s
p r o b l è m
e s
• P r o p o s e r d e s
r e c o m m
a n d a t i o n s
A r c h i t e c t e e
n C h e f ,
D i r e c t e u r d e
P r o j e t , C l i e n
t s :
• P r o j e t i n f o r m e l ,
s t a n d a r d s i
n t e r n e s
• L o g i c i e l s s u
r
é t a g è r e s –
i n t e r n e s o u
v i a a p p e l d
' o f f r e
• U t i l i s e r d e s
c h e c k - l i s t s
F i g u r e 2 4 : L e P r o c e s s u s
d ’ A n a l y s e d e C o n f o r m i t é d e l ’ A r c h i t e c t u r e
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 157/177
156 TOGAF™ Version 9 – Guide de Poche
Parmi les catégories de compétences, on peut citer:
• Les compétences génériques, comprenant typiquement l’aptitude à
diriger, le travail en groupe, la sociabilité, etc.• Les compétences et les méthodes du business, comprenant typiquement
des cas d’étude, des processus métiers, des plans stratégiques, ...etc.,
• Les compétences en Architecture d’Entreprise, comprenant typiquement
la modélisation, la conception des Building Blocks, les applications, la
définition des rôles et l’intégration des systèmes, etc.,
• Les compétences en gestion de programmes et de projets, comprenanttypiquement la gestion des modifications de l’entreprise, les méthodes et
les outils de gestion des projets, etc.,
• Les connaissances générales en informatiques, comprenant typiquement
les applications de médiation, la gestion des actifs, la planification de la
migration, les SLA, etc.,
• Les compétences techniques en informatique, comprenant typiquementl’ingénierie des logiciels, la sécurité, l’échange de données, la gestion des
données, etc.,
• L’environnement légal, comprenant typiquement les lois sur la
protection des données, les lois régissant les contrats, le droit des
marchés, la fraude, etc.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 158/177
Annexe A - Résumé de la
Migration A.1 IntroductionCette annexe fournit des informations générales concernant la migration,
c’est-à-dire un résumé des changements apportés par rapport à TOFAG
8.1.1. Il est présupposé que le lecteur est familier avec l’environnementTOGAF 8.1.1.
Chapitre
de TOGAF 9
Evolution par rapport à TOGAF 8.1.1
Partie I : Introduction
1 Introduction
(Introduction)
Mise à jour ; basé sur le Chapitre 1.
Ce chapitre mis à jour décrit la structure et fournit unsommaire de l’architecture d’entreprise et les bénéfices
que l’on peut tirer de l’utilisation de TOGAF. Certains
contenus de la version précédente ont été déplacés vers les
nouveaux chapitres 2 et 4.
2 Concepts Clés
(Core Concepts )
Nouveau chapitre.
Ce nouveau chapitre introduit les concepts clés de
TOGAF ; ce qu’est TOGAF ; qu’est-ce que l’architecturedans le contexte de TOGAF ; quels types d’architectures
sont concernés par TOGAF ; l’ADM. Il introduit des
concepts fondamentaux tels que les livrables, les éléments
d’architecture et les Building Blocks . Il introduit le
Continuum d’Entreprise et le Référentiel d’Architecture.
Il introduit aussi la création et les opérations effectuées
par une Capacité d’Architecture d’Entreprise. Il décritcertains aspects concernant l’utilisation de TOGAF avec
d’autres cadres conceptuels. Il contient également le
Modèle de Catégorisation de Documents TOGAF qui
est utilisé pour structurer la gestion des évolutions de la
spécification elle-même.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 159/177
158 TOGAF™ Version 9 – Guide de Poche
Chapitre
de TOGAF 9
Evolution par rapport à TOGAF 8.1.1
3 Définitions
(Definitions )
Dérivé du Chapitre 36, remanié sous forme de dénitions
et d’abréviations formelles.
Ce chapitre mis à jour contient les termes et les
définitions fondamentales. D’autres définitions et
abréviations complémentaires ont été déplacées vers
d’autres annexes.
4 Notes de mise à
jour (Release Notes )
Nouveau chapitre.
Il s’agit d’un nouveau chapitre contenant des
informations sur cette mise à jour du document.Il contient un aperçu général des nouveautés, des
bénéfices attendus des modifications et un résumé des
correspondances entre les structures des documents
TOFAF 8.1.1 et TOGAF 9 et inversement. Il fournit des
informations sur les conditions d’utilisation de TOGAF
et l’endroit où on peut le télécharger.
Partie II : Méthode de Développement d’Architecture(Architecture Development Method)
5 Introduction
(Introduction)
Mise à jour ; basé sur le Chapitre 3.
Les changements réalisés dans ce chapitre consistent en
un positionnement de l’ADM par rapport au Référentiel
d’Architecture et à la partie III : Recommandations et
Techniques de l’ADM. Le concept de gestion des versions
(versioning ) est introduit à l’aide d’un exemple.6 Phase Préliminaire
(Preliminary
Phase )
Mise à jour ; basé sur le Chapitre 4.
La section Démarche ( Approach) a été considérablement
élargie pour englober la définition de l’entreprise, des
moteurs clés et des éléments de l’organisation, des
exigences du chantier d’architecture, des cadres de
gestion et de leurs relations, ainsi que de la maturité de
l’entreprise.Des Etapes explicites sont maintenant définies, alors qu’il
n’y en avait pas auparavant.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 160/177
159TOGAF™ Version 9 – Guide de Poche
Chapitre
de TOGAF 9
Evolution par rapport à TOGAF 8.1.1
7 Phase A :
Vision de
l’Architecture
(Phase A:
Architecture Vision)
Mise à jour ; basé sur le Chapitre 5.
Les Scénarios Métiers sont maintenant regroupés sous
la forme d’une section distincte appelée Démarche
( Approach) ; ils faisaient auparavant partie d’une sous-
section de Etapes (Steps ).
Les Etapes ont été revues et comprennent maintenant
une évaluation des Capacités du Business, de l’état de
préparation à une Transformation du Business, une
définition de Propositions de Valeurs de l’Architecturecible et des KPI, et une identification des Risques
de Transformation pour le Business et des activités
d’Atténuation des Risques.
Dans TOGAF 9, les Entrants et les Sortants sont
réorganisés de façon à correspondre aux livrables.
8 Phase B :
Architecture duBusiness
Mise à jour ; basé sur le Chapitre 6.
La section Démarche ( Approach) a été revue de façonà évoquer le Référentiel d’Architecture plutôt que le
Continuum d’Entreprise. La description de la technique
d’Analyse des Ecarts se trouve maintenant dans la partie
III : Recommandations et Technique de l’ADM (Part III
: ADM Guidelines and Techniques ).
Une séquence d’étapes mise à jour a été introduite.
Cette même séquence d’étapes est également utiliséedans les Phases C et D. Les Entrants et les Sortants ont
été réorganisés de façon à correspondre aux livrables de
TOFAF 9. Une différence essentielle est l’introduction
de deux documents maîtres: le Document de Définition
de l’Architecture et la Spécification des Exigences de
l’Architecture.
9 Phase C : Architecture
des Systèmes
d’Information
Mise à jour ; basé sur le Chapitre 8.Les Entrants et les Sortants sont réorganisés de façon à
correspondre aux livrables de TOGAF 9.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 161/177
160 TOGAF™ Version 9 – Guide de Poche
Chapitre
de TOGAF 9
Evolution par rapport à TOGAF 8.1.1
10 Phase C :
Architecture des
Données
(Phase C: Data
Architecture )
Mise à jour ; basé sur le Chapitre 8.
Dans la section Démarche ( Approach) : la référence au
Continuum d’Entreprise est remplacée par le Référentiel
d’Architecture. La section portant sur l’Analyse des
Ecarts a été supprimée. Une section portant sur les
Considérations Clés de l’Architecture des Données a
été ajoutée. Une séquence d’étapes mise à jour a été
introduite. Cette même séquence est également utilisée
lors des Phases B, C (Architecture des Applications) et D.Les Entrants et les Sortants sont réorganisés de façon à
correspondre aux livrables de TOGAF 9.
11 Phase C :
Architecture des
Applications
(Phase C:
Application Architecture )
Mise à jour ; basé sur le Chapitre 9.
Dans la section Démarche ( Approach) : la référence au
Continuum d’Entreprise est remplacée par le Référentiel
d’Architecture. La section portant sur l’Analyse des Ecarts
a été supprimée.Une séquence d’étapes mise à jour a été introduite. Cette
même séquence est également utilisée lors des Phases B,
C (Architecture des Données) et D.
Les Entrants et les Sortants sont réorganisés de façon à
correspondre aux livrables de TOGAF 9.
12 Phase D :
ArchitectureTechnique
(Phase D:
Technology
Architecture )
Mise à jour ; basé sur le Chapitre 10.
Dans la section Démarche ( Approach) : la référence auContinuum d’Entreprise est remplacée par le Référentiel
d’Architecture.
Les Etapes ont subi un remaniement majeur et utilisent
maintenant la même séquence que celle des Phase B et C.
Les Entrants et les Sortants sont réorganisés de façon à
correspondre aux livrables de TOGAF 9.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 162/177
161TOGAF™ Version 9 – Guide de Poche
Chapitre
de TOGAF 9
Evolution par rapport à TOGAF 8.1.1
13 Phase E :
Opportunités et
Solutions
(Phase E:
Opportunities &
Solutions )
Mise à jour ; basé sur le Chapitre 11.
Cette phase a fait l’objet d’une révision majeure et de
nombreux détails ont été ajoutés aux sections Démarche
( Approach) et Etapes (Steps ) décrivant comment passer
des Architectures Cibles à la réalisation via une série
d’Architectures de Transition.
Les Entrants et les Sortants sont réorganisés de façon à
correspondre aux livrables de TOGAF 9.
14 Phase F :Planification de la
Migration
(Phase F:
Migration
Planning )
Mise à jour ; basé sur le Chapitre 12.Cette phase a fait l’objet d’une révision majeure et de
nombreux détails ont été ajoutés aux sections Démarche
( Approach) et Etapes (Steps ) pour finaliser la Réalisation
et le Plan de Migration des Architectures de Transition
identifiées lors de la Phase E.
Les Entrants et les Sortants sont réorganisés de façon à
correspondre aux livrables de TOGAF 9.15 Phase G :
Gouvernance de la
Mise en œuvre
(Phase G:
Implementation
Governance )
Mise à jour ; basé sur le Chapitre 13.
Les Objectifs ont été remaniés et contiennent des ajouts
qui insistent sur l’aspect gouvernance de la phase.
La section Démarche ( Approach) a été mise à jour de
façon à inclure la Réalisation de la Valeur Métier.
La section Etapes (Steps ) a fait l’objet d’une révision
majeure de façon à inclure une confirmation dupérimètre de déploiement en insistant sur la gestion
du développement, l’identification des compétences et
des ressources de déploiement, le développement d’une
assistance pour le déploiement de solutions, les analyses
de conformité, la mise en œuvre des opérations, et une
analyse post-mise en œuvre.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 163/177
162 TOGAF™ Version 9 – Guide de Poche
Chapitre
de TOGAF 9
Evolution par rapport à TOGAF 8.1.1
16 Phase H : Gestion
du Changement
d’Architecture
(Phase G:
Architecture
Change
Management )
Mise à jour ; basé sur le Chapitre 14.
Les Objectifs ont été redéfinis et comprennent
maintenant la maximisation de la valeur métier.
La section Démarche ( Approach) est étendue pour inclure
en outre le suivi de la gestion du business et des capacités.
La section Steps (Etapes) a fait l’objet d’une révision
majeure et comprend maintenant en outre l’établissement
du processus de réalisation de valeur, le déploiement
d’outils de suivi, la gestion des risques, l’analyse deschangements et le développement d’exigences de
changement devant atteindre des cibles de performance.
17 ADM
Gestion des
Exigences de
l’Architecture
( ADM ArchitectureRequirements
Management )
Aucune modification du contenu ; correspond au
Chapitre 15.
Les Entrants et les Sortants sont réorganisés de façon à
correspondre aux livrables de TOGAF 9.
Partie III : Recommandations et Techniques de l’ADM
(Part III : ADM Guidelines and Techniques)
18 Introduction
(Introduction)
Nouveau Chapitre.
Cette nouvelle partie a été ajoutée comme soutien pour
l’application de l’ADM.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 164/177
163TOGAF™ Version 9 – Guide de Poche
Chapitre
de TOGAF 9
Evolution par rapport à TOGAF 8.1.1
19 Application des
itérations à l’ADM
( Applying Iteration
to the ADM )
Nouveau Chapitre.
Ce chapitre décrit le concept d’itération et illustre des
stratégies qui pourraient être utilisées pour appliquer les
concepts d’itération à l’ADM
20 Application de
l’ADM à différents
Niveaux de
l’Entreprise
( Applying the
ADM at Different
Enterprise Levels )
Nouveau Chapitre.
Ce chapitre décrit diverses façons dont on peut impliquer
l’architecture à différents niveaux de l’entreprise et
comment l’ADM peut y contribuer.
21 L’Architecture de
Sécurité et l’ADM
(Security
Architecture and
the ADM )
Nouveau Chapitre ; dérivé du Livre Blanc sur la Sécurité
(W055).
Ce chapitre décrit des aspects spécifiques de la sécurité
pour chaque phase de l’ADM
22 Utilisation
de TOGAF
pour définir et
gouverner les SOA
(Using TOGAF to
Define & Govern
SOAs )
Nouveau Chapitre.
Ce chapitre décrit comment le style d’architecture SOA
peut être pris en charge par TOGAF.
23 Principes de
l’Architecture
( Architecture
Principles )
Aucune modification du contenu ; correspond au
Chapitre 29.
Il s’agit d’un nouvel exemple de principe de l’Orientation
Service des Principes du Business
24 Gestion des
Acteurs Concernés
(Stakeholder Management )
Nouveau chapitre.
Ce chapitre décrit la technique de gestion des acteurs
concernés, cette discipline étant importante pour lespraticiens de l’architecture.
25 Patterns de
l’architecture
( Architecture
Patterns )
Aucune modification du contenu ; correspond au
chapitre 28.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 165/177
164 TOGAF™ Version 9 – Guide de Poche
Chapitre
de TOGAF 9
Evolution par rapport à TOGAF 8.1.1
26 Scénarios Métiers
(Business Scenarios )
Aucune modification du contenu ; correspond au
chapitre 34.
27 Analyse des Ecarts
(Gap Analysis )
Nouveau chapitre ; dérivé de l’Analyse des Ecarts.
Ce chapitre est introduit pour pouvoir mettre la
technique en regard des phases de l’ADM et par
conséquent, pour éviter la répétition de certains textes.
28 Techniques de
Planification de la
Migration
( Migration
Planning
Techniques )
Nouveau chapitre.
Ce chapitre décrit plusieurs techniques utilisées à l’appui
des phases E et F.
29 Exigences
d’interopérabilité
(Interoperability
Requirements )
Nouveau chapitre.
Ce chapitre fournit des recommandations pour le
développement d’exigences d’interopérabilité.
30 Evaluation
de l’état de
préparation à la
Transformation du
Business
(Business
TransformationReadiness
Assessment )
Nouveau chapitre.
Ce chapitre décrit une technique permettant d’identifier
les problèmes liés aux transformations du business.
31 Gestion du Risque
(Risk Management )
Nouveau chapitre.
Ce chapitre décrit une technique permettant de gérer
les risques au cours d’un projet d’architecture ou de
transformation du business.
32 Planificationen fonction des
capacités
(Capability-Based
Planning )
Nouveau chapitre.Ce chapitre décrit la technique de planification en
fonction des capacités.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 166/177
165TOGAF™ Version 9 – Guide de Poche
Chapitre
de TOGAF 9
Evolution par rapport à TOGAF 8.1.1
Partie IV : Cadre de Contenu d’Architecture
(Architecture Content Framework)
33 Introduction Nouveau chapitre.
Cette nouvelle partie de TOGAF concerne les sortants et
joue le rôle de cadre conceptuel organisant les principaux
livrables de l’architecture.
34 Métamodèle du
Contenu
(Content
Metamode l)
Nouveau chapitre.
Ce chapitre fournit la définition d’un métamodèle de
tous les types de Building Blocks d’une architecture,
montrant la façon dont ils peuvent être décrits et
comment ils sont liés les uns aux autres.
35 Eléments
d’Architecture
( Architectural
Artifacts )
Dérivé du chapitre 31, avec ajout de nouveaux contenus.
Ce chapitre a été mis à jour pour traiter un ensemble de
livrables d’architecture atomiques créés conformément à
l’ADM. Un diagramme illustrant les concepts découlant
de la norme ISO/IEC 32010:2007 a été introduit.Des classes de points de vue sont définis : catalogues,
matrices et diagrammes. De nouveaux points de vue de
l’architecture ont été ajoutés.
36 Livrables de
l’architecture
( Architecture
Deliverables )
Révision du Chapitre 16.
Une révision significative des livrables a été réalisée.
On a introduit une table montrant où sont produits et
consommés les livrables au cours du cycle ADM. L’unedes principales différences consiste en l’introduction de
deux documents conteneurs : le document de Définition
de l’Architecture et la Spécification des Exigences de
l’Architecture.
37 Building Blocks Révision du chapitre 32.
La description du processus de spécification des Building
Blocks lors de l’ADM a été mise à jour de façon à cequ’elle corresponde aux modifications apportées aux
étapes de l’ADM.
La section décrivant les Niveaux de Modélisation (Levels
of Modeling ) a été supprimée.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 167/177
166 TOGAF™ Version 9 – Guide de Poche
Chapitre
de TOGAF 9
Evolution par rapport à TOGAF 8.1.1
Partie V : Continuum d’Entreprise et Outils
(Enterprise Continuum and Tools)
38 Introduction
(Introduction)
Nouveau chapitre.
39 Continuum
d’Entreprise
(Enterprise
Continuum)
Dérivé des chapitres 17 et 18.
L’explication du Continuum d’Entreprise a été remaniée
pour mieux expliquer son but et son contexte, y compris
sa relation avec les référentiels d’entreprise.
La section Architectures des Organisations (Organisation
Architectures ) a été mise à jour en Architectures
Spécifiques à l’Organisation (Organisation-specific
Architectures ) dans le diagramme du Continuum
d’Architecture.
La section Solutions pour l’Organisation (Organisation
Solutions ) a été mise à jour en Solutions spécifiques à
l’Organisation (Organisation-specific Solutions ) dans lediagramme du Continuum des Solutions.
Dans la description du Continuum d’Architecture,
la section Architectures d’Entreprise (Enterprise
Architectures ) a été mise à jour en Architectures
Spécifiques à l’Organisation (Organisation-specific
Architectures ).
Dans la description du Continuum des Solutions, lasection Solutions d’Entreprise (Enterpirse Solutions) a
été mise à jour en Solutions Spécifiques à l’Organisation
(Organisation-specific solutions ).
40 Partitionnement
de l’Architecture
( Architectural
Partitioning )
Nouveau chapitre.
Ce chapitre décrit les diverses caractéristiques
pouvant être utilisées pour classer puis partitionner les
architectures.41 Référentiel de
l’Architecture
( Architecture
Repository )
Nouveau chapitre.
Ce chapitre décrit la façon dont les classifications
abstraites de l’architecture peuvent être appliquées à une
structure du référentiel.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 168/177
167TOGAF™ Version 9 – Guide de Poche
Chapitre
de TOGAF 9
Evolution par rapport à TOGAF 8.1.1
42 Outils pour le
Développement
d’une Architecture
(Tools for
Architecture
Development )
Aucune modification du contenu ; correspond au
chapitre 38.
Une référence au programme de certification TOGAF a
été ajoutée.
Partie VI : Modèles de Référence TOGAF
(TOGAF Reference Models)
43 Socle de
l’Architecture
: Modèle de
Référence
Technique
(Foundation
Architecture :
Technical Reference Model )
Aucune modification du contenu ; correspond aux
chapitres 19 et 20
La Taxinomie Détaillée des plates-formes est maintenant
une section de ce chapitre plutôt que d’être un chapitre
séparé.
44 Modèle de
Référence
d’Infrastructure
d’Information
Intégrée
(IntegratedInformation
Infrastructure
Reference Model )
Aucune modification du contenu ; correspond au
chapitre 22.
Partie VII : Cadre de Capacité d’Architecture
(Architecture Capability Framework)
45 Introduction
(Introduction)
Nouveau chapitre.
46 Etablir une
Capacité
d’Architecture
(Establishing
an Architecture
Capability )
Nouveau chapitre.
Ce chapitre décrit comment utiliser l’ADM pour établir
une pratique d’architecture au sein d’une organisation.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 169/177
168 TOGAF™ Version 9 – Guide de Poche
Chapitre
de TOGAF 9
Evolution par rapport à TOGAF 8.1.1
47 Comité
d’Architecture
( Architecture
Board )
Modifications mineures ; correspond au chapitre 23.
Les modifications ont été limitées à des mises à jour
éditoriales mineures ou à des mises à jour du document
de définition du chantier d’architecture.
48 Conformité de
l’Architecture
( Architecture
Compliance )
Modifications mineures ; correspond au chapitre 24.
La section Évaluations de l’Impact sur les Projets
(Découpage des Projets) (Project Impact Assessment
(Project Slices )) a été supprimée.
49 Contrats
d’Architecture
( Architecture
Contracts )
Modifications mineures ; correspond au chapitre 25.
Des explications ont été ajoutées pour associer
plus étroitement ce chapitre à la Gouvernance de
l’Architecture. Au lieu d’énumérer les contenus de la
Définition du Chantier d’Architecture, on a ajouté une
référence à la définition donnée dans la Partie IV : Cadre
de Contenu d’Architecture.
50 Gouvernance del’Architecture
( Architecture
Governance )
Modications mineures ; correspond au chapitre 26.On a ajouté une référence à l’article de l’ITGI décrivant
la correspondance entre TOGAF et COBIT. La section
Architecture Governance in Practice (Gouvernance
de l’Architecture dans la Pratique) a été légèrement
remaniée.
51 Modèles de
Maturité del’Architecture
( Architecture
Maturity Models )
Modifications mineures ; correspond au chapitre 27.
Des modifications mineures ont été apportées pour faireréférence à la version la plus récente de l’ACMM.
52 Cadre de
Compétences
d’Architecture
( Architecture SkillsFramework )
Quelques modifications superficielles ; correspond au
chapitre 30.
Le terme d’Architecte de l’Informatique a été remplacé
par celui d’Architecte d’Entreprise
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 170/177
169TOGAF™ Version 9 – Guide de Poche
Chapitre
de TOGAF 9
Evolution par rapport à TOGAF 8.1.1
Annexes
A Glossaire de
Définitions
Supplémentaires
(Glossary of
Supplementary
Definitions )
Dérivé du chapitre 36.
Les termes et définitions fournis dans ce chapitre ont été
séparés du glossaire d’origine car ils ne sont pas propres
à TOGAF.
B Abréviations
( Abbreviations )
Dérivé du chapitre 36.
Cette section a été séparée du glossaire original.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 171/177
170 TOGAF™ Version 9 – Guide de Poche
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 172/177
Glossaire Acteur Concerné (Stakeholder)Un individu, une équipe ou une organisation (ou une classe de ceséléments) avec des intérêts ou des inquiétudes (soucis) en relation avec leproduit de l’architecture. Des acteurs concernés jouant des rôles différentsauront des préoccupations différentes.
Architecture ( Architecture)
L’architecture a deux significations selon son contexte d’utilisation :1. Description formalisée d’un système, ou bien, au niveau d’uncomposant, la description détaillée de ce composant permettant sa miseen œuvre,
2. Structure des composants, accompagnées des relations inter composants,des principes & règles de dénition et d’évolution au cours du temps deceux-ci.
Architecture des Applications ( Application Architecture)Description du principal regroupement logique de capacités gérant ce quiest nécessaire au traitement des données et au développement du business.
Architecture Cible (Target Architecture) Description d’un état futur de l’architecture en cours de développementpour une organisation. Il peut y avoir plusieurs états futurs développéssous la forme d’une feuille de route faisant apparaître l’évolution del’architecture vers un état cible.
Architecture du Business (Business Architecture) Stratégie, gouvernance, organisation du business, processus et informationsclés du business, ainsi que les interactions entre ces concepts.
Architecture de Capacités (Capability Architecture)Description très détaillée de la démarche architecturale permettantd’aboutir à une solution particulière ou à un certain aspect d’une solution.
Architecture des Données (Data Architecture)Structure des données physiques et logiques et des ressources de gestion deces données.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 173/177
172 TOGAF™ Version 9 – Guide de Poche
Architecture Initiale (Baseline Architecture) L’architecture (existante ou future) prise comme point de départ pour uncycle de revue ou de redéfinition d’architecture.
Architecture Orientée Services (SOA - Service Oriented Architecture)Type d’architecture adapté à l’orientation service. Il possède lescaractéristiques distinctives suivantes :• Il se fonde sur la conception des services, qui reètent des activités
métiers du monde réel, englobant les processus métiers de l’entreprise(ou interentreprises),
• La représentation des services utilise des descriptions des métiers utiliséescomme contexte (par exemple des processus, des buts, des règles, desinterfaces de services et des composants de services métiers) et met enœuvre des services en orchestrant divers services ;
• Il impose des exigences uniques à l’infrastructure (il est recommandéde faire en sorte que les formes de réalisation utilisent des standardsouverts pour assurer l’interopérabilité et l’indépendance vis à vis du lieu
géographique) ;• Les réalisations dépendent de l’environnement, c’est-à-dire qu’elles sontimposées ou autorisées par le contexte et doivent être décrites dans cecontexte ;
• Il nécessite une bonne gouvernance de la représentation et de la mise enœuvre des services ;
• Il nécessite une “mise à l’épreuve” qui détermine un “service de bonnequalité”.
Architecture des Segments (Segment Architecture)Description détaillée et formelle de domaines d’une entreprise, que l’onutilise au niveau des programmes ou des portefeuilles pour organiser etaligner les activités de changement.
Architecture de Solution (Solution Architecture)
Description d’une opération ou d’une activité délimitée et précise etmanière dont l’informatique et le système d’information soutiennentcette opération. Une solution d’architecture s’applique généralement à unprojet unitaire ou une version de projet (palier de projet), accompagnantla traduction des exigences dans une vision de solution, des spécificationsmacroscopiques (de haut niveau) métiers et /ou informatiques et unportefeuille de tâches de mise en œuvre (d’implémentation).
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 174/177
173TOGAF™ Version 9 – Guide de Poche
Architecture Technique (Technology Architecture) Capacités logicielles et matérielles logiques exigées pour prendre en chargele déploiement de services liés au métier, aux données et aux applications.
Cela comprend l’infrastructure informatique, le middleware, le réseau, lescommunications, les moyens de traitement et les standards.
Architecture de Transition (Transition Architecture)Description formelle de l’architecture d’entreprise faisant apparaître lespériodes de transition et le développement de parties particulières del’entreprise. Les Architectures de Transition sont utilisées pour offrir un
aperçu général des capacités courante et cible et permettre le regroupementde lots de travail et de projets individuels en des portefeuilles etprogrammes gérés.
Building Block d’Architecture (ABB - Architecture Building Block)
1. Sous-ensemble, ou composant de l’architecture,2. Ensemble cohérent de fonctions,
3. Ensemble technique ou fonctionnel représentant un élément réutilisable& combinable avec d’autres ensembles ou sous-ensembles pourcomposer une solution.
Building Block de Solution (SBB - Solution Building Block )Choix possible d’implémentation de Building Block d’architecture, parexemple un package “ sur étagère ” ou un composant spécifique réutiliséou développé à façon.
Cadre d’Architecture ( Architecture Framework )Structure ou ensemble de structures fondamentales qui peuvent être utilisées
pour développer une large gamme d’architectures différentes. Elle devra
contenir une méthode permettant de concevoir un système d’information
sous la forme d’un jeu de Building Blocks et d’indiquer comment les
Building Blocks s’emboîtent les uns dans les autres. Elle devra contenir un
ensemble d’outils et proposer un vocabulaire commun. Elle devra égalementcomprendre une liste de standards recommandés et de produits conformes
pouvant être utilisés pour mettre en œuvre les Building Blocks .
Cadre Conceptuel (Framework )Structure pour un contenu ou un processus qui peut être utilisée commeoutil afin de structurer la pensée, assurant ainsi la cohérence et la
complétude.Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 175/177
174 TOGAF™ Version 9 – Guide de Poche
Capacité (Capability) Possibilité offerte par une organisation, une personne ou un système. Lescapacités sont exprimées en termes généraux, en utilisant des concepts
d’un haut niveau d’abstraction. Elle nécessite pour sa mise en œuvreune combinaison d’organisations, de personnes, de processus & detechnologies. On peut par exemple citer le marketing, les contacts clientèleet le télémarketing sortant.
Continuum d’Architecture ( Architecture Continuum)Partie du Continuum d’Entreprise. Il s’agit d’un référentiel d’éléments
architecturaux ayant un niveau croissant de détail et de spécialisation. CeContinuum commence par des définitions fondamentales telles que lesmodèles de référence, les principales stratégies et les Building Blocks de base.Il se prolonge ensuite aux Architectures Industrielles en passant par toutesles étapes allant jusqu’à une architecture spécifique d’une organisation.
Continuum d’Entreprise (Enterprise Continuum)
Mécanisme de catégorisation permettant de classer des élémentsd’architecture et de solutions, qui sont à la fois intérieurs et extérieurs auRéférentiel d’Architecture lorsqu’ils passent des Socles d’ArchitecturesGénériques à des Architectures Spécifiques d’une Organisation.
Continuum des Solutions (Solutions Continuum)Partie du Continuum d’Entreprise. Référentiel de solutions qui pourrontêtre réutilisées lors des futures étapes de mise en œuvre. Elle contient desformes de réalisation des définitions correspondantes présentes dans leContinuum d’Architecture.
Écart (Gap) Constat de la différence entre deux états. Utilisé dans le contexte de“l’analyse des écarts” où est identié la différence entre le “Ce qui existe” et“Ce que l’on doit architecturer”.
Entreprise (Enterprise)Typiquement le plus haut niveau de description d’une organisation quicouvre toutes les missions et les fonctions. Une entreprise sera souventrépartie en plusieurs organisations.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 176/177
175TOGAF™ Version 9 – Guide de Poche
Exigence (Requirement) Description d’un besoin d’entreprise qui doit être satisfait par unearchitecture ou un lot de travail particulier.
Gestion des Risques (Risk Management) Gestion des risques et problèmes qui peuvent menacer le succès de lapratique d’architecture d’entreprise et sa capacité à répondre à la vision,buts et objectifs, et, ce qui est important, la fourniture du service.
Gouvernance (Governance)
Discipline consistant à suivre, gérer et orienter un business (ou un paysagede Systèmes d’Information/Informatiques) pour délivrer le résultat métiervoulu.
Incrémentation de Capacité (Capability Increment)
Le sortant issu d’une initiative de modification du business qui a amené àun accroissement de performance pour une capacité donnée de l’entreprise.
Lot de Travail (Work Package) Ensemble d’actions identifiées pour atteindre un ou plusieurs objectifsdu business. Un lot de travail peut faire partie d’un projet, être un projetcomplet ou être un programme.
Métamodèle (Metamodel)Modèle qui décrit comment et avec quoi l’architecture sera décrite de façonstructurée.
Méthode de Développement d’Architecture (ADM - ArchitectureDevelopment Method )Il s’agit du cœur de TOGAF, démarche pas à pas permettant de développeret d’utiliser une architecture d’entreprise.
Modèle de Référence Technique (TRM - Technical Reference Model )Structure qui permet de décrire les composants d’un système d’informationde manière cohérente.
Orientation Service (Service Orientation)Mode de pensée en termes de services et de développements à base deservices et services rendus.
Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
7/25/2019 TOGAF Version 9_ Guide de Poche
http://slidepdf.com/reader/full/togaf-version-9-guide-de-poche 177/177
176 TOGAF™ Version 9 – Guide de Poche
Point de vue (Viewpoint) Définition de la perspective depuis la quelle une vue est prise. C’estla spécification d’une convention pour la construction et l’utilisation
d’une vue. Une vue est “ ce que vous voyez ” ; un point de vue est “ d’oùregardez-vous” ; le point culminant ou la perspective qui détermine ce quevous voyez.
Référentiel (Repository) Système qui gère toutes les données d’une entreprise, ce qui inclut lesmodèles de données et de processus et d’autres informations d’entreprise.
Ainsi, les données dans un répertoire sont plus larges (étendues) que cellesd’un dictionnaire de données, qui généralement définit uniquement lesdonnées formant une base de données.
Socle d’Architecture (Foundation Architecture) Architecture de services et fonctions génériques qui fournissent lesfondations sur lesquelles une architecture spécifique ainsi que des