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

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)
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)
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.
Architecture d’Entreprise Descriptive

Eléments de
l’architecture Eléments de
métier: l’architecture
•Chaine de valeur données:
•Ressources •Modèle conceptuel
•Donnée •ZonesSujet
•Processus •Entités
•Produits et services •Eléments
•Organisation •Relations

Eléments de
l’architecture Eléments de
applicative: l’architecture
•Framework technique:
•Interfaces •Plateformes
•Propriétés d’exploitation
•Composants •Plateformes
technologies
•Composants réseau
Architecture d’Entreprise Prescriptive

Principes
Alignés avec les Processus
exigences de la
stratégie
commerciale et Directives Architecture
d’Information
d’Entreprise

Normes
Politiques

Guider

Le choix + la création + la mise en œuvre

des solutions / l'orientation prise pour les
futures architectures
Formation 6
© Neoxia 2012
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
Livrables Descriptives

• Inventaires simples
Catalogues • Informations linéaires mais
riche

• Croisement de catalogues
Matrices • Dépendances et liens
• Analyse d’écart et d’impact

• Vues composites
Modèles ou • Zoom progressif
diagrammes • Perspectives par acteurs

Formation 8
© Neoxia 2012
Livrables Prescriptives

• Obligatoires • Obligatoire et doit

• Directeurs être respectés
• Permettent de • Validé formellement
définir la cible

Principes Règles

• Basés sur les • Ouverts

bonnes pratiques • Consensus au
• Recommandés niveau de l’industrie
“Nice to have” • Supportés
• Outillés

Guidelines Standards
Formation 9
© Neoxia 2012
Démarche globale

• Description de l’architecture • Matrices de dépendance

• Catalogues • Analyse d’écart
• Diagrammes
• Principes, standards, règles
et guidelines

Architecture Diagnostic de
actuelle l’existant

Roadmap de
Architecture
transformatio
cible
n

• Matrices de dépendance • Description de

• Analyse d’impact l’architecture
• Catalogues
• Diagrammes
• Principes, standards, règles
et guidelines
Formation 10
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 •Commencer “In the middle”, c’est-à-dire là où le métier et les
par l’équipe d’architecture au niveaux des services IT parlent le même langage puis remonter vers les processus
métier unitaires et les services applicatifs 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
Ingrédients de l’AE

•Standard Framework
•Ouvert

Processes • Création
• MAJ
• Gouvernance
• mesures

Personnes Outil • Standard

•Certifiés
•Expérimentés • Exhaustif
•Personnalisable
Synthèse du contenu de TOGAF

Formation 13
© Neoxia 2011
TOGAF ADM

 La structure de base de l’ADM:

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

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

Formation 16
© Neoxia 2012
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)
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é
Définition du programme: Projets
exemples
• Cadrage et structuration
• Cartographie de l’existant (catalogues, matrices et diagrammes)
– Métier
– Applicatifs
– Données
– Techniques
• Principes, standards, règles et bonnes pratiques
– Métier
– Applicatifs
– Données
– Techniques
• Gouvernances et organisation de l’architecture
– 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
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
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
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
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
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
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

Architecture 25
© Neoxia 2012
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

Architecture 26
© Neoxia 2012
Contenu du DA

Architecture 27
© Neoxia 2012
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
Architecture 28
© Neoxia 2012
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)

Architecture 29
© Neoxia 2012
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

Architecture 30
© Neoxia 2012
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
Architecture 31
© Neoxia 2012
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
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
Architecture 33
© Neoxia 2012
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)
Démarche globale

Formation 35
© Neoxia 2012
Méta-modèle

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

Formation 37
© Neoxia 2012
Structuration du référentiel

Formation 38
© Neoxia 2012
Architecture métier

Modèle d’organisation
Architecture métier

Chaîne de valeurs

Domaines/fonctions

Macro-processus

Objets métier

Produits métier
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
Chaîne de valeur : exemple d’un organisme
de distribution de crédit
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.
Architecture métier : Domaines et fonctions
Architecture métier : Domaines et fonctions
Architecture métier : Domaines, fonctions et
processus

45
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
Architecture métier : exemple d’objets métier

Objet métier Description Sous-types (s)

o Prospect
Tiers Un tiers est un terme générique qui désigne tout
o Client
intervenant impliqué à quel titre que ce soit dans
o Avocat
les affaires gérées. Un tiers est caractérisé par son
o Courtier
type (personne morale, personne physique, etc.) et
o Apporteur d’affaire
son rôle (client, fournisseur de prestation,
o Huissier
apporteur d’affaire, avocat, etc.). Bien qu'un tiers
soit unique, il peut donc avoir plusieurs rôles.
Contrat L’acte juridique sur lequel figure toutes les clauses o Contrat client
relatives à une prestation. o Contrat prestataire
o Contrat partenaire
Produit Désigne les caractéristiques (TEG, durée, montant,
barème, etc.) d’un type de produit proposé en
vente aux clients

Offre Il s’agit d’un package marketing intégrant un ou

plusieurs produits et des prestations associées à
ces produits

