Démarche mise en place de référentiel d'architecture

2,923
-1

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,923
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
224
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Démarche mise en place de référentiel d'architecture

  1. 1. CONSEIL EN GOUVERNANCE ET ARCHITECTURE DU SYSTEME D’INFORMATION Présentation de la démarche de mise en place d’un Référentiel d’Architecture Référentiel d’architecture en mode projet
  2. 2. Plan  Démarche de cartographie et d’architecture d’entreprise  Projet de mise en place de référentiel d’architecture  Utilisation et personnalisation des outils d’architecture  Utilisation du modèle de référence Frameworx (eTom, TAM, SID, TNA)
  3. 3. Plan  Démarche de cartographie et d’architecture d’entreprise  Projet de mise en place de référentiel d’architecture  Utilisation et personnalisation des outils d’architecture  Utilisation du modèle de référence Frameworx (eTom, TAM, SID, TNA)
  4. 4. C’est quoi l’architecture  Les cadres, ou référentiels d’architecture, tels que Zachman ou TOGAF, permettent de structurer le travail d’architecture en définissant différentes vues ou niveaux. Ainsi, le référentiel d’architecture d’entreprise TOGAF définit 4 niveaux :  l’architecture métier, qui définit la stratégie métier, la gouvernance, l’organisation et les processus métier clés ;  l’architecture applicative, qui définit le parc applicatif de l’entreprise, les interactions entre applications et la couverture fonctionnelle des applications ;  l’architecture de données, qui décrit la structure et l’organisation des données au niveau logique et physique, les référentiels de données ainsi que la manière avec laquelle ces données sont gérées ;  et enfin, l’architecture technique (ou technologique), qui décrit l’infrastructure logicielle, matérielle et réseau, nécessaire au déploiement des données et des applications.  Pour les différents vues, l’architecte doit cartographier l’existant, définir la cible et tracer le plan de migration.
  5. 5. Architecture d’Entreprise Descriptive Eléments de l’architecture métier: •Chaine de valeur •Ressources •Donnée •Processus •Produits et services •Organisation Eléments de l’architecture applicative: •Framework •Interfaces •Propriétés •Composants Eléments de l’architecture données: •Modèle conceptuel •ZonesSujet •Entités •Eléments •Relations Eléments de l’architecture technique: •Plateformes d’exploitation •Plateformes technologies •Composants réseau
  6. 6. Architecture d’Entreprise Prescriptive Principes Alignés avec les exigences de la stratégie commerciale et d’Information Processus Directives Architecture d’Entreprise Normes Politiques Guider © Neoxia 2012 Le choix + la création + la mise en œuvre des solutions / l'orientation prise pour les futures architectures Formation 6
  7. 7. Démarche globale  Une méthodologie structurante de la démarche architecture d’entreprise: Quel plan pour aller de là où on est à là où on veut aller? Formation 7
  8. 8. Livrables Descriptives Catalogues • Inventaires simples • Informations linéaires mais riche Matrices • Croisement de catalogues • Dépendances et liens • Analyse d’écart et d’impact Modèles ou diagrammes © Neoxia 2012 • Vues composites • Zoom progressif • Perspectives par acteurs Formation 8
  9. 9. Livrables Prescriptives • Obligatoires • Directeurs • Permettent de définir la cible Principes Règles • Basés sur les bonnes pratiques • Recommandés “Nice to have” • Ouverts • Consensus au niveau de l’industrie • Supportés • Outillés Guidelines © Neoxia 2012 • Obligatoire et doit être respectés • Validé formellement Standards Formation 9
  10. 10. Démarche globale • Description de l’architecture • Catalogues • Diagrammes • Principes, standards, règles et guidelines • Matrices de dépendance • Analyse d’écart Architecture actuelle Diagnostic de l’existant Roadmap de transformatio n Architecture cible • Matrices de dépendance • Analyse d’impact • Description de l’architecture • Catalogues • Diagrammes • Principes, standards, règles et guidelines Formation 10
  11. 11. Approches d’urbanisation Top-down •Commencer par les processus métier et descendre en niveau de granularité jusqu’à arriver aux services techniques Meet in the middle Middle-out •Combiner les deux approche en assurant la cohérence par l’équipe d’architecture au niveaux des services métier unitaires et les services applicatifs •Commencer “In the middle”, c’est-à-dire là où le métier et les IT parlent le même langage puis remonter vers les processus métier et descendre vers les services techniques Bottom-up •Commencer par les service technique ou les services applicatifs en encapsulant les fonctionnalités de l’existant 11
  12. 12. Ingrédients de l’AE •Standard •Ouvert Framework Processes •Certifiés •Expérimentés Personnes • Création • MAJ • Gouvernance • mesures Outil • Standard • Exhaustif •Personnalisable
  13. 13. Synthèse du contenu de TOGAF © Neoxia 2011 Formation 13
  14. 14. TOGAF ADM  La structure de base de l’ADM: © Neoxia 2012 Formation 14
  15. 15. Framework de contenu: Méta-modèle © Neoxia 2012 Formation 15
  16. 16. Framework de contenu: Méta-modèle © Neoxia 2012 Formation 16
  17. 17. Plan  Démarche de cartographie et d’architecture d’entreprise  Projet de mise en place de référentiel d’architecture  Utilisation et personnalisation des outils d’architecture  Utilisation du modèle de référence Frameworx (eTom, TAM, SID, TNA)
  18. 18. Projet d’Architecture d’Entreprise  La démarche d’architecture basé sur TOGAF ADM est une démarche: Continue (en terme de temps) Itérative (en terme de profondeur) Incrémentale (en terme de largeur) Dépasse le périmètre d’un projet  Ces caractéristiques impliquent le besoin de gérer ce chantier dans un programme avec plusieurs projets à périmètre défini et cerné
  19. 19. Définition du programme: Projets exemples • • Cadrage et structuration Cartographie de l’existant (catalogues, matrices et diagrammes) – – – – • Principes, standards, règles et bonnes pratiques – – – – • Métier Applicatifs Données Techniques Gouvernances et organisation de l’architecture – – – – • Métier Applicatifs Données Techniques Mission, rôles et responsabilité de l’architecture Rôle de l’architecture dans le projets Processus de l’architecture Template et modèle de l’architectures Orientations et recommandations pour la cible
  20. 20. Définition du programme : Projets • Projet 0 : Cadrage et structuration – Cadrage du besoin – Définition et validation du méta-modèle – Définition des livrables à restituer – Matrices – Diagrammes – Rapport – Personnalisation dans l’outil – Métamodèle – Livrables • Objectifs : – Cadrer le besoin – Structurer la démarche – Définir les livrables attendus
  21. 21. Définition du programme : Projets • Projet 1 : Cartographie globale de l’existant – Inventaire des éléments du SI (collecte) • Métier : chaine de valeur, domaines/fonctions, macro-processus, organisation • Applicatifs : Applications, Fonctionnalités, flux • Données : Base de données, Grand blocs de données • Techniques : Serveurs matériel et logiciels – Liens et dépendances – Mise en place du référentiel sur l’outil – Restitution • Matrices et diagrammes • Rapports • Objectifs : – – – – – Avoir plus de visibilité sur l’existant Assurer une vision transverse sur le SI Améliorer la gouvernance des éléments du SI Permettre une analyse d’écart et d’impact de premier niveau Alimenter les RFPs et accompagner les projet
  22. 22. Définition du programme : Projets  Projet 2 : Cartographie détaillée pilote (Gestion des réclamations)  Modélisation des processus  Détail de/des applications  Modélisation de la données  Liens et dépendances  Matrices et diagrammes  Dossier d’architecture  Objectifs :  Avoir plus de visibilité sur l’existant  Permettre une analyse d’écart et d’impact  Alimenter les RFPs et accompagner les projet  Supporter la définition du roadmap d’évolution
  23. 23. Définition du programme : Projets  Projet 3 : Définition des principes, standards, règles et bonnes pratiques (pilote : internet/intranet, échanges, workflow)  Partir du métier vers le technique  Catalogue des standards  Guide pratique pour les chefs de projet  Objectifs :  Orienter les choix futur  Alimenter les RFPs  Supporter les chefs de projet en terme de choix  Alignement des standards avec la stratégie
  24. 24. Définition du programme : Projets  Projet 4 : Gouvernance de l’architecture  Définition de la mission, rôle et responsabilité de l’architecture  Définition du rôle de l’architecture dans les projets  Définition des modèles et template pour les travaux d’architecture  Définition des processus d’alimentation et MAJ du référentiel  Objectifs :  Asseoir une bonne gouvernance  Assurer la MAJ du référentiel, son exhaustivité et sa cohérence  Supporter les chefs de projet
  25. 25. Lien avec les Dossier d’Architecture  Le référentiel est un regroupement de DA  Un DA est une vue partielle et temporelle du référentiel axée sur : Un domaine Une application Une plateforme © Neoxia 2012 Architecture 25
  26. 26. Lien avec les Dossier d’Architecture  Objectifs des DA : Maitriser l’existant Avoir plus de visibilité sur le SI Avoir un contenu pour les RFPs et les prestataires Construire de manière itérative et incrémentale le référentiel d’architecture Accompagner et supporter l’évolution du SI © Neoxia 2012 Architecture 26
  27. 27. Contenu du DA © Neoxia 2012 Architecture 27
  28. 28. Contenu du DA  Couches d’architecture concernées  Architecture fonctionnelle  Architecture applicative  Architecture de données  Architecture technique logicielle  Architecture technique matérielle (production)  Le DA doit également mentionner les exigences d’architecture  Performance  Sécurité  Haute disponibilité  Le contenu doit être limité aux aspects architecture et non spécification © Neoxia 2012 Architecture 28
  29. 29. Intervenants dans l’élaboration des DA  Equipe étude et développement (chefs de projet)  Aspect fonctionnel, applicatif et données  Equipe infrastructure (Administrateurs)  Aspect infrastructure logicielle et matérielle  Equipe de production  Aspect infrastructure matérielle et exigences d’architecture  Equipe Architecture  Aspects flux et intégration  Cohérence et consistance  Tous les aspects en termes de documentation  Fournisseurs  Aspect applicatif, donnée et logiciel (détail) © Neoxia 2012 Architecture 29
  30. 30. Deux mode d’alimentation/MAJ  Un mode release (déconnecté du projet) Prévoir 1 à 2 release annuelle Chaque release permettra d’alimenter et de mettre à jour des Das selon les priorités et les besoins Nécessite des ressources dédiées  Un mode projet (connecté au projet) Prévoir l’alimentation et la MAJ lors des phases projets Nécessite une modification des phases/livrables projets Un cout additionnel pour les projets Assuré par les ressources projet (internes et exeternes) Il faut prévoir une validation/information par l’équipe architecture © Neoxia 2012 Architecture 30
  31. 31. Processus liés aux DAs  Alimentation Elle doit se faire systématiquement pour les nouveaux projets Elle peut se faire de manière obligatoire à l’occasion d’une maintenance à fort impact  Mise à jour Elle doit se faire pour les maintenance à fort impact Elle peut se faire dans le cadre de releases périodiques (annuelle p.ex)  Deux option par rapport à ces processus Validation formelle par l’architecture Information de l’architecture © Neoxia 2012 Architecture 31
  32. 32. Exemple de modèle pour le DA  Modèle exhaustif à adapter (réduire probablement) pour garder une certaine flexibilité et agilité  Mapping avec Frameworx Architecture 32
  33. 33. DA et référentiel et outil d’architecture  Deux approches peuvent être adoptées Faire du DA l’élément d’entrée du référentiel  Pour cela il faut veiller au format et s’assurer qu’une bonne partie de l’information est tabulaire et conforme au métamodèle Faire du DA un élément de sortie du référentiel  Le DA peut être généré directement de l’outil à condition que les informations soient alimentées dans le référentiel  Il faut commencer par la 1ère approche et converger vers la deuxième © Neoxia 2012 Architecture 33
  34. 34. Plan  Démarche de cartographie et d’architecture d’entreprise  Projet de mise en place de référentiel d’architecture  Utilisation et personnalisation des outils d’architecture  Utilisation du modèle de référence Frameworx (eTom, TAM, SID, TNA)
  35. 35. Démarche globale © Neoxia 2012 Formation 35
  36. 36. Méta-modèle © Neoxia 2012 Formation 36
  37. 37. Méta-modèle © Neoxia 2012 Formation 37
  38. 38. Structuration du référentiel © Neoxia 2012 Formation 38
  39. 39. Architecture métier Modèle d’organisation Architecture métier Chaîne de valeurs Domaines/fonctions Macro-processus Objets métier Produits métier
  40. 40. Architecture métier : Chaîne de valeur  Définition  La chaîne de valeur peut se définir comme l’étude précise des activités de l’entreprise afin de mettre en évidence ses activités clés, c’est-à-dire celles qui ont un impact réel en termes de coût ou de qualité et qui lui donneront un avantage concurrentiel.  Usage  Identifier les domaines métier nécessitant d’être ciblés par la vision d’architecture et orientent l’effort d’architecture.  Fournir un vocabulaire commun grâce à un haut niveau de classification des activités métier.  Identifier les domaines d'investissement qui permettront de conduire à un avantage concurrentiel.  Constituer un point de départ incontournable pour la modélisation des activités du métier 40
  41. 41. Chaîne de valeur : exemple d’un organisme de distribution de crédit
  42. 42. Architecture métier : Domaines et fonctions  Définition  Le modèle de capacités métier fournit une décomposition de la chaine de valeurs en domaines et fonctions.  Il offre un niveau de détail plus tangible que la chaîne de valeur, ce qui est utile pour l'analyse et la gestion des exigences métier.  Usage  Fournir un langage commun pour décrire le métier.  Identifier les possibilités de réutilisation du métier en identifiant les activités communes avec le même objectif sous-jacent.  Comprendre les besoins métier pour le développement des architectures du système d'information.  Permet d’analyser le métier, identifier les domaines cibles prioritaires pour l'amélioration de la gouvernance.
  43. 43. Architecture métier : Domaines et fonctions
  44. 44. Architecture métier : Domaines et fonctions
  45. 45. Architecture métier : Domaines, fonctions et processus 45
  46. 46. Architecture métier : Objets métier  Définition L'objectif de l’information métier (appelée également les objets métier) est la compréhension des exigences en matière d'organisation de l’information pour améliorer l’efficacité du métier.  Usage Fournir une base pour l'analyse et le développement de l’architecture de données des systèmes d'information y compris les modèles conceptuels de données d'entreprise. Identifier et gérer les exigences de données métier. Aligner et gérer les modèles de données de l’entreprise au : Niveau opérationnel : applications de bases de données et les stocks opérationnels de données. Niveau décisionnel : Entrepôt de données d'entreprise (Datawarehouse et Datamarts.) Niveau d’intégration Inter-application : normalisation des flux internes et externes de la normalisation. 46
  47. 47. Architecture métier : exemple d’objets métier Objet métier Description Sous-types (s) Tiers o Prospect o Client o Avocat o Courtier o Apporteur d’affaire o Huissier Contrat Un tiers est un terme générique qui désigne tout intervenant impliqué à quel titre que ce soit dans les affaires gérées. Un tiers est caractérisé par son type (personne morale, personne physique, etc.) et son rôle (client, fournisseur de prestation, apporteur d’affaire, avocat, etc.). Bien qu'un tiers soit unique, il peut donc avoir plusieurs rôles. L’acte juridique sur lequel figure toutes les clauses o o relatives à une prestation. o Produit Contrat partenaire Il s’agit d’un package marketing intégrant un ou plusieurs produits et des prestations associées à ces produits Proposition Contrat prestataire Désigne les caractéristiques (TEG, durée, montant, barème, etc.) d’un type de produit proposé en vente aux clients Offre Contrat client Il s’agit d’un document délivré suite à une demande prestation, elle doit donner à demandeur une information complète sur les caractéristiques de la prestation proposée par le canal de distribution qui a traité la demande de prestation. 47
  48. 48. Architecture métier : Processus métier  Définition Un processus métier est un ensemble d'activités organisées, qui, lorsqu'il est exécuté fournit une sortie spécifique qui crée de la valeur pour l'entreprise et ses clients.  Usage  Au niveau de l'architecture d'entreprise, les processus fournissent:     Un mécanisme pour identifier les possibilités ou opportunités de réutilisation Un moyen d'identifier les domaines clés pour l'amélioration du métier Un point de départ pour l'identification des données nécessaires à l'exploitation du métier Un point de départ pour identifier les règles métier  Au niveau de l'architecture du SI, les processus fournissent:     Un alignement entre le métier et le SI. Un point central pour la définition des exigences métier. La définition des modèles de workflow et de l’orchestration. Les exigences des données et des règles métier. 48
  49. 49. Architecture métier : exemple de processus métier
  50. 50. Architecture métier : Services métier  Les services métier présentent un élément de base de l’architecture de l’entreprise, notamment les architectures orientées services.  Le rôle d'un service métier est d'offrir un ensemble cohérent de traitements métier.  Ces traitements concernent la représentation d’une activité métier élémentaire ou complexe.  Exemple  l’annulation d’une commande est un ordre simple de suppression. Cependant, les ordres de modification associés dans les systèmes CRM, Supply Chain et ERP (plan de fabrication ou comptabilité) sont représentés par un service plus complexe.  Un service métier peut être soit un service d'accès à des informations ou de données métier, soit un service de calcul et de vérification de règles métier, soit une composition des deux.  Un service métier vu par un processus peut combiner plusieurs services de granularité plus fine. Il s’agit ici d’une relation de composition/agrégation. La composition de services joue un rôle important pour construire d'autres services. 50
  51. 51. Matrices de dépendance Macro-services métier et macroprocessus métier Gestion Accueil d’une compagne Synthèse client Sélection des offres Configuration des offres Simulation des offres de prêt Création de proposition Scoring Création de marketing    Etude prise décision et Réalisation de échéances crédit  Recouvrement amiable et Traitement de Gestion dossier d’une en perte demande SAV                                  Calcul des     Qualification  des procédures judiciaires Traitement des  procédures Judiciaires Dispatching portefeuille   Notification de sinistre honoraires Calcul de pénalités Recouvrement contentieux de précontentieux  Facturation Remontée des Traitement monétique des  l’affaire Financement Modification de l’affaire impayés Alerte/notification client Gestion   51
  52. 52. Matrices de dépendance Macro-services métier et objets métier Synthèse Liste Config Simulation Création Scoring Création Modification Facturation Remontée Alerte/ Traitement Calcul Calcul Dispatch client des des des offres de affaire Affaire des Notif monétique des pénalité portefeuille offres offres de prêt proposition impayés client honoraires Tiers Contrat Avenant Demande de prêt Proposition Bien Prestation Canal de distribution Commission Participation Affaire Créance Sinistre Facture Règlement Support de financement Demande SAV Contact Produit Offre Carte                                                                          52 
  53. 53. Architecture applicative  Définition et validation des principes applicatifs  Définition de l’architecture applicative existante  Définition de l’architecture applicative cible et du gap  Mise en place des modèles d’architectures couvrants les éléments suivants : Plan d’urbanisme (cartographie) Architecture applicative et couverture fonctionnelle 53
  54. 54. Architecture métier : vue générale 54
  55. 55. Architecture applicative : couverture fonctionnelle au niveau de la chaîne de valeur 55
  56. 56. Architecture applicative : diagramme de l’architecture fonctionnelle  Présente la structure fonctionnelle d’une application :  organisé en plusieurs blocs (ou modules fonctionnels), chaque bloc décrit un ensemble de fonctionnalités présentant une cohérence fonctionnelle.  Présente le lien entre l'architecture métier et l'architecture applicative.  On distingue deux type de fonctions  Les fonctions purement métiers : doivent être logiquement au préalable identifiées dans le diagramme sous-domaines et fonctions de l'architecture métier, ou au minimum liés aux fonctions ou aux sousdomaines métiers de l'architecture métier.  Les fonctions applicatives : ont une connotation interne à l'application et ne sont pas liées à une fonction métier précise. Exemples :    Les fonctions de l'administration fonctionnelle ou technique de l'application, Les fonctions d'authentification/gestion des habilitation Les fonctions de recherche/consultation, etc. 56
  57. 57. Architecture applicative : exemple de diagramme de l’architecture fonctionnelle Module fonction nel Fonctio ns 57
  58. 58. Architecture applicative : diagramme de l’architecture applicative  Présente la structure de l'application en termes de composants applicatifs      Modules Batch Framework Services, etc. Décrit les liens/échanges entre cette application et les autres éléments du Système d'Information :     Bases de données Autres applications Acteurs internes et externes etc. 58
  59. 59. Architecture applicative : diagramme de l’architecture applicative Données utilisées : • Base de données • Référentiels de données • Fichiers Utilisat eurs Modu les Partenair Flux Batch externes es s 59
  60. 60. Architecture applicative : vue générale 60
  61. 61. Architecture technique : vue générale 61
  62. 62. Référentiel d’Architecture d’Entreprise : exemples de matrices de dépendance Applications VS Processus Processus 1 Process 2 Processus 3 Processus 5 Processus 4 Processus 6 Processus 7 APPL 1 APPL 2 APPL 3 APPL 4 APPL 5 APPL 6 APPL 7 APPL 8 Processus 1 Objets métier VS Processus Process 2 Processus 3 Processus 4 Processus 6 Processus 5 Processus 7 Objet métier 1 Objet métier 2 Objet métier 3 Objet métier 4 Objet métier 5 Objet métier 6 Serveurs matériel et logiciel VS Application APPL 1 Serveur Serveur Serveur Serveur Serveur Serveur Serveur Serveur Serveur matériel matériel matériel matériel matériel matériel matériel matériel matériel 1 1 2 2 2 3 4 5 5 Serveur Serveur Serveur Serveur Serveur Serveur Serveur Serveur Serveur APPL 2 APPL 3 Unités d’organisation VS Activités Unité d’organisation Unité d’organisation Unité d’organisation Unité d’organisation Unité d’organisation Unité d’organisation Unité d’organisation Unité d’organisation Unité d’organisation Unité d’organisation Unité d’organisation Unité d’organisation Unité d’organisation Unité d’organisation 1 2 3 4 5 6 7 8 9 10 11 12 13 14 APPL 4 APPL 5 APPL 6 APPL 7 APPL 8 APPL 9 APPL 10 APPL 11 APPL 12 APPL 13 APPL 14 1PPL 15 APPL 16 logiciel 1 logiciel 2 logiciel 3 logiciel 4 logiciel 5 logiciel 6 logiciel 7 logiciel 8 logiciel 6 Rôles VS Processus Proc 1 Rôle 1 Rôle 2 Rôle 3 Rôle 4 Rôle 5 Rôle 6 Rôle 7 Rôle 8 Rôle 9 Rôle 10 Rôle 11 Rôle 12 Rôle 13 Rôle 14 Proc 2 Proc 3 Proc 4 Serveurs matériels VS Sites Site 1 Site 2 Site 3 Site 4 Serv mat Serv mat Serv mat Serv mat Serv mat Serv mat Serv mat Serv mat Serv mat Serv mat Serv mat Serv mat Serv mat 1 2 3 4 5 6 7 8 9 10 11 12 13 Site 5 Site 6 Site 7 62
  63. 63. Référentiel d’Architecture d’Entreprise : exemples de rapports tabulaires Applications et modules Application Application 1 Application 1 Application 1 Application 2 Application 2 Application 3 Application 3 Application 3 Description Module Module 1.1 Module 1.2 Module 1.3 Module 2.1 Module 2.2 Module 3.1 Module 3.2 Module 3.3 Description Inventaires des applications Application Description Etat Plateforme OS Type Windows Se Progiciel Dév interne Application 1 En production Application 2 En production Java Linux Application 3 En production C Solaris Serveurs matériels-sites et réseaux Serveur matériel Site Réseau Serveur matériel 1 Site 1 LAN Serveur matériel 2 Site 1 DMZ Serveur matériel 3 Site 1 AFM Serveur matériel 4 Site 1 LAN Serveur matériel 5 Site 2 LAN Serveur matériel 6 Site 3 LAN Serveur matériel 7 Site 3 LAN Serveur matériel 8 Site 3 LAN 63
  64. 64. Référentiel d’Architecture d’Entreprise : exemples de rapport généré (modélisation de processus) 64
  65. 65. Personnalisation du méta-modèle © Neoxia 2012 Formation 65
  66. 66. Personnalisation du méta-modèle © Neoxia 2012 Formation 66
  67. 67. Alimentation automatique © Neoxia 2012 Formation 67
  68. 68. Alimentation automatique © Neoxia 2012 Formation 68
  69. 69. Plan  Démarche de cartographie et d’architecture d’entreprise  Projet de mise en place de référentiel d’architecture  Utilisation et personnalisation des outils d’architecture  Utilisation du modèle de référence Frameworx (eTom, TAM, SID, TNA)
  70. 70. Frameworx © Neoxia 2012 Formation 70
  71. 71. Frameworx © Neoxia 2012 Formation 71
  72. 72. Frameworx : eTOM © Neoxia 2012 Formation 72
  73. 73. Frameworx : TAM © Neoxia 2012 Formation 73
  74. 74. Frameworx : SID © Neoxia 2012 Formation 74
  75. 75. TOGAF et Frameworx © Neoxia 2012 Formation 75
  76. 76. Catalogues : Mapping eTOM, TAM, SID Domaine SousDomaine Fonction Description Segment Client Ligne produit Equivalent eTOM Gestion de la Support relation client Client Gestion des Fonction qui permet réclamations de saisir, modifier et consulter des réclamations client B2B/B2C Domaine Description Ligne produit Equivalent SID Entité Gestion de la Client relation client Segment Client Fonction qui permet de saisir, modifier et consulter des réclamations client Flux Source Destina Type Format tion d’échange (mapping SID) Temp s réel batch B2B/B2C Fréquence Technologie XML RTP Problem Handling Party, Customer Fonctions
  77. 77. Diagramme : Mapping TAM © Neoxia 2012 Formation 77

×