TOGAF+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

TOGAFTM VERSION 9 - GUIDE DE POCHE


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.


TOGAF™ Version 9G U I D E D E P O C H E


Titre : TOGAF™ Version 9 – Guide de PochePublié par : The Open GroupAuteurs: 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, Real IRM

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 conception de 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 sous quelque forme ou par quelque moyen (électronique, mécanique, photocopie, enregistrement ou autres) que ce soit tout ou partie du présent document (édition originale en anglais) sans autorisation 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 TOGAF 9 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 site www.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 RoadReadingBerkshire, RG1 1LXRoyaume Uni

ou par courrier électronique à : [email protected] protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

PréfaceA 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 :

• LeChapitre1fournituneprésentationgénéraledeTOGAF,de

l’architecture d’entreprise, du contenu et des concepts fondamentaux de

TOGAF.

• LeChapitre2présentelaMéthodedeDéveloppementd’Architecture

(ADM—Architecture Development Method). TOGAF utilise cette

méthode pour développer des architectures d’entreprise.

• LeChapitre3fournitunaperçugénéraldestechniquesclésetdes

livrables du cycle ADM.

• LeChapitre4fournitunaperçugénéraldesrecommandationsàsuivre

pour adapter l’ADM.

• LeChapitre5introduitlanotiondeCadredeContenud’Architecture,

métamodèle structuré des éléments d’une architecture.

• LeChapitre6présenteleContinuumd’Entreprise,conceptde

haut niveau pouvant être utilisé avec l’ADM pour développer une

architecture d’entreprise.

• LeChapitre7présentelesmodèlesderéférenceTOGAF,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).

• LeChapitre8introduitleCadredeCapacité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’AnnexeAdécritdefaçongénéralelesdifférencesentreTOGAF9et

TOGAF 8.1.1.


6 TOGAF™ Version 9 – Guide de Poche

Ce document intéressera :

• Lesarchitectesd’entreprise,lesarchitectesmétiers,lesarchitectesdes

systèmes d’information, les architectes des données, les architectes

systè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 :

• Uneplusgrandesouplessed’utilisation—unbutbienprécispour

chaque domaine ; une utilisation isolée sous la forme d’un jeu autonome

de recommandations.

• UneadoptionincrémentielledelaspécificationTOGAF.

Cadre de Contenu : TOGAF 9 comprend un cadre de contenu améliorant

la cohérence des divers sortants créés lors de l’application de la Méthode

1 TheOpenGroupArchitectureFramework(TOGAF),Version9EnterpriseEdition(ISBN:

978-90-8753-094-5,G091v);consulterwww.opengroup.org/bookstore/catalog/g091v.htm.


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 :

• LePartitionnement(Partioning) : On décrit différentes techniques

permettant de partitionner les diverses architectures d’une entreprise.

• LeRéférentield’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.

• LeCadredeCapacité(Capability Framework) : définition plus structurée

de 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 :

• Lesdiversesfaçonsd’itérerdanslaméthodeADMetlesmomentsoùil

convient d’appliquer chaque technique

• Lesliensentrel’ADMTOGAFetl’ArchitectureOrientéeService

(SOA—Service Oriented Architecture)

• Lesinformationsspécifiquespermettantdemettreenœuvre

l’architecture de sécurité au sein de l’ADM



• Lesdiverstypesdedéveloppementsd’architecturesexigésdansune

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 :

• Lefaitquelaphasepréliminaireoffreuneassistanceétendueàla

création d’un cadre d’architecture d’entreprise et à la planification du

développement d’une architecture.

• LesphasesOpportunités&SolutionsetPlanificationdelaMigration

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 :

• Pointsdesuspension(…)

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.

• Politiquesurlesacronymes

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



TOGAF -> Le Cadre d’Architecture de l’Open Groupe (TOGAF - The

Open Group Architecture Framework).

• Politiquesurlesexpressionsconcepts

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 plusieurs

sens 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 et

de 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



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’adoption

par 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éesBoundaryless Information Flow™ et TOGAF™ sont des marques

dé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ées

par leurs propriétaires respectifs.


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 21

1.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 25

1.5.5 Les Modèles de référence TOGAF 25

1.5.6 LeCadredeCapacité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? 28

2.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 41

2.3.6 PhaseE:OpportunitésetSolutions 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


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 59

3.3 Les Principes de l’Architecture 59

3.3.1 DévelopperdesPrincipesdel’Architecture 60

3.3.2 DéfinirlesPrincipesdel’Architecture 60

