Interopérabilité des SI Urbanisation des Systèmes d’information Stéphane Tallard Le démarche...

1

Interopérabilité des SI

Urbanisation des Systèmes d’informationStéphane Tallard

Le démarche de l’urbanisation

Master 2 SIGLIS Interoperabilité des SI - Urbanisation

2Interoperabilité des SI - UrbanisationMaster 2 SIGLIS

Les liens entre les différentes vues

Vue fonctionnelle

Vue métier

Système d’information

Vue Applicative

Vue technique

Répartition des applications sur des infrastructures

Les applications supportent des activités liées aux processus de l’entreprise

Le SI participe à la chaîne de plus-value. Le SI est aligné sur le métier.

Le SI est supporté par des applications

Les fonctionnalités sont à disposition au travers des services applicatifs

Le SI est découpé en modules ayant des rôles fonctionnels

Les fonctionnalités assurent la couverture métier


Objectifs du cours

Comprendre et réaliser la cartographie d’un système

d’information en tenant compte des règles d’urbanisation

• Prendre en compte une demande et proposer une cartographie

d’un système d’information cible


Plan du cours

Architecture fonctionnelle

Architecture applicative

Architecture technique

Etude de cas


Définition : fonction

Une fonction du SI c’est un service que rend le SI

Une fonction peut s’appuyer sur une ou plusieurs

applications qui s’appuient sur un ou plusieurs dispositifs

techniques (serveur, salles informatiques, réseaux, …)



• Pour répondre à la question « De quoi est-ce que j’ai besoin ? » • Pour affranchir la réflexion d’un contexte applicatif• Pour affranchir la réflexion d’un contexte technique (Mac/PC, Linux/Microsoft, …) • Pour préparer la conception de l’architecture applicative: • Une fois que les fonctions sont clairement définies on peut

tenter de répondre à la question « Comment vais-je répondre à ces besoins ? »

Pourquoi réaliser une « architecture fonctionnelle » ?


Les familles de fonctions

Quelque soit les métiers d’une entreprise ou d’une organisation , on peut toujours structurer la liste des fonctions de son système d’information en familles:

opération;

échange;

gestion des données;

pilotage;

ressources.



• Ce sont les fonctions qui correspondent au métier d’une entreprise.

•Exemples • accorder un prêt • créer un produit • voir les photos de l’album XX du compte de YY

(facebook)

Les fonctions opération



• En entrée ou en sortie • sous forme de fichiers, • sous forme de fonctions offertes (type RMI), • …

• Exemples: • Extraire les codes produits du SI Gestion des

produits • Importer les temps de réparation standard du SI

gestion des garantie

Les fonctions d’échange



Les fonctions de gestion des données

Dans un SI, on classe les informations en deux catégories:

• les informations "privées", n'ayant pas vocation à être largement partagées au sein du SI• les informations "transverses", ayant vocation à être partagées• les informations variant "peu »

