Atelier de modélisation TOGAF

Transcription

1 Atelier de modélisation TOGAF Aubry Matthieu Université de Nantes Année 2009 Atelier de modélisation TOGAF Maitre de stage : Christian Chabot Encadrant : Mourad Oussalah

2 Table des matières Présentation de Sodifrance...3 Introduction...6 TOGAF...9 L architecture d entreprise...9 L ADM...10 Phase Préliminaire Phase A Vision de l architecture...12 Phase B Architecture métier...13 Phase C...14 Phase D Architecture technique...16 Phase E Opportunités et Solutions...17 Phase F Planning de migration...18 Phase G Mise en œuvre de la gouvernance...19 Phase H Gestion des changements d architecture...20 GMF...21 Les éléments de GMF...21 Ecore...21 Gmfgraph...22 Gmfmap...24 Gmfgen...25 Gmftool...26 Points d'extension...28 Actions...28 Wizard...28 Mise en œuvre...28 La palette d'outils...30 Description du Wizard...31 L'obtention des phases...32 Solutions existantes...33 Application pratique de l éditeur...34 Création de documents...35 Principe...35 Réalisation...35 Transformation...36 Génération...37 Implémentation...38 Extrait d'exemple de document à rendre...38 Élément du modèle à représenter dans le document...39 Présentation de la maquette...40 Code XML à obtenir...40 Comment générer le code XML...41 Utilisation du XML pour avoir le document...41 EVOLUTIONS POSSIBLES / LACUNES...42 Conclusion...44 ANNEXES...45 ABREVIATIONS...49 GLOSSAIRE...49 BIBLIOGRAPHIE...50 Page 2 sur 50

3 Présentation de Sodifrance Historique et quelques chiffres 1986 : création de Sodifrance 57 M de CA en collaborateurs 11 implantations en France et Belgique Création à Rennes par Francis Mazin 1999 introduction en Bourse Disparition du fondateur Franck Mazin, Président Recentrage métier Stratégie de spécialisation Investissements outils pilotage et processus contrôle Augmentation de capital Avance technologique des offres Croissance et Rentabilité Développement national Projet d entreprise «Réussir Ensemble» - Croissance des services informatiques - Leadership en transformation automatisée des SI - Renforcement métiers clients Ambition 150 M Au départ Sodifrance était une entreprise spécialisé dans le traitement des chèques de banques, puis au fil des ans, leur volonté de disposer d outils pour réaliser l ensemble des tâches au sein de l entreprise fait qu en 2001, elle s est orientée vers les services grâce à ses acquis obtenus. C est cette volonté de disposer d outils qui fait également que Sodifrance est axé autour de la R&D, et ce depuis plus de 15 ans. Aujourd hui Sodifrance compte plus de 20 personnes spécialisées dans la R&D. Elle est également le leader européen du MDA. Une présence dans les grands secteurs économiques Page 3 sur 50

4 Quatre idées majeures guident leur développement. Industrialiser pour réduire les coûts informatiques et pérenniser les systèmes d information Les systèmes d information sont régulièrement confrontés à des besoins de modernisation. Face à ces projets stratégiques, la transformation industrielle est aujourd hui reconnue comme la seule alternative qui en réduise les coûts, les délais et les risques. Sodifrance capitalise depuis plus de dix ans une expertise unique dans ce domaine. Son centre de Recherche & Innovation a développé un Atelier de Génie Logiciel complet pour industrialiser la transformation des systèmes d information, quelle que soit la complexité des environnements ou des patrimoines «légués». Transformer, plutôt que refaire pour accélérer l adaptation des systèmes d information est le leitmotiv de l offre «Legacy Modernization». Elle est validée par le succès de nombreux projets réalisés auprès d une clientèle prestigieuse (CNP, Crédit du Nord, Crédit Agricole, AXA, MAIF, ING ). Conjuguer héritage du passé et nouvelles technologies Pour développer de nouveaux services, les entreprises font évoluer l architecture de leurs systèmes d information existants vers une logique «n-tiers» (.Net, J2EE). Sodifrance apporte là encore une réponse innovante et sécurisante par la mise en oeuvre des techniques de génie logiciel les plus avancées : à partir de l analyse de l existant et de la rétro modélisation des applications, Sodifrance réalise la transformation de modèles, selon les techniques du MDA (Model Driven Architecture) et la re-génération vers les technologies n-tiers. Apporter une valeur ajoutée technologique à proximité L évolution récente de la demande des directions informatiques se traduit notamment par la recherche d une réelle valeur ajoutée conjuguée à une productivité accrue. Pour prendre en compte cette tendance de fond, Sodifrance a mis en place une organisation basée sur des services de proximité et la diffusion d offres à valeur ajoutée. De l ingénierie et l intégration à l infogérance, Sodifrance propose des offres packagées, l intervention d ingénieurs de haut niveau. Dans le cadre de ce dispositif et grâce à son expérience des grands projets, Sodifrance optimise de nombreuses prestations grâce à l industrialisation de leur réalisation (développement nouvelles technologies, TMA ) chez les clients ou sur les centres de services. Partager une ambition de développement Les attentes des clients en termes d innovation, de pérennité des investissements, d engagements de résultats, de productivité confortent Sodifrance dans sa stratégie de développement en tant que spécialiste de la transformation industrielle des systèmes d information. Cette expertise confère à Sodifrance un positionnement à part dans le monde des sociétés de service et constitue un atout de pénétration de nouveaux comptes. Cette stratégie se conjugue avec le renforcement de la présence de proximité au plus près des besoins des clients. L engagement, comme le projet d entreprise, est ambitieux : apporter aux clients des solutions complètes et innovantes pour faciliter et accélérer la transformation de leur système d information afin d en faire un facteur de réussite de leurs entreprises. Page 4 sur 50