3.3.3 QualitésdesPrincipes 63

3.3.4 Applicationdesprincipesdel’architecture 63

3.4 Les Principes du business, buts du business et moteurs

dubusiness 65

3.5 LeRéférentield’Architecture 66

3.6 LesOutilsd’Architecture 66

3.7 LaDemandedeMiseenChantierd’Architecture 66

3.8 LaDéfinitionduChantierd’Architecture 67

3.9 LaVisiondel’Architecture 68

3.10 LaGestiondesActeursConcerné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 74

3.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 LaSpécificationdesExigencesd’Architecture 80

3.16.1 LesExigencesdel’ArchitectureduBusiness 81

3.16.2 LesExigencesdesArchitecturesdes

Systèmes d’Information 82

3.16.3 LesExigencesdel’ArchitectureTechnique 82

3.16.4 LesExigencesd’Interopérabilité 83



3.17 La Feuille de route de l’Architecture 83

3.18 Les Scénarios Métiers 84

3.19 L’Analyse des Écarts 85

3.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 92

3.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 95

3.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 LePlandeMiseenœuvreetdeMigration 98

3.27 L’Architecture de Transition 99

3.28 Le Modèle de Gouvernance de la Mise en œuvre 101

3.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 107

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


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 125

5.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çugénéralduContinuumd’Entreprise 137

6.1.1 LeContinuumd’EntrepriseetlaRéutilisation

d’Architectures 139

6.1.2 UtilisationduContinuumd’Entreprisedansl’ADM 139

6.2 LePartitionnementdel’Architecture 140

6.3 LeRéférentield’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’Informations

Inté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 152

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


A propos des auteursAndrew 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 grand

nombre 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 titulaire

d’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 TOGAF

et 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).



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

architecture 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ès

avoir é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’informatique

agréé 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 études

d’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,



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 de

changements 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 cycle

dans le département d’informatique de l’université de Pretoria.



RemerciementsL’Open Group souhaite remercier :

• Lesanciensetnouveauxmembresdel’ArchitectureForumdel’Open

Group qui ont développé TOGAF (The Open Group Architecture

Framework),

• CapgeminietSAPpourleursdiversescontributions,

• Lesrelecteursdecedocument:

– 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 :

• ARISMOREetIBMpourleurparticipationactiveàlatraductiondes

concepts clés et à la relecture du document traduit,

• PeterGolépourlatraductiondel’anglaisverslefrançais,

• Lesrelecteursdudocumenttraduit:

– Alain Carasso

– Bernard Henri Le Goff

– Sylvain Licheron

– François Maître

– Jean-Christophe Mestres

– Renaud Phélizon


Chapitre 1Présentation de TOGAFTM

Ce chapitre présente TOGAF 9.

Les sujets abordés sont :

• PrésentationdeTOGAF

• TOGAF,sastructureetsoncontenu

• Lestypesd’architecturestraitésparTOGAF

1.1 Présentation de TOGAF 9 TOGAF 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èle

de 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 Information

Management) 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



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 plus

pré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 TOGAFLe document TOGAF 9 se décompose en sept parties résumées dans le

tableau 1 ci-après.

Tableau1:StructuredudocumentTOGAF

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 notes

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



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 les

composants, 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/IEC42010:2007,SystemsandSoftwareEngineering–RecommendedPractice

forArchitecturalDescriptionofSoftware-IntensiveSystems,Edition1(techniquement

identiqueàlanormeANSI/IEEEStd1471-2000).



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

mé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 la

partie VI de TOGAF 9).

Tableau2:Typesd’ArchitecturesprisenchargeparTOGAF

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.

Architecture

Technique

Capacités des logiciels et des matériels nécessaires au

dé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 Certainsorganismesdésignentl’Architecturedesdonnéessouslenomd’Architecture

d’informations



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 & Cadrede 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 les Capacité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

Figure1:SynoptiqueducontenudeTOGAF



• Elleproposeuncertainnombredephases d’un cycle de

développement d’architecture (Architecture du Business, Architectures

des Systèmes d’Information, Architecture Technique), sous la forme

d’un modèle de processus global destiné à l’activité de développement

d’architectures.

• Ellefournitundescriptif 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 description

détaillée des entrants de phase et des sortants de phase est fournie dans

le Cadre de Contenu d’Architecture).

• Ellefournitdesrécapitulatifsdel’ensembledesphasescouvrantla

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 par

exemple 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



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’Entreprise Le 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 la

faç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.

