Plan du chapitre

1 L’architecture fonctionnelle du SI

Master Informatique et Systèmes

2 Règles et pattern d’architecture fonctionnelle
3 L’approche « services » pour urbaniser le SI
Urbanisation des Systèmes d’Information 4 Concepts et représentation
Architecture d’Entreprise
5 MDA

04 – Architecture du SI : identifier et
décrire les services, structurer le SI

Philippe Declercq 2012-2013

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 2 Philippe Declercq

Références

[1] : Le projet d’Urbanisation du SI, Christophe Longépé, édition Dunod

[2] : Livre orange « Urbanisation et intégration de Systèmes », Valtech

[3] : SOA – Architecture logique, Softeam

[4] : Architecture Orientée Services (SOA), une politique de
l’interopérabilité, Octo

[5] : Architecture de Systèmes d’Information, livre blanc, Octo

[6] : Urbanisation et SOA, Sopra L’architecture fonctionnelle du SI

[7] : Urbanisation et SOA, quelques bonnes pratiques pour leur mise en
œuvre, Aubay

[8] : Principes d’urbanisation pour un SI, Techniques de l’ingénieur, Jean-
Paul Figer
1

[9] : Gartner's Seven Building Blocks of MDM : The Foundation for
Successful MDM

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 3 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 4 Philippe Declercq
 L’architecture fonctionnelle du SI L’architecture fonctionnelle du SI

Les processus métier d’un domaine ou de l’entreprise étant
Comment passer d’un Système construit sur des
décrits, le Système d’Information doit permettre de réaliser applications monolithiques (« en silo »), sur un système
ces processus. « Plat de spaghetti » à un Système urbanisé ?

Démarches d’urbanisation : réorganiser le Système

d’Information en structurant ses fonctions dans des blocs
fonctionnels communicants.

Démarches SOA : réorganiser le Système Informatique en

structurant celui-ci en services.

Urbanisation et SOA se rapprochent en considérant que

l’élément de base d’un bloc fonctionnel est le service
(fonctionnel).
Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 5 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 6 Philippe Declercq

L’architecture fonctionnelle du SI L’architecture fonctionnelle du SI

Comment structurer le futur Système ? Quelles applications
La solution : identifier les fonctions du Système d’Information
construire ? et les « ranger » dans des blocs fonctionnels.

Quelques principes généraux :
Construire un plan d’urbanisme ou une architecture

Tout n’est pas dans tout ! fonctionnelle cible

Regrouper ce qui est/semble proche

Identifier ce qui est commun à plusieurs/tous les métiers
Exemple :

…

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 7 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 8 Philippe Declercq
 L’architecture fonctionnelle du SI L’architecture fonctionnelle du SI

Fonction : action d’un produit ou de l’un de ses constituants
L’architecture fonctionnelle est une représentation du
exprimée exclusivement en termes de finalité (NF X 50-150) Système d’Information qui doit garder une (relative)
indépendance par rapport aux technologies.

Quelques règles :

une fonction est formulée par un verbe à l’infinitif suivi
Horizon urbanisation = long terme  stabilité par rapport
d’un ou plusieurs compléments. aux évolutions des technologies.

la formulation de la fonction doit être indépendante des
solutions de la réaliser.

Exemples : contrôler une facture, calculer une plus-value,

archiver un dossier, authentifier un utilisateur, …

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 9 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 10 Philippe Declercq

L’architecture fonctionnelle du SI L’architecture fonctionnelle du SI

Exemple : à partir d’un objectif stratégique :
Décrire le(s) processus :
Faire rire !

2 - TOURNER

1 - SALUER

3 - METTRE LA TÊTE
4- S'ECHAPPER DANS LA GUEULE

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 11 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 12 Philippe Declercq
 L’architecture fonctionnelle du SI

Identifier les fonctions qui supportent le(s) processus

ALLER
& VENIR

ENTRAÎNER Les règles et pattern d’architecture

TOURNER
ALLER
fonctionnelle
& VENIR
2
TRANSFORMER
TRANSFORMER

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 13 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 14 Philippe Declercq

Les règles et pattern d’architecture fonctionnelle Les règles et pattern d’architecture fonctionnelle

