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

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)

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

données:

•Modèle conceptuel

•ZonesSujet

•Entités

•Eléments

•Relations

Eléments de

l’architecture

applicative:

•Framework

•Interfaces

•Propriétés

•Composants

Eléments de

l’architecture

technique:

•Plateformes

d’exploitation

•Plateformes

technologies

•Composants réseau

Architecture d’Entreprise Prescriptive

© Neoxia 2012 Formation 6

Directives

Principes

Processus

Politiques

Normes

Architecture

d’Entreprise

Alignés avec les

exigences de la

stratégie

commerciale et

d’Information

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

des solutions / l'orientation prise pour les

futures architectures

Guider

Démarche globale

Une méthodologie structurante de la

démarche architecture d’entreprise:

Formation 7

Quel plan pour aller

de là où on est à là

où on veut aller?

Livrables Descriptives


• Inventaires simples

• Informations linéaires mais riche

Catalogues

• Croisement de catalogues

• Dépendances et liens

• Analyse d’écart et d’impact Matrices

• Vues composites

• Zoom progressif

• Perspectives par acteurs

Modèles ou diagrammes

Livrables Prescriptives


• Obligatoires

• Directeurs

• Permettent de définir la cible

Principes

• Obligatoire et doit être respectés

• Validé formellement

Règles

• Basés sur les bonnes pratiques

• Recommandés “Nice to have”

Guidelines

• Ouverts

• Consensus au niveau de l’industrie

• Supportés

• Outillés

Standards

Démarche globale

Formation 10

• Description de l’architecture

• Catalogues

• Diagrammes

• Principes, standards, règles et guidelines

• Matrices de dépendance

• Analyse d’impact

• Matrices de dépendance

• Analyse d’écart

• Description de l’architecture

• Catalogues

• Diagrammes

• Principes, standards, règles et guidelines

Architecture actuelle

Diagnostic de l’existant

Architecture cible

Roadmap de transformatio

n

Approches d’urbanisation

Top-down

•Commencer par les processus métier et descendre en niveau de granularité jusqu’à arriver aux services techniques

Middle-out

•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

Meet in the middle

•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

11

Outil • Standard

• Exhaustif

•Personnalisable

Personnes •Certifiés

•Expérimentés

Processes • Création

• MAJ

• Gouvernance

• mesures

•Standard •Ouvert

Framework

Ingrédients de l’AE

Synthèse du contenu de TOGAF


TOGAF ADM

La structure de base de l’ADM:


Framework de contenu: Méta-modèle


Plan


d’entreprise


d’architecture


d’architecture



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


• 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


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


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


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


Contenu du DA


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


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


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


Plan


d’entreprise


d’architecture


d’architecture



Démarche globale


Méta-modèle


Structuration du référentiel


Chaîne de valeurs

Domaines/fonctions

Macro-processus

Objets métier

Produits métier

Arc

hite

ctu

re m

étie

r

Modèle d’organisation

Architecture métier

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

Architecture métier : Chaîne de valeur

Chaîne de valeur : exemple d’un organisme

de distribution de crédit

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

45

Architecture métier : Domaines, fonctions et

processus

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 : Objets métier

47

Objet métier Description Sous-types (s)

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

o Prospect

o Client

o Avocat

o Courtier

o Apporteur d’affaire

o Huissier

Contrat L’acte juridique sur lequel figure toutes les clauses

relatives à une prestation.

o Contrat client

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.

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

Architecture métier : exemple de processus

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

Architecture métier : Services métier

Matrices de dépendance

Macro-services métier et macro-

processus métier

51

Gestion

d’une

compagne

marketing

Accueil Etude et

prise de

décision

Réalisation Gestion

des

échéances de

crédit

Recouvrement

amiable et

précontentieux

Recouvrement

contentieux

Traitement de

dossier

en perte

Gestion

d’une

demande

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

Matrices de dépendance

Macro-services métier et objets métier

52

Synthèse

client

Liste

des

offres

Config

des

offres

Simulation

des offres

de prêt

Création

de

proposition

Scoring Création

affaire

Modification

Affaire

Facturation Remontée

des

impayés

Alerte/

Notif

client

Traitement

monétique

Calcul

des

honoraires

Calcul

pénalité

Dispatch

portefeuille

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

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

Cartographie des flux applicatifs

Architecture orientée service

Architecture d’intégration

Identification des principaux services

applicatifs

Mise en place d’un outil de gestion du

portefeuille applicatif (APM)

54

Architecture métier : vue générale

55

Architecture applicative : couverture

fonctionnelle au niveau de la chaîne de valeur

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

57


exemple de diagramme de l’architecture fonctionnelle

Module fonctionnel

Fonctions

58


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.

59


diagramme de l’architecture applicative

Données utilisées : • Base de données • Référentiels de données • Fichiers

Flux externes

Partenaires

Modules

Batchs

Utilisateurs

60


vue générale

61

Architecture technique :

vue générale

62

Référentiel d’Architecture d’Entreprise :

exemples de matrices de dépendance

Applications VS Processus

Objets métier VS Processus

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

Serveurs matériel et logiciel VS Application

Processus 1 Processus 3 Processus 7 Processus 6 Processus 5 Processus 4 Process 2 APPL 1

APPL 2

APPL 3

APPL 4

APPL 5

APPL 6

APPL 7

APPL 8

Objet métier 1

Objet métier 2

Objet métier 3

Objet métier 4

Objet métier 5

Objet métier 6

Processus 1 Processus 3 Processus 7 Processus 6 Processus 5 Processus 4 Process 2

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 matériel 1

Serveur matériel 2

Serveur matériel 2

Serveur matériel 2

Serveur matériel 3

Serveur matériel 4

Serveur matériel 5

Serveur matériel 5

Serveur logiciel 1

Serveur logiciel 2

Serveur logiciel 3

Serveur logiciel 4

Serveur logiciel 5

Serveur logiciel 6

Serveur logiciel 7

Serveur logiciel 8

Serveur logiciel 6

Unité d’organisation 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

Serv mat 1

Serv mat 2

Serv mat 3

Serv mat 4

Serv mat 5

Serv mat 6

Serv mat 7

Serv mat 8

Serv mat 9

Serv mat 10

Serv mat 11

Serv mat 12

Serv mat 13

Site 1 Site 2 Site 3 Site 4 Site 5 Site 6 Site 7 Proc 1 Proc 2 Proc 3 Proc 4

63

Référentiel d’Architecture d’Entreprise :

exemples de rapports tabulaires

Inventaires des applications

Applications et modules

Serveurs matériels-sites et réseaux

Application Description Module Description

Application 1 Module 1.1








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

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






64

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

Personnalisation du méta-modèle


Alimentation automatique


Plan


d’entreprise


d’architecture


d’architecture



Frameworx


Frameworx : eTOM


Frameworx : TAM


Frameworx : SID


TOGAF et Frameworx


Catalogues : Mapping eTOM, TAM, SID

Domaine Sous-

Domaine

Fonction Description Segment

Client

Ligne

produit

Equivalent

eTOM

Gestion de la

relation client

Support

Client

Gestion des

réclamations

Fonction qui permet

de saisir, modifier et

consulter des

réclamations client

B2B/B2C

Problem

Handling

Domaine Entité Description Segment

Client

Ligne produit Equivalent SID

Gestion de la

relation client

Client Fonction qui permet de

saisir, modifier et

consulter des

réclamations client

B2B/B2C

Party, Customer

Flux Source Destina

tion

Type Format

d’échange

(mapping SID)

Fréquence Technologie Fonctions

Temp

s réel

XML

batch RTP

Diagramme : Mapping TAM


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

Technology