Eugenio Mauri: présentation de TOGAF

3 655 vues

Publié le

Master « Management des Systèmes d’Information et de Connaissance »
U.E. 9 : Pratiques de l’entreprise et méthodes d’analyse - I.A.E. Paris, Sorbonne-Pantheon

Publié dans : Technologie
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
3 655
Sur SlideShare
0
Issues des intégrations
0
Intégrations
3
Actions
Partages
0
Téléchargements
259
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Eugenio Mauri: présentation de TOGAF

  1. 1. TOGAFUn cadre d’architecture pour industrialiser lesprojetsMaster Management des Systèmes d’Information et de ConnaissanceUE09 : Pratiques de l’entreprise et méthodes d’analysePrésentation de Dominique Le Mouël et Eugenio Mauri
  2. 2. TOGAF : Un cadre d’architecture pour industrialiser les projets Sommaire1 Les grandes lignes .......................................................................................................... 22 L’EA et les principaux « Framework » ............................................................................. 2 2.1 Une définition de L’EA ............................................................................................. 2 2.2 Généalogie des « Framework »............................................................................... 3 2.3 Le « Framework de Zachman » ............................................................................... 4 2.4 L’Open Group et la mise en place de TOGAF ......................................................... 6 2.5 TOGAF9 et ses apports .......................................................................................... 6 2.6 L’évolution de l’Enterprise Architecture.................................................................... 73 Les grands principes de TOGAF ..................................................................................... 84 Présentation de la démarche méthodologique ................................................................ 95 L’ADM ............................................................................................................................11 5.1 Principes de l’ADM .................................................................................................11 5.2 Les phases de l’ADM .............................................................................................12 5.2.1 Phase préliminaire ..........................................................................................12 5.2.2 Phase A: Architecture Vision ...........................................................................13 5.2.3 Phase B: Business Architecture ......................................................................14 5.2.4 Phase C: Information Systems Architectures ..................................................15 5.2.5 Phase D: Technology Architecture ..................................................................16 5.2.6 Phase E: Opportunities & Solutions.................................................................16 5.2.7 Phase F: Migration Planning ...........................................................................17 5.2.8 Phase G: Implementation ................................................................................18 5.2.9 Phase H: Architecture Change Management...................................................19 5.3 Le Cœur de l’ADM : la gestion des exigences ........................................................20 5.4 Cycle de vie et utilisation pratique de l’ADM ...........................................................20 5.4.1 Mode itératif ....................................................................................................20 5.4.2 Adaptation au contexte de l’entreprise ............................................................216 « ArchiMate language » et TOGAF ................................................................................217 Quelques critiques .........................................................................................................228 Pour conclure.................................................................................................................229 Bibliographie ..................................................................................................................23eugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 1
  3. 3. TOGAF : Un cadre d’architecture pour industrialiser les projets1 Les grandes lignesCette présentation de TOGAF(The Open Group Architecture Framework) s’inscrit dans lecadre de l’UE09 de notre Master qui propose d’aborder une problématique de SIC.De nombreux cadres, méthodes et outils existent sur le marché de l’EnterpriseArchitecture (EA)utilisé par les entreprises.Par la mise en place de telles approches, les entreprises mettent en relief un certain nombrede difficultés et les surmontent.De nouvelles problématiques surgissent et restent sans réponse : l’emploi de ces approchesgénère de nouveaux risques.Nous proposerons dans la suite de ce document : L’EA o Une définition de l’EA o Les principes du 1er cadre de référence : « Framework de Zachman », o Quelques rappels historiques sur les évolutions de l’EA Les 4 grands principesretenus par TOGAF La démarche méthodologiqueutilisée par l’ADM (le cœur de TOGAF) Quelques critiques cités autour de TOGAF Des propositions autour des évolutions de l’EA2 L’EA et les principaux « Framework »2.1 Une définition de L’EALa définition retenue de l’Enterprise Architectureque nous donnons ici est celle duGartner Group« L’architecture d’entreprise est un processus de transformation de la visionet de la stratégie en changements effectifs dans l’entreprise en créant, communicant et enaméliorant les principes clés et les modèles qui décrivent la cible à atteindre pour l’ensembledes ressources de l’entreprise et en rendant possible son évolution ».L’EA peut aussi être définie comme «un cadre de référence proposant un méta-modèle desconcepts, des règles, une architecture fonctionnelle générique type, une démarcheméthodologique ».Il est à noter que l’EA - traduite au travers de frameworks- reste indépendant des outils ettechnologies utilisées pour la mettre en œuvre.eugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 2
  4. 4. TOGAF : Un cadre d’architecture pour industrialiser les projets2.2 Généalogie des « Framework »Voici un bref aperçu des « Framework » mis en place dont les 2 plus importants souventcités sont : Le « Framework de Zachman »  le précurseur TOGAFeugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 3
  5. 5. TOGAF : Un cadre d’architecture pour industrialiser les projets2.3 Le « Framework de Zachman »Les débuts de l’EA ont été marqués en 1987 par John Zachmancréateur du 1er Framework.Il présentait un nouveau modèle pour visualiser et communiquer sur les architecturesd’entreprises.Zachman décrivait son modèle comme un ensemble de représentations pertinentes pourdécrire l’entreprise, qui une fois établies constituent une base de références pour celle-ci.C’est une approche de représentation de l’architecture d’entreprise organisée suivantdifférents points de vue et selon différents concepts (cf. site internet : www.zifa.com)Il est constitué d’un tableau à 6 lignes et 6 colonnes dans lequel chaque cellule identifie untype de modèle qui peut être développé pour documenter l’entreprise et son SI.Cette matrice croisée représente : En ligne, les points de vue ou perspectives pris par les divers acteurs (ce sont les lignes de la matrice) En colonne, les concepts de base pour décrire une architecture qui répond à une questioneugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 4
  6. 6. TOGAF : Un cadre d’architecture pour industrialiser les projetsUne autre représentation plus graphique.eugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 5
  7. 7. TOGAF : Un cadre d’architecture pour industrialiser les projets2.4 L’Open Group et la mise en place de TOGAFL’Open Group travaille avec des clients, des fournisseurs et d’autres organismes proposantdes normes. Son rôle est principalement de : Capter, comprendre et aborder les besoins courants des entreprises, établir des politiques et partager des « best practices », Faciliter l’interopérabilité, développer un consensus en intégrant des spécifications et des technologies Open Source.La 1ère version de TOGAF a été mise en place par l’Open Group en 1995.A dernière version est la V9.0 datant de Février 2009.« TOGAF est une méthode, largement reconnue et utilisée ainsi qu’un ensemble d’outilspour concevoir, planifier, implémenter et gouverner une architecture d’entreprise.Cette méthode ne prescrit aucun livrable obligatoire : les architectes peuvent utiliser leslivrables décrits dans TOGAF ou d’autres livrables associés à d’autres frameworks » (cf. C.Longépé).TOGAF reste une base de départ pour chaque entreprise, il reste à elle à construireson propre cadre.2.5 TOGAF9 et ses apportsUn des apports important de TOGAF9 est le méta model d’architecture. Il s’applique àtoutes les phases du cycle ADM.TOGAF est modulaire et il ne préjuge ni d’un outil ni d’un formalisme particulier.TOGAF9fournit de plus, une grille de critères d’évaluation pour choisir un outil.Sa modularité offre de la souplesse dans le processus d’adoption des entreprises. En effet,les entreprises ont déjà souvent un voir plusieurs méta model couvrant tout ou partie despréoccupations d’architecture et passez vers un nouveau méta model en mode big-bangn’est souvent pas très réaliste.eugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 6
  8. 8. TOGAF : Un cadre d’architecture pour industrialiser les projets2.6 L’évolution de l’Enterprise ArchitectureAux USA, avec le Clinger-Cohen Act (en 1996) cette discipline a pris son essor. Cette loi aimposé aux administrations fédérales américaines l’élaboration d’une Enterprise ITArchitecture.Depuis toutes les grandes entreprises américaines ont adoptés ce principe.En 1998, le travail fait sur TAFIM (Technical Architecture Framework for InformationManagement) 1a été confié à l’Open Grouppour l’intégrer à TOGAF (The Open GroupArchitecture Framework).En parallèle de l’EA mis en avant dans les pays anglo-saxons, une démarche d’urbanisationdes SI est apparue en France.Le précurseur de cette démarche reste Jacques Sassoon avec son ouvrage « Urbanisationdes systèmes dinformation » paru en 1998 qui pose les bases de la discipline.Ses principes ont été repris en France par le Club URBA EAfondé en 2000 et par leCIGREF (Club informatique de grandes entreprises françaises) au travers de leur ouvrage« Accroitre l’agilité des SI » paru en 2003.En 2007, la création du CEISAR (Center of excellence for Enterprise Architecture adossé àl’Ecole Centrale de Paris) permet de rassembler toutes les initiatives et de former tous lesjeunes ingénieurs et permet de perfectionner les ingénieurs expérimentés en matière d’EA.Nous pouvons citer les principaux standards de l’EA : (source IFEAD, Institute for EnterpriseArchitecture Developments) 2 Integrated Architecture Framework (IAF) Federal EnterpriseArchitecture Framework (FEAF) Technical Architecture Framework For Information Management (TAFIM) Computer Integrated manufacturing Open System Architecture (CIMOSA) …1 TAFIM (source Wikipédia): is a 1990s reference model for enterprise architecturedevelopment, defined by the United States Department of Defense (DoD) in 1986. TechnicalArchitecture Framework for Information Management (TAFIM) is a 1990s referencemodel for enterprise architecture development, defined by the United States Department ofDefense (DoD) in 1986.TAFIM provides enterprise-level guidance for the evolution of the DoD Technical infrastructure. Itidentifies the services, standards, concepts, components, and configurations that can be used to guidethe development of technical architectures that meet specific mission requirements2 IFEAD : site internet www.enterprise-architecture.infoeugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 7
  9. 9. TOGAF : Un cadre d’architecture pour industrialiser les projets3 Les grands principes de TOGAFL’objectif 1er de TOGAF est de désenclaver le travail des urbanistes en le remettant aucentre de la gouvernance du système d’information.« Pour être pertinente, la cartographie de l’organisation de l’entreprise, de ses processus, etde ses systèmes, doit être élaborée de manière à ce que les équipes technique et métierpuissent partager des vues différentes d’un élément unique en fonction de leurscompétences et leur place dans le projet » 3TOGAF est une méthodologie destinée à créer une architecture d’entreprise dans le butd’améliorer les performances lors d’évolutions informatiques au sein d’une entreprise.Le Framework proposé par TOGAF repose sur quatre couches : Architecture métier : description de la stratégie métier et des processus métier supportant les objectifs Architecture des données : définition de la structure de stockage des données logiques et physiques et des ressources de gestion des données, Architecture applicative : description des applications incluant leurs interactions avec les processus cœur de métier de l’organisation, Architecture technique : description de l’infrastructure du middleware, des réseaux,… supportant le déploiement des services métier, données et applications.3www.le journal du neteugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 8
  10. 10. TOGAF : Un cadre d’architecture pour industrialiser les projetsNB : Nous pouvons retrouver ce principe dans les 4 niveaux de l’urbanisme à la françaisemême si la classification n’est pas complètement identique4 Présentation de la démarche méthodologiqueLes piliers de TOGAF sont : «Architecture Capability Framework » : Ce composant décrit l’organisation, les processus, les compétences, les rôles et responsabilités des acteurs requis pour établir et diriger la fonction darchitecture dansune entreprise, « Architecture Development Method » (ADM) : C’est la méthode de construction d’une architecture d’entreprise. ADM est considéré comme le cœur de TOGAF. Elle consiste en une approche du cycle de vie du développement global de l’entreprise, « Architecture Content Framework » : C’est un ensemble de guides, de modèles, d’outils de méthodes … pour aider l’architecte à utiliser ADM. Elle se compose de 4 architectures imbriquées : Business Architecture, Data Architecture, Application Architecture et Technology (IT) Architecture. « Enterprise Continuum » and Tools: C’est un référentiel à compléter de modèles d’architecture du marché ou développés dans l’entreprise et qui peuvent être utilisés comme point de départ pour bâtir une architecture. Le continuum d’entreprise constitue une bonne pratique de classification : o Il s’agit de séparer les architectures et les solutions o Ranger les éléments (architectures, solutions) suivant leur généricitéeugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 9
  11. 11. TOGAF : Un cadre d’architecture pour industrialiser les projetsTOGAF s’appuie sur : « Technical reference Model », Les deux modèles génériquesde références sont : o TOGAF Foundation Architecture o Integrated Information Infrastructure Reference Model (III-RM) « Open Group’s Standards Information Base » (SIB), « Building Blocks Information Base (BBIB).eugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 10
  12. 12. TOGAF : Un cadre d’architecture pour industrialiser les projets5 L’ADM5.1 Principes de l’ADMLa démarche de l’ADM est composée de huit phases principales et d’une phasepréliminaire.Ces phases seront détaillées ci-après.Chaque phase est divisée en étapes. Des livrables sont générées tout au long duprocessus, mais le livrable d’une phase peut être modifié dans une phase ultérieure.eugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 11
  13. 13. TOGAF : Un cadre d’architecture pour industrialiser les projetsLes points clés d’ADM sont : 4 ADM est une démarche itérative, tout au long du processus, entre les phases et à l’intérieur d’une phase, Pour chaque itération, une décision doit être prise sur : o Le périmètre couvert, o Le niveau de détail, o L’horizon visé, y compris le nombre et la portée des jalons intermédiaires, o Les éléments d’architectures existants de l’Enterprise Continuum, déjà crées dans les itérations précédentes ou existantes dans l’entreprise, Ces décisions doivent être prises sur la base d’une évaluation pratique des ressources et des compétences disponibles et sur la valeur attendue pour l’entreprise de la démarche d’architecture,En tant que méthode générique, ADM est prévue pour être utilisée dans des contextes trèsvariés, et peut donc être adaptée à des besoins spécifiques.L’ADM représente le cycle de développement de la méthodologie TOGAF.Ses 9 étapes peuvent être réparties en trois sous-catégories : La 1ère catégorieest composée dela phase préliminaire (Preliminary Phase) étant donné qu’elle ne rentre pas directement en compte dans le cycle à proprement parler de TOGAF, elle sera prise en compte et définira les bases, La 2èmecatégorieest celle du développement des architectures (phases A, B, C, D et H) La 3èmecatégorieregroupe les phases E, F et G et tout ce qui est extérieur aux architectures qui ont été vues.5.2 Les phases de l’ADMNB : Seul les étapes et livrables les plus importants sont mentionnés dans chaque phaseréférencées.5.2.1 Phase préliminaireCette phase s’apparente à dire « où, pourquoi, qui et comment nous faisons l’architecture ».Elle met en place le contexte organisationnel, les parties prenantes permettant de créerl’architecture d’entreprise. Etapes Evaluer les organisations de l’entreprise impactées : en effet soit l’entreprise peut s’inscrire dans la démarche, soit certaines lignes de métiers s’y inscrivent Définir et établir l’équipe et l’organisation de l’architecture d’entreprise Identifier et établir les principes de l’architecture Sélectionner les frameworks de l’architecture et les adapter Implémenter les outils d’architecture.4 C.Longépé : Le projet d’urbanisation du SI (page 267-268)eugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 12
  14. 14. TOGAF : Un cadre d’architecture pour industrialiser les projets Livrables Un modèle organisationnel pour l’architecture d’entreprise Un Framework d’architecture adapté Un répertoire pour l’architecture initiale, incluant les contenus du Framework5.2.2 Phase A: Architecture VisionCette phase va permettre decréer la vision de l’architecture.La phase Apermet de définir ce qui est dans et ce qui esthors du champ d’application del’effort d’architecture et les contraintes qui doivent être traitées.Sesobjectifs principaux sont de sassurer que l’évolution du cycle de développementdarchitecture a lareconnaissance et lapprobation de la gestion dentreprise, lappui etlengagement nécessaire de l’organisation hiérarchique.Il sagit de donner une vision, donc on reste à un niveau relativement macroscopique enfocalisant sur les points structurants pour obtenir un GO en fin de phase. Etapes Etablir le projet d’architecture Identifier les parties prenantes, les préoccupations et les besoins métiers Confirmer et élaborer les objectifs métiers, les pilotes métiers et les contraintes S’assurer de l’état de préparation aux changements métier qui peuvent être introduits par un changement d’architecture Confirmer et élaborer les principes de l’architecture Définir les valeurs seuil et les indicateurs de performance clé de l’architecture cible Identifier les risques des transformations métier et les activités d’atténuation Développer les plans de l’architecture et l’état du travail d’architecture. Livrables Une déclaration de travail architectural approuvée Les déclarations des principes métier, les buts métiers et les pilotes métier raffinés Les principes de l’architecture Les évaluations de capacité de l’entreprise Un Framework d’entreprise adapté Une vision de l’architecture incluant : o Les besoins clé des parties prenantes pertinentes raffinés o Les architectures de bases en version 0.1 o Les architectures cibles en version 0.1.eugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 13
  15. 15. TOGAF : Un cadre d’architecture pour industrialiser les projets5.2.3 Phase B: Business ArchitectureCette phase va permettre de créer l’architecture métier,prémices au travail d’architecturedes autres domaines (tel que les données, les applications et les technologies).C’est donc une architecture « primordiale ».Elle sert également pour montrer la valeur marchande du travail sur les architectures sous-jacentes aux parties prenantes clés ainsi que le retour sur investissement qu’auraient celles-ci en le soutenant et en participant à ces travaux. Etapes Sélectionner les modèles de référence, points de vue et outils Développer les descriptions de l’architecture de base Développer les descriptions de l’architecture cible Analyser les lacunes Définir le plan de charge Conduire une révision formelle des parties prenantes Finaliser l’architecture Créer les documents de définition de l’architecture. Livrables Des versions mises à jour et raffinées des livrables de la vision de l’architecture : o Déclarations de travail architectural o Les principes métier, les buts métier et les pilotes métier validés (et mis à jours si nécessaire) o Les principes de l’architecture Une ébauche d’un document de définition de l’architecture incluant : o L’architecture métier de base o L’architecture métier cible :  La structure organisationnelle  Les buts et objectifs métier  Les fonctions métier  Les services métier  Les rôles métier  Le modèle de données métier  La corrélation entre les fonctions et les organisations Les vues correspondantes aux points de vue adressés par les préoccupations desparties prenantes clé.eugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 14
  16. 16. TOGAF : Un cadre d’architecture pour industrialiser les projets5.2.4 Phase C: Information Systems ArchitecturesLa phase C se décompose en deux sous-parties : la partie données, et la partie applications.La phase C sur les donnéesva permettre de définir les principaux types de données quiseront nécessaires pour soutenir l’activité métier en cours.Il faut que ces données soient compréhensibles par les parties prenantes, complètes etconsistantes et enfin il faut qu’elles soient stables. Il est à noter que ceci ne concerne pastout ce qui a un rapport avec les bases de données. Le but étant de définir les entités quivont servir à l’entreprise, pas de concevoir les systèmes de stockages physiques oulogiques.La phase C a pour but de définir les systèmes applicatifs principauxnécessaires pourtraiter les données et soutenir l’activité métier.Tout comme la partie précédente, cette phase n’est pas concernée par la conception de cessystèmes applicatifs, ces applications ne sont pas décrites comme des systèmesinformatiques mais comme des groupes logiques capables de gérer les objets définis dansl’architecture de données et de soutenir l’activité métier.Les applications et leurs possibilités sont définies sans référence à des technologiesparticulières car celles-ci sont stables et finies tandis que les technologies utilisées pour lesmettre en œuvre ne sont quant à elles pas encore arrêtées, elles changeront avec le tempsen fonction des besoins changeant d’activités métier en cours. Etapes Sélectionner les modèles de référence, les points de vue et les outils Analyser les lacunes Définir les composantes du plan de charge Résoudre les impacts possibles sur l’ensemble des architectures Conduire une révision formelle des parties prenantes Créer un document de définition de l’architecture. Livrables Des versions mises à jour et raffinés de la vision de l’architecture incluant : o Une ébauche du document de définition de l’architecture incluant :  Les architectures de bases en version 1.0  Les architectures cibles en version 1.0  Les vues des architectures correspondant aux points de vue des préoccupations des parties prenantes clé Une ébauche des spécifications des besoins de l’architecture comprenant notamment les besoins techniques pertinents qui seront pris en compte dans l’évolution du cycle de développement de l’architecture Les composantes de l’architecture métier du plan de charge architectural.eugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 15
  17. 17. TOGAF : Un cadre d’architecture pour industrialiser les projets5.2.5 Phase D: Technology ArchitectureLa phase D cherche à définir des relations entre les composants applicatifs, définisdans la phase C correspondante, et un ensemble de composants technologiques quireprésenteront les composants logiciels et matériels disponibles sur le marché ou bienconfigurés au sein de l’organisation dans des plateformes technologiques.Durant cette phase, l’équipe en charge de l’architecture devra considérer que les ressourcespertinentes pour l’architecture technologique sont disponibles dans le dépôt d’architecture(ou se trouve l’ensemble des informations liées aux architectures). Étapes : Développer une description de l’architecture technique de base Développer une description de l’architecture technique cible Finaliser l’architecture technique. Livrables Vision de l’architecture : o Principes des technologies validés Les documents de définition de l’architecture technologique cible : o Des composants technologiques et leurs relations aux systèmes d’information o Des plateformes technologiques et leur décomposition montrant les combinaisons des technologies requises pour réaliser un parc technologique spécifique o Localisations et environnements o Spécifications réseau et matérielles.5.2.6 Phase E: Opportunities & SolutionsLa phase Eest la première phase qui soit directement concernée par la façon dont seramise en place l’architecture cible. Elle se concentre sur la façon de fournir l’architecture.C’est uniquement lors de la phase E que l’analyse d’opportunité est réalisée avec les choixde solution. Ces choix sont réalisés à partir des travaux des phases B,C et D. Le métierreste au cœur de la démarche, même pour les choix de solution.C’est lors de cette phase que l’on commence à identifier les projets d’implémentation, qu’onidentifie une trajectoire (macro planning) et que l’on définit les architectures intermédiaires(sur les paliers de la trajectoire).Ses objectifssont donc de passer en revue les capacités et les objectifs métiers cibles, deconsolider les lacunes des phases B à D et d’organiser des groupes de blocs constitutifspour gérer ces capacités, de revoir et de confirmer les paramètres courants de l’entreprisepour mieux absorber les éventuels changements, d’avoir une série d’architectures detransitions fournissant une valeur ajoutée continue à travers l’exploitation des opportunités,et de réaliser des blocs constitutifs.eugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 16
  18. 18. TOGAF : Un cadre d’architecture pour industrialiser les projets Étapes : Déterminer/confirmer les changements des attributs clés de l’entreprise Déterminer les contraintes de l’entreprise vis-à-vis de la mise en œuvre Révision et consolidation des résultats de l’analyse des lacunes pour les phases B à D Révision des besoins des technologies informatiques à partir des perspectives fonctionnelles Consolider et réconcilier les besoins d’interopérabilités Affiner et valider les dépendances afin d’assurer que toutes les contraintes de la mise en œuvre et des plans de migration aient été identifiées Confirmer la préparation de l’organisation et les risques pour les transformations métier Formuler une implémentation haut-niveau et une stratégie de migration. Livrables Une mise à jour et un affinement des versions de la vision de l’architecture, de l’architecture métier, des architectures des systèmes d’information et de l’architecture technologique : Un plan de charge architectural consolidé et validé. Une architecture de transition version 1.0 incluant : o Les lacunes, solutions et les évaluations de dépendances consolidées. o Un recueil des risques version 1.0. o Une analyse des impacts. Un plan d’implémentation et de migration version 0.1.5.2.7 Phase F: Migration PlanningLa phase Fcorrespond à la mise en place d’un plan détaillé d’exécution et de migration.Elle va aussi servir à mettre au point la vision d’architecture ainsi que les documents quidéfinissent l’architecture en conformité avec l’approche convenue. Les architectures detransitions définies dans la phase E avec les parties prenantes vont également êtreconfirmées.Finalement, le cycle d’évolution des architectures doit être établi pour assurer que lesarchitectures restent pertinentes, et que les leçons apprises soient documentées pour activerun processus d’amélioration continu.Elle fait ainsi une analyse de la valeur des travaux résultant de la phase E par une analysedes couts, des bénéfices mais aussi des risques. Elle détaille la trajectoire et les projetsassociés.eugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 17
  19. 19. TOGAF : Un cadre d’architecture 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 métier à chacun des projets Estimer les besoins en ressources, les échéances et les moyens de diffusions des livrables Hiérarchiser les projets de migration à travers la conduite d’une évaluation des coûts/bénéfices et valider les risques Générer la feuille de route de la mise en œuvre de l’architecture et du plan de migration. Livrables Un plan d’implémentation et de migration version 1.0 Un document de définition de l’architecture finalisée Une spécification des besoins de l’architecture finalisée Des blocs constitutifs de l’architecture réutilisables Un modèle de la mise en œuvre de la gouvernance Des demandes de changement.5.2.8 Phase G: ImplementationLa phase Gcorrespond à la mise en place de la gouvernance, son but est de formuler desrecommandations pour chaque implémentation de projets.Elle doit également gouverner et gérer un contrat d’architecture couvrant l’ensemble desprocessus d’implémentation et de déploiement.Elle doit assurer que le programme opérationnel est déployé correctement et comme il avaitété prévu dans le programme de travail et que la solution déployée est conforme avecl’architecture cible.C’est avec cette phase que toute l’information sur la bonne gestion des différentsprojets opérationnels est rassemblée.Parallèlement à cette phase, il y a l’exécution d’un processus de développementspécifiqueà une organisation où le développement réel se produit. Étapes : Confirmer les possibilités et les priorités pour le déploiement avec la gestion du développement. Identifier les ressources de déploiement et les qualifications. Guider le développement des solutions de déploiement. Faire la revue de la conformité de l’architecture. Mettre en œuvre les opérations métier et les technologies informatiques. Faire une revue post-implémentation et clore la phase de mise en œuvre.eugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 18
  20. 20. TOGAF : Un cadre d’architecture pour industrialiser les projets Livrables Un contrat d’architecture signé Une évaluation de la conformité Des demandes de changement Des solutions d’architectures conformes déployées : o Le système de l’architecture conforme mis en œuvre o Le répertoire de l’architecture rempli o Des recommandations et des dispenses conformes à l’architecture o Des recommandations sur les besoins de livraisons des services o Des recommandations sur les métriques de performance o Les accords de niveau de services o Une vision de l’architecture mise à jour o Un document de définition de l’architecture mis à jour o Une architecture de transition mise à jour o Des modèles pour le métier et les systèmes d’information pour la solution mise en œuvre.5.2.9 Phase H: Architecture Change ManagementLa phase Hsert principalement à s’assurer que les architectures de base continuent àêtre adaptées aux besoins.Elle va aussi permettre à la fois d’évaluer l’exécution de l’architecture et à émettre desrecommandations pour des changements et évaluer les changements de Framework et deprincipes configurés dans les phases précédentes.Cette phase fera fonctionner le « Framework » de gouvernance.C’est durant cette phase que le gestionnaire de changement va déterminer en fonction deschangements à apporter s’il faut initier un nouveau cycle d’évolution de l’architecture.La phase H peut ainsi être à l’origine d’un nouveau cycle d’architecture. Étapes : Établir un processus pour exploiter les revenus de l’architecture d’entreprise Déployer les outils de surveillance Gérer les risques Fournir une analyse pour la gestion des changements d’architecture Développer les besoins de changement pour atteindre les cibles de performances Gérer les processus de gouvernance Activer les processus pour mettre en œuvre les changements. Livrables Des mises à jour des architectures Des changements dans le Framework de l’architecture et de ses principes De nouvelles demandes de travail architectural Les déclarations de travail architectural mises à jour Un contrat d’architecture Une évaluation de la conformité.eugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 19
  21. 21. TOGAF : Un cadre d’architecture pour industrialiser les projets5.3 Le Cœur de l’ADM : la gestion des exigencesEnfin, le point central du cycle ADM est la gestion des exigences qui permet de s’assurerque l’ensemble des phases du cycle ADM s’appuient et valident les exigences métier.5.4 Cycle de vie et utilisation pratique de l’ADMNous venons de décrire les principes d’un cycle ADM.Confronté à la pratique, les cycles ADM peuvent se décliner de façon différente et TOGAFdéfinit des modes d’utilisation au travers de bonnes pratiques5.4.1 Mode itératifTout d’abord le déroulement d’un cycle ADM peut être itératif. A titre d’exemple, lespréliminaires et Vision sont souvent assez liées: Donner la vision d’architecture sur un projetstructurant aboutit souvent à faire évoluer les principes d’architecture transverses.De la même façon, les phases E et F sont très interdépendantes voire même traitées enmême temps dans certains casEnfin dans certains cas, des itérations supplémentaires sont à prévoir quand par exemplel’analyse des couts des bénéfices et des risques réalisés dans la phase F nécessite unerevisite de l’architecture métier cible.eugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 20
  22. 22. TOGAF : Un cadre d’architecture pour industrialiser les projets5.4.2 Adaptation au contexte de l’entrepriseAutre cas concret auquel sont confrontées les entreprises est de savoir comment déclinerdes cycles ADM pour traiter à la fois et de façon cohérente la définition des architecturesstratégiques (Ex: Schéma Directeur), la définition des architectures d’un domaine métier etles architectures de solution par essence plus proche des projets.Ces niveaux d’architecture font intervenir des profils d’architectes différents qui doiventcollaborer à une même cible. Ce schéma illustre 2 modes de mise en œuvre proposés parTOGAF : 1. Un seul cycle TOGAF dans lequel chaque profil d’architecte apporte sa pierre à l’édifice. Ce mode est préconisé quand on est dans le cas d’une seule et même équipe d’architecte qui traite l’ensemble 2. Des cycles imbriqués, plus adaptés à des organisations importantes ou à des gros programmes de transformation pour lesquels on doit souvent décliner une vision stratégique, domaines et ensuite projet.6 « ArchiMate language » et TOGAFArchiMate 1.05 a été mis en place par l’Open Group pour modéliser les principes définis parTOGAF en explicitant à un niveau plus détaillé le « Business Process » et mêmeles« Software » au travers de concepts génériques de modélisation applicable à touteentreprise.Ce type de langage de modélisation permet à l’architecte d’entreprise de mettre en évidenceles liens entre les domaines :6 Une structure globale pour chaque domaine montrant les éléments principaux et les liens de dépendance entre domaines dans un langage compréhensible à tous (parties-prenantes dont les utilisateurs finaux), De mettre en évidence les relations entre domaines.5 ArchiMate (d’après Wikipédia) : ArchiMate is a technical standard from the Open Groupand is based on the concepts of the IEEE 1471 standard. It is supported by various toolvendors 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, andwider enterprise modelling scopeeugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 21
  23. 23. TOGAF : Un cadre d’architecture pour industrialiser les projets7 Quelques critiquesTOGAF reste difficile à mettre en place au sein des PMEau vu de la complexité de laméthodeet du niveau d’implication des acteursqui doivent intervenir.Le cœur de TOGAF (ADM) contient des procès, termes et descriptions en forme textuellesmais pas de schémas ou diagrammes, qui sont normalement privilégiés par les architectesquand il s’agit de parler au client.Le glossaire de TOGAF redéfinit certains termes normalement utilisé en architecture des SIet cela tends à rendre son appropriation plus difficile.Il y a beaucoup d’information sur le processus de création d’un « artefact » mais très peu dedétails sur la façon dont les organisations s’en servent et comment ils les mettent en place(absence d’exemples concrets).TOGAF ne fournit pas les procédés pour développer les éléments et les livrables delArchitecture.Etant un « Framework » générique, il demande un travail d’adaptation important.TOGAF fournit peu de conseils pour la création dun modèle darchitecture complet etcohérent. Par contre il fait référence aux outils qui fournissent ce support.Une autre limitation est constituée par le manque dintégration entre les différents domainesarchitecturaux.8 Pour conclureL’Enterprise Architecture et notamment TOGAF, servent de point de départ pour mettre enplace des développements en entreprise basé sur une analyse des processus del’entreprise.TOGAF offre un cadre de travail complet couvrant tout le cycle de vie de lArchitecturedEntreprise.Les modèles d’EA servent de point de départ pour développer des systèmes conduit par lesmodèles.« Pour passer de l’Enterprise IT Architecture à l’Enterprise Architecture,le défi majeur est certainement la mobilisation des acteurs.L’architecture d’entreprise doit en effet réunir tous les acteurs et tous lesprocessus de l’entreprise ».77 Le projet d’Urbanisation du SI » C. Longépé (page 280).eugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 22
  24. 24. TOGAF : Un cadre d’architecture pour industrialiser les projets9 Bibliographie « Enterprise Architecture at Work » de Marc Lankhorst et al (Springer) “Le projet d’urbanisation du SI” de Christophe Longépé (Dunod) TOGAF9 Quick Start Guide for Enterprise Architects de Wolfgang Keller “Enterprise Architecture, des problèmes pratiques à l’innovation” de Camille Salinesi et Laure-Hélène Thévenet (CRI Université Paris I, Sorbonne) www.journaldunet.com (articles sur TOGAF) « A framework for information systems architecture” de J.A. Zachman dans « IBM SYSTEMS JOURNAL, VOL 26. NO 3, 1987” “Atelier de modélisation TOGAF” de Matthieu Aubry/ Université de Nantes http://www.ceisar.fr/ http://en.wikipedia.org/wiki/ et Wikipédia français www.enterprise-architecture.info (site IFEAD) www.opengroup.org/architectureeugeniomauriue09prsentationdetogaf-120621104606-phpapp02.docx Page 23

×