TOGAF

Un cadre darchitecture pour industrialiser les projets

Master Management des Systmes dInformation et de Connaissance UE09 : Pratiques de lentreprise et mthodes danalyse Prsentation de Dominique Le Moul et Eugenio Mauri

TOGAF : Un cadre darchitecture pour industrialiser les projets

Sommaire
1 2 Les grandes lignes .......................................................................................................... 2 LEA et les principaux Framework ............................................................................. 2 2.1 2.2 2.3 2.4 2.5 2.6 3 4 5 Une dfinition de LEA ............................................................................................. 2 Gnalogie des Framework ............................................................................... 3 Le Framework de Zachman ............................................................................... 4 LOpen Group et la mise en place de TOGAF ......................................................... 6 TOGAF9 et ses apports .......................................................................................... 6 Lvolution de lEnterprise Architecture.................................................................... 7

Les grands principes de TOGAF ..................................................................................... 8 Prsentation de la dmarche mthodologique ................................................................ 9 LADM ............................................................................................................................11 5.1 5.2 Principes de lADM .................................................................................................11 Les phases de lADM .............................................................................................12 Phase prliminaire ..........................................................................................12 Phase A: Architecture Vision ...........................................................................13 Phase B: Business Architecture ......................................................................14 Phase C: Information Systems Architectures ..................................................15 Phase D: Technology Architecture ..................................................................16 Phase E: Opportunities & Solutions.................................................................16 Phase F: Migration Planning ...........................................................................17 Phase G: Implementation ................................................................................18 Phase H: Architecture Change Management...................................................19

5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 5.2.6 5.2.7 5.2.8 5.2.9 5.3 5.4

Le Cur de lADM : la gestion des exigences ........................................................20 Cycle de vie et utilisation pratique de lADM ...........................................................20 Mode itratif ....................................................................................................20 Adaptation au contexte de lentreprise ............................................................21

5.4.1 5.4.2 6 7 8 9

ArchiMate language et TOGAF ................................................................................21 Quelques critiques .........................................................................................................22 Pour conclure.................................................................................................................22 Bibliographie ..................................................................................................................23

Document1

Page 1

TOGAF : Un cadre darchitecture pour industrialiser les projets 1 Les grandes lignes
Cette prsentation de TOGAF (The Open Group Architecture Framework) sinscrit dans le cadre de lUE09 de notre Master qui propose daborder une problmatique de SIC. De nombreux cadres, mthodes et outils existent sur le march de lEnterprise Architecture (EA) utilis par les entreprises. Par la mise en place de telles approches, les entreprises mettent en relief un certain nombre de difficults et les surmontent. De nouvelles problmatiques surgissent et restent sans rponse : lemploi de ces approches gnre de nouveaux risques. Nous proposerons dans la suite de ce document : LEA o Une dfinition de lEA o Les principes du 1er cadre de rfrence : Framework de Zachman , o Quelques rappels historiques sur les volutions de lEA Les 4 grands principes retenus par TOGAF La dmarche mthodologique utilise par lADM (le cur de TOGAF) Quelques critiques cits autour de TOGAF Des propositions autour des volutions de lEA

2 LEA et les principaux Framework 2.1 Une dfinition de LEA

La dfinition retenue de lEnterprise Architecture que nous donnons ici est celle du Gartner Group Larchitecture dentreprise est un processus de transformation de la vision et de la stratgie en changements effectifs dans lentreprise en crant, communicant et en amliorant les principes cls et les modles qui dcrivent la cible atteindre pour lensemble des ressources de lentreprise et en rendant possible son volution . LEA peut aussi tre dfinie comme un cadre de rfrence proposant un mta-modle des concepts, des rgles, une architecture fonctionnelle gnrique type, une dmarche mthodologique . Il est noter que lEA - traduite au travers de frameworks- reste indpendant des outils et technologies utilises pour la mettre en uvre.

Document1

Page 2

TOGAF : Un cadre darchitecture pour industrialiser les projets 2.2 Gnalogie des Framework
Voici un bref aperu des Framework mis en place dont les 2 plus importants souvent cits sont : Le Framework de Zachman le prcurseur TOGAF

Document1

Page 3

TOGAF : Un cadre darchitecture pour industrialiser les projets

