urbanisation des systèmes d’information architecture...

Urbanisation des Systèmes d’Information

Architecture d’Entreprise

04 – Architecture du SI : identifier et

décrire les services, structurer le SI

Master Informatique et Systèmes

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

Plan du chapitre

L’architecture fonctionnelle du SI1

Modélisation et automatisation3

L’approche « services » pour urbaniser le SI2

Définitions, règles, patterns1.1Gestion des données de référence (MDM)1.2Moteurs de règles (BRMS)1.3

Définitions2.1Spécification des services2.2Typologies de services2.3Gouvernance et référentiel de services2.4Normalisation sémantique2.5

Concepts et représentationAutomatisation (MDA)

3.13.2

Urbanisation des Systèmes d’Information et Architecture d’Entreprise – Architecture du SI 3 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� [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� [9] : Gartner's Seven Building Blocks of MDM : The Foundation for

Successful MDM


1

L’architecture fonctionnelle du SIDéfinitions, règles, patterns1.1Gestion des données de référence (MDM)1.2Moteurs de règles (BRMS)1.3


L’architecture fonctionnelle du SI

� Les processus métier d’un domaine ou de l’entreprise étant décrits, le Système d’Information doit permettre de réaliser ces processus.

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



� Comment passer d’un Système construit sur des applications monolithiques (« en silo »), sur un système « Plat de spaghetti » à un Système urbanisé ?



� Comment structurer le futur Système ? Quelles applications construire ?

� Quelques principes généraux : � Tout n’est pas dans tout ! � Regrouper ce qui est/semble proche� Identifier ce qui est commun à plusieurs/tous les métiers� …



� La solution : identifier les fonctions du Système d’Information et les « ranger » dans des blocs fonctionnels.

� Construire un plan d’urbanisme ou une architecture fonctionnelle cible

� Exemple :



� Fonction : action d’un produit ou de l’un de ses constituants exprimée exclusivement en termes de finalité (NF X 50-150)

� Quelques règles :� une fonction est formulée par un verbe à l’infinitif suivi

d’un ou plusieurs compléments.� 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, …



� L’architecture fonctionnelle est une représentation du Système d’Information qui doit garder une (relative) indépendance par rapport aux technologies.

� Horizon urbanisation = long terme � stabilité par rapport aux évolutions des technologies.



� Exemple : à partir d’un objectif stratégique : Faire rire !



� Décrire le(s) processus :

1 - SALUER

3 - METTRE LA TÊTEDANS LA GUEULE

2 - TOURNER

4- S'ECHAPPER



� Identifier les fonctions qui supportent le(s) processus

TOURNER

ENTRAÎNER

TRANSFORMER

TRANSFORMER

ALLER& VENIR

ALLER& VENIR


Les règles et pattern d’architecture fonctionnelle

� Vision de Longépé ([1])

� 3 types de blocs fonctionnels : zone, quartier, îlot.� Zone : 1er niveau de découpage du SI.� Quartier : regroupement de composants homogènes

quant à la nature de l’information traitée.� Îlot : entité remplaçable du SI, correspondant à une

finalité fonctionnelle et comprenant des traitements et des accès à des données pour cette finalité.

Zone

Quartier

Îlot



� Les règles d’urbanisme de Longépé ([1]) :► R1 : Règle d’unicité des blocs fonctionnels► R2 : Règle d’asynchronisme des îlots► R3 : Un bloc comporte obligatoirement une prise► R4 : Toute communication entrante ou sortante d’un bloc

passe par sa prise► R5 : Seules les prises communiquent avec le gestionnaire

de flux► R6 : Une donnée est sous la responsabilité d’un îlot et

d’un seul Zone

Quartier

Îlot



� D’après Longépé [1], un Système d’Information doit comporter au moins les zones suivantes :� une zone d’échange (la prise du SI),� une zone gisement de données,� une zone référentiel de données,� une zone pilotage unique,� une zone opération par métier principal de l’entreprise,� une zone ressource unique.



� Exemple de mise en œuvre des règles de Longépé :

Architecture fonctionnelle existante

Architecture fonctionnelle cible

http://blog.xebia.fr



� Exemple de mise en œuvre des règles de Longépé :

Architecture applicative existanteArchitecture applicative cible

http://blog.xebia.fr



� Les pattern d’architecture fonctionnelle d’OCTO ([5]) :� Le pattern Royaume-Emissaire� Le pattern Noyau� Le pattern Référentiel

� Autres pattern de OCTO ([4]) :� Modélisation document� Processus implicite/explicite� Agrégation IHM



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

� Les SI de la plupart des grandes entreprises se sont construits graduellement au cours des vingt dernières années sous forme d'applications indépendantes où les informations sont dupliquées.

� Il en résulte des incohérences, des saisies multiples et un service peu satisfaisant pour les utilisateurs et pour l'entreprise.



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

� Pour résoudre ces problèmes, il est souvent décidé de restructurer le système d'information autour de référentiels de données transverses accessibles et utilisés par l'ensemble des traitements informatiques.

� Ce choix impose le respect de principes de conception, sous peine de réintroduire les mêmes problèmes ou de rendre ingérable la complexité du système d'information.



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.



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.



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.



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



� Les principes d’architecture de Jean Paul Figer ([8]) :� Principe 4 : Unicité de la localisation du pilotage des

activités- L'utilisation du système d'information est modélisée sous forme

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.



� Les principes d’architecture de Jean Paul Figer ([8]) :� Principe 5 : Garantie de la cohérence fonctionnelleUne information est propriété de son service fonctionnel Silo qui est seul responsable de la garantie de sa cohérence fonctionnelle.



� Les principes d’architecture de Jean Paul Figer ([8]) :� Principe 6 : Asynchronisme des pilotes (ou l'illusion du

temps absolu pour les pilotes)Les services fonctionnels Pilotes ne peuvent présupposer qu'ils seront synchronisés sur une même base temporelle, en particulier vis à vis de 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.



� Les principes d’architecture de Jean Paul Figer ([8]) :� Principe 7 : Non-exclusivité des données (même de

manière temporaire)Les services fonctionnels Pilotes ne peuvent réserver, même de manière temporaire, un accès exclusif à une donnée d'un référentiel.



� Les principes d’architecture de Jean Paul Figer ([8]) :� Principe 8 : Services sans étatsLes 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).



