TOGAF Version 9_ Guide de Poche

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



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 9

G U I D E D E P O C H E





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.




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.





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.





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






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






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






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.





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.





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






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.





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





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






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,






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.






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





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






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.






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






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






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






• 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






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.





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






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






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.






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.






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






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


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






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






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



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






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


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






Entrants Sortants


l’Architecture

Principes du business, buts du

business et moteurs du business

Évaluation des Capacités





Approbation du Chantierd’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)

– Architecture Initiale des Données

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






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


l’Architecture Cible du Business


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


l’Architecture






Entrants Sortants


l’Architecture






Principes concernant les données

Définition du Chantier d’Architecture

Vision de l’ArchitectureRéférentiel d’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 :– 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






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

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






Entrants Sortants


l’Architecture






Principes des applications






(détaillée)

– Architecture cible du Business

(détaillée)– Architecture Initiale des Données


– Architecture Cible des données


– Architecture Initiale des Applications

(vision)

– Architecture Cible des Applications(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 :


– Architecture Cible des Applications

– Vues de l’Architecture des Applicationscorrespondant aux points de vue

sélectionnés, prenant en compte les




à jour du contenu :

– Résultats de l’analyse des écarts– Exigences d’interopérabilité des

applications


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






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




l’Architecture Technique InitialeDévelopper une Description de

l’Architecture Technique Cible


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


l’Architecture






Entrants Sortants


l’Architecture






Principes techniques






(détaillée)


(détaillée)– Architecture Initiale des Données

(détaillée)

– Architecture Cible des données

(détaillée)


(détaillée)

– Architecture Cible des Applications(détaillée)


(vision)

– Architecture Technique Cible

(vision)


de l’Architecture, y compris :

– Résultats de l’analyse des écarts


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

correspondant aux points de vue

sélectionnés, prenant en compte les




à 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






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






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






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






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


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






Entrants Sortants


l’Architecture



l’Architecture d’entreprise



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


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






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






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


l’Architecture identifiés lors des phases

E et F







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


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






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


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






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






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 ?





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







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.19, L’Analyse des Écarts

Section 3.20, Les Points de Vue 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.20, Les Points de vue d’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.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.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






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.


F. Planification

de la Migration


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


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






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,






– 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






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.






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


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






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.






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.






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






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






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






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






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






• 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






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






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






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






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






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






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.






• É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






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






• 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),






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






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


d'Information

D.







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






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






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.


d'Information

D.


E.


F.







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






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


d'Information

D.


E.







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






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.


C.


d'Information






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






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.






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.


C.Architecture desSystèmes

d'Information

B.

Architecture

du Business

C.


d'Information

D.


E.







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


d'Information

D.


E.







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.


F.







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.


F.







(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

... ...






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






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

... ... ... ... ...






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)

... ...






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.


F.







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


F.







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






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


F.


G.

Gouvernance

de la Mise

en Œuvre

H.

Gestion duChangement

d'Architecture

G.

Gouvernance

de la Mise

en Œuvre

H.


d'Architecture






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é






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


d'Architecture






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.


d'Architecture






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.


d'Architecture






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





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






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






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.






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


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


F.Planification de

la migration

G.Gouvernance de la

Mise en Œuvre

H.Gestion du


B.Architecturedu Business


D.ArchitectureTechnique






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






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


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






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


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


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


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






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é






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






• 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 ;






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


F. Planification

de la

migration

G.

Gouvernance

de la Mise

en Œuvre

H.Gestion du



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



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



Figure 12 : Exemple de hiérarchie des processus de l’ADMCopyright protected. Use is for Single Users only via a VHP Approved License.





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






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.






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






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.





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à






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.






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.






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






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.






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



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






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.






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






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






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






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






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.





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


D.ArchitecturesTechniques


F.Planification

de lamigration

G.Gouvernance

de la Miseen Œuvre

H.Gestion du



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






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.





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






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






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






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.






• 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



…

Architectures

de l'Industrieet 1, Point de Vue 1



…

Architectures

Spécifiques

de l'Organisationset 1, Point de Vue 1



…

Figure 19 : Résumé d’un Modèle de Classication des Modèles de Référence de l’Architecture






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.





• 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





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.






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






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





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.






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 )






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,






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






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






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






D e m a n d e

d ' a n a l y s e d 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

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






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.





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.






Chapitre

de TOGAF 9


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)


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 )


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.






Chapitre

de TOGAF 9


7 Phase A :

Vision de

l’Architecture

(Phase A:

Architecture Vision)


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


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.






Chapitre

de TOGAF 9


10 Phase C :

Architecture des

Données

(Phase C: Data

Architecture )


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 à


11 Phase C :

Architecture des

Applications

(Phase C:

Application Architecture )


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 à


12 Phase D :

ArchitectureTechnique

(Phase D:

Technology

Architecture )


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.








Chapitre

de TOGAF 9


13 Phase E :

Opportunités et

Solutions

(Phase E:

Opportunities &

Solutions )


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.



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.


correspondre aux livrables de TOGAF 9.15 Phase G :

Gouvernance de la

Mise en œuvre

(Phase G:

Implementation

Governance )


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.






Chapitre

de TOGAF 9


16 Phase H : Gestion

du Changement

d’Architecture

(Phase G:

Architecture

Change

Management )


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.



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.






Chapitre

de TOGAF 9


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 )


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 )


chapitre 28.






Chapitre

de TOGAF 9


26 Scénarios Métiers

(Business Scenarios )


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.






Chapitre

de TOGAF 9


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.






Chapitre

de TOGAF 9


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.






Chapitre

de TOGAF 9


42 Outils pour le

Développement

d’une Architecture

(Tools for

Architecture

Development )


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 )


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.






Chapitre

de TOGAF 9


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 )


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 )


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 )


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






Chapitre

de TOGAF 9


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.





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.






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






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.





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.






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.






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

TOGAF Version 9_ Guide de Poche

Documents

Transcript of TOGAF Version 9_ Guide de Poche