2.3 Le Framework de Zachman

Les dbuts de lEA ont t marqus en 1987 par John Zachman crateur du 1er Framework. Il prsentait un nouveau modle pour visualiser et communiquer sur les architectures dentreprises. Zachman dcrivait son modle comme un ensemble de reprsentations pertinentes pour dcrire lentreprise, qui une fois tablies constituent une base de rfrences pour celle-ci. Cest une approche de reprsentation de larchitecture dentreprise organise suivant diffrents points de vue et selon diffrents concepts (cf. site internet : www.zifa.com) Il est constitu dun tableau 6 lignes et 6 colonnes dans lequel chaque cellule identifie un type de modle qui peut tre dvelopp pour documenter lentreprise et son SI. Cette matrice croise reprsente : En ligne, les points de vue ou perspectives pris par les divers acteurs (ce sont les lignes de la matrice) En colonne, les concepts de base pour dcrire une architecture qui rpond une question

Document1

Page 4

TOGAF : Un cadre darchitecture pour industrialiser les projets

Une autre reprsentation plus graphique.

Document1

Page 5

TOGAF : Un cadre darchitecture pour industrialiser les projets

2.4 LOpen Group et la mise en place de TOGAF

LOpen Group travaille avec des clients, des fournisseurs et dautres organismes proposant des normes. Son rle est principalement de : Capter, comprendre et aborder les besoins courants des entreprises, tablir des politiques et partager des best practices , Faciliter linteroprabilit, dvelopper un consensus en intgrant des spcifications et des technologies Open Source.

La 1re version de TOGAF a t mise en place par lOpen Group en 1995. A dernire version est la V9.0 datant de Fvrier 2009. TOGAF est une mthode, largement reconnue et utilise ainsi quun ensemble doutils pour concevoir, planifier, implmenter et gouverner une architecture dentreprise. Cette mthode ne prescrit aucun livrable obligatoire : les architectes peuvent utiliser les livrables dcrits dans TOGAF ou dautres livrables associs dautres frameworks (cf. C. Longp). TOGAF reste une base de dpart pour chaque entreprise, il reste elle construire son propre cadre.

2.5 TOGAF9 et ses apports

Un des apports important de TOGAF9 est le mta model darchitecture. Il sapplique toutes les phases du cycle ADM. TOGAF est modulaire et il ne prjuge ni dun outil ni dun formalisme particulier. TOGAF9 fournit de plus, une grille de critres dvaluation pour choisir un outil. Sa modularit offre de la souplesse dans le processus dadoption des entreprises. En effet, les entreprises ont dj souvent un voir plusieurs mta model couvrant tout ou partie des proccupations darchitecture et passez vers un nouveau mta model en mode big-bang nest souvent pas trs raliste.

Document1

Page 6

TOGAF : Un cadre darchitecture pour industrialiser les projets

2.6 Lvolution de lEnterprise Architecture

Aux USA, avec le Clinger-Cohen Act (en 1996) cette discipline a pris son essor. Cette loi a impos aux administrations fdrales amricaines llaboration dune Enterprise IT Architecture. Depuis toutes les grandes entreprises amricaines ont adopts ce principe. En 1998, le travail fait sur TAFIM (Technical Architecture Framework for Information Management) 1a t confi lOpen Group pour lintgrer TOGAF (The Open Group Architecture Framework). En parallle de lEA mis en avant dans les pays anglo-saxons, une dmarche durbanisation des SI est apparue en France. Le prcurseur de cette dmarche reste Jacques Sassoon avec son ouvrage Urbanisation des systmes d'information paru en 1998 qui pose les bases de la discipline. Ses principes ont t repris en France par le Club URBA EA fond en 2000 et par le CIGREF (Club informatique de grandes entreprises franaises) au travers de leur ouvrage Accroitre lagilit des SI paru en 2003. En 2007, la cration du CEISAR (Center of excellence for Enterprise Architecture adoss lEcole Centrale de Paris) permet de rassembler toutes les initiatives et de former tous les jeunes ingnieurs et permet de perfectionner les ingnieurs expriments en matire dEA. Nous pouvons citer les principaux standards de lEA : (source IFEAD, Institute for Enterprise Architecture Developments) 2 Integrated Architecture Framework (IAF) Federal Enterprise Architecture Framework (FEAF) Technical Architecture Framework For Information Management (TAFIM) Computer Integrated manufacturing Open System Architecture (CIMOSA)