Vision de Longépé ([1])
Les règles d’urbanisme de Longépé ([1]) :
► R1 : Règle d’unicité des blocs fonctionnels

3 types de blocs fonctionnels : zone, quartier, îlot. ► R2 : Règle d’asynchronisme des îlots

Zone : 1er niveau de découpage du SI. ► R3 : Un bloc comporte obligatoirement une prise

Quartier : regroupement de composants homogènes ► R4 : Toute communication entrante ou sortante d’un bloc
quant à la nature de l’information traitée. passe par sa prise

Îlot : entité remplaçable du SI, correspondant à une ► R5 : Seules les prises communiquent avec le gestionnaire
finalité fonctionnelle et comprenant des traitements et des de flux
accès à des données pour cette finalité. ► R6 : Une donnée est sous la responsabilité d’un îlot et
Zone d’un seul Zone

Quartier Quartier

Îlot Îlot

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 15 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 16 Philippe Declercq
 Les règles et pattern d’architecture fonctionnelle Les règles et pattern d’architecture fonctionnelle

D’après Longépé [1], un Système d’Information doit
Les pattern d’architecture fonctionnelle d’OCTO ([5]) :
comporter au moins les zones suivantes :
Le pattern Royaume-Emissaire

une zone d’échange (la prise du SI),
Le pattern Noyau

une zone gisement de données,
Le pattern Référentiel

une zone référentiel de données,

une zone pilotage unique,
Autres pattern de OCTO ([4]) :

une zone opération par métier principal de l’entreprise,
Modélisation document

une zone ressource unique.
Processus implicite/explicite

Agrégation IHM

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 17 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 18 Philippe Declercq

Les règles et pattern d’architecture fonctionnelle Les règles et pattern d’architecture fonctionnelle

Les neuf principes d’architecture de Jean Paul Figer ([8]).
Les neuf principes d’architecture de Jean Paul Figer ([8]).

Les SI de la plupart des grandes entreprises se sont
Pour résoudre ces problèmes, il est souvent décidé de
construits graduellement au cours des vingt dernières années restructurer le système d'information autour de référentiels de
sous forme d'applications indépendantes où les informations données transverses accessibles et utilisés par l'ensemble
sont dupliquées. des traitements informatiques.

Il en résulte des incohérences, des saisies multiples et un
Ce choix impose le respect de principes de conception, sous
service peu satisfaisant pour les utilisateurs et pour peine de réintroduire les mêmes problèmes ou de rendre
l'entreprise. ingérable la complexité du système d'information.

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 19 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 20 Philippe Declercq
 Les règles et pattern d’architecture fonctionnelle
Les neuf principes d’architecture de Jean Paul Figer ([8]) :

Principe 1 : Modularité et encapsulation
► Le Système d'Information est partitionné en sous-ensembles
fortement cohérents et faiblement couplés : les Services Fonctionnels
(SF).
► Le SI est segmenté suivant des critères fonctionnels par identification
de sous-ensembles fortement cohérents et faiblement couplés :
► fortement cohérents : les données et les traitements à l'intérieur
d'un sous-ensemble sont conceptuellement proches.
► faiblement couplés : une évolution d'un sous-ensemble impacte
au minimum les autres sous-ensembles.
Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI
Les règles et pattern d’architecture fonctionnelle
Les neuf principes d’architecture de Jean Paul Figer ([8]) :

Principe 2 : Sécurité
- La sécurité est fondée sur une infrastructure de confiance :
authentification réciproque des acteurs avant d'autoriser les échanges.
- Chaque SF gère ses propres règles d'autorisations.
- Une règle de sécurité stricte stipule que les flux de contrôle sont toujours
à l'initiative du destinataire. Chaque SF garde donc un contrôle total
sur ses données.
Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI
Les règles et pattern d’architecture fonctionnelle
Les neuf principes d’architecture de Jean Paul Figer ([8]) :

Les Services Fonctionnels sont de 2 types :
► Services Fonctionnels Silos (SFS): ils fournissent à l'ensemble du SI
les services liés à leurs données - c'est leur dimension silo de données
ou référentiels,
► Services Fonctionnels Pilotes (SFP) : ils fournissent la réalisation d'un
ensemble de traitements.

