eugenio mauri : présentation de togaf (togaf : un cadre d’architecture pour industrialiser les...

TOGAFUn cadre d’architecture pour industrialiser les projets

Master Management des Systèmes d’Information et de Connaissance

UE09 : Pratiques de l’entreprise et méthodes d’analyse

Présentation de Dominique Le Mouël et Eugenio Mauri

TOGAF : Un cadre d’architecture pour industrialiser les projets

Sommaire

1 Les grandes lignes.............................................................................................................2

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

3 Les grands principes de TOGAF........................................................................................8

4 Présentation de la démarche méthodologique...................................................................9

5 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..............................................................21

6 « ArchiMate language » et TOGAF..................................................................................21

7 Quelques critiques............................................................................................................22

8 Pour conclure...................................................................................................................22

9 Bibliographie.....................................................................................................................23

document.docx Page 1


1 Les grandes lignes

Cette présentation de TOGAF (The Open Group Architecture Framework) s’inscrit dans le cadre 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’Enterprise Architecture (EA) utilisé par les entreprises.

Par la mise en place de telles approches, les entreprises mettent en relief un certain nombre de difficultés et les surmontent.

De nouvelles problématiques surgissent et restent sans réponse : l’emploi de ces approches génère de nouveaux risques.

Nous proposerons dans la suite de ce document :

L’EAo Une définition de l’EAo 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 principes retenus par TOGAF La démarche méthodologique utilisée par l’ADM (le cœur de TOGAF) Quelques critiques cités autour de TOGAF Des propositions autour des évolutions de l’EA

2 L’EA et les principaux « Framework »

2.1 Une définition de L’EA

La définition retenue de l’Enterprise Architecture que nous donnons ici est celle du Gartner Group « L’architecture d’entreprise est un processus de transformation de la vision et de la stratégie en changements effectifs dans l’entreprise en créant, communicant et en améliorant les principes clés et les modèles qui décrivent la cible à atteindre pour l’ensemble des 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 des concepts, des règles, une architecture fonctionnelle générique type, une démarche méthodologique ».

Il est à noter que l’EA - traduite au travers de frameworks- reste indépendant des outils et technologies utilisées pour la mettre en œuvre.



2.2 Généalogie des « Framework »

Voici un bref aperçu des « Framework » mis en place dont les 2 plus importants souvent cités sont :

Le « Framework de Zachman » le précurseur TOGAF



2.3 Le « Framework de Zachman »

Les débuts de l’EA ont été marqués en 1987 par John Zachman créateur du 1er Framework.

Il présentait un nouveau modèle pour visualiser et communiquer sur les architectures d’entreprises.

Zachman décrivait son modèle comme un ensemble de représentations pertinentes pour dé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 suivant diffé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 un type 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 question



Une autre représentation plus graphique.



2.4 L’Open Group et la mise en place de TOGAF

L’Open Group travaille avec des clients, des fournisseurs et d’autres organismes proposant des 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’outils pour concevoir, planifier, implémenter et gouverner une architecture d’entreprise.

Cette méthode ne prescrit aucun livrable obligatoire : les architectes peuvent utiliser les livrables 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 à construire son propre cadre.

2.5 TOGAF9 et ses apports

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

TOGAF9 fournit 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 des préoccupations d’architecture et passez vers un nouveau méta model en mode big-bang n’est souvent pas très réaliste.



2.6 L’évolution de l’Enterprise Architecture

Aux USA, avec le Clinger-Cohen Act (en 1996) cette discipline a pris son essor. Cette loi a imposé aux administrations fédérales américaines l’élaboration d’une Enterprise IT Architecture.

Depuis toutes les grandes entreprises américaines ont adoptés ce principe.

En 1998, le travail fait sur TAFIM (Technical Architecture Framework for Information Management) 1a été confié à l’Open Group pour l’intégrer à TOGAF (The Open Group Architecture Framework).

En parallèle de l’EA mis en avant dans les pays anglo-saxons, une démarche d’urbanisation des SI est apparue en France.

Le précurseur de cette démarche reste Jacques Sassoon avec son ouvrage « Urbanisation des systèmes 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 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 les jeunes 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 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) …

