Cours chapitre2 2012

Copyright © Yves Caseau – 2012 - Cours Polytechnique (II) 1/26

Théorie et Pratique du Système Théorie et Pratique du Système d’Informationd’InformationDeuxième Chapitre: Architecture du SIDeuxième Chapitre: Architecture du SI

Janvier - Mars 2012Ecole Polytechnique

Yves Caseau


Plan du Cours – Architecture du Système Plan du Cours – Architecture du Système d’Informationd’Information

Première partie:Qu’est-ce que l’architecture ?

Deuxième partie: Etablir une architecture cible

Troisième partie:Urbanisation du Système d’Information


Qu’est-ce qu’une architecture ?Qu’est-ce qu’une architecture ?

Définition du terme “architecture” ( ANSI/IEEE Std 1471-2000 ): "The fundamental organization of a system, embodied in its

components, their relationships to each other and the environment, and the principles governing its design and evolution.“

Pour l’ “Open Group Architecture Forum”, deux sens conjoints: A formal description of a system, or a detailed plan of the system at

component level to guide its implementation The structure of components, their inter-relationships, and the

principles and guidelines governing their design and evolution over time.

Pour le CEISAR En premier lieu, un outil de communication

« Une architecture » correspond à une finalité d’un système sous deux modalité:

opération/ transformation Une cible (acte de communication)

Pre

miè

re P

art

ie:

l’A

rch

itectu

re d

u S

I


Objectifs d’une architectureObjectifs d’une architecture

Communiquer au service d’une idée Principal outil de transformation

Favoriser la réutilisation Réduire les coûts et la complexité Support de standardisation

Communication entre parties prenantes Éviter les outils et les formalismes complexes (dépend du niveau de

maturité de l’entreprise) Communication « asynchrone / diachronique »

Rôle de mémoire Simplifie les évolutions

Pre

miè

re P

art

ie:

l’A

rch

itectu

re d

u S

I


Architecture logicielle et architecture de SIArchitecture logicielle et architecture de SI

Architecture Logicielle (cf. 3e cours) Décomposition en composants/ sous-composants Approches objets/ services / modules

Architecture du SI Vision macroscopique Top-down (ex: cartographie fonctionnelle) et bottom-up (des objets

métiers aux services) Architecture « logique » et « physique »

Architecture « logique » – Architecture « métier » (processus / objets métiers)– Architecture fonctionnelle / service

Architecture « physique »– Architecture applicative– Architecture système

Pre

miè

re P

art

ie:

l’A

rch

itectu

re d

u S

I


Architecture de donnéesArchitecture de données

Référentiel de données Référentiel sémantique: qu’est-ce qu’un client, etc? Modèle conceptuel de données: qu’est-ce qui constitue un client Ontologie: modèle de classes (UML) Outil fondamental de partage dans l’entreprise

Architecture de données Répartition Formats (ex: XML) Cycle de vie

Architecture dynamique de donnée (cf. 7e cours) Distribution / synchronisation Sauvegarde / restauration Pilotage des flux

Pre

miè

re P

art

ie:

l’A

rch

itectu

re d

u S

I


Architecture de servicesArchitecture de services

Service = Fonction + Interface + Contrat Architecture de Service

Créer une structure (mettre de l’ordre dans le graphe des appels) Donner du sens (pour favoriser évolution et réutilisation)

SOA « Départemental » = architecture à base de services Souvent associé à l’utilisation de technologies « Web Services » Formalise une bonne pratique ancienne Le service est un moyen, ce qui est décrit par l’architecture est

l’objectif SOA « Global » = Construire un catalogue de service structuré

sous forme d’architecture Indépendant de la technologie (Tuxedo, procédures, …) Une application des théories de la réutilisation des composants

logiciel au niveau du système d’information Le catalogue de services réutilisables est l’objectif, l’architecture

(l’organisation) est un moyen

Pre

miè

re P

art

ie:

l’A

rch

itectu

re d

u S

I


Analyse fonctionnelle et Architecture objetAnalyse fonctionnelle et Architecture objet

L’architecture fonctionnelle est une décomposition Fonction / sous-fonction, top-down Normalisation descriptive: (input, output, transformation, rôles, …)

L’architecture fonctionnelle n’est plus isolée (vs. il y a 20 ans) Une « architecture fonctionnelle » isolée conduit à se préoccuper trop

tard des aspects processus, distribution de données, etc. Une analyse trop poussée conduit à une informatique en « silos » L’approche fonctionnelle top-down est mal adaptée à l’utilisation de