Les SF doivent masquer les détails internes de leur
implémentation, en particulier la structuration interne du
stockage de leurs données. Les SF ne donnent donc accès à
leurs données que via des offres de services précisément
décrites et publiées.
21 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 22 Philippe Declercq
Les règles et pattern d’architecture fonctionnelle

Les principes d’architecture de Jean Paul Figer ([8]) :

Principe 3 : Unicité de la localisation d'une information
- Une information est gérée en un point unique du système d'information.
- Il peut exister des copies des informations pour assurer l'archivage,
certains recoupements en temps différé ou d'autres raisons.
- En conséquence :
- Les modèles de données de référentiels sont disjoints deux à
deux,
- Chaque information du SI possède un URI qui vérifie les
propriétés suivantes :
- Non signifiance,
- Non modification,
- Non réutilisation,
- Non destruction.
23 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 24 Philippe Declercq
 Les règles et pattern d’architecture fonctionnelle Les règles et pattern d’architecture fonctionnelle

Les principes d’architecture de Jean Paul Figer ([8]) :
Les principes d’architecture de Jean Paul Figer ([8]) :

Principe 4 : Unicité de la localisation du pilotage des
Principe 5 : Garantie de la cohérence fonctionnelle
activités Une information est propriété de son service fonctionnel Silo qui est seul
- L'utilisation du système d'information est modélisée sous forme responsable de la garantie de sa cohérence fonctionnelle.
d'activités métier. Une activité métier est une unité de travail, telle que
vue par l'utilisateur final, et doit respecter la règle des 4 unités
suivante : unité de lieu, unité de temps, unité d'acteur et d'action.
- Toute activité métier est pilotée de bout en bout sans délégation par un
unique service fonctionnel Pilote (SFP), qui enchaîne des demandes
de services à des services fonctionnels Silo.

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 25 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 26 Philippe Declercq

Les règles et pattern d’architecture fonctionnelle Les règles et pattern d’architecture fonctionnelle

Les principes d’architecture de Jean Paul Figer ([8]) :
Les principes d’architecture de Jean Paul Figer ([8]) :

Principe 6 : Asynchronisme des pilotes (ou l'illusion du
Principe 7 : Non-exclusivité des données (même de
temps absolu pour les pilotes) manière temporaire)
Les services fonctionnels Pilotes ne peuvent présupposer qu'ils seront Les services fonctionnels Pilotes ne peuvent réserver, même de manière
synchronisés sur une même base temporelle, en particulier vis à vis de temporaire, un accès exclusif à une donnée d'un référentiel.
la mise à jour des données des référentiels.
En conséquence :
- Toutes les modifications des informations des référentiels sont
placées dans un historique,
- Les informations ne sont pas détruites mais marquées comme
invalides à partir d’une certaine date.

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 27 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 28 Philippe Declercq
 Les règles et pattern d’architecture fonctionnelle

Les principes d’architecture de Jean Paul Figer ([8]) :

Principe 8 : Services sans états
Les services fonctionnels Silo fournissent des offres de services sans
état - laissant toujours le référentiel dans un état cohérent.
Chaque activation du service est traitée de manière indépendante sans
référence aux précédentes activations des services du SF (autrement
que via les données stockées dans le référentiel).
Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI
Les règles et pattern d’architecture fonctionnelle

Zoom sur la zone référentiel, une zone primordiale et
prioritaire dans la mise en œuvre de l’urbanisation.

Définitions : référentiel de données :
► Ensemble structuré d'informations, utilisé pour l'exécution d'un logiciel,
et constituant un cadre commun à plusieurs applications.
► Ensemble cohérent de données ayant une définition sémantique
commune et répondant au besoin de langage commun entre plusieurs
acteurs appartenant à des entités organisationnelles différentes ou à
une même entité.
► Données qui, relativement stables et hautement partagées d’un
processus à l’autre, composent les informations fondamentales autour
desquelles l’entreprise structure son activité.
Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI
Les règles et pattern d’architecture fonctionnelle

Les principes d’architecture de Jean Paul Figer ([8]) :