TAFIM (source Wikipdia): is a 1990s reference model for enterprise architecture development, defined by the United States Department of Defense (DoD) in 1986. Technical Architecture Framework for Information Management (TAFIM) is a 1990s reference model for enterprise architecture development, defined by the United States Department of Defense (DoD) in 1986.
TAFIM provides enterprise-level guidance for the evolution of the DoD Technical infrastructure. It identifies the services, standards, concepts, components, and configurations that can be used to guide the development of technical architectures that meet specific mission requirements
2

IFEAD : site internet www.enterprise-architecture.info Page 7

Document1

TOGAF : Un cadre darchitecture pour industrialiser les projets

3 Les grands principes de TOGAF

Lobjectif 1er de TOGAF est de dsenclaver le travail des urbanistes en le remettant au centre de la gouvernance du systme dinformation. Pour tre pertinente, la cartographie de lorganisation de lentreprise, de ses processus, et de ses systmes, doit tre labore de manire ce que les quipes technique et mtier puissent partager des vues diffrentes dun lment unique en fonction de leurs comptences et leur place dans le projet 3 TOGAF est une mthodologie destine crer une architecture dentreprise dans le but damliorer les performances lors dvolutions informatiques au sein dune entreprise. Le Framework propos par TOGAF repose sur quatre couches : Architecture mtier : description de la stratgie mtier et des processus mtier supportant les objectifs Architecture des donnes : dfinition de la structure de stockage des donnes logiques et physiques et des ressources de gestion des donnes, Architecture applicative : description des applications incluant leurs interactions avec les processus cur de mtier de lorganisation, Architecture technique : description de linfrastructure du middleware, des rseaux, supportant le dploiement des services mtier, donnes et applications.

www.le journal du net Page 8

Document1

TOGAF : Un cadre darchitecture pour industrialiser les projets

NB : Nous pouvons retrouver ce principe dans les 4 niveaux de lurbanisme la franaise mme si la classification nest pas compltement identique

4 Prsentation de la dmarche mthodologique

Les piliers de TOGAF sont : Architecture Capability Framework : Ce composant dcrit lorganisation, les processus, les comptences, les rles et responsabilits des acteurs requis pour tablir et diriger la fonction d'architecture dans une entreprise, Architecture Development Method (ADM) : Cest la mthode de construction dune architecture dentreprise. ADM est considr comme le cur de TOGAF. Elle consiste en une approche du cycle de vie du dveloppement global de lentreprise, Architecture Content Framework : Cest un ensemble de guides, de modles, doutils de mthodes pour aider larchitecte utiliser ADM. Elle se compose de 4 architectures imbriques : Business Architecture, Data Architecture, Application Architecture et Technology (IT) Architecture. Enterprise Continuum and Tools: Cest un rfrentiel complter de modles darchitecture du march ou dvelopps dans lentreprise et qui peuvent tre utiliss comme point de dpart pour btir une architecture. Le continuum dentreprise constitue une bonne pratique de classification : o o Il sagit de sparer les architectures et les solutions Ranger les lments (architectures, solutions) suivant leur gnricit

Document1

Page 9

TOGAF : Un cadre darchitecture pour industrialiser les projets

TOGAF sappuie sur : Technical reference Model , Les deux modles gnriques de rfrences sont : o TOGAF Foundation Architecture o Integrated Information Infrastructure Reference Model (III-RM) Open Groups Standards Information Base (SIB), Building Blocks Information Base (BBIB).

Document1

Page 10

TOGAF : Un cadre darchitecture pour industrialiser les projets

5 LADM 5.1 Principes de lADM

La dmarche de lADM est compose de huit phases principales et dune phase prliminaire. Ces phases seront dtailles ci-aprs.

Chaque phase est divise en tapes. Des livrables sont gnres tout au long du processus, mais le livrable dune phase peut tre modifi dans une phase ultrieure.

Document1

Page 11

TOGAF : Un cadre darchitecture pour industrialiser les projets

