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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Synthèse du contenu de TOGAF
© Neoxia 2011
Formation
13

14. TOGAF ADM
 La structure de base de l’ADM:
© Neoxia 2012
Formation
14

15. Framework de contenu: Méta-modèle
© Neoxia 2012
Formation
15

16. Framework de contenu: Méta-modèle
© Neoxia 2012
Formation
16

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Contenu du DA
© Neoxia 2012
Architecture
27

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. 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. 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. 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. 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. 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. 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. Démarche globale
© Neoxia 2012
Formation
35

36. Méta-modèle
© Neoxia 2012
Formation
36

37. Méta-modèle
© Neoxia 2012
Formation
37

38. Structuration du référentiel
© Neoxia 2012
Formation
38

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. 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. Chaîne de valeur : exemple d’un organisme
de distribution de crédit

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. Architecture métier : Domaines et fonctions

44. Architecture métier : Domaines et fonctions

45. Architecture métier : Domaines, fonctions et
processus
45

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. 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. 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. Architecture métier : exemple de processus
métier

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. 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. 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. 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. Architecture métier : vue générale
54

55. Architecture applicative : couverture
fonctionnelle au niveau de la chaîne de valeur
55

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. Architecture applicative :
exemple de diagramme de l’architecture fonctionnelle
Module
fonction
nel
Fonctio
ns
57

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. 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. Architecture applicative :
vue générale
60

61. Architecture technique :
vue générale
61

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. 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. Référentiel d’Architecture d’Entreprise :
exemples de rapport généré (modélisation de processus)
64

65. Personnalisation du méta-modèle
© Neoxia 2012
Formation
65

66. Personnalisation du méta-modèle
© Neoxia 2012
Formation
66

67. Alimentation automatique
© Neoxia 2012
Formation
67

68. Alimentation automatique
© Neoxia 2012
Formation
68

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. Frameworx
© Neoxia 2012
Formation
70

71. Frameworx
© Neoxia 2012
Formation
71

72. Frameworx : eTOM
© Neoxia 2012
Formation
72

73. Frameworx : TAM
© Neoxia 2012
Formation
73

74. Frameworx : SID
© Neoxia 2012
Formation
74

75. TOGAF et Frameworx
© Neoxia 2012
Formation
75

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. Diagramme : Mapping TAM
© Neoxia 2012
Formation
77