� Les principes d’architecture de Jean Paul Figer ([8]) :� Principe 9 : référentiels passifsUn service fonctionnel Silo (référentiel) n'a pas vocation à avertir les autres SF Silo des modifications de ses données.



� Les règles d’or de l’urbanisation ([7]) :

� Règle 1 : Respecter les zones d’urbanismeTout système doit s’inscrire dans une seule zone d’urbanisme

� Règle 2 : Limiter les nouveaux développementsRéutiliser (au sens « mutualisation » et non « réplication ») plutôt qu’acheter, acheter plutôt que développer, développer seulement pour acquérir un avantage compétitif certain et durable.En cas de développement, il faut veiller à respecter les standards et normes de l’entreprise.

� Règle 3 : Contrôler les flux d’information entre applicationsLa gestion des échanges doit être pilotée par un bus de communication inter-applicatifs (type, EAI, ESB, MOM selon besoin).



� Les règles d’or de l’urbanisation ([7]) :

� Règle 4 : Partager les données communesLes données communes de l’entreprise sont contenues dans des bases dites référentielles.

� Règle 5 : Partager les traitements métiersLes traitements métiers doivent être encapsulés sous forme de services réutilisables.


1



Gestion des données de référence

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



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



► Conflit sémantique. Le même terme est interprété de manières différentes (ex : un « compte » est un compte courant bancaire dans une application et un identifiant utilisateur permettant de gérer la sécurité des accès pour une autre).

► Redondance de valeur. Le même concept est dupliqué dans plusieurs applications indépendantes (ex : le tarif catalogue des produits est représenté par N bases avec des recoupements sur certaines catégories de produits).

► Plus grande complexité du SI à assurer la sécurité, en ce qui concerne les habilitations. Dans une configuration de redondance de valeur, le cas classique est d’interdire l’accès à une donnée dans telle base en oubliant d’en interdire l’accès dans telle autre.

► Plus grande complexité du SI à assurer les mises à jour. Dans une configuration de redondance de valeur, nécessité de mettre à jour toutes les bases ou fichiers contenant cette donnée via des passerelles compliquées entre les différentes sources de données.



� Exemple d’acteurs liés aux référentiels :

Référentielbénéficiaires

Mise à jour

Création

Acteur(s) chargéde la création / mise à jour(acteur métier, ou dédié)

Flux externes

Liquidation Service Médical Gestion de dossiersmédico-

administratifs

Gestion des contrats

Services de consultation du référentiel

Données de références / procédures / services

Utilisateurs

InitiateursSous la responsabilité des

GestionnairesContrôleur

Mise à jourMise à jour



� Les référentiels les plus courants au sein des SI :► Référentiels clients,► Référentiels des nomenclatures,► Référentiels des produits,► Référentiel de l’organisation,► Référentiel de sécurité,► Référentiel des règles métier.



� Le MDM est une discipline visant à mettre en place les processus, les organisations et les outils pour rassembler, gérer et partager, de manière transverse, les données de référence.

� MDM = Master Data Management (Gestion de Données de 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.



� Différentes architectures du MDM :



� Différentes architectures du MDM :



� Les fonctions associées au MDM :



� Des outils du marché (cots) existent pour la gestion des données de référence.


1



Moteurs de règles

� Les Systèmes de Gestion des Règles Métiers (BRMS)


En résumé

� Le POS du SI permet de faire évoluer le SI de manière cohérente, vers une cible partagée par les projets.

� SI cible

SI existant

Trajectoire : état intermédiaire du SI


Étude de cas : Architecture d’Entreprise

� Étude de cas : TransalTaxi – Etape 6

� L’objectif de l’étude de cas est de proposer une architecture d’entreprise de TransalTaxi, et un système d’information urbanisé.

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

urbanisation des systèmes d’information architecture...

Documents