Les points cls dADM sont : 4 ADM est une dmarche itrative, tout au long du processus, entre les phases et lintrieur dune phase, Pour chaque itration, une dcision doit tre prise sur : o Le primtre couvert, o Le niveau de dtail, o Lhorizon vis, y compris le nombre et la porte des jalons intermdiaires, o Les lments darchitectures existants de lEnterprise Continuum, dj cres dans les itrations prcdentes ou existantes dans lentreprise, Ces dcisions doivent tre prises sur la base dune valuation pratique des ressources et des comptences disponibles et sur la valeur attendue pour lentreprise de la dmarche darchitecture, En tant que mthode gnrique, ADM est prvue pour tre utilise dans des contextes trs varis, et peut donc tre adapte des besoins spcifiques. LADM reprsente le cycle de dveloppement de la mthodologie TOGAF. Ses 9 tapes peuvent tre rparties en trois sous-catgories : La 1re catgorie est compose de la phase prliminaire (Preliminary Phase) tant donn quelle ne rentre pas directement en compte dans le cycle proprement parler de TOGAF, elle sera prise en compte et dfinira les bases, La 2me catgorie est celle du dveloppement des architectures (phases A, B, C, D et H) La 3me catgorie regroupe les phases E, F et G et tout ce qui est extrieur aux architectures qui ont t vues.

5.2 Les phases de lADM

NB : Seul les tapes et livrables les plus importants sont mentionns dans chaque phase rfrences.

5.2.1 Phase prliminaire

Cette phase sapparente dire o, pourquoi, qui et comment nous faisons larchitecture . Elle met en place le contexte organisationnel, les parties prenantes permettant de crer larchitecture dentreprise. Etapes Evaluer les organisations de lentreprise impactes : en effet soit lentreprise peut sinscrire dans la dmarche, soit certaines lignes de mtiers sy inscrivent Dfinir et tablir lquipe et lorganisation de larchitecture dentreprise Identifier et tablir les principes de larchitecture Slectionner les frameworks de larchitecture et les adapter Implmenter les outils darchitecture.

C.Longp : Le projet durbanisation du SI (page 267-268) Page 12

Document1

TOGAF : Un cadre darchitecture pour industrialiser les projets

Livrables Un modle organisationnel pour larchitecture dentreprise Un Framework darchitecture adapt Un rpertoire pour larchitecture initiale, incluant les contenus du Framework

5.2.2 Phase A: Architecture Vision

Cette phase va permettre de crer la vision de larchitecture. La phase A permet de dfinir ce qui est dans et ce qui est hors du champ dapplication de leffort darchitecture et les contraintes qui doivent tre traites. Ses objectifs principaux sont de s'assurer que lvolution du cycle de dveloppement d'architecture a la reconnaissance et l'approbation de la gestion d'entreprise, l'appui et l'engagement ncessaire de lorganisation hirarchique. Il s'agit de donner une vision, donc on reste un niveau relativement macroscopique en focalisant sur les points structurants pour obtenir un GO en fin de phase. Etapes Etablir le projet darchitecture Identifier les parties prenantes, les proccupations et les besoins mtiers Confirmer et laborer les objectifs mtiers, les pilotes mtiers et les contraintes Sassurer de ltat de prparation aux changements mtier qui peuvent tre introduits par un changement darchitecture Confirmer et laborer les principes de larchitecture Dfinir les valeurs seuil et les indicateurs de performance cl de larchitecture cible Identifier les risques des transformations mtier et les activits dattnuation Dvelopper les plans de larchitecture et ltat du travail darchitecture.

Livrables Une dclaration de travail architectural approuve Les dclarations des principes mtier, les buts mtiers et les pilotes mtier raffins Les principes de larchitecture Les valuations de capacit de lentreprise Un Framework dentreprise adapt Une vision de larchitecture incluant : o Les besoins cl des parties prenantes pertinentes raffins o Les architectures de bases en version 0.1 o Les architectures cibles en version 0.1.

Document1

Page 13

TOGAF : Un cadre darchitecture pour industrialiser les projets

5.2.3 Phase B: Business Architecture

