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

50 %
50 %
Information about Démarche mise en place de référentiel d'architecture
Technology

Published on March 6, 2014

Author: mlakhdissi

Source: slideshare.net

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

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

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

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

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

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

Ingrédients de l’AE •Standard •Ouvert Framework Processes •Certifiés •Expérimentés Personnes • Création • MAJ • Gouvernance • mesures Outil • Standard • Exhaustif •Personnalisable

Synthèse du contenu de TOGAF © Neoxia 2011 Formation 13

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

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

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

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) – – – – • 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

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

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

Contenu du DA © Neoxia 2012 Architecture 27

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

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

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

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

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

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 © Neoxia 2012 Formation 35

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

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

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

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

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

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

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 utilisées : • Base de données • Référentiels de données • Fichiers Utilisat eurs Modu les Partenair Flux Batch externes es s 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 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

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

Référentiel d’Architecture d’Entreprise : exemples de rapport généré (modélisation de processus) 64

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

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

Alimentation automatique © Neoxia 2012 Formation 67

Alimentation automatique © Neoxia 2012 Formation 68

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

Frameworx © Neoxia 2012 Formation 71

Frameworx : eTOM © Neoxia 2012 Formation 72

Frameworx : TAM © Neoxia 2012 Formation 73

Frameworx : SID © Neoxia 2012 Formation 74

TOGAF et Frameworx © Neoxia 2012 Formation 75

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

Diagramme : Mapping TAM © Neoxia 2012 Formation 77

Add a comment

Related presentations

Related pages

Référentiel d’architecture d’entreprise : vous ne ...

... années pour mettre en place des référentiels d’architecture ? ... un référentiel d’architecture d ... la mise en place de standards ...
Read more

Une démarche qualité est-elle applicable en agence d ...

... l’UNSFA a mis en place les ... 9001 constitue le référentiel à partir ... une démarche qualité en agence d’architecture devient ...
Read more

4 Bonnes pratiques pour déployer un référentiel d ...

Pourquoi déployer un référentiel d’architecture ? ... 1 / Adoptez une démarche ... L’urbanisation du SI passe dans un premier temps par la mise en ...
Read more

Cadre Commun d’Architecture

La mise en place de référentiel de données ne consiste ... C’est précisément l’un des objectifs de la démarche permanente d’architecture d ...
Read more

Démarche qualité — Wikipédia

La mise en place d'une démarche ... La démarche qualité mise en place s’appuie sur un référentiel collectif intégrant un certain nombres de ...
Read more

Architecture d'entreprise TOGAF 9 niveau 2

... sur la mise en œuvre d’une démarche d’architecture d ... sur la démarche de mise en ... pratiques d'architecture d'entreprise référentiel ...
Read more

Architecture d’entreprise : le temps des illusions ...

... si elles adoptent une attitude plus « smart » dans leur mise en place et ... référentiel d’architecture et ... la démarche au ...
Read more

Haute qualité environnementale — Wikipédia

... qui peut être intégrée dans les offres d'architecture et d'ingénierie ... la démarche et à en ... a mis en place fin 2005 une ...
Read more