Architecture des Systèmes d ... -...

04/10/2015

1

Architecture des Systèmes d’Information

02 –Architecture Applicative

Master Informatique et Systèmes

Damien Ploix 2014-2015

Architecture des Systèmes d’Information – Introduction 2 Damien Ploix

Plan du chapitre

Architecture Applicative 1

Modélisation des composants applicatifs 1.1

Modélisation des interfaces 1.2

Architecture d’intégration applicative 2

Intégration des processus : EAI/ESB 2.1

Intégration des données : MDM 2.2

04/10/2015

2

Références sur ArchiMate

Site source d’AchiMate :

http://www.opengroup.org/subjectareas/enterprise/archimate

Logiciel de modélisation archi : http://archi.cetis.ac.uk/

Mastering Archimate edition II, Gerben Weirda

http://pubs.opengroup.org/architecture/archimate2-doc/toc.html


Démarche d’AA : Définition

Architecture Applicative

► Elle structure le SI en blocs applicatifs communicants

► Elle décrit sous l’angle technique les applications, les flux et les

messages échangés entre applications

Bloc applicatif (application componant)

► Module logiciel exécutable ayant une identité, proposant des services et

ayant une interface (prise) bien définie [Longépé]

► Chaque bloc offrant un service est responsable de la qualité de service

[Longépé]

► C’est un composant cohérent en communication avec d’autres

composants de l’application.

La démarche d’architecture applicative est itérative à partir d’une

vue globale (application(s)) jusqu’à l’identification des blocs

applicatifs unitaires.

► Chaque niveau donne lieu à une vue lui correspondant


http://www.opengroup.org/subjectareas/enterprise/archimate

http://archi.cetis.ac.uk/




04/10/2015

3

Démarche d’AA : méta-modèle Archimate


Pourquoi un méta-modèle de modélisation ?

► UML permet de modéliser l’architecture logicielle interne à une

application

• 13 diagrammes,

• Design pattern,

• …

► ArchiMate permet de

modéliser l’architecture SI

de l’entreprise et de

formaliser les liens entre les

différentes couches qui le

compose

Finalité des modélisation de l’architecture


04/10/2015

4


Cas d’usage : introduction « globale »

Introductory Viewpoint

Stakeholders Enterprise architects, managers

Concerns Make design choices visible, convince stakeholders

Purpose Designing, deciding, informing

Abstraction Level Coherence, Overview, Detail

Layer Business, Application, and Technology layers

Aspects Active structure, behavior, passive structure


04/10/2015

5



Quels métiers ?

Quoi?

Comment?

Avec quoi?

Architecture d’entreprise

Urbanisme

Architecture applicative

Architecture Technique

Architecture Applicative : méta-modèle Archimate


04/10/2015

6


Modélisation de l’application :

► Identifier les éléments qui agissent (application)

► Représenter leur comportement (fonction)

► Et les éléments qui sont sujet du comportement (données)

Par exemple : un Pickpocket (l’application) vole (la

fonction de l’application) un portemonnaie (la donnée)


Décomposition de l’application

La modélisation de la couche applicative Archimate

prend comme base la mise en relation d’un composant

(UML) avec la fonction qu’il porte et la donnée sur

laquelle il travail et l’interface qu’il expose à cette fin

(décomposition des classes UML).

L’application réalise un service via une interface. Ils sont

à rapprocher des cas d’usage UML.


Affectation

Composition Réalise

Accès

04/10/2015

7


Plan du chapitre







Démarche en 2 étapes d’Architecture Applicative

1. Décrire de façon détaillée (fonctionnelle et applicative)

chacun des blocs applicatifs.

2. Identifier les interfaces, les flux et messages échangés

entre les blocs applicatifs et en produire la matrice


04/10/2015

8

Décomposition de l’application

Exemple :

► L’application OpenOffice est un agrégat de plusieurs

composants dont OpenOffice Writer

► OpenOffice Writer est composée de l’interface IHM Office Writer

► OpenOffice Writer réalise la fonction d’édition de document

► Afin d’offrir le service de création de document

► Et opère sur la donnée le Document


Agrégation

Application Usage Viewpoint Stakeholders Enterprise, process, and application architects, operational managers

Concerns Consistency and completeness, reduction of complexity

Purpose Designing, deciding

Abstraction Level Coherence

Layer Business and application layers (see also Figure 4)

Aspects Behavior, active structure, passive structure (see also Figure 4)


04/10/2015

9

Point de vue : comportement de l’application


Stakeholders Enterprise, process, application, and domain architects