Cette phase va permettre de crer larchitecture mtier, prmices au travail darchitecture des autres domaines (tel que les donnes, les applications et les technologies). Cest donc une architecture primordiale . Elle sert galement pour montrer la valeur marchande du travail sur les architectures sousjacentes aux parties prenantes cls ainsi que le retour sur investissement quauraient cellesci en le soutenant et en participant ces travaux. Etapes Slectionner les modles de rfrence, points de vue et outils Dvelopper les descriptions de larchitecture de base Dvelopper les descriptions de larchitecture cible Analyser les lacunes Dfinir le plan de charge Conduire une rvision formelle des parties prenantes Finaliser larchitecture Crer les documents de dfinition de larchitecture.

Livrables

Des versions mises jour et raffines des livrables de la vision de larchitecture : o Dclarations de travail architectural o Les principes mtier, les buts mtier et les pilotes mtier valids (et mis jours si ncessaire) o Les principes de larchitecture Une bauche dun document de dfinition de larchitecture incluant : o Larchitecture mtier de base o Larchitecture mtier cible : La structure organisationnelle Les buts et objectifs mtier Les fonctions mtier Les services mtier Les rles mtier Le modle de donnes mtier La corrlation entre les fonctions et les organisations Les vues correspondantes aux points de vue adresss par les proccupations des parties prenantes cl.

Document1

Page 14

TOGAF : Un cadre darchitecture pour industrialiser les projets

5.2.4 Phase C: Information Systems Architectures

La phase C se dcompose en deux sous-parties : la partie donnes, et la partie applications.

La phase C sur les donnes va permettre de dfinir les principaux types de donnes qui seront ncessaires pour soutenir lactivit mtier en cours. Il faut que ces donnes soient comprhensibles par les parties prenantes, compltes et consistantes et enfin il faut quelles soient stables. Il est noter que ceci ne concerne pas tout ce qui a un rapport avec les bases de donnes. Le but tant de dfinir les entits qui vont servir lentreprise, pas de concevoir les systmes de stockages physiques ou logiques. La phase C a pour but de dfinir les systmes applicatifs principaux ncessaires pour traiter les donnes et soutenir lactivit mtier. Tout comme la partie prcdente, cette phase nest pas concerne par la conception de ces systmes applicatifs, ces applications ne sont pas dcrites comme des systmes informatiques mais comme des groupes logiques capables de grer les objets dfinis dans larchitecture de donnes et de soutenir lactivit mtier. Les applications et leurs possibilits sont dfinies sans rfrence des technologies particulires car celles-ci sont stables et finies tandis que les technologies utilises pour les mettre en uvre ne sont quant elles pas encore arrtes, elles changeront avec le temps en fonction des besoins changeant dactivits mtier en cours. Etapes Slectionner les modles de rfrence, les points de vue et les outils Analyser les lacunes Dfinir les composantes du plan de charge Rsoudre les impacts possibles sur lensemble des architectures Conduire une rvision formelle des parties prenantes Crer un document de dfinition de larchitecture.

Livrables Des versions mises jour et raffins de la vision de larchitecture incluant : o Une bauche du document de dfinition de larchitecture incluant : Les architectures de bases en version 1.0 Les architectures cibles en version 1.0 Les vues des architectures correspondant aux points de vue des proccupations des parties prenantes cl Une bauche des spcifications des besoins de larchitecture comprenant notamment les besoins techniques pertinents qui seront pris en compte dans lvolution du cycle de dveloppement de larchitecture Les composantes de larchitecture mtier du plan de charge architectural.

Document1

Page 15

TOGAF : Un cadre darchitecture pour industrialiser les projets

5.2.5 Phase D: Technology Architecture
La phase D cherche dfinir des relations entre les composants applicatifs, dfinis dans la phase C correspondante, et un ensemble de composants technologiques qui reprsenteront les composants logiciels et matriels disponibles sur le march ou bien configurs au sein de lorganisation dans des plateformes technologiques. Durant cette phase, lquipe en charge de larchitecture devra considrer que les ressources pertinentes pour larchitecture technologique sont disponibles dans le dpt darchitecture (ou se trouve lensemble des informations lies aux architectures). tapes : Dvelopper une description de larchitecture technique de base Dvelopper une description de larchitecture technique cible Finaliser larchitecture technique.

Livrables Vision de larchitecture : o Principes des technologies valids Les documents de dfinition de larchitecture technologique cible : o Des composants technologiques et leurs relations aux systmes dinformation o Des plateformes technologiques et leur dcomposition montrant les combinaisons des technologies requises pour raliser un parc technologique spcifique o Localisations et environnements o Spcifications rseau et matrielles.