Proposition 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
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
Architecture métier : exemple de processus
métier
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
Matrices de dépendance
Macro-services métier et macro-
Gestion Accueil Etude et Réalisation Gestion Recouvrement Recouvrement Traitement de Gestion
d’une prise de amiable et contentieux d’une
processus métier
des dossier
décision
compagne échéances de précontentieux en perte demande
marketing crédit SAV
Synthèse client       
Sélection des
  
offres
Configuration des
offres  

Simulation des
 
offres de prêt
Création de

proposition
Scoring     
Création de
 
l’affaire
Financement  
Modification de l’affaire

Facturation     
Remontée des

impayés
Alerte/notification client
      
Notification de sinistre

Traitement monétique
 
Calcul des

honoraires
Calcul de pénalités
  
Qualification
des procédures 
judiciaires
Traitement des
procédures 
Judiciaires
Dispatching portefeuille
 
51
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
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
Architecture métier : vue générale

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

55
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 sous-
domaines 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
Architecture applicative :
exemple de diagramme de l’architecture fonctionnelle

Module
fonction
nel

Fonctio
ns

57
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
 Architecture applicative :
diagramme de l’architecture applicative

Données Utilisat Modu

utilisées : eurs les
• Base de Flux Partenair
Batch
données externes es
s
• Référentiels de
données
• Fichiers

59
Architecture applicative :
vue générale

60
Architecture technique :
vue générale

61
 Référentiel d’Architecture d’Entreprise :
exemples de matrices de dépendance

Applications VS Processus
Processus 1 Process 2 Processus 3 Processus 4 Processus 5 Processus 6 Processus 7
APPL 1
APPL 2
APPL 3
APPL 4
APPL 5
APPL 6
APPL 7
APPL 8
Objets métier VS Processus
Processus 1 Process 2 Processus 3 Processus 4 Processus 5 Processus 6 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 APPL 2 APPL 3 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
Serveur matériel 1 Serveur logiciel 1
Serveur matériel 1 Serveur logiciel 2
Serveur matériel 2 Serveur logiciel 3
Serveur matériel 2 Serveur logiciel 4
Serveur matériel 2 Serveur logiciel 5
Serveur matériel 3 Serveur logiciel 6
Serveur matériel 4 Serveur logiciel 7
Serveur matériel 5 Serveur logiciel 8
Serveur matériel 5 Serveur logiciel 6

Unités d’organisation VS Activités Rôles VS Processus Serveurs matériels VS Sites

Proc 1 Proc 2 Proc 3 Proc 4 Site 1 Site 2 Site 3 Site 4 Site 5 Site 6 Site 7
Unité d’organisation 1 Rôle 1 Serv mat 1
Unité d’organisation 2 Rôle 2 Serv mat 2
Unité d’organisation 3 Rôle 3 Serv mat 3
Unité d’organisation 4 Rôle 4 Serv mat 4
Unité d’organisation 5 Rôle 5 Serv mat 5
Unité d’organisation 6 Rôle 6 Serv mat 6
Unité d’organisation 7 Rôle 7 Serv mat 7
Unité d’organisation 8 Rôle 8 Serv mat 8
Unité d’organisation 9 Rôle 9 Serv mat 9
Unité d’organisation 10 Rôle 10 Serv mat 10
Unité d’organisation 11 Rôle 11 Serv mat 11
Unité d’organisation
Unité d’organisation
12
13
Rôle 12
Rôle 13
Serv mat
Serv mat
12
13
62
Unité d’organisation 14 Rôle 14
Référentiel d’Architecture d’Entreprise :
exemples de rapports tabulaires

Applications et modules
Application Description Module Description
Application 1 Module 1.1
Application 1 Module 1.2
Application 1 Module 1.3
Application 2 Module 2.1
Application 2 Module 2.2
Application 3 Module 3.1
Application 3 Module 3.2
Application 3 Module 3.3

Inventaires des applications

Application Description Etat Plateforme OS Type
Application 1 En production Windows Se Progiciel
Application 2 En production Java Linux Dév interne
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
Référentiel d’Architecture d’Entreprise :
exemples de rapport généré (modélisation de processus)

64
Personnalisation du méta-modèle

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

Formation 66
© Neoxia 2012
Alimentation automatique

Formation 67
© Neoxia 2012
Alimentation automatique

Formation 68
© Neoxia 2012
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)
Frameworx

Formation 70
© Neoxia 2012
Frameworx

Formation 71
© Neoxia 2012
Frameworx : eTOM

Formation 72
© Neoxia 2012
Frameworx : TAM

Formation 73
© Neoxia 2012
Frameworx : SID

Formation 74
© Neoxia 2012
TOGAF et Frameworx

Formation 75
© Neoxia 2012
Catalogues : Mapping eTOM, TAM, SID
Domaine Sous- Fonction Description Segment Ligne Equivalent
Domaine Client produit eTOM
Gestion de la Support Gestion des Fonction qui permet B2B/B2C Problem
relation client Client réclamations de saisir, modifier et Handling
consulter des
réclamations client

Domaine Entité Description Segment Ligne produit Equivalent SID

Client
Gestion de la Client Fonction qui permet de B2B/B2C Party, Customer
relation client saisir, modifier et
consulter des
réclamations client

Flux Source Destina Type Format Fréquence Technologie Fonctions

tion d’échange
(mapping SID)
Temp XML
s réel
batch RTP
Diagramme : Mapping TAM

Formation 77
© Neoxia 2012