progiciels Elle irrigue 3 approches:

Cartographie métier : analyse description des fonctions/métiers de l’entreprise

Définition des services au sein de la SOA Enrichissement de l’architecture de donnée et du modèle métier

Pre

miè

re P

art

ie:

l’A

rch

itectu

re d

u S

I


Architecture de processusArchitecture de processus

Poser une structure sur les interactions temporelles Événements Enchainements => logique métiers Finalités => processus

Décrire la structure « fractale/récursive » des processus Processus / sous-processus Familles de processus

Partages de ressources: données, IHM, … Rôles (alignement organisationnel)

L’approche processus est le meilleur outil d’alignement organisation/SI

Etapes des processus -> services, fonctions, … (lien avec autres approches)

Normaliser/ Standardiser Mutualiser / réutiliser / outsourcer Pédagogie

Pre

miè

re P

art

ie:

l’A

rch

itectu

re d

u S

I


Construire une architecture cibleConstruire une architecture cible

Fonctions Processus Données

TerminologieMétiers

Objets (ontologie)

Cycle de vie objets

Macro-fonctions Macro-processus(ébauche)

Macro-processusEchanges – Contenu

EvénementsServices

Processus

Protocole m-a-j

Archi. Données v1Archi. Processus v1Archi. Services v1

Level 0

Catalogue

Référence externe

Référence externe

Référence externe


Modèle Fonctionnel MétierModèle Fonctionnel MétierP

rem

ière

Part

ie:

l’A

rch

itectu

re d

u S

I

• Résultat du premier niveau d’analyse fonctionnelle (cf. « level 0 »)• Le modèle fonctionnel est un outil d’organisation (des hommes, des SI et des idées) • Il existe des standards métier (ex: eTom dans les telcos), il est bon de s’en inspirer


Deuxième partieDeuxième partie





Propriétés d’une « bonne architecture »Propriétés d’une « bonne architecture »

Modularité Lisibilité Evolutivité (support à l’agilité) Survavibilité Standardisation

L’architecture est un outil de standardisation des interconnexions, en termes de technologies et de paradigme

Une « bonne architecture » sert à réduire le nombre de techniques, et à favoriser la réutilisation

Sert à favoriser l’utilisation de standards (LDAP, ETL, BPB, ESB – cf. chapitre 3)

Deu

xiè

me P

art

ie:

Arc

hit

ectu

re c

ible


ModularitéModularité

Modularité = « diviser pour régner » Modularité modulo l’organisation : objectif = rendre les départements

autonomes Minimiser les interactions / les dépendances / les flux

Rôle clé des modèles Déclinaisons

Architecture en couche Architecture de données Architecture orientée-services Processus

Art ou science ?: Chapitre 4: métriques de modularité Multidimensionnel – doit être isomorphe à l’organisation Appropriation/pédagogie sont fondamentales

Deu

xiè

me P

art

ie:

Arc

hit

ectu

re c

ible


LisibilitéLisibilité

Méta-modèle compris et partagé Que signifient les boites et les flèches ? Typologie claire et consistante

Chercher la continuité – éviter les modes Intérêt du standard (UML)

Séparer les fonds des flux Une même nomenclature partagée Un schéma par objectif de communication

Cf. Georges Miller « Magical seven » Capacité du « canal » (mémoire immédiate) : 7 +/- 2 Peut s’utiliser de façon fractale, mais chaque niveau ne contient pas

plus de 7 objets Construction progressive : animation des schémas !

Deu

xiè

me P

art

ie:

Arc

hit

ectu

re c

ible


EvolutivitéEvolutivité

Ajouts et suppression d’éléments Éviter la centralité (degré trop important) Dans le cas contraire, normaliser l’interconnexion

«Publish & Suscribe » Les événements forment une « grammaire » pour l’évolutivité Très simple avec un middleware asynchrone

Evolution des flux Volume - scalabilité Nature

Une « bonne architecture » doit éviter les situations de blocage en termes d’évolution

Composant saturé Composant irremplaçable

Deu

xiè

me P

art

ie:

Arc

hit

ectu

re c

ible


« Survavibilité »« Survavibilité »

Pas de SPOF Redondance (similaire à la scalabilité) Back-up / restauration Architecture de données

Privacy & CNIL Chiffrement des données sensibles

Securité Intrusion Attaque « denial of service »

Deu

xiè

me P