Principe 9 : référentiels passifs
Un service fonctionnel Silo (référentiel) n'a pas vocation à avertir les
autres SF Silo des modifications de ses données.
29 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 30 Philippe Declercq
Les règles et pattern d’architecture fonctionnelle

Le besoin de gérer des données de référence provient
souvent d’une situation où plusieurs ensembles de données
co-existent et où leur multiplicité pose des problèmes de
cohérence.

L’existence de plusieurs bases de données relatives à un
même ensemble d’information se heurte, plus ou moins tôt,
à un ensemble de problèmes critiques :
► Conflit d’identité. Le même objet possède des identités différentes
selon les sources de données. (ex : le client X est identifié par la clé
X1 dans un référentiel et X2 dans un autre).
► Conflit de schémas. Le même concept est modélisé de manière
différente (ex : le client est modélisé par le champ « customer » d’un
coté, et par les deux champs « nom » et « prénom» par ailleurs).
► Conflit de valeur. Le même objet a des valeurs différentes selon les
sources (ex : la balance d’un compte courant apparaît différente
suivant les bases dans lesquelles on le consulte).
31 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 32 Philippe Declercq
 Les règles et pattern d’architecture fonctionnelle Les règles et pattern d’architecture fonctionnelle
► Conflit sémantique. Le même terme est interprété de manières
Exemple d’acteurs liés aux référentiels :
différentes (ex : un « compte » est un compte courant bancaire dans
Flux externes
une application et un identifiant utilisateur permettant de gérer la
sécurité des accès pour une autre). Données de références / procédures / services
Mise
► Redondance de valeur. Le même concept est dupliqué dans plusieurs Initiateurs à jou
r
applications indépendantes (ex : le tarif catalogue des produits est Sous la responsabilité des Contrôleur
représenté par N bases avec des recoupements sur certaines Gestionnaires Création
Référentiel
catégories de produits). bénéficiaires
Mise à jour
► Plus grande complexité du SI à assurer la sécurité, en ce qui
concerne les habilitations. Dans une configuration de redondance de
Acteur(s) chargé
valeur, le cas classique est d’interdire l’accès à une donnée dans telle de la création / mise à jour Services de consultation du référentiel
(acteur métier, ou dédié)
base en oubliant d’en interdire l’accès dans telle autre.
► Plus grande complexité du SI à assurer les mises à jour. Dans une
Gestion des Liquidation Service Médical Gestion de dossiers
configuration de redondance de valeur, nécessité de mettre à jour contrats médico-
administratifs
toutes les bases ou fichiers contenant cette donnée via des
passerelles compliquées entre les différentes sources de données. Utilisateurs

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 33 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 34 Philippe Declercq

Les règles et pattern d’architecture fonctionnelle Les règles et pattern d’architecture fonctionnelle

Les référentiels les plus courants au sein des SI :
Le MDM est une discipline visant à mettre en place les
► Référentiels clients, processus, les organisations et les outils pour rassembler,
► Référentiels des nomenclatures, gérer et partager, de manière transverse, les données de
► Référentiels des produits, référence.
► Référentiel de l’organisation,
► Référentiel de sécurité,

MDM = Master Data Management (Gestion de Données de
► Référentiel des règles métier.
Référence)

Le MDM offre :
► La mise à disposition de données de référence pour les
« consommateurs » de ces données dans le SI,
► Un worflow de gestion et mise à jour de ces données de
référence.

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 35 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 36 Philippe Declercq
 Les règles et pattern d’architecture fonctionnelle Les règles et pattern d’architecture fonctionnelle

Différentes architectures du MDM :
Différentes architectures du MDM :

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 37 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 38 Philippe Declercq

Les règles et pattern d’architecture fonctionnelle Les règles et pattern d’architecture fonctionnelle

Les fonctions associées au MDM :
Des outils du marché (cots) existent pour la gestion des
données de référence.

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 39 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 40 Philippe Declercq
 Étude de cas : Architecture d’Entreprise

Étude de cas : MyBestCar – Etape 6

L’objectif de l’étude de cas est de proposer une architecture

d’entreprise de MyBestCar, et un système d’information
urbanisé.
L’approche « service » pour