Concerns Structure, relationships and dependencies between applications, consistency and completeness, reduction of complexity

Purpose Designing

Abstraction Level Coherence, details

Layer Application layer (see also Figure 4)

Aspects Passive structure, behavior, active structure (see also Figure 4)

Application Co-operation Viewpoint Stakeholders Enterprise , process, application, and domain architects

Concerns

Relationships and dependencies between applications, orchestration/choreography of services, consistency and completeness, reduction of complexity

Purpose Designing

Abstraction Level Coherence, details


Aspects Behavior, active structure, passive structure (see also Figure 4)


04/10/2015

10

Application Structure Viewpoint Stakeholders Enterprise, process, application, and domain architects

Concerns Application structure, consistency and completeness, reduction of complexity

Purpose Designing

Abstraction Level Details


Aspects Active structure, passive structure (see also Figure 4)


Exemple 2 : application N-Tiers : du besoin aux composants

Exemple d’un ensemble d’application permettant aux

examinateurs externes de déclarer leurs rendez-vous et

de faire leur reporting.


Utilise

04/10/2015

11


Détails de la décomposition de l’application


04/10/2015

12

Vision globale d’une chaîne applicative : modélisation d’un ERP pour le

métier IT http://www.lean4it.com/


Architecture Applicative : autres formes de modélisations


04/10/2015

13

Mise en pratique

Modélisation ArchiMate d’une application M – V – C de

génération de graphes 3D