LeContinuumd’EntrepriseestdétailléplusavantauChapitre6.

1.5.5 Les Modèles de référence TOGAF TOGAF 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 - Integrated

Information 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, de

recommandations, 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.




Chapitre 2La 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 phase

de l’ADM.

Les sujets abordés dans ce chapitre comprennent :

• Uneprésentationdel’ADM

• Lesphasesdel’ADM

• Lesobjectifs,étapes,entrantsetsortantsdesphasesdel’ADM

• LagestiondesexigencespendantlecycleADM

• Ladéfinitiondupérimètredel’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’élaborer

des architectures d’entreprise propres à chaque organisation. Elle est

spécifiquement conçue pour répondre aux exigences de l’entreprise.

L’ADM décrit :

• Unedémarchefiableetéprouvéepermettantdedévelopperetd’utiliser

une architecture d’entreprise

• Uneméthodededéveloppementd’architecturesàdesniveauxdifférents4

(business, applications, données, technique) qui permettent à l’architecte

de bien prendre en compte un jeu complexe d’exigences.

• Desrecommandationsconcernantlesoutilsutilisésdansle

développement d’une architecture

4 DansTOGAFonlesdésignesouslenomd’ensemblededomainesdel’architecture



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.

Figure2:CycledelaMéthodedeDéveloppementd’Architecture

Gestion des Exigences

Phase préliminaire

A.Vision de

l'Architecture

E.Opportunités et Solutions

F. Planification

de la migration

G.Gouvernance de

la Mise en Œuvre

H.Gestion du

Changement d'Architecture

B.Architecture du Business

C.Architecture des Systèmes d'Information

D.Architectures

Techniques



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 exigences

initiales, 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 entre