5 Leur modèle SSII à valeur ajoutée Les offres et savoir-faire : - Un positionnement unique combinant offres technologiques spécialisées et services informatiques de proximité - Une avance technologique reconnue sur des domaines ciblés : Legacy Modernization, MDA, Èvolution vers les Nouvelles Technologies - Une expérience importante des grands projets capitalisée dans une méthodologie éprouvée - Une activité de Recherche et Développement permanente et soutenue, garantissant l'excellence des solutions proposées - Des équipes de haut niveau, intervenant tout au long du cycle des projets - La maîtrise de technologies multiples, la double culture Main-Frame - Nouvelles Technologies Les clients : - Un taux de fidélisation élevé des clients, témoignant de la réussite des projets et d'une relation de confiance établie dans la durée - De nombreuses références clients, en France, en Belgique et en Suisse mais également dans d'autres pays via des accords de distributions des offres de Sodifrance - Une clientèle mixte, composée de grands comptes et de grandes PME régionales - Une clientèle multi-sectorielle, avec une forte représentation dans le secteur de la Banque et de l'assurance L organisation : - Une organisation en Conseil de Surveillance et Directoire - Un Directoire composé des principaux dirigeants, fortement impliqués dans la stratégie du groupe - Un actionnariat solide, détenu en majorité par les dirigeants (43,4% du capital et plus de 50% des droits de vote) - Un développement privilégiant la croissance organique, démontrant l'attractivité des offres et le dynamisme des équipes de Sodifrance - Une organisation favorisant l'inspiration technologique comme élément moteur de la stratégie de Sodifrance Page 5 sur 50

6 Introduction Il existe de nombreux frameworks permettant la définition d architecture des Systèmes d Information d entreprise, chacun étant plus ou moins aboutis, certains étant même spécifiques aux entreprises qui les utilisent. Les architectures des Systèmes d Information déterminent grandement les performances globales des entreprises. C est pour cette raison que des frameworks comme Zachman ou TOGAF, qui permettent de définir une architecture d entreprise de manière formelle et structurée et de prendre en compte l ensemble des informations d une entreprise dans les mêmes diagrammes (ou matrices), sont de plus en plus connus et utilisés. De ce fait, les possibles relations de gestion et de développement sont plus simples à mettre en valeur, et surtout sont visibles sans avoir à chercher entre les différents diagrammes. Ceci engendre alors des économies réelles sur le coût possible de mise en place de certains éléments dans l entreprise. Le but du stage est donc de proposer un atelier s articulant autour de la méthodologie TOGAF, développée par «The Open Group», sur la notion d architecture d entreprise. L utilisateur pourra alors à partir d'un diagramme de cette entreprise, faire de la génération documentaire, des contrôles de cohérences de modèle, et tout ce qui pourrait avoir un rapport avec la gestion formelle d une architecture de SI d entreprise. Les parties concernant TOGAF vont être développées, afin de voir de façon générale les principes de cette méthodologie, qui vont ensuite permettre de créer un éditeur graphique, qui servira de support à l'utilisateur pour définir son architecture et lui permettra de pouvoir générer des documents. Page 6 sur 50

7 Plan de travail Page 7 sur 50

8 Détail du travail réalisé Durant le premier mois, le travail réalisé a essentiellement été un travail de recherche documentaire concernant TOGAF, les sources du site officiel étaient disponibles directement sur ordinateur, mais il a fallu également tenter de trouver d autres sources afin de voir si le travail n avait pas été déjà réalisé par d autres personnes. Pendant une semaine environ, les tutoriels de GMF ont été réalisés afin de faire une «cassure» dans la lecture de TOGAF. Ces tutoriels ont été réalisés puisque dans la suite du travail, c est un éditeur GMF qui va permettre de créer les diagrammes représentant les éléments de TOGAF. Durant les deux mois suivant, c est l éditeur graphique qui a été réalisé, en commençant par faire le méta-modèle sur ce qui a été retenu parmi des éléments majeurs de la méthodologie TOGAF. Une fois ce méta-modèle réalisé, la création des fichiers propres à GMF ainsi que le rendu graphique a débuté. Le méta-modèle continuant, à chaque point où le rendu n était pas celui attendu, a être modifié, comme par exemple au niveau des liens, de l imbrication des différents éléments, où bien que la forme du méta-modèle ne permettait pas par exemple de mettre un élément dans tel diagramme. Une révision technique du méta-modèle a ensuite été effectuée afin de corriger certaines erreurs dans la forme globale de celui-ci. Ces modifications ont été répercutées la semaine suivante afin d avoir à nouveau un éditeur graphique fonctionnel. La phase à été assez rapide, puisque la majorité des fichiers de GMF n avaient pas de réels liens avec le méta-modèle. Après cela, la génération documentaire à été abordée, et les logiciels MIA-generation et Graphane ont été utilisés durant cette phase qui fût assez rapide du fait des limitations de Graphane. Le rapport de stage a ensuite été rédigé. Page 8 sur 50