5.2.6 Phase E: Opportunities & Solutions

La phase E est la premire phase qui soit directement concerne par la faon dont sera mise en place larchitecture cible. Elle se concentre sur la faon de fournir larchitecture. Cest uniquement lors de la phase E que lanalyse dopportunit est ralise avec les choix de solution. Ces choix sont raliss partir des travaux des phases B, C et D. Le mtier reste au cur de la dmarche, mme pour les choix de solution. Cest lors de cette phase que lon commence identifier les projets dimplmentation, quon identifie une trajectoire (macro planning) et que lon dfinit les architectures intermdiaires (sur les paliers de la trajectoire). Ses objectifs sont donc de passer en revue les capacits et les objectifs mtiers cibles, de consolider les lacunes des phases B D et dorganiser des groupes de blocs constitutifs pour grer ces capacits, de revoir et de confirmer les paramtres courants de lentreprise pour mieux absorber les ventuels changements, davoir une srie darchitectures de transitions fournissant une valeur ajoute continue travers lexploitation des opportunits, et de raliser des blocs constitutifs.

Document1

Page 16

TOGAF : Un cadre darchitecture pour industrialiser les projets

tapes : Dterminer/confirmer les changements des attributs cls de lentreprise Dterminer les contraintes de lentreprise vis--vis de la mise en uvre Rvision et consolidation des rsultats de lanalyse des lacunes pour les phases B D Rvision des besoins des technologies informatiques partir des perspectives fonctionnelles Consolider et rconcilier les besoins dinteroprabilits Affiner et valider les dpendances afin dassurer que toutes les contraintes de la mise en uvre et des plans de migration aient t identifies Confirmer la prparation de lorganisation et les risques pour les transformations mtier Formuler une implmentation haut-niveau et une stratgie de migration.

Livrables Une mise jour et un affinement des versions de la vision de larchitecture, de larchitecture mtier, des architectures des systmes dinformation et de larchitecture technologique : Un plan de charge architectural consolid et valid. Une architecture de transition version 1.0 incluant : o Les lacunes, solutions et les valuations de dpendances consolides. o Un recueil des risques version 1.0. o Une analyse des impacts. Un plan dimplmentation et de migration version 0.1.

5.2.7 Phase F: Migration Planning

La phase F correspond la mise en place dun plan dtaill dexcution et de migration. Elle va aussi servir mettre au point la vision darchitecture ainsi que les documents qui dfinissent larchitecture en conformit avec lapproche convenue. Les architectures de transitions dfinies dans la phase E avec les parties prenantes vont galement tre confirmes. Finalement, le cycle dvolution des architectures doit tre tabli pour assurer que les architectures restent pertinentes, et que les leons apprises soient documentes pour activer un processus damlioration continu. Elle fait ainsi une analyse de la valeur des travaux rsultant de la phase E par une analyse des couts, des bnfices mais aussi des risques. Elle dtaille la trajectoire et les projets associs.

Document1

Page 17

TOGAF : Un cadre darchitecture pour industrialiser les projets

tapes : Confirmer la gestion des interactions du Framework pour les plans de mise en uvre et de migration Assigner une valeur mtier chacun des projets Estimer les besoins en ressources, les chances et les moyens de diffusions des livrables Hirarchiser les projets de migration travers la conduite dune valuation des cots/bnfices et valider les risques Gnrer la feuille de route de la mise en uvre de larchitecture et du plan de migration.

Livrables Un plan dimplmentation et de migration version 1.0 Un document de dfinition de larchitecture finalise Une spcification des besoins de larchitecture finalise Des blocs constitutifs de larchitecture rutilisables Un modle de la mise en uvre de la gouvernance Des demandes de changement.

5.2.8 Phase G: Implementation