phases (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 la

partie III de TOGAF 9 : Recommandations et Techniques de l’ADM

(Chapitre 4).

Tableau3:Lesactivitésdel’ADMphaseparphase

Phase ADM Activité

Phase préliminaire Préparer l’organisation pour la réussite des projets

d’architecture TOGAF. Entreprendre les activités de

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



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èmesd’Information(ApplicationsetDonné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 de

l’architecture pour le métier.



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 Lesnumérosdeversioncorrespondantàdeslivrablesparticuliersontétéomisdece

GuidedePochecarTOGAFdéfinitlemodedenumérotationADMàseuletitred’exemple,

celui-cidevantêtreadaptéselonlescirconstances.

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



2.3.2 Phase A : Vision de l’Architecture La Phase A concerne l’établissement d’un projet et déclenche une itération

du 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’architecture

Dé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’architecture

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


Cadre d’Architecture

Personnalisé, y compris les

principes d’architecture

Ré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 en

Chantier de l’Architecture

Cadre de gouvernance



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 contraintes

Cré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éveloppement

parallè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 business

Dé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 Cible

Identifier 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



2.3.3 Phase B : Architecture du Business La 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



Cadre d’Architecture Contextualisé, y

compris les principes d’architecture

Référentiel d’Architecture Peuplé ;

ou documentation de l’architecture

existante (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




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 en

compte 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


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 de

l’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



Entrants Sortants


l’Architecture

Principes du business, buts du

business et moteurs du business

Évaluation des Capacités





Approbation du Chantier

d’Architecture

Principes d’Architecture, y compris

les principes du business, lorsqu’ils

préexistent

Continuum d’Entreprise


Vision de l’Architecture, y compris :

– Les exigences clés des acteurs

concernés précisées à haut niveau


(vision)


(vision)

– Architecture Initiale des

Applications (vision)


(vision)


(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 :


(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 exigences

l’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



2.3.4 Phase C : Architectures des Systèmes d’Information

La phase C documente l’organisation fondamentale des systèmes

informatiques 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’ArchitecturedesDonnées

• l’ArchitecturedesApplications

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 le

business

Sélectionner des modèles, des points de

vue et des outils de Référence

Développer une Description Initiale de

l’Architecture des Données


l’Architecture Cible du Business


Définir les composants de la feuille de

route

Résoudre les impacts sur tout le paysage

de l’Architecture

Passer en revue de façon formelle les

acteurs concernés

Finaliser l’Architecture des données


l’Architecture



Entrants Sortants


l’Architecture






Principes concernant les données

Définition du Chantier d’Architecture

Vision de l’Architecture



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


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 :


– 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



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



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


route

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


l’Architecture



Entrants Sortants


l’Architecture






Principes des applications







(détaillée)

– Architecture cible du Business

(détaillée)



– Architecture Cible des données



(vision)


(vision)


(vision)

– Architecture Technique Cible

(vision)


de l’Architecture, y compris :

– Résultats d’analyse des écarts


Composants des Architectures du

Business et des Données dans une

Feuille de route d’Architecture



Principes d’application validés, ou

nouveaux principes d’application



jour du contenu :



– Vues de l’Architecture des Applications


sélectionnés, prenant en compte les






– Exigences d’interopérabilité des

applications


devant s’appliquer à cette évolution

du cycle de développement de

l’architecture

– Contraintes imposées à l’Architecture

Technique

– 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



2.3.5 Phase D : Architecture Technique La phase D consiste à documenter l’organisation fondamentale des

systèmes informatiques, à savoir les matériels, les logiciels et les techniques

de 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 qui

s’ensuivront




l’Architecture Technique Initiale


l’Architecture Technique Cible



route

Résoudre les impacts sur tout le Paysage

de l’Architecture

Effectuer un passage en revue formel des

acteurs concernés

Finaliser l’Architecture Technique


l’Architecture



Entrants Sortants


l’Architecture






Principes techniques







(détaillée)


(détaillée)


(détaillée)

– Architecture Cible des données

(détaillée)


(détaillée)


(détaillée)


(vision)

– Architecture Technique Cible

(vision)


de l’Architecture, y compris :



Composants des Architectures

du Business, des Données et des

applications dans une Feuille de route

d’Architecture



Principes techniques validés ou nouveaux

principes techniques (s’ils sont générés

à ce stade)



jour du contenu :


– Architectures Techniques Cibles

– Vues de l’Architecture Technique


sélectionnés, prenant en compte les





– 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



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, puis

organiser 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 en

permanence 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 business

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



Entrants Sortants

Information sur les Produits


l’Architecture


Méthodologies de Planification


l’Architecture d’entreprise






l’Architecture


de l’Architecture

Demandes de changement de

programmes et de projets existants


éventuellement mise à jour

Vision de l’Architecture, éventuellement

mise à jour


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


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)



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 un

Plan 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’entreprise

Hié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éfinition

de 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 projet

Estimer 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 de

l’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



Entrants Sortants


l’Architecture





Modèles et Cadres de Gouvernance






l’Architecture, y compris :

– le Plan Stratégique de Migration

– l’analyse d’impact - liste et chartes

de projets

Spécification provisoire des exigences

de 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’Architecture

Demandes 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



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 Contrat

d’Architecture signé.

Objectifs Etapes

Formuler des recommandations sur

chaque projet de mise en œuvre

Gouverner et gérer un Contrat

d’Architecture couvrant l’ensemble

du 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 avec

l’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étences

de déploiement

Guider le développement de solutions de

déploiement

Effectuer des analyses de conformité de


Exécuter des opérations au niveau du

métier et de l’informatique

Effectuer une analyse post-mise en œuvre

et clore la mise en œuvre



Entrants Sortants


l’Architecture



l’Architecture d’entreprise





Document de Définition de

l’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 œuvre

Contrat d’Architecture


l’Architecture identifiés aux phases

E et F


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



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 du

Changement 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



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 Exigences

est 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


l’Architecture identifiés lors des phases

E et F







Document de Définition de

l’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 à des

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


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


éventuellement mise à jour

Contrat d’architecture, éventuellement

mis à jour

Évaluations de Conformité,

éventuellement mises à jour



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, et

comble 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 ADM

Identifier 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 initiales

Identifier 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 exigences

Evaluer 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 la

phase présente

Evaluer et réviser l’analyse des écarts pour

les phases précédentes



2.4 Définition du périmètre de l’Activité d’Architecture

L’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 :

• Auresponsableenchargedel’organisationauseindel’équipe

produisant l’architecture

• Parlesobjectifsetlespréoccupationsformulésparlesacteursconcernés

et qui doivent être pris en compte dans l’architecture

• Parladisponibilitédespersonnes,desfinancementsetautresressources

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


Chaque domaine architectural génère

ensuite des exigences détaillées. Les

livrables des phases ADM ultérieures

ont 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).



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 partitions

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

Tableau4:DimensionssuivantlesquellesondélimitelePérimètredel’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 taille

et 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 un

périmètre d’entreprise inférieur à celui de l’entreprise dans sa

globalité.



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’est

pas le cas, combien d’Architectures Cibles intermédiaires

doivent être définies et sur quelles périodes de temps ?


Documents

TOGAF+9+guide+de+poche