1 TAFIM (source Wikipédia): 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


http://en.wikipedia.org/wiki/Requirements

http://en.wikipedia.org/wiki/Infrastructure

http://en.wikipedia.org/wiki/United_States_Department_of_Defense


http://en.wikipedia.org/wiki/Enterprise_architecture

http://en.wikipedia.org/wiki/Enterprise_Architecture_framework



http://en.wikipedia.org/wiki/Enterprise_architecture



3 Les grands principes de TOGAF

L’objectif 1er de TOGAF est de désenclaver le travail des urbanistes en le remettant au centre de la gouvernance du système d’information.

« Pour être pertinente, la cartographie de l’organisation de l’entreprise, de ses processus, et de ses systèmes, doit être élaborée de manière à ce que les équipes technique et métier puissent partager des vues différentes d’un élément unique en fonction de leurs compétences et leur place dans le projet » 3

TOGAF est une méthodologie destinée à créer une architecture d’entreprise dans le but d’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.

NB : Nous pouvons retrouver ce principe dans les 4 niveaux de l’urbanisme à la française même si la classification n’est pas complètement identique

3 www.le journal du net


http://www.le/


4 Présentation de la démarche méthodologique

Les 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 d'architecture dans une 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 solutionso Ranger les éléments (architectures, solutions) suivant leur généricité



TOGAF s’appuie sur :

« Technical reference Model »,

Les deux modèles génériques de références sont :

o TOGAF Foundation Architectureo Integrated Information Infrastructure Reference Model (III-RM)

« Open Group’s Standards Information Base » (SIB), « Building Blocks Information Base (BBIB).


http://pubs.opengroup.org/architecture/togaf9-doc/arch/Figures/01_structu


5 L’ADM

5.1 Principes de l’ADM

La démarche de l’ADM est composée de huit phases principales et d’une phase pré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 du processus, mais le livrable d’une phase peut être modifié dans une phase ultérieure.



Les 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ès varié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égorie est composée de la 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ème catégorie est celle du développement des architectures (phases A, B, C, D et H)

La 3ème catégorie regroupe 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’ADM

NB : Seul les étapes et livrables les plus importants sont mentionnés dans chaque phase référencées.

5.2.1 Phase préliminaire

Cette 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éer l’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.

Livrables

4 C.Longépé : Le projet d’urbanisation du SI (page 267-268)



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 Framework

5.2.2 Phase A: Architecture Vision

Cette phase va permettre de créer la vision 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 principaux 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, l'appui et l'engagement nécessaire de l’organisation hiérarchique.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 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éso Les architectures de bases en version 0.1o Les architectures cibles en version 0.1.



5.2.3 Phase B: Business Architecture

Cette phase va permettre de créer l’architecture métier, prémices au travail d’architecture des 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 architecturalo 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 baseo 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 des parties prenantes clé.



5.2.4 Phase C: Information Systems Architectures

La phase C se décompose en deux sous-parties :

la partie données, et la partie applications.

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

La phase C 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 quant à elles pas encore arrêtées, elles changeront avec le temps en 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.

5.2.5 Phase D: Technology Architecture

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 cette phase, 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 :

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’informationo Des plateformes technologiques et leur décomposition montrant les

combinaisons des technologies requises pour réaliser un parc technologique spécifique

o Localisations et environnementso Spécifications réseau et matérielles.

5.2.6 Phase E: Opportunities & 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. 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 choix de solution. Ces choix sont réalisés à partir des travaux des phases B, C et D. Le métier reste 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’on identifie une trajectoire (macro planning) et que l’on définit les architectures intermédiaires (sur les paliers de la trajectoire).

Ses objectifs sont donc 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.

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 Planning

La phase F correspond à 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 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.

Elle fait ainsi une analyse de la valeur des travaux résultant de la phase E par une analyse des couts, des bénéfices mais aussi des risques. Elle détaille la trajectoire et les projets associés.