La phase G correspond la mise en place de la gouvernance, son but est de formuler des recommandations pour chaque implmentation de projets. Elle doit galement gouverner et grer un contrat darchitecture couvrant lensemble des processus dimplmentation et de dploiement. Elle doit assurer que le programme oprationnel est dploy correctement et comme il avait t prvu dans le programme de travail et que la solution dploye est conforme avec larchitecture cible. Cest avec cette phase que toute linformation sur la bonne gestion des diffrents projets oprationnels est rassemble. Paralllement cette phase, il y a lexcution dun processus de dveloppement spcifique une organisation o le dveloppement rel se produit. tapes : Confirmer les possibilits et les priorits pour le dploiement avec la gestion du dveloppement. Identifier les ressources de dploiement et les qualifications. Guider le dveloppement des solutions de dploiement. Faire la revue de la conformit de larchitecture. Mettre en uvre les oprations mtier et les technologies informatiques. Faire une revue post-implmentation et clore la phase de mise en uvre.

Document1

Page 18

TOGAF : Un cadre darchitecture pour industrialiser les projets

Livrables Un contrat darchitecture sign Une valuation de la conformit Des demandes de changement Des solutions darchitectures conformes dployes : o Le systme de larchitecture conforme mis en uvre o Le rpertoire de larchitecture rempli o Des recommandations et des dispenses conformes larchitecture o Des recommandations sur les besoins de livraisons des services o Des recommandations sur les mtriques de performance o Les accords de niveau de services o Une vision de larchitecture mise jour o Un document de dfinition de larchitecture mis jour o Une architecture de transition mise jour o Des modles pour le mtier et les systmes dinformation pour la solution mise en uvre.

5.2.9 Phase H: Architecture Change Management

La phase H sert principalement sassurer que les architectures de base continuent tre adaptes aux besoins. Elle va aussi permettre la fois dvaluer lexcution de larchitecture et mettre des recommandations pour des changements et valuer les changements de Framework et de principes configurs dans les phases prcdentes. Cette phase fera fonctionner le Framework de gouvernance. Cest durant cette phase que le gestionnaire de changement va dterminer en fonction des changements apporter sil faut initier un nouveau cycle dvolution de larchitecture. La phase H peut ainsi tre lorigine dun nouveau cycle darchitecture.

tapes : tablir un processus pour exploiter les revenus de larchitecture dentreprise Dployer les outils de surveillance Grer les risques Fournir une analyse pour la gestion des changements darchitecture Dvelopper les besoins de changement pour atteindre les cibles de performances Grer les processus de gouvernance Activer les processus pour mettre en uvre les changements.

Livrables Des mises jour des architectures Des changements dans le Framework de larchitecture et de ses principes De nouvelles demandes de travail architectural Les dclarations de travail architectural mises jour Un contrat darchitecture Une valuation de la conformit.

Document1

Page 19

TOGAF : Un cadre darchitecture pour industrialiser les projets 5.3 Le Cur de lADM : la gestion des exigences
Enfin, le point central du cycle ADM est la gestion des exigences qui permet de sassurer que lensemble des phases du cycle ADM sappuient et valident les exigences mtier.

5.4 Cycle de vie et utilisation pratique de lADM

Nous venons de dcrire les principes dun cycle ADM. Confront la pratique, les cycles ADM peuvent se dcliner de faon diffrente et TOGAF dfinit des modes dutilisation au travers de bonnes pratiques

5.4.1 Mode itratif

Tout dabord le droulement dun cycle ADM peut tre itratif. A titre dexemple, les prliminaires et Vision sont souvent assez lies: Donner la vision darchitecture sur un projet structurant aboutit souvent faire voluer les principes darchitecture transverses. De la mme faon, les phases E et F sont trs interdpendantes voire mme traites en mme temps dans certains cas Enfin dans certains cas, des itrations supplmentaires sont prvoir quand par exemple lanalyse des couts des bnfices et des risques raliss dans la phase F ncessite une revisite de larchitecture mtier cible.

Document1

Page 20

TOGAF : Un cadre darchitecture pour industrialiser les projets

5.4.2 Adaptation au contexte de lentreprise

Autre cas concret auquel sont confrontes les entreprises est de savoir comment dcliner des cycles ADM pour traiter la fois et de faon cohrente la dfinition des architectures stratgiques (Ex: Schma Directeur), la dfinition des architectures dun domaine mtier et les architectures de solution par essence plus proche des projets. Ces niveaux darchitecture font intervenir des profils darchitectes diffrents qui doivent collaborer une mme cible. Ce schma illustre 2 modes de mise en uvre proposs par TOGAF : 1. Un seul cycle TOGAF dans lequel chaque profil darchitecte apporte sa pierre ldifice. Ce mode est prconis quand on est dans le cas dune seule et mme quipe darchitecte qui traite lensemble 2. Des cycles imbriqus, plus adapts des organisations importantes ou des gros programmes de transformation pour lesquels on doit souvent dcliner une vision stratgique, domaines et ensuite projet.