9 TOGAF L architecture d entreprise va être abordée puisque c est le sujet sur lequel est basé TOGAF, avec un point détaillé sur l ADM qui est une grosse partie de la méthodologie TOGAF. L architecture d entreprise TOGAF est une méthodologie destinée à créer une architecture d entreprise dans le but d améliorer les performances lors d évolution informatiques au sein d une entreprise. Qu est ce qu une architecture d entreprise? Une architecture d entreprise regroupe différentes parties au sein de l entreprise, entre autre les fournisseurs, les clients et les associés, les principes qui la régissent, les buts, les pilotes et tout ce qui peut composer une entreprise. TOGAF est constitué de plusieurs parties, la première et la principale concerne l ADM (Architecture Development Method). L ADM est le résultat de contributions continuelles de nombreux utilisateurs des architectures. Elle décrit une méthode de développement d une architecture d entreprise et forme le cœur de TOGAF. Elle intègre les éléments de TOGAF décrits par la suite, ainsi que d autres évaluations d architecture disponibles pour rejoindre les besoins métier et les technologies informatiques au sein d une organisation. Ensuite l ADM peut être adapté pour mieux correspondre avec un nombre important de scénarios incluant différents styles de processus ainsi que des architectures spécialisées (comme la sécurité). Cela correspond à la deuxième partie de TOGAF. Les architectes qui exécutent l ADM produisent un nombre d éléments en fonction de leurs efforts, comme par exemple les flux de processus, les besoins architecturaux, les plans des projets, les évaluations de conformité des projets, etc. Le contenu du framework fournit un modèle structurel pour le contenu architectural qui permet à la majorité du travail produit par un architecte d être défini, structuré et présenté de façons consistantes. C est la troisième phase de TOGAF. La quatrième étape est représentée par la mise en place d un continuum d entreprise et de ses outils. Cette étape vient principalement du fait qu il est généralement impossible de créer une seule architecture unifiée qui satisfait l ensemble des besoins de toutes les parties prenantes et ce à tout moment. De ce fait, l architecte d entreprise devra traiter non pas une seule architecture d entreprise, mais de nombreuses architectures d entreprises qui sont reliées. La cinquième partie correspond à la mise en place d un modèle de référence technique, incluant une taxonomie centrale, une représentation graphique et une taxonomie de la plateforme applicative détaillée. La dernière phase de TOGAF concerne les capacités du framework architectural. En effet pour faire fonctionner avec succès des fonctions architecturales au sein d une entreprise, il est nécessaire de mettre en place des structures organisationnelles, des processus, des rôles, des responsabilités et des compétences pour mettre en œuvre les capacités architecturales. Page 9 sur 50

10 Figure 1 L'ADM de TOGAF L ADM L ADM représente le cycle de développement de la méthodologie TOGAF. Elle est composée de neuf étapes qui peuvent être réparties en trois sous-catégories. La première est seulement composée de la partie préliminaire étant donné qu elle ne rentre pas en compte dans le cycle à proprement parler de TOGAF, elle sera prise en compte et définira les bases, mais cette phase ne sera plus abordée par la suite. La deuxième sous partie est celle du développement des architectures, correspondant aux phases A, B, C, D et H. Et la dernière sous partie regroupe les phases E, F et G et tout ce qui est extérieur aux architectures qui ont été vues. Les parties suivantes vont donc décrire l ensemble de ces phases, ce qu il en retourne afin de dégager une vue plus générale du principe de fonctionnement de l ADM. Page 10 sur 50