É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: Implementation

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.

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

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.



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 œuvreo Le répertoire de l’architecture remplio Des recommandations et des dispenses conformes à l’architectureo Des recommandations sur les besoins de livraisons des serviceso Des recommandations sur les métriques de performanceo Les accords de niveau de serviceso Une vision de l’architecture mise à jouro Un document de définition de l’architecture mis à jouro Une architecture de transition mise à jouro 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 Management

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

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



5.3 Le Cœur de l’ADM : la gestion des exigences

Enfin, le point central du cycle ADM est la gestion des exigences qui permet de s’assurer que 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’ADM

Nous 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 TOGAF définit des modes d’utilisation au travers de bonnes pratiques

5.4.1 Mode itératif

Tout d’abord le déroulement d’un cycle ADM peut être itératif. A titre d’exemple, les préliminaires et Vision sont souvent assez liées: Donner la vision d’architecture sur un projet structurant 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 en même temps dans certains cas

Enfin dans certains cas, des itérations supplémentaires sont à prévoir quand par exemple l’analyse des couts des bénéfices et des risques réalisés dans la phase F nécessite une revisite de l’architecture métier cible.



5.4.2 Adaptation au contexte de l’entreprise

Autre cas concret auquel sont confrontées les entreprises est de savoir comment décliner des cycles ADM pour traiter à la fois et de façon cohérente la définition des architectures stratégiques (Ex: Schéma Directeur), la définition des architectures d’un domaine métier et les architectures de solution par essence plus proche des projets.

Ces niveaux d’architecture font intervenir des profils d’architectes différents qui doivent collaborer à une même cible. Ce schéma illustre 2 modes de mise en œuvre proposés par TOGAF :

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 TOGAF

ArchiMate 1.0 5 a été mis en place par l’Open Group pour modéliser les principes définis par TOGAF en explicitant à un niveau plus détaillé le « Business Process » et même les« Software » au travers de concepts génériques de modélisation applicable à toute entreprise.

Ce type de langage de modélisation permet à l’architecte d’entreprise de mettre en évidence les 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 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 scope6


http://en.wikipedia.org/wiki/IEEE_1471

http://en.wikipedia.org/wiki/Open_Group

http://en.wikipedia.org/wiki/Enterprise_modelling

http://en.wikipedia.org/wiki/Metamodel

http://en.wikipedia.org/wiki/Business_Process_Modeling_Notation

http://en.wikipedia.org/wiki/Unified_Modeling_Language


7 Quelques critiques

TOGAF reste difficile à mettre en place au sein des PME au vu de la complexité de la méthode et du niveau d’implication des acteurs qui doivent intervenir.

Le cœur de TOGAF (ADM) contient des procès, termes et descriptions en forme textuelles mais pas de schémas ou diagrammes, qui sont normalement privilégiés par les architectes quand il s’agit de parler au client.

Le glossaire de TOGAF redéfinit certains termes normalement utilisé en architecture des SI et 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 de dé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 de l'Architecture.

Etant un « Framework » générique, il demande un travail d’adaptation important.

TOGAF fournit peu de conseils pour la création d'un modèle d'architecture complet et cohérent. Par contre il fait référence aux outils qui fournissent ce support.

Une autre limitation est constituée par le manque d'intégration entre les différents domaines architecturaux.

8 Pour conclure

L’Enterprise Architecture et notamment TOGAF, servent de point de départ pour mettre en place des développements en entreprise basé sur une analyse des processus de l’entreprise.

TOGAF offre un cadre de travail complet couvrant tout le cycle de vie de l'Architecture d'Entreprise.

Les modèles d’EA servent de point de départ pour développer des systèmes conduit par les modè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 les processus de l’entreprise ». 7

7 Le projet d’Urbanisation du SI » C. Longépé (page 280).



9 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/architecture


http://www.enterprise-architecture.info/

http://en.wikipedia.org/wiki/

http://www.ceisar.fr/

http://www.journaldunet.com/

eugenio mauri : présentation de togaf (togaf : un cadre d’architecture pour industrialiser les...

Documents