Travaux à réaliser : urbaniser le SI
► Diagramme de décomposition fonctionnelle,
► Diagramme d’évènement centré sur le processus de réservation. 3

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 41 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 42 Philippe Declercq

L’approche « services » pour urbaniser le SI L’approche « services » pour urbaniser le SI

Dans une vision « services » du SI, la brique de base pour

construire le SI est le service.

Les architectures fonctionnelles, applicatives, techniques

peuvent intégrer ce nouveau paradigme.

Vision Sopra

Vision Valtech
Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 43 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 44 Philippe Declercq
 L’architecture fonctionnelle du SI L’approche « services » pour urbaniser le SI

Exemples de méta-modèles de la couche fonctionnelle, à
base de services :

ALLER
& VENIR Mais au fait ….

ENTRAÎNER
TOURNER
Cas d’utilisation
0..n 0..n
Qu’est ce qu’un service ?
ALLER Un cas Un cas d’utilisation manipule
& VENIR d’utilisation
orchestre des
Des informations
1..n 1..n
services
TRANSFORMERService
fonctionnel
Information Qu’est ce qu’une architecture orientée service (SOA) ?
TRANSFORMER Un Objet de gestion 0..1
est décrit par un cycle de vie0..1
Cycle de vie des
informations

Analyse fonctionnelle
Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 45 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 46 Philippe Declercq

L’approche « services » pour urbaniser le SI L’approche « services » pour urbaniser le SI

Service : traitement normalisé, mutualisé et référencé au
Représentation externe/interne d’un service :
sein de l’entreprise, dont l’interface d’appel est décrite dans
un langage neutre (indépendant des technologies), et qui est
déployé physiquement sur un serveur ([2]).

L’interface d’appel d’un service est constituée de 1 à n

opérations qui constituent les traitements élémentaires et
atomiques proposés par le service.

Chaque service expose des opérations dont les paramètres

sont définis par des classes d’objets pivots.

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 47 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 48 Philippe Declercq
 L’approche « services » pour urbaniser le SI L’approche « services » pour urbaniser le SI

Contrat de service : chaque service est défini selon un
Les données d’échange sont les informations véhiculées
contrat, établissant les règles d’usage du service. entre les participants (consommateurs ou fournisseurs de
service) à travers l’invocation des opérations de service.

Un contrat de service spécifie un contrat d’interface et une
qualité de service attendue et admise par les parties
On parle de modèle d’objets « pivot ».
prenantes :
► Le contrat d’interface caractérise les conditions d’utilisation et

A distinguer des données persistantes.
garantit un service sans état à des fins de mutualisation (type de
traitement, données d’entrée et données de sortie, contraintes de
sécurité).
► La qualité de service porte sur la disponibilité (éventuelle via la mise
en place de solutions dégradées), la réactivité (temps de
latence/délai d’exécution, débit), la sécurité et, éventuellement, le
coût de fonctionnement.

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 49 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 50 Philippe Declercq

L’approche « services » pour urbaniser le SI L’approche « services » pour urbaniser le SI

Quelques caractéristiques d’un service :
Architecture Orientée Services : style d’architecture logicielle
pour lequel les processus métier de l’entreprise sont des
1. Couplage faible : les services sont connectés aux clients et autres composants logiciels paramétrable, orchestrant des tâches
services via des standards. avec les acteurs de l’entreprise et des appels à des
2. Langage commun : les données échangées par les services doivent composants de service pour s’exécuter ([2]).
être définies dans un dictionnaire de données commun, définissant
l’ensemble des objets pivot en entrée/sorties des services.
3. Composition : tout service doit être composable par les processus.
Service-oriented architecture (SOA) is a client/server
4. Réutilisation : chaque traitement métier doit être offert par un seul software design approach in which an application consists of
service. Ce besoin de réutilisation doit être traité au niveau d’une software services and software service consumers (also
gouvernance SOA au sein de l’entreprise. known as clients or service requesters). SOA differs from the
5. Référencé : chaque service est référencé dans un annuaire de services. more general client/server model in its definitive emphasis
6. Sans état : l’exécution d’un service est non-interruptible et ne dépend on loose coupling between software components, and in its
pas de son exécution précédente. use of separately standing interfaces (Gartner, 1996).

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 51 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 52 Philippe Declercq
 L’approche « services » pour urbaniser le SI L’approche « services » pour urbaniser le SI