11 Phase Préliminaire La phase préliminaire correspond à tout ce qui va avoir pour but de définir ce dont il sera question. Cela s apparente à dire «où, quoi, pourquoi, qui et comment nous faisons l architecture». C'est-à-dire qu un contexte organisationnel, des parties prenantes, vont être définis afin de déterminer leurs conditions, leurs rapports et leurs comportements pour créer l architecture d entreprise. Il sera également nécessaire de s assurer que chacune des personnes impliquées dans le processus architectural sont présentes. Le commanditaire de l architecture pourra créer des exigences pour le travail à travers les secteurs d'activité affectés. Le framework et les méthodologies détaillées qui vont être employés pour développer des architectures d'entreprise dans l'organisation concernée seront définis (typiquement, une adaptation de l'adm générique). Étapes : - Evaluer les organisations de l entreprise impactées. - Confirmer les caractéristiques requises de la gouvernance et soutenir les frameworks choisis. - 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. Sorties (livrables) : - Un modèle organisationnel pour l architecture d entreprise. - Un framework d architecture d adapté. - Un répertoire pour l architecture initiale, incluant les contenus du framework. - Une réévaluation ou une référence vers les principes métier, les buts métiers, et les pilotes métiers. - Des requêtes de travail architectural. - Un framework de gouvernance. Page 11 sur 50

12 Phase A Vision de l architecture La phase A va permettre de créer la vision d architecture, cette phase débutera avec la réception d une demande de travail d architecture provenant d un commanditaire de l organisation à l organisation en charge de l architecture. La phase A permet de définir ce qui est dans et ce qui est hors du champ d application de l effort d architecture et les contraintes qui doivent être traitées. Ses objectifs sont de s'assurer que l évolution du cycle de développement d'architecture a la reconnaissance et l'approbation de la gestion d'entreprise, et l'appui et l'engagement nécessaire de l organisation hiérarchique. Ses autres objectifs sont de définir la portée, et identifier et donner la priorité aux composants, de l'effort d'architecture de ligne de base, de créer des plans complets qui adressent l'établissement du programme, le recrutement, le financement, la communication, les risques, les contraintes, les ambitions, et les dépendances, en conformité avec les frameworks de gestion de projets adoptés par l'entreprise, et enfin de comprendre l'impact sur, et de, d'autres cycles de développement d'architecture d'entreprise qui sont en cours parallèlement. Étapes: - 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. - Evaluer les capacités métier. - S assurer de l état de préparation aux changements métier qui peuvent être introduits par un changement d architecture. - Définir la portée de l étude d architecture. - Confirmer et élaborer les principes de l architecture. - Développer la vision 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. Sorties (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 Des plans de communication. - Du contenu additionnel rajouté dans le répertoire de l architecture. Page 12 sur 50

13 Phase B Architecture métier La phase B va permettre de créer l architecture métier qui est une prémisse au travail d architecture dans les 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 les soutenant et en participant à ces travaux. Durant cette phase, les lignes de base de l architecture métier seront décrites. Une architecture métier cible sera développée, elle décrira le produit ou le service et les aspects organisationnels, fonctionnels, de processus, d informations et géographiques de l environnement commercial, ceux-ci étant basés sur les principes de gestion, les buts commerciaux et la stratégie globale. Et enfin elle permettra d identifier également les lacunes entre l architecture de base et l architecture cible. Étapes : - 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. - Résoudre les impacts possibles sur l ensemble des architectures. - Conduire une révision formelle des parties prenantes. - Finaliser l architecture. - Créer les documents de définition de l architecture. Sorties (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 en version 1.0. o L architecture métier cible en version 1.0 : La structure organisationnelle. Les buts et objectifs métier. Les fonctions métier. Les services métier. Les rôles métier. Page 13 sur 50

14 Le modèle de données métier. La corrélation entre les fonctions et les organisations. o Les vues correspondantes aux points de vue adressés par les préoccupations des parties prenantes clé. - Une ébauche des spécifications des besoins de l architecture : o Les résultats de l analyse des lacunes. o Les besoins techniques. o Les besoins métier mis à jour. - Les composantes de l architecture métier du plan de charge architectural. Phase C La phase C se décompose en deux sous-parties, la partie données et la partie applications. Étapes communes: - 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. Sorties (livrables) : - Des versions mises à jour et raffinés de la vision de l architecture incluant : o Les déclarations de travail architectural. - Une ébauche du document de définition de l architecture incluant : o Les architectures de bases en version 1.0. o Les architectures cibles en version 1.0. o 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 : o Les résultats de l analyse des lacunes. o Les besoins techniques pertinents qui seront pris en compte dans l évolution du cycle de développement de l architecture. o Des contraintes sur l architecture technologique. o Des besoins métier mis à jours. - Les composantes de l architecture métier du plan de charge architectural. Page 14 sur 50

15 Phase C Architecture de Données La phase C sur les données va permettre de définir les principaux types de données qui seront 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 et consistantes et enfin il faut qu elles soient stables. Il est à noter ce que ceci ne concerne pas tout ce qui a un rapport avec les bases de données. Le but étant de définir les entités qui vont servir à l entreprise, pas de concevoir les systèmes de stockages physiques ou logiques. Étapes : - Développer une description de l architecture de données de base. - Développer une description de l architecture de données cible. - Finaliser l architecture de données. Sorties (livrables) : - Vision de l architecture : o Principes des données validés. - Document de définition de l architecture : o L architecture de donnée cible : Modèle de données métier. Modèle de données logique. Modèles des processus de gestion de données. Matrices des entités de données/fonction métier. Phase C Architecture applicative Cette phase a pour but de définir les systèmes applicatifs principaux nécessaires pour traiter 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 ces systèmes applicatifs, ces applications ne sont pas décrites comme des systèmes informatiques mais comme des groupes logiques capables de gérer les objets définis dans l 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 technologies particulières car celles-ci sont stables et finies tandis que les technologies utilisées pour les mettre en œuvre ne sont quand à elles pas encore arrêtées, elles changeront avec le temps en fonction des besoins changeant d activités métier en cours. Étapes : - Développer une description de l architecture applicative de base. - Développer une description de l architecture applicative cible. - Finaliser l architecture applicative. Page 15 sur 50

16 Sorties (livrables) : - Vision de l architecture : o Principes applicatifs validés. - Document de définition de l architecture : o L architecture applicative cible : Modèle des systèmes de processus. Modèle des systèmes localisés. Modèle des systèmes temporels. Modèle des systèmes de personnes. Phase D Architecture technique La phase D cherche à définir des relations entre les composants applicatifs, définis dans la phase C correspondante, et un ensemble de composants technologiques qui représenteront les composants logiciels et matériels disponibles sur le marché ou bien configurés au sein de l organisation dans des plateformes technologiques. Durant la phase D, l équipe en charge de l architecture devra considérer que les ressources pertinentes 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 (reprendre en compte les étapes communes de la phase C) : - Développer une description de l architecture technique de base. - Développer une description de l architecture technique cible. - Finaliser l architecture technique. Sorties (livrables) : - Vision de l architecture : o Principes des technologies validés - Document de définition de l architecture : o L architecture technologique cible : Des composants technologiques et leurs relations aux systèmes d information. Des plateformes technologiques et leur décomposition montrant les combinaisons des technologies requises pour réaliser un parc technologique spécifique. Localisations et environnements. Charge des processus attendus et distribution de cette charge à travers les composants technologiques Communication physiques (réseau) Spécifications réseau et matérielles. Page 16 sur 50

17 Phase E Opportunités et Solutions La phase E est la première phase qui soit directement concernée par la façon dont sera mise en place l architecture cible. La phase E se concentre sur la façon de fournir l architecture. Ses objectifs sont de passer en revue les capacités et les objectifs métiers cibles, de consolider les lacunes des phases B à D et d organiser des groupes de blocs constitutifs pour gérer ces capacités, de revoir et de confirmer les paramètres courants de l entreprise pour mieux absorber les éventuels changements, d avoir une série d architectures de transitions fournissant une valeur ajoutée continue à travers l exploitation des opportunités, et de réaliser des blocs constitutifs. É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. - Identifier et grouper la majorité des activités architecturales. - Identifier les architectures de transitions. - Créer un portefeuille et des chartes de projet et une mise à jour des architectures. Sorties (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 : o Déclarations du travail architectural. o La vision de l architecture incluant la définition des types et les degrés d interopérabilité. o Une ébauche du document de définition de l architecture incluant : L identification des incréments. L interopérabilité et la coexistence des besoins. L inclusion des listes de projets et de chartes correspondantes. o Une ébauche des spécifications des besoins de l architecture. - Un plan de charge architectural consolidé et validé. - Une évaluation des capacités incluant : o Un profil de la maturité de l architecture d entreprise. o Un rapport sur la préparation aux transformations. Page 17 sur 50

18 - 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. o Un rapport sur l analyse des dépendances. o Une évaluation sur les facteurs de l implémentation et des matrices de déduction. - Un plan d implémentation et de migration version 0.1. Phase F Planning de migration La phase F correspond à la mise en place d un plan détaillé d exécution et de migration. Le but étant de s assurer que ces éléments sont coordonnés avec les divers frameworks de gestion au sein de l entreprise. Elle va aussi servir à mettre au point la vision d architecture ainsi que les documents qui définissent l architecture en conformité avec l approche convenue. Les architectures de transitions définies dans la phase E avec les parties prenantes vont également être confirmées. Finalement, le cycle d évolution des architectures doit être établi pour assurer que les architectures restent pertinentes, et que les leçons apprises soient documentées pour activer un processus d amélioration continu. É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. - Établir le cycle d évolution de l architecture et documenter les leçons apprises. Sorties (livrables) : - Un plan d implémentation et de migration version Un document de définition de l architecture finalisée. - Une spécification des besoins de l architecture finalisée. - Un plan de charge architectural finalisé. - Une architecture de transition finalisée. - Des blocs constitutifs de l architecture réutilisables. - Des demandes de travail architectural. - Des contrats d architecture. - Un modèle de la mise en œuvre de la gouvernance. - Des demandes de changement. Page 18 sur 50

19 Phase G Mise en œuvre de la gouvernance La phase G correspond à la mise en place de la gouvernance, son but est de formuler des recommandations pour chaque implémentation de projets. Elle doit également gouverner et gérer un contrat d architecture couvrant l ensemble des processus d implémentation et de déploiement. Cette phase 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 avec l architecture cible. C est avec cette phase que toute l information sur la bonne gestion des différents projets opérationnels est rassemblée. Il faut noter que parallèlement à cette phase il y a l exécution d un processus de développement spé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. Sorties (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. Page 19 sur 50

20 Phase H Gestion des changements d architecture Cette phase sert 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 des recommandations pour des changements et évaluer les changements de framework et de principes 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 des changements à apporter s il faut initier un nouveau cycle d évolution de l 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. Sorties (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é. Page 20 sur 50

21 GMF Les éléments de GMF GMF est un ensemble de procédés (et de fichiers) qui permettent à terme de concevoir un éditeur graphique pour un méta-modèle donné, le tout dans un environnement Eclipse. Le but de cette partie est donc d expliquer le principe de fonctionnement de chacune des parties qui le compose en fonction du moment où elles sont utilisées (dans l ordre Ecore-Gmfgraph-Gmftool-Gmfmap- Gmfgen). Ecore Ecore permet de mettre en forme le méta modèle qui servira pour la suite du déroulement de la gestion de l architecture d entreprise. Il va permettre de générer le code de l éditeur graphique ainsi la génération documentaire. De nombreux concepts peuvent être définis, comme les éléments communs tels que les classes, les packages, les types de données et les énumérations. À partir de là, il sera possible de créer des relations d'agrégation et de composition, de définir des classes ou des interfaces, des classes abstraites et de définir les conteneurs et les contenus. Figure 2 Extrait d'un fichier Ecore Page 21 sur 50

22 Le premier méta modèle réalisé décomposait chacune des phases en un package qui contenait un élément définissant la racine de la phase. Cette approche avait été déterminée pour une utilisation simple et rapide de GMF, puisque pour un diagramme donné il faut un élément racine qui contienne tout ce que le diagramme pourra afficher. Le problème de cette approche est que de ce fait l'unicité des éléments est perdue, puisque si par exemple une entreprise est définie dans la phase préliminaire, il faut alors pour définir cette même entreprise dans une phase suivante définir une classe entreprise propre à cette phase et qui posséderait une référence vers l'élément de base. Le méta-modèle a donc été revu afin qu'il permette de définir l'unicité quand à la déclaration d'un élément (ne pas avoir deux éléments définissant le même objet). Pour cela, chaque élément a été repris à l intérieur des phases et a été mis à la racine du modèle Ecore, puis une hiérarchie a été définie telle que l'ensemble des éléments soient disponibles à partir de la racine du document et que les diagrammes ne soient que des vues différentes de ce document. De ce fait, puisque tous les éléments sont disponibles à partir de la racine, il est possible de les faire apparaître dans n'importe quel diagramme et de conserver leurs informations d'origine. Seuls les éléments de la phase préliminaire jusqu'à la phase C complète ont été représentés, principalement à cause du facteur temps, mais également pour limiter l'éparpillement des données à travers les diagrammes. Gmfgraph Gmfgraph permet de définir tous les éléments graphiques d un diagramme, c'est à dire les figures, les liens, les compartiments, les nœuds qui pourront être utilisés ensuite par gmfmap. Il est à noter, que les éléments définis n'ont pas de but précis tant qu'ils ne sont pas mis en relation avec les éléments du modèle Ecore. Ainsi une même figure pourrait servir pour deux classes différentes, de même qu'un lien. C'est pour cette raison qu'il faut être le plus proche du modèle lorsqu'un élément est nommé, afin que les relations soient les plus simples possible, car pour des modèles complexes il serait très vite difficile de s y retrouver si les noms étaient choisis de façon arbitraire. Il existe deux types de figures, celles prédéfinies et celles personnalisées, pour ces dernières, il faut associer du code java qui utilise des librairies GMF afin de créer la forme désirée, tout en gardant à l'esprit que la forme devra contenir tout les éléments rajoutés, comme les étiquettes, les compartiments, etc. Page 22 sur 50

23 Figure 3 Extrait d'un fichier GMFgraph Les éléments Node concernent les nœuds du graphe, une figure ayant nécessairement un élément Node associé, sinon il est impossible de les ajouter puisque dans le cas contraire cela impliquerait que l'élément ne pourrait être retrouvé dans le modèle. Les éléments Connection représentent les figures qui seront utilisées pour définir les liens dans le fichier gmfmap. Les compartiments permettent de définir des sous parties dans les figures pour pouvoir ajouter des éléments qui seraient contenus dans celles-ci, comme par exemple le fait qu'une organisation puisse avoir une sous-organisation. Les Diagram Label servent à définir les parties textuelles d'une figure qui pourront être modifiées lors de l'édition graphique. Ils référencent une étiquette contenue dans une des figures. Il est d'ailleurs à noter qu'il est fréquent que les diagrammes se bloquent parce qu une figure possède un Diagram Label mal définit. Dans la majorité des cas, l'accès à ce label n a pas été créé, puisque lors de la définition d un label, la figure à qui il est associé est spécifiée, ainsi que le pointeur qui définit l accès à ce label. C'est ce dernier point qui est parfois mal défini, soit parce qu'un label a été créé et donc que les champs n ont pas encore été remplis, soit parce que la figure a été changée ou encore que le nom a changé. Page 23 sur 50

24 Gmfmap Gmfmap est l outil de mapping entre les éléments du modèle, les éléments présents dans le fichier gmfgraph et les outils qui ont été définis dans le fichier gmftool. Il est ainsi possible de définir des nœuds, des références vers des fils, des liens, des contraintes afin d'avoir la meilleure représentation possible de la vision globale du modèle. Il est également possible de faire des références vers d'autres fichiers Gmfmap lorsqu un objet en cours, qui peut être la racine d'un autre diagramme, est requis, afin qu'il puisse y avoir dans le fichier gmfgen une politique permettant lors d'un double clic sur l'élément en question, d'ouvrir la représentation correspondante. Pour un «Top Node», il faut définir une référence vers un Node Mapping qu'il contient, ainsi qu un conteneur de cet élément, sachant que la base d un modèle est définie dans un Canvas Mapping à l'intérieur duquel il faut définir un élément racine, le domaine, la palette d'outils et le fichier gmfgraph. Dans les Node Mapping, il faut définir la référence à cet élément dans le modèle Ecore, quels outils vont être utilisés pour le créer, et à quel nœud il fait référence dans le fichier gmfgraph. Et comme dit précédemment, il est éventuellement possible de lui associer un autre gmfmap afin de pouvoir faire une relation vers un sous diagramme. Dans ceux-ci, tous les éléments qui peuvent être contenus, comme les compartiments, les références vers des labels, des sous nœuds, etc., sont alors définis. À partir de ce fichier, si tous les éléments présents sont liés correctement, la génération du fichier gmfgen peut alors avoir lieu. Page 24 sur 50

25 Figure 4 Exemple de fichier GMFmap Gmfgen Gmfgen permet de générer le code source en fonction de tous les éléments qui ont pu être définis avant. Le nom du fichier contenant les informations peut être modifié, celui du diagramme, le nom du plugin, faire le mapping vers l'éditeur graphique et le modèle pour le «diagram partitioning», qui consiste à pouvoir ouvrir un autre diagramme à partir d'un des éléments du diagramme sur courant, et modifier les priorités pour les providers. Le comportement de certains éléments, qui sont choisis de façon «arbitraire», peut être modifié, comme par exemple la représentation des éléments à l'intérieur d'un compartiment, qui est défini en fonction de ce qui lui est ajouté. Par exemple, si dans un compartiment, un objet peut contenir d'autres objets, alors le compartiment aura des objets «flottants», tandis que si ce sont des paramètres, alors la représentation prendra la forme d une liste. Ceci est d'ailleurs changé en modifiant le paramètre à l'intérieur des compartiments nommé «List Layout». Page 25 sur 50

26 Figure 5 Extrait de fichier GMFgen Gmftool Gmftool est une palette qui permet de définir quels seront les outils qui seront disponibles lors du lancement du diagramme. La façon dont se décrit un fichier gmftool ainsi que sa représentation dans l'éditeur une fois fini est visible sur les deux illustrations suivantes. Il est à noter qu il est possible de définir des icônes personnalisées afin d'avoir une représentation ergonomique des éléments qui pourront être utilisés (comme par exemple faire une flèche pour représenter un lien). Page 26 sur 50

27 Figure 6 Exemple d'un fichier GMFtool Figure 7 Extrait d'une palette d'outils Page 27 sur 50

28 Points d'extension Les points d'extensions permettent de rajouter des fonctionnalités à un diagramme, comme par exemple les actions disponibles à partir d'un clic droit sur un élément du diagramme. Actions Les actions qui ont été implémentées concernent l'ajout automatique d'éléments dans le diagramme à partir d'un menu pop-up. Ainsi à partir du choix, la classe qui se chargera de créer l'élément voulu est lancée. Pour ce faire, l'éditeur envoie une requête sur la source du clic (les choix étant de toute façon limités en fonction de la source), il demande à créer l'élément puis, si besoin est, la connexion entre les deux éléments. Wizard Afin d'automatiser la création d'éléments dans les diagrammes, un assistant (Wizard) constitué d'une page pour chacune des phases du processus à été réalisé. Le but étant de pouvoir créer un diagramme complexe sans avoir à manipuler les outils graphiques. L'inconvénient majeur de cette approche est que c est alors Eclipse qui se charge de la disposition automatique des éléments à l'intérieur des diagrammes. Cette disposition est particulièrement mauvaise si le diagramme contient beaucoup d'éléments. Et étant donné que c'est la vue qui détermine la position des éléments et non le modèle, il n'est pas possible pour l utilisateur au moment de la création de définir des positions pour les éléments du modèle. Mise en œuvre La plupart des fichiers, qui correspondent aux éléments principaux du diagramme, ont été modifiés de façon à ce que leur représentation graphique soit telle que visible sur l illustration 8 : Figure 8 Figures des éléments du graphe Page 28 sur 50

29 Figure 9 Description des correspondances gmfgraph <=> figures Certaines modifications n ont pas eu lieu dans GMF parce qu il ne permet pas, par exemple, de spécifier l'alignement du texte à l'intérieur d'un label. De même que de spécifier des préfixes pour le nom des paramètres (comme «Besoin :» dans la partie architecture d'entreprise). Il a fallu pour cela passer par le code généré et plus précisément modifier les classes qui correspondent à l'affichage de ces classes. Page 29 sur 50

30 La palette d'outils La palette d'outil a été séparée en trois catégories, les éléments principaux, qui seront placés directement à la racine du modèle graphique, les paramètres qui seront contenus à l'intérieur des éléments principaux, et les liens. Pour cette dernière catégorie les liens ont été découpés en fonction du premier élément sur lequel se base le lien, de cette façon plusieurs liens sont regroupés à partir de ce choix, ils ne sont certes pas forcément connus de l'utilisateur, mais celui ci à de toute façon la possibilité de lâcher son lien dans le vide afin de voir quelles options s'offrent à lui. L'avantage de cette représentation est que le nombre de liens dans la palette est inférieur au nombre réel de connexions possibles, ce qui permet de réduire le nombre d outils présent dans la palette afin que l utilisateur débutant puisse l appréhender facilement tandis que l utilisateur averti dispose facilement du lien dont il a besoin. Il est à noter que pour les éléments de la palette qui n'auraient pas de correspondance dans le modèle gmfmap il n y a pas d'icône associée, ce qui signale à l'utilisateur que cette option n'est pas disponible dans l'éditeur. Cela permet de vérifier si une erreur a été introduite dans le fichier gmfmap, si des éléments ont pu être retirés du fichier gmftool, ou si des modifications ont été apportées et qu'elles ont modifié de façon involontaire certaines informations. Par exemple il suffit de rajouter un outil dans le fichier gmftool pour que lors de la génération du fichier gmfmap il y ait des outils de création qui aient été déplacés, changés, voire dans certains cas supprimés. (Il est alors possible si jamais le troisième cas n'apparait pas qu il y ait des incohérences dans le fichier et que la création de certains éléments n'ait aucun rapport avec l'outil de création choisi.) Page 30 sur 50

31 Description du Wizard Le Wizard est composé d un arbre dans lequel tous les éléments principaux sont représentés. Un modèle d une des phases peut alors être crée de façon rapide sans devoir ajouter manuellement les éléments ainsi que leurs liens. Il suffit juste de sélectionner quels éléments doivent être représentés en cochant leur case pour qu'ils soient présent lors de la création du fichier. Les boutons sur les cotés permettent de personnaliser le diagramme, comme par exemple le bouton ajouter organisation qui permet d'ajouter soit des organisations si jamais l'élément «entreprise» est ciblé, soit des sous organisations si jamais une organisation avait été sélectionnée. De ce fait, il est possible d obtenir une structure d'organisation suffisamment complexe pour ne pas avoir à la modifier ensuite. Des contextes peuvent être ajoutés à ces organisations, et comme ceux-ci ne sont pas forcément uniques pour une organisation, il faut lors de la création choisir parmi un choix d'organisations qui sont présentes dans l arbre, lesquelles correspondent à ce contexte. Il est à noter que si une organisation est supprimée et qu un contexte lui était associé, la liste des organisations dont il a la charge est correctement mise a jour, et s il ne possède plus d'organisations dans sa liste il est alors supprimé de l arbre. Pour les autres phases, le Wizard est structuré sur le même principe. Il y a un élément racine, généralement l'architecture sur laquelle la phase se focalise, ainsi que les éléments qui sont Page 31 sur 50

32 pertinents pour cette phase, ainsi que des boutons pour personnaliser un peu plus ce que la phase doit représenter. L'obtention des phases Une fois le Wizard terminé, l'éditeur graphique est ouvert et le diagramme de la phase préliminaire qui s'affiche à l'écran. Pour afficher les autres phases, il faut passer par l'explorateur de projet et faire un clic droit sur le modèle racine nommé «*.adm», puis faire «initialize» sur la phase à afficher. L outil demande alors la racine du nouveau diagramme, mais il n'est pas nécessaire de la préciser puisque la bonne racine est sélectionnée par défaut pour les phases normales. Un nouveau fichier est créé, ce qui permet de ne pas avoir à renouveler l'opération lorsque l ouverture de ce diagramme sera à nouveau nécessaire. Pour les diagrammes particuliers tel que celui de l'architecture métier, il suffit de faire un double clic sur sa représentation graphique afin d initialiser directement un nouveau diagramme. Cependant s il faut obtenir un fichier de ce type de diagramme, il faut recommencer la même opération que pour une phase normale mais en choisissant cette foisci la racine correspondante. Gmf se base sur un pattern MVC pour fonctionner. Cela permet de limiter les incohérences entre le modèle et la vue, celui-ci limitant par exemple la création des objets si un objet ne peut être présent qu'une fois dans le modèle. Les phases qui ont été traitées sous GMF sont toutes les phases du début jusqu à la phase C comprise. Ces phases ont été choisies parce qu elles sont les plus pertinentes dans la conception des diagrammes et également à cause de la contrainte temporelle. En effet, il faut compter environ une à deux semaines de travail pour pouvoir rajouter une phase au méta-modèle et l intégrer dans l éditeur graphique. Il faut prendre en compte la recherche des éléments pertinents pour la phase à rajouter, sachant que ces ajouts se basent sur une documentation qui ne fournit pas d exemple et qu il faut donc déterminer lors de la lecture ce qui sera représenté ou non. Il faut compter pour cette opération entre deux et quatre jours. Il faut ensuite créer les fichiers GMF, ce qui encore une fois suivant la taille des éléments rajoutés peut prendre entre deux à trois jours, et enfin mettre en place toutes les options disponibles pour l éditeur graphique, comme le Wizard ainsi que les actions, ce qui prend une journée environ. Si la génération documentaire est prise en compte, c'est-à-dire la génération du XML avec MIAgeneration et la création des éléments de la maquette correspondant, il faudra également rajouter une journée suivant le contenu de ce qui a été rajouté avant. Les éléments à rajouter en priorité sont, dans l ordre : - La phase D de façon à pouvoir couvrir tout les aspects principaux d un projet. - La phase E car elle fait référence aux possibilités et aux solutions de l architecture. - La phase H puisqu elle détermine la façon de procéder lors changement importants dans l architecture. - Les phases F et G, car elles concernent l ADM, et sont donc à compléter avant de passer aux autres points dont est constitué TOGAF. - Rajouter les éléments qui concernent la sécurité, le continuum d entreprise, le répertoire d entreprise et tout élément que l entreprise jugerait utile de rajouter. Page 32 sur 50