• Exemple : Client, Produit, Compte bancaire (il ne s'en crée pas 'souvent')

• les informations "à cycle de vie rapide", se renouvelant souvent• Exemple : Opération sur compte bancaire (il s'en crée très

'souvent‘)


Les familles de fonction

Les référentiels sont des applications centralisatrices des informations• fortement partageables sur le SI• stables - cycle de vie lent

Les gisements (ou ‘Puits de données') sont des applications centralisatrices des informations• fortement partageables sur le SI• à cycle de vie rapide




• En résumé, pour les données partageables : • les fonctions « gisement de données »• les fonctions « référentiels de données »


• On structure suivant les métiers, suivant le contexte



• Exemples de règles métier : • les clients ayant eu un volume de commandes >

500 000 euros sur l’année 2011 se verront accorder une remise de 15% sur leurs commandes de 2012 à condition que leur volume de commande soit > 300000 euros en 2012.

• L’acompte à la commande est de 10 % du total de la commande.

Les fonctions de gestion des règles métier



Les fonctions de pilotage

Les fonctions de pilotage permettent la régulation et le contrôle du Système opérant

Système de Pilotage

Système Opérant

Décision sur le SOInformations sur l’état du SO

Flux entrant Flux sortant



• Ce sont les fonctions dédiées à la gestion des ressources internes • Exemples:• gestion du parc informatique (liste des ordinateurs

et des logiciels installés) • comptabilité• ressources humaines

Les fonctions ressources


Les famille de fonctions : en résumé

Les fonctions opération

Les fonctions d’échange

Les fonctions de pilotage


Gestion de gisement des

données

Gestion des référentiels de

données

Gestion des règles métier

Les fonctions ressource



• Faire la liste des fonctions que doit supporter le SI • Respecter les règles d’urbanisation• Bien délimiter le périmètre de chaque bloc • Structurer ces fonctions suivant une décomposition arborescente: zone, quartier, îlot

quartier îlot

zone

Objectifs

• les noms des zones sont préfixés par z_• les noms des quartiers sont préfixés par q_• les noms des îlots sont préfixés par i_


Exercice: Les familles de fonctions

Pour chaque famille de fonctions (opération, échange, pilotage, ressource, pilotage, gisement de données, référentiel de données, règles), citer au moins une fonction du système d’information de Facebook. Regroupez les fonctions trouvées en zones, quartier, îlots.

Au total, vous devez recenser au moins 20 fonctions.


Exercice: Les familles de fonctions

Z-Echange

Z-opération

Z-Ressource

Z-Pilotage Z-Gestion des données

Q-Référentiel de données

Q-Référentiel de règles

Q-Gisement de données


Vue fonctionnelle: Règle d’urbanisme N°=1

• Un îlot appartient à un seul quartier

• Un quartier appartient à une seul zone

Un bloc fonctionnel ne doit pas être dupliqué

Règle d’unicité des blocs


Vue fonctionnelle: Règle d’urbanisme N°= 2

• Après avoir traité un évènement, un îlot peut en traiter immédiatement un autre sans avoir à se préoccuper de ce qu’il advient du compte rendu du traitement de l’évènement précédent

Règle d’asynchronisme des îlots

On procède comme si les compte rendus étaient traités par une autre fonction


Vue fonctionnelle: Règle d’urbanisme N°=3

• La prise peut activer les services du bloc

• La prise gère les communications entrantes et sortantes du bloc

Prise (Interface externe)

Un bloc comporte obligatoirement une prise (interface externe)



Toute communication entrante ou sortante d’un bloc passe par sa prise

Communication avec l’extérieur


Vue fonctionnelle: Règle d’urbanisme N°= 4 (suite)

• Encapsulation • l’intérieur d’un bloc fonctionnel est une boîte noire pour

l’extérieur • Réutilisation et mutualisation : un service public pour répondre

à des besoins identiques formulés par des demandeurs différents pouvant appartenir à des blocs distincts

• Modularité • On peut remplacer un module par un autre à condition qu’il

possède la même interface

• Réduction des impacts (effets dominos) • Si je modifie le bloc en ajoutant des interfaces, les appelants ne

sont pas impactés; • Si je modifie l’intérieur de mon bloc, les appelants ne sont pas

impactés.



Seules les prises communiquent avec le gestionnaire de flux

Communication avec le gestionnaire de flux



Une donnée est sous la responsabilité (création, modification, suppression, recherche) d’un îlot et d’un seul.

Ilots et données

Exemple: Seul l’ilot « gestion client » est responsable de la création, de la modification, de la destruction, de la recherche d’un client


Vue fonctionnelle: Règle de bonne pratique N°= 1

Toute architecture fonctionnelle comporte une zone d’échange

Zone d’échange

•La zone d’échange se comporte comme la prise du SI


Vue fonctionnelle: Règle de bonne pratique N°= 2

Toute architecture fonctionnelle comporte une zone gisement des données

Zone gisement des données

• Il y plusieurs options : • une seule zone gisement des données • plusieurs zones gisement des données localisées dans

les quartiers


Vue fonctionnelle: Règle de bonne pratique N°=3

Toute architecture fonctionnelle comporte une zone référentiel de données et de règles

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

•Référentiel de données•Référentiel de règles • Les règles métiers sont stockées dans un référentiel unique


Vue fonctionnelle: Règle de bonne pratique N°4

Toute architecture fonctionnelle comporte une zone pilotage unique

Zone pilotage unique

• La zone pilotage prend en compte les aspects décisionnels



Toute architecture fonctionnelle comporte une zone opération par métier de l’entreprise

Zones opération

Exemple: une société exerce dans le domaine de l’assurance, de l’assurance-vie et de la banque. On trouvera:• une zone opération assurance• une zone opération assurance-vie• une zone opération banque



Toute architecture fonctionnelle comporte une zone ressource unique

Zone ressource

• La zone ressource regroupe les systèmes dédiés à la gestion des ressources internes à l’entreprise (ressources humaines, comptabilité, …).


Plan du cours




Etude de cas


Définition : Bloc Applicatif

Un bloc applicatif est un objet logiciel concret qui, dans un contexte technique donné, offre à l’ensemble du SI, l'implémentation des fonctionnalités des prises définies par le bloc fonctionnel correspondant. Un bloc applicatif communique avec les autres blocs par échange de messages et par appel de services.

Le bloc applicatif est un ensemble de composants logiciels qui présentent une cohérence fonctionnelle : données et traitement sur les mêmes objets métiers, technique.



• Pour répondre à la question « Comment est ce que je vais répondre à mes besoins fonctionnels ? »

• Pour représenter les flux entre applications

• Pour se poser les questions :

• Les applications du SI existants sont elles satisfaisantes ?

• J’achète de nouvelles applications ?

• Je vais créer des applications spécifiques ?

Pourquoi réaliser une « architecture applicative » ?


Objectif de l’architecture applicative

• Proposer une structuration du SI en blocs communicants

• L’étude doit tenir compte des acteurs et de l’organisation

• Une bloc fonctionnel peut donner lieu à n blocs applicatifs

• Une bloc applicatif peut contribuer à l’implémentation de 1 à N blocs fonctionnels


Le Gestionnaire de flux

c’est le bus logiciel

Quatre fonctions:

• Acheminement des messages de l’émetteur vers le(s) destinataire(s)

• Stockage des messages avec gestion d’échéancier et de seuil

• Activation de procédures distantes à échéance (date, seuil) ou au fil de l’eau

• Transformation des messages; enrichissement et mise en forme


Le message

• C’est le mode de propagation entre blocs applicatifs d’un flux de données résultant d’un évènement de gestion

• flux interne (autre bloc applicatif) ou externe (extérieur à l’entreprise)

• Synchrone ou asynchrone


Front, middle et back office

.

• Ce sont les applications en contact avec le client de l’entreprise ou avec l’employé en contact avec le client de l’entreprise

• Exemple: Dans le domaine bancaire, le logiciel de demande de prêt

Front Office: vue client

• Ce sont les applications qui sont chargées des fonctions administratives associées à la production.

• Dans le domaine bancaire, le logiciel qui contrôle le paiement des mensualités, qui gère les aspects contractuels (envois de courriers, …)

Back Office: vue produit

• Ce sont les applications qui sont chargées de faire l’interface entre le front office et la back office.

• Dans le domaine boursier, le logiciel qui va contrôler la régularité des opérations et le respect des procédures de contrôle. Middle Office


Règle d’urbanisme N°1

Les données partagées des gisements de données doivent être historisées.

Gestion des processus

Le contexte: • un processus est constitué par plusieurs traitements pris en charge par

des applications différentes •Le problème: • lorsque une application échoue (pb réseau, chute d’un serveur, …) le

traitement est arrêté• la base est polluée par des données intermédiaires

La solution : • revenir à l’état « avant » en effaçant les données intermédiaires

produites • rejouer le processus si besoin



Les données des gisements de données doivent être accompagnées d’une date de publication de mise à jour.

Gestion des processus (2)

Le contexte: • un processus produit des données et modifie la base en conséquence

•Le problème: • On peut être amené à demander de rejouer le processus (données en

entrées incorrectes, lancement du processus par erreur, arrivée de nouvelles données dont il faut tenir compte ….

La solution: • revenir à l’état « avant » le début du processus en effaçant les

données produites • rejouer le processus



Les données des référentiels de données doivent être accompagnées d’une date de publication de mise à jour et aussi d’une date d’effet.

Gestion des processus (3)

Le contexte: • On doit revenir dans le temps sur les données des gisements de données

ou • A la suite d’une erreur, les nouvelles données du référentiel sont incorrectes

•Le problème: • Les données des gisements de données pointent sur des données du référentiel • Si les données du référentiel ont changé entre temps, on ne retrouve pas la base

dans l’état « avant » La solution : • historiser les données du référentiel • donner une date d’effet aux données du référentiel



Les données peuvent être dupliquées à condition que cela soit au niveau d’un même bloc. Le niveau gisement de données doit rester maître: la modification des données impose la publication du nouveau contexte.

Duplication des données



Le bloc offrant un service est le responsable de la qualité de service.

Qualité de service


Règle de bonne pratique N°1

Toute architecture applicative comporte une zone ordonnancement qui assure l’interface entre front office, back office et middle office.

FO, BO, MO

Cette zone assure:

• la traduction, l’ordonnancement et le pilotage des demandes du FO. Une demande du FO est traduite en un ensemble de services appelés dans un certain ordre au niveau de MO et BO

• le pilotage des processus internes au SI

• la gestion des priorités


Plan du cours




Etude de cas


Vue technique: Règle d’urbanisme N°1

Pour les flux engageant financièrement et/ou légalement la société, la communication entre tous les systèmes concernés doit être synchrone durant la phase de stockage mise à jour des gisements de données.

Intégrité des gisement de données (1)

C’est le seul cas où la communication synchrone est obligatoire



Toute mise à jour des gisements de données et toute émission vers l’extérieur de flux critiques doivent respecter les principes suivants• atomicité (tout ou rien) • cohérence à tout moment des gisements de

données• Caractère durable de la publication si elle réussit

Intégrité des gisement de données (2)



Les batch doivent être construits pour s’exécuter de manière concurrente aux processus transactionnels avec respect de la règle d’intégrité des gisements de données

Concurrence Batch/Transactionnel


On ne fait pas de doublons de composants logiciels.

Vue technique: Règle d’urbanisme N°=4

Source unique



Les gisements de données doivent se trouver sur une plate-forme centrale, sécurisée, accessible depuis une autre plate-forme.

Centralisation des gisements de données



On ne recourt à la duplication que lorsqu’il y a des contraintes impératives (performance, sécurité, charge réseau, exploitabilité …)

Non duplication


Plan du cours




Etude de cas


Une exemple simple

• L’entreprise : un opérateur de téléphonie mobile

•L’objectif: Augmenter la satisfaction client

•Le moyen (parmi d’autres) : changer le N°= de

téléphone d’un client en moins d’une heure

• Le travail : urbanisation du processus « Changement

du numéro de téléphone ».


Vision Métier

Identifier le client et

l’objet de sa demande

Consulter la situation et le statut du client

Attribuer un nouveau

numéro de téléphone

Authentifier le client

Contrôler la faisabilité de la

demande de changement de

numéro

Client et demande

identifiées

Situation et statut client

connus

Client authentifié

Changement de N°= faisable

Appel client

N° modifié

Effectuer un changement de numéro de téléphone


Vision fonctionnelle

Identifier le client et l’objet de sa

demande

• acceuillir le client •Identifier le client •Identifier sa demande

Consulter la situation et le statut client

•Consulter l’état de la ligne (suspension, restriction) • Consulter la valeur du client et son historique• Consulter les dossiers en cours

Authentifier le client

•Demander des élèments d’authentification

Contrôler la faisabilité de la demande

•Annoncer le coût de l’acte et du service selon le forfait du client

Attribuer un nouveau N°

•Sélectionner le type de N° souhaité (or, argent,…) •Réserver un N° disponible• Si besoin ajouter le service liste privée complémentaire •Historiser le contact

Client et demande

identifiées

Situation et statut client

connus

Client authentifié

Changement de N°= faisable


Vision applicative

Identifier le client

Consulter Situation

client

Consulter offres client

Réserver N° Changer N°

Application Maintenance client

Définition du périmètre d’une nouvelle application


Bilan de l’exemple

• On est passé du besoin au processus puis à une analyse fonctionnelle puis à une analyse applicative •Pas de cartographie du système cible

• Pas d’impacts sur la cartographie existante …

C’est un exemple simple !


Un texte ici

• Un texte ici •

Interopérabilité des SI Urbanisation des Systèmes d’information Stéphane Tallard Le démarche...

Documents

Transcript of Interopérabilité des SI Urbanisation des Systèmes d’information Stéphane Tallard Le démarche...