L’architecture orientée service se base sur les principes
suivants ([3]) :
4. Mutualisation : favoriser la réutilisation de services métiers par
plusieurs lignes métiers ou applications. Permettre la construction de
services de haut niveau par combinaison de services existants.
1. Diviser pour régner : substituer la découpe strictement applicative par
une structuration en composants plus réduits et potentiellement plus simples
à faire évoluer. 5. Automatisation des processus métier : isoler la logique des
processus métiers sur des composants dédiés qui prennent en charge les
enchaînements et les échanges de flux d’information.
2. Alignement métier : construire et organiser le système à partir des
réalités métiers, qui doivent se retrouver dans ses constituants.
6. Échanges orientés Document : les informations échangées par
les services possèdent une structure propre, guidée par les besoins métiers.
3. Neutralité technologique : assurer une indépendance totale entre On privilégie la transmission de contenus complets et utilisables au profit
les interfaces et les implémentations. L’élément qui utilise un service ne doit
d’accès direct aux structures de type objet ou relationnel.
pas être contraint ni par la technologie d’implémentation, ni par sa
localisation (potentiellement distribué).

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 53 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 54 Philippe Declercq

L’approche « services » pour urbaniser le SI L’approche « services » pour urbaniser le SI

Pour que les composants de l’architecture puissent
Convergence des bénéfices attendus de l’urbanisation et de
communiquer de façon standard, il est nécessaire de mettre SOA : l’agilité du Système !
en place un système qui les mettent en relation.

Le Bus d’entreprise (ou ESB) agit comme la colonne

vertébrale reliant ces participants d’une manière banalisée à
travers les interfaces de services.

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 55 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 56 Philippe Declercq
 L’approche « services » pour urbaniser le SI L’approche « services » pour urbaniser le SI

Typologie de services : plusieurs modèles. Exemples :
Typologie de services, modèle de Valtech :

Services données : opérations de manipulation d’une classe d’objet
métier et application des règles de gestion associées.

Services composés : opérations nécessitant la manipulation de
divers objets métier par l’utilisation des services Données associés.

Schématiquement, les processus s’appuient sur un

ensemble de services de plus bas niveau et d’accès aux
données.

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 57 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 58 Philippe Declercq

L’approche « services » pour urbaniser le SI

Typologie de services, modèle de Softeam

Concepts et représentation

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 59 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 60 Philippe Declercq
 Concepts et représentations Concepts et représentations
ARIS SOA Architect

Pas de modèle standard

Des notations propriétaires proposées par les outils : MEGA,

ARIS, …

Des profiles UML 2

MEGA

SoaML

Archimate

Praxeme

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 61 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 62 Philippe Declercq

Concepts et représentations Concepts et représentations

Il existe des profiles UML 2 pour modéliser les services.
SoaML : Service Oriented Architecture Modeling Language.

Exemple : IBM
Standard de l’OMG pour la modélisation des architectures

Message Service
de services.
Order
Order Service
Provider

Header Body

Policy
Un profil UML.

Interaction Composition

Purchaser Order Service

Version béta "In Process« (décembre 2009).

Ordering
p : Purchaser
o : Order Service

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 63 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 64 Philippe Declercq
 Concepts et représentations Concepts et représentations

ArchiMate : langage de modélisation de l’Open Group pour
PRAXEME : la description de l’architecture des services se
l’architecture d’entreprise. fait en premier lieu dans l’aspect logique.

L’aspect logique a pour objectif de structurer au mieux le SI.

Les services sont obtenus par dérivation des modèles amont

(sémantiques et pragmatiques).

PRAXEME opte pour une approche SOA sur ses aspects

logique, technique et logiciel.

PRAXEME recommande UML pour modéliser les services

(classe, interface, état, paquetage).

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 65 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 66 Philippe Declercq

Étude de cas : Architecture d’Entreprise

Étude de cas : MyBestCar – Etape 7

L’objectif de l’étude de cas est de proposer une architecture

d’entreprise de MyBestCar, et un système d’information
urbanisé.

Travaux à réaliser : phase C – Architecture SI :