(WilmaScope : http://wilma.sourceforge.net)



Plan du chapitre







04/10/2015

14

Démarche en 2 étapes d’Architecture Applicative

1. Décrire de façon détaillée (fonctionnelle et applicative)

chacun des composant applicatifs.

2. Modéliser les interfaces, les flux et messages échangés

entre les composant applicatifs et en produire la matrice


Modélisation des interfaces : les interfaces utilisateur

On a besoin de modéliser l’application « utilisateur »

afin d’identifier l’ensemble des échanges (usages) des

services fourni par les interfaces


04/10/2015

15

Modélisation des interfaces : les échanges

Les échanges entre applications sont de deux types :

► Échanges de données

► Échanges de service

La modélisation de ces échanges utilisera :

► Les données pour l’échange de données,

► Les interfaces et les services pour les échanges de services.


Flow (échange)

Retour au fil conducteur :

► Focus sur l’interaction entre les différents composants du

système :

► Proposez une modélisation des échanges entre le workflow de

validation et les autres composants

Modélisation des interfaces


04/10/2015

16

Identification des interfaces : matrice de flux

La matrice de flux va identifier, pour chacune des

interfaces

► Caractéristique de l’interface

• Donnée métier / Service utilisé

• Format technique

• Protocole utilisé

► Composant source

• Fonctionnel (propriétaire/source de l’information)

• Technique (initiateur du flux technique (PULL/PUSH))

► Composant cible

• Fonctionnel (consommateur/destinataire de l’information)

• Technique (récepteur du flux technique)


Identification des interfaces : matrice fonctionnelle des flux


Identifiant Flux Composant Source Composant Cible Objet Métier Protocol Format Volumétrie Fréquence

CRMUSR1 Navigateur Internet Portail CRM HTTPS

ADMFAC1 Application Facturation Administration Contrats InformationsContratClient SOAP/HTTP XML

ADMFAC2 Administration Contrats Application Facturation Référentiel Taux Contractuels FTP CSV

ADMFAC1

ADMFAC2

04/10/2015

17

Identification des échanges : matrice de flux (exemple 2)



Plan du chapitre







04/10/2015

18

Démarche d’AA : répartition des blocs applicatifs dans des zones fonctionnelles

► Zone de pilotage : processus de

gouvernance et d’analyse

► Zones par métiers principaux de

l’entreprise

► Zones par métiers support


En parallèle à la modélisation de l’architecture, les différents blocs

suivent un regroupement « fonctionnel » en zone [Longépé] :

► Zone d’échange : regroupe les blocs applicatifs portant les fonctions

d’acquisition / restitution,

► Zone de gisement de données : informations dynamiques et pérennes de

l’entreprise,

► Zone de référentiel de données et de règles :

• Informations communes ayant un cycle de vie stable,

• Référentiel de règles communes


Plan du chapitre







04/10/2015

19

Brique applicative d’échange : intégration d’application

Cas d’usage

► Couplage d’application

► Simplification de la gestion des évolutions

► Gestion de l’asynchronisme

► Intégration avec un outil de supervision des processus métier

(BPMS/BAM)

Source : Entreprise Integration Patterns, Gregor Hohpe and Bobby

Woolf, Addison-Wesley


Intégration « point à point »

Échange de fichiers :

Partage d’une base de données :

Appel distant :


04/10/2015

20

Intégration via un bus de messages

L’intégration via un bus de messages décompose

l’échange en deux parties :

► Émission / consommation des messages par les applications

► Traitement interne du message au sein du bus d’échanges


Émission / consommation des messages

L’interaction entre l’application et le bus d’échange

est effectuée via un « adapter » intégré au bus

d’échanges compatible avec la technologie de

l’application (base de données, RPI/RPC, …) ► L’adapter défini la partie technique du contrat d’interface entre le bus

et l’application

Le mode d’échange entre une application et un bus

d’échange est soit émetteur (publisher) d’un message,

soit en attente (subscriber) de l’arrivée d’un message. ► Selon les cas de figure, les applications peuvent jouer les deux rôles.

La circulation des messages peux combiner plusieurs

systèmes EAI reliés via des ponts (Bridge) ► Différentes technologies (WebMethods, IBM, SAP, Microsoft)

► Différents « bus d’échanges » (EAI finance, EAI production, …)


04/10/2015

21

Traitement interne des messages : routage

Routage selon le contenu

Routage dynamique

► Cas d’usage :

• Répartition de charge

• Rotation des systèmes

• Gestion dynamique du

contenu

► Technique :

• Règles de routage dans l’EAI

• Règles de routage dans le

message


Traitement interne des messages : routage

Agrégation des retours

Routage complexe

► Via un bordereau de routage (routing slip)

► Via un gestionnaire de processus

► Via un broker de message


04/10/2015

22

Traitement interne des messages : transformation

Gestion de l’enveloppe (crypto, …)

Traitement du message :

► Fonction de la gestion de données de référence

(MDM) fournie par l’EAI

► Enrichissement / filtrage

► Normalisation et transcodage

► Passage par un format pivot

Point d’attention :

► L’intégration de logique métier dans l’EAI n’est pas

adaptée à tous les cas de figure (sauf en couplage

avec un BRMS)


Exemple d’intégration : gestion de cotation de prêt via un broker de messages


04/10/2015

23

Exemple d’intégration : gestion de cotation de prêt via un gestionnaire de processus


Définition et implémentation du

processus Instanciation du processus

EAI : en conclusion

L’intégration via l’implémentation des processus dans

l’EAI le transforme en BPM et permet la mise en œuvre

de BAM.

Attention aux cas d’usage :

► Différentiel de coût de 1 à 20 entre le point à point et l’EAI

► Le ROI intervient :

• En couplage avec un PBM,

• En cas de message one to many

• En cas d’interface ayant des contraintes d’agilité


04/10/2015

24


Plan du chapitre







Gestion de Données de Référence

Les concepts

► Données de référence

► Gestion des données de référence

Architecture et intégration

Projets et MDM


04/10/2015

25

Une définition

Parmi toutes les données en circulation dans le système

d’information, certaines sont plus critiques pour

l’activité métier car structurantes et largement partagées

(disséminées) entre plusieurs applications. Ce sont les

données de référence.

Référentiel client

► Contractuel (CRM)

► Commande

► Facturation

Référentiel de localisation géographique

► Adresses

Référentiel des fournisseurs

► Centralisation des achats pour un groupe, …

Référentiel des données de marcher

…


Caractéristiques des DR : typologie

• Elles peuvent être classifiées en types :

• « DR Maître » : objets métiers principaux (« cœur de

métier ») d’un domaine fonctionnel et structurante

pour l’ensemble des applications du domaine.

• « DR Constitutives » : entrent dans la composition de

plusieurs données maître (par ex. adresses).

• « DR Paramètre » : tables de valeurs ou nomenclature

(code postaux, code devises, taux des taxes, …)

partagées.

La différence entre maître et constitutive est

fonction du sujet d’analyse…


04/10/2015

26

DR : positionnement



Les concepts

► Données de référence

► Gestion des données de référence



04/10/2015

27

Des DR à la Gestion des DR (MDM)


Enjeux et besoins attendus du MDM

Cohérence globale

Unicité

Visibilité / disponibilité

Productivité / agilité

Contraintes réglementaires

Qualité

Sécurité


04/10/2015

28

Attendus du MDM


Qualité des données

Critères intrinsèques :

► Unicité

• Quelles données sont en doublons ?

► Complétude

• Quel attribut manque ou est inutilisable ?

► Exactitude

• Quelle donnée est incorrecte ?

► Conformité

• Quelle donnée est dans un format non prévu ?

► Cohérence

• Quelles données fournissent des informations conflicutelles ?

► Intégrité

• Quelle relation manque ?


04/10/2015

29


Critères de service

► Actualité

• Impact la modalité de transmission et d’acquisition dans les

contextes transactionnel / décisionnel.

► Accessibilité

► Pertinence

► Compréhensibilité



Critères de sécurité

► Disponibilité

► Intégrité

► Confidentialité

► Traçabilité


04/10/2015

30


Problématique de la qualité de données particulièrement

important dans le contexte multi-source :

► Conflit sémantiques

► Conflit de modèle

► Conflit de l’âge

► Conflit de mode opératoire sur le cycle de vie

► Conflit de modalité de diffusion

► Conflit de niveau de sécurité


Cycle de vie des données

Technique

Création

Mise à jour

Fusion (rapprochement

de données)

Historisation

Consommation

Archivage

Suppression logique

Suppression physique

Métier

Étude / prospect

Saisie / pré-Validation

Validation

Commercialisation

Arrêt de com.

En Extinction


04/10/2015

31


Les concepts


► Architecture

► Fonctions du MDM

► Solution pour le MDM


Situation des données de référence dans le SI

Processus amont :

Point d’acquisition d’une donnée

Source(s), états transitoires de validation,

contrôles de gestion, …

Processus aval :

Consommation de la donnée

Journalisation, diffusion (ETL, EAI, …)

Données Valides.

Point de

vérité

(MDM)


04/10/2015

32

Situation des GDR dans le SI

Situation dans la chaîne de l’information

► Référentiel en début de chaîne :

• Unique point de saisie de la donnée

• Passerelle entre un fournisseur de donnée externe

Point de vérité = point d’acquisition

Meilleurs situation possible

► Référentiel en milieu de chaîne :

• Récupère et réconcilie la donnée issue de points d’acquisition multiples

• Assure la redistribution des données et son contrôle qualitatif

► Référentiel en fin de chaine

• Assure les traitements qualitatifs de redressement et de rapprochement.

Souvent très complexes et coûteux à mettre en œuvre.


Typologies d’architectures MDM Consolidation

Consolidation : plusieurs sources alimentent le référentiel et

les points d’acquisition sont distincts du point de vérité.


04/10/2015

33

Typologies d’architectures MDM Répertoire Virtuel

Répertoire Virtuel : comparable à de la consolidation

avec une intermédiation de type EAI/ESB ou EII (BD

virtuelle).


Typologies d’architectures MDM Coopération

Coopération : consolidation avec un couplage fort

entre les applications source et la solution de

référentiel (font parties ou dépendent de)


04/10/2015

34

Typologies d’architectures MDM Centralisation

Centralisation : fusion du point d’acquisition et

du point de vérité.


Typologie d’architecture

La réalité est souvent une composition des patterns

selon les données (voir les parties de données).


04/10/2015

35

Critères de choix d’une architecture



Les concepts


► Architecture

► Fonctions MDM



04/10/2015

36

MDM et ED

il s’agit d’identifier où et comment sont portées les fonctions permettant la gestion

des données de référence


Fonctions MDM : acquisition

La fonction acquisition MDM clarifie la source d’une

donnée de référence et l’outille (cf positionnement du

« point de vérité »)

Pour chaque (caractéristiques des) données de

référence sera identifiée une source unique


04/10/2015

37

MDM : fonction validation

La fonction validation du MDM décrit les règles

permettant de valider une donnée. Ce sont les

►Règles syntaxiques,

►Règles de gestion,

►Règles de cohérence (par exemple, pour un objet

métier intégrant une donnée de référence paramètre).

►Règle d’identification unique d’une donnée

►Règles de transcodification

• Via des tables de correspondance entre les valeurs des deux

applications

• Via des mises en correspondance entre les ID des données entre

deux applications


Key mapping : transcodification d’ID

Instance / occurrence de données

Données historisées Données actuelles

ID d’instance 11223344 9922344

Identifiant UID 12345678 12345678

ID Application A PKI1123 PKI1123

ID Application B 002134 002134

Civilité M. M.

Nom Jean Jean

Prénom Dupuis Dupuis

Type voie Rue Avenue

Adresse Rue des chaumes Avenue du moulin

Code Postal 13100 13008

Localité Aix en Provence Marseille

La transcodification de l’ID peut alors être réalisé par

l’intermédiation ou par l’outils de MDM.


04/10/2015

38

Tables de transcodification de valeurs

Application A Application B

Attribut A Attribut 1 Attribut 2

FRA France Euro

CAD Canada Dollar

Lors de la transmission des données de A vers B, la valeurs des

Attributs 1 et 2 de l’application B seront fixés selon la valeur de

l’attribut A de l’application A (et inversement).


MDM : fonction de pilotage

La fonction pilotage est assurée par des outils (tableaux de bords,

…) basés sur la mise en place d’indicateurs, d’audits

(historisation/journalisation) et d’analyse d’impacts.

Par exemple, dans le cas d’intégration de données dans un ED,

cette fonction de pilotage se traduira principalement par la mise en

place d’indicateurs sur la mesure du taux de rejet des donnée

différenciée par les causes :

► obsolescence (une adresse pas vérifiée depuis plus d’un an à 10% de

chance d’être fausse),

► transcodification, format technique, cohérence, règle de gestion…

Du fait du volume, une analyse sur les causes possible doit être

réalisée préalablement.


04/10/2015

39

MDM : modèles et méta-données


MDM : fonction stockage et journalisation

Mise en œuvre de la base MDM sur les données

identifiées :

► Via un modèle normalisé intégrant, au besoin, les ID multiples

(correspondant à leur instanciation dans les applications

sources/consommatrices),

► Il peut également intégrer des dimension de contextualisation (cf

transcodification).

► Intégrant une journalisation de l’historique des données afin de

pouvoir porter les fonctions d’audit et de pilotage.

Un modèle dépendant du contexte de partage (dans sa

richesse fonctionnelle) mais, par exemple, qui simplifie

le processus de mise à jours des ED via l’historisation.


04/10/2015

40

MDM : fonction accès et diffusion

Le MDM ne se positionne pas uniquement en

tant que base de stockage d’un certain nombre

de données mais également en source et doit,

de ce fait, être interfacé via une IHM de gestion

et des composants d’intermédiation vers/depuis

les applications destinatrices/sources.


MDM : fonction administration et maintenance

Le positionnement du MDM comme « point de

vérité » lui impose les contraintes des

applications les plus strictes

►En terme de gestion des droits d’accès

►En terme de niveau disponibilité

Ce problème se retrouve également en point

central des difficultés rencontrées par le SOA :

►Problème de coût induit

►Problème de délégation de responsabilité

►Problème de niveau de disponibilité quasi impossible

à atteindre


04/10/2015

41


Les concepts


► Architecture

► Fonctions MDM



Outillage du MDM : quelle solution ?

Le MDM est souvent répartis entre plusieurs outils

couvrant tout ou partie des fonctions qu’il requière :

► DQM (Data Quality Managment)

► EII (Entreprise Information Integration)

► Annuaires

► CRM (Customer Relationship Managment)

► PLM (Product Lifecycle Managment)


04/10/2015

42

Relation DQM / MDM

Fonctions principales portées par le DQM :

►Nettoyage des données (normalisation, consolidation,

enrichissement, surveillance, analyse, profilage) en

fonction de règles spécifiques de gestion de la

qualité.

►Périmètre de données plus large que les données de

références

►Brique essentielle du MDM

Mais il manque :

►La persistance (stockage) : fonction de point de vérité

►À l’inverse, un MDM peu exister sans DQM mais il ne

garanti plus la qualité des données.


Relation EII / MDM

L’EII et le MDM ont des fonctions séparées et

complémentaires, le MDM référence les données alors que

l’EII les restitues sans harmonisation ni réconciliation ni

correspondance à une vérité unique.


04/10/2015

43

Annuaire et MDM

Les annuaires (LDAP principalement) permettent de

stocker des données hiérarchisées « spécialisées »

dans la gestion de l’identification

Même s’ils imposent une structure de données, ils ne

peuvent que servir de conteneur technique de données

au sein d’un MDM spécialisé sur ces sujets. Pas

constituer un MDM (couverture fonctionnelle trop faible).


Progiciel métier comme MDM

L’utilisation de progiciel métier (CRM, ERP, …) s’adapte

mal à porter la fonction de MDM car ils :

► Imposent le schéma de données

► Contraignent fortement les règles de gestion sur la qualité

► Ne couvrent pas une partie importante des fonctionnalités

attendues (key maping, pilotage, …).

► Imposent un rythme de mise à jour

Mais : adaptés si la couverture fonctionnelle est

suffisante, peu ou pas de besoin de pilotage ou de

gouvernance des données, intègre les processus métier

prioritaires.


04/10/2015

44

Solutions pour le MDM


Modes d’intermediation


Architecture des Systèmes d ... -...

Documents

Transcript of Architecture des Systèmes d ... -...