art

ie:

Arc

hit

ectu

re c

ible


Troisième PartieTroisième Partie





Urbanisation & « Urbanisation & « Enterprise ArchitectureEnterprise Architecture » »

Qu’est-ce que l’urbanisation ? L’approche composant L’orientation processus (externalisation de la logique) Le découpage temporel (messages asynchrones) Le découpage fonctionnel (intermédiation)

Qu’est-ce qu’une « architecture d’entreprise » ? Mise en cohérence de 3 plans :

Stratégie : objectifs Opérationnel : processus et objets Système d’information: applications et services

On parle de la même chose, mais EA = cible Urbanisation = démarche

Tro

isiè

me P

art

ie:

Urb

an

isati

on

du

SI


Parallèle avec l’urbanisation des villesParallèle avec l’urbanisation des villes

Organisation des quartiers Nomenclature Structure hiérarchique Organisation fonctionnelle

Planification de la croissance Définir les réseaux

Communication / voiries Définir les interfaces

Connections Définir les processus transverses de la ville

Transport / éclairage / .. Exemple de parallèle avec la cible « Urbanization 2020 »

Téléphonie (mobile puis Internet) : Information (ESS) Electricité : Ressources calcul & stockage (cloud/grid) Eau : Innovation, focus client Assainissement : Nettoyage applicatif


Démarche d’urbanisationDémarche d’urbanisation

Cartographier Définir la cible :

Architecture d’entreprise Objets (données) Processus (et événements) Services (analyse fonctionnelle)

Architecture informatique (fonctionnelle & technique) Choix technologiques Plan de progression par lot Conduite du changementT

rois

ièm

e P

art

ie:

Urb

an

isati

on

du

SI

DiagnosticProblèmesinformatiques

Début de la démarcheD’urbanisation

« refondation » Métier (modèles,Processus)

Gouvernance SI (planificationAllocation)

Réalisation

Définition du programmed’urbanisation


Modèles de déploiementModèles de déploiement

Stratégies• Big bang • avec migration

• Progressif • sans migration

Leçons de migration Le plus dur Tester dès le début, attention aux performances ! Prévoir la sortie (prise de purge)

Savoir lotir, savoir prendre son temps, savoir respirer

COCOMO vs. Notre expérience sur la valorisation

SegmentationMétier / historique / …

Tro

isiè

me P

art

ie:

Urb

an

isati

on

du

SI


Déploiement ProgressifDéploiement Progressif

L’approche « big bang » ne fonctionne que pour des SI de taille moyenne

Nous avons adopté une approche progressive à Bouygues Telecom

C’est un compromis: plus sûr mais plus cher (en fonction du nombre d’étapes)

Cette stratégie se compose avec une approche « fractale »

Tro

isiè

me P

art

ie:

Urb

an

isati

on

du

SI


LotissementLotissement

Faire des lots de taille « raisonnable » De 1 à 5 M€ suivant l’entreprise, moins d’un an Règle de John Chambers : 3 personnes, 300k$, 3mois

Utiliser les outils Cocomo, Casper-Jones, etc. Règles de conduite des projets …

Eviter le gel « iso-fonctionnel » Besoin du support client

Insister sur la compatibilité ascendante Conception Format des échanges (XML)

Tro

isiè

me P

art

ie:

Urb

an

isati

on

du

SI


« Parallel Run »« Parallel Run »

Les composants doivent subir des tests de non-régression sur données réelles

Dans certains cas, il est trop complexe de produire un jeu de test complet -> on compare

comparaison

Environnement de production

Environnement de test

Flux d’événements

passerelle

passerelle

Composantrefondu

Composantoriginal

Tro

isiè

me P

art

ie:

Urb

an

isati

on

du

SI


MigrationMigration

Quelques recommandations : Il faut penser aux plannings d’exploitation et à l’optimisation

des performances dès le début du projet. La migration est une activité qui aura lieu plusieurs fois, il faut

donc l’industrialiser. En particulier, il faut s’appuyer sur XML et les outils XML.

Il faut inclure des contrôles de cohérence et faire du nettoyage pendant la migration des données.

Il est souhaitable d’utiliser le plus possible l’infrastructure pour faire les migrations, en particulier le flux incrémental.

Enfin, il faut anticiper le problème de la migration qui se posera dans quelques années avec la génération suivante !.

Tro

isiè

me P

art

ie:

Urb

an

isati

on

du

SI

Education

Cours chapitre2 2012