MDA
► Diagramme de communication inter-applications,
► Diagramme de localisation des applications et utilisateurs, 5
► Diagramme logique des données,
► Diagramme de dissémination des données.

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 67 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 68 Philippe Declercq
 MDA - principes MDA - principes

MDA : Model Driven Architecture

Démarche de développement proposée par l’OMG.

Permet de séparer les spécifications fonctionnelles d’un
Élaboration de différents

système des spécifications de son implémentation sur une modèles, en partant d'un modèle
plate-forme donnée. métier indépendant de
l'informatisation (Computation
Independent Model, CIM),
la transformation de celui-ci en modèle indépendant de la
plate-forme (Platform Independent Model, PIM) et enfin
la transformation de ce dernier en modèle spécifique à la
plate-forme cible (Platform Specific Model, PSM) pour
l'implémentation concrète du système.

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 69 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 70 Philippe Declercq

MDA - principes MDA - principes

Exemple de mise en œuvre ([6]) :
PRAXEME applique la démarche MDA, en considérant la

correspondance suivante :

CIM ≅ aspects sémantique et pragmatique

PIM ≅ aspect logique

PSM ≅ aspect logiciel

Dans TOGAF on peut considérer :

CIM est inclus dans la vue « Business architecture »

PIM est inclus dans la vue « Application architecture »

PSM est inclus dans la vue « Technical architecture »

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 71 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 72 Philippe Declercq
 MDA - principes MDA – exemples pour une architecture SOA

Pour mettre en œuvre MDA, il est nécessaire de posséder :
Qu’apporte MDA dans le cadre d’une architecture SOA ?

Des techniques de modélisation (règles de construction des
modèles CIM et PIM)

Sans entrer dans l’étude de l’ensemble des technologies

Des techniques de transformation (règles de transformation de du
modèle PIM en modèle PSM). disponibles pour implémenter une SOA, nous retiendrons

Et des outils ! trois éléments qui participent à la construction d’une SOA :
► XSD (XML Schéma Definition),
► WSDL (Web Services Description Language),
► BPEL (Business Proccess Execution Language).

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 73 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 74 Philippe Declercq

MDA – exemples pour une architecture SOA MDA – exemples pour une architecture SOA

XSD (XML Schema Definition) : schéma XML qui permet de
WSDL (Web Services Description Language) : description la
définir la structure d’un document XML. façon dont on peut accéder à un service web.

Dans une architecture SOA, permet de décrire la structure des
Définit de manière abstraite et indépendante du langage l'ensemble
données échangées entre services. des opérations et des messages qui peuvent être transmis vers et

La modélisation des données d’échange peut se faire en UML, ou depuis un service web donné.
dans un langage spécifique à un outil.
Équivalent à l’interface ou le contrat du service.

Modélisation sous MODELIO Fichier XML

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 75 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 76 Philippe Declercq
 MDA – exemples pour une architecture SOA MDA – exemples pour une architecture SOA

WSDL
BPEL (Business Process Execution Language) : pour définir
et gérer les orchestrations de processus.

Orchestration : collaboration entre deux ou plusieurs services, mise
en place et/ou gérée (orchestré) par un tiers - en l'occurrence, BPEL.

Ce dernier prend en charge la séquence complète d'invocations des
divers services, ou "collaborateurs".

Chaque processus BPEL dispose par ailleurs de sa propre définition
WSDL. Un processus BPEL est donc un service Web à part entière.

Dans une démarche MDA, le BPEL est généré à partir d’un
Modélisation sous MODELIO
diagramme BPMN.

Un service BPEL s’exécute sur un « moteur » BPEL.

Fichier XML

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 77 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 78 Philippe Declercq

MDA – exemples pour une architecture SOA Étude de cas : Architecture d’Entreprise

BPEL

Étude de cas : MyBestCar – Etape 8

Modélisation
sous MODELIO
L’objectif de l’étude de cas est de proposer une architecture
d’entreprise de MyBestCar, et un système d’information
urbanisé.

Travaux à réaliser : phase C – Architecture SI :

Fichier XML ► Diagramme des données de service.

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 79 Philippe Declercq Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 80 Philippe Declercq