6 ArchiMate language et TOGAF

ArchiMate 1.0 5 a t mis en place par lOpen Group pour modliser les principes dfinis par TOGAF en explicitant un niveau plus dtaill le Business Process et mme les Software au travers de concepts gnriques de modlisation applicable toute entreprise. Ce type de langage de modlisation permet larchitecte dentreprise de mettre en vidence les liens entre les domaines :6 Une structure globale pour chaque domaine montrant les lments principaux et les liens de dpendance entre domaines dans un langage comprhensible tous (parties-prenantes dont les utilisateurs finaux), De mettre en vidence les relations entre domaines.

ArchiMate (daprs Wikipdia) : ArchiMate is a technical standard from the Open Group and is based on the concepts of the IEEE 1471 standard. It is supported by various tool vendors and consulting firms. ArchiMate is also a registered trademark of The Open Group.
6

ArchiMate distinguishes itself from other languages such as Unified Modeling Language (UML) and Business Process Modeling Notation (BPMN) by its well defined metamodel, and wider enterprise modelling scope

Document1

Page 21

TOGAF : Un cadre darchitecture pour industrialiser les projets

7 Quelques critiques
TOGAF reste difficile mettre en place au sein des PME au vu de la complexit de la mthode et du niveau dimplication des acteurs qui doivent intervenir. Le cur de TOGAF (ADM) contient des procs, termes et descriptions en forme textuelles mais pas de schmas ou diagrammes, qui sont normalement privilgis par les architectes quand il sagit de parler au client. Le glossaire de TOGAF redfinit certains termes normalement utilis en architecture des SI et cela tends rendre son appropriation plus difficile. Il y a beaucoup dinformation sur le processus de cration dun artefact mais trs peu de dtails sur la faon dont les organisations sen servent et comment ils les mettent en place (absence dexemples concrets). TOGAF ne fournit pas les procds pour dvelopper les lments et les livrables de l'Architecture. Etant un Framework gnrique, il demande un travail dadaptation important. TOGAF fournit peu de conseils pour la cration d'un modle d'architecture complet et cohrent. Par contre il fait rfrence aux outils qui fournissent ce support. Une autre limitation est constitue par le manque d'intgration entre les diffrents domaines architecturaux.

8 Pour conclure
LEnterprise Architecture et notamment TOGAF, servent de point de dpart pour mettre en place des dveloppements en entreprise bas sur une analyse des processus de lentreprise. TOGAF offre un cadre de travail complet couvrant tout le cycle de vie de l'Architecture d'Entreprise. Les modles dEA servent de point de dpart pour dvelopper des systmes conduit par les modles.

Pour passer de lEnterprise IT Architecture lEnterprise Architecture, le dfi majeur est certainement la mobilisation des acteurs. Larchitecture dentreprise doit en effet runir tous les acteurs et tous les processus de lentreprise . 7

Le projet dUrbanisation du SI C. Longp (page 280). Page 22

Document1

TOGAF : Un cadre darchitecture pour industrialiser les projets

9 Bibliographie

Enterprise Architecture at Work de Marc Lankhorst et al (Springer) Le projet durbanisation du SI de Christophe Longp (Dunod) TOGAF9 Quick Start Guide for Enterprise Architects de Wolfgang Keller Enterprise Architecture, des problmes pratiques linnovation de Camille Salinesi et Laure-Hlne Thvenet (CRI Universit Paris I, Sorbonne) www.journaldunet.com (articles sur TOGAF) A framework for information systems architecture de J.A. Zachman dans IBM SYSTEMS JOURNAL, VOL 26. NO 3, 1987 Atelier de modlisation TOGAF de Matthieu Aubry/ Universit de Nantes http://www.ceisar.fr/ http://en.wikipedia.org/wiki/ et Wikipdia franais www.enterprise-architecture.info (site IFEAD) www.opengroup.org/architecture

Document1

Page 23