Théorie et Pratique du Système d’Information Deuxième Chapitre: Architecture du SI
Janvier 2009
Ecole Polytechnique
Yves Caseau
2/34
Plan du Cours – Architecture du Système d’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 ?
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 Formum”, deux sens conjoints:
o A formal description of a system, or a detailed plan of the system at component level to guide its implementation
o The structure of components, their inter-relationships, and the
principles and guidelines governing their design and evolution over time.
• Pour le CEISAR (cf. TD)
o 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) Première Partie: l’Architecture du SI
Yves Caseau – Cours Polytechnique - 2009 4/34
Objectifs d’une architecture
• Communiquer au service d’une idée
o Principal outil de transformation
• Favoriser la réutilisation
o Réduire les coûts et la complexité
o Support de standardisation
• Communication entre parties prenantes
o Éviter les outils et les formalismes complexes (dépend du niveau de maturité de l’entreprise)
• Communication « asynchrone / diachronique »
o Rôle de mémoire
o Simplifie les évolutions Première Partie: l’Architecture du SI
Architecture logicielle et architecture de SI
• Architecture Logicielle (cf. 3
ecours)
o Décomposition en composants/ sous-composants
o Approches objets/ services / modules
• Architecture du SI
o Vision macroscopique
o Top-down (ex: cartographie fonctionnelle) et bottom-up (des objets métiers aux services)
o Architecture « logique » et « physique »
Architecture « logique »
Architecture « métier » (processus / objets métiers)
Architecture fonctionnelle / service
Architecture « physique »
Architecture applicative
Architecture système
Première Partie: l’Architecture du SI
Yves Caseau – Cours Polytechnique - 2009 6/34
Architecture de données
• Référentiel de données
o Référentiel sémantique: qu’est-ce qu’un client, etc?
o Modèle conceptuel de données: qu’est-ce qui constitue un client
o Ontologie: modèle de classes (UML)
o Outil fondamental de partage dans l’entreprise
• Architecture de données
o Répartition
o Formats (ex: XML)
o Cycle de vie
• Architecture dynamique de donnée (cf. 7
ecours)
o Distribution / synchronisation
o Sauvegarde / restauration
o Pilotage des flux Première Partie: l’Architecture du SI
Architecture de services
• Service = Fonction + Interface + Contrat
• Architecture de Service
o Créer une structure (mettre de l’ordre dans le graphe des appels)
o Donner du sens (pour favoriser évolution et réutilisation)
• SOA « Départemental » = architecture à base de services
o Souvent associé à l’utilisation de technologies « Web Services »
o Formalise une bonne pratique ancienne
o 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
o Indépendant de la technologie (Tuxedo, procédures, …)
o Une application des théories de la réutilisation des composants logiciel au niveau du système d’information
o Le catalogue de services réutilisables est l’objectif, l’architecture (l’organisation) est un moyen
Première Partie: l’Architecture du SI
Yves Caseau – Cours Polytechnique - 2009 8/34
Analyse fonctionnelle et Architecture objet
• L’architecture fonctionnelle est une décomposition
o Fonction / sous-fonction, top-down
o Normalisation descriptive: (input, output, transformation, rôles, …)
• L’architecture fonctionnelle n’est plus isolée (vs. il y a 20 ans)
o Une « architecture fonctionnelle » isolée conduit à se préoccuper trop tard des aspects processus, distribution de données, etc.
o Une analyse trop poussée conduit à une informatique en « silos »
o L’approche fonctionnelle top-down est mal adaptée à l’utilisation de progiciels
• Elle irrigue 3 approches:
o Cartographie métier : analyse description des fonctions/métiers de l’entreprise
o Définition des services au sein de la SOA
o Enrichissement de l’architecture de donnée et du modèle métier Première Partie: l’Architecture du SI
Architecture de processus
• Poser une structure sur les interactions temporelles
o Événements
o Enchainements => logique métiers
o Finalités => processus
• Décrire la structure « fractale/récursive » des processus
o Processus / sous-processus
o Familles de processus
Partages de ressources: données, IHM, …
o Rôles (alignement organisationnel)
L’approche processus est le meilleur outil d’alignement organisation/SI
o Etapes des processus -> services, fonctions, … (lien avec autres approches)
• Normaliser/ Standardiser
o Mutualiser / réutiliser / outsourcer
o Pédagogie Première Partie: l’Architecture du SI
10/34
Trois dimensions de l’urbanisation
Vision Données Vision Services Vision Evénements ETL fournit le modèle de
donnée qui est
commun aux échanges
Le modèle de donnée objet est enrichi par la vision service
permet de valider la cinématique et
planification des échanges de données
SOA induit une partie des services métiers
structure les interfaces de service
Fournit le catalogue de services qui sont implémentés par les composants
permet de produire un ensemble d’interfaces de service qui sont facilement re-
composables
EAI les flux d’échanges de données doivent être harmonisés avec les flux de contrôle
permet de stabiliser la contribution de
chaque composant au système d’information
fournit la structure asynchrone des
échanges qui permet de définir des processus
Construire une architecture cible
Fonction
s Processu
s Données
Terminolo Métier gie
s Objets
(ontologie) Cycle de vie objets
Macro-
fonctions Macro-
processus (ébauche)
Macro-
processus Echanges – Contenu Evéneme
Servic nts es
Process
us Protocole
m-a-j Archi.
Données v1 Archi.
Processus v1 Archi.
Services v1 Level
0
Catalog ue
Référence externe
Référence externe
Référence externe
12/34
Yves Caseau – Cours Polytechnique - 2009
Pourquoi une « architecture d’entreprise » ?
• L’Architecture est une activité métier stratégique …
• Alignement stratégique (SI/métier) est une contrainte !
o Si on n’aligne pas le SI sur la stratégie métier, l’inverse se produit
• Agilité => Anticiper => Planifier
• Enjeux stratégiques
o Optimisation -> processus
o Segmentation -> flexibilité (orientée client et non système)
o Expérience client unifiée
o Mutualisation (maîtrise des coûts)
o Cf. présentation précédente sur urbanisation (objectifs SI)
Modèle Fonctionnel Métier
Première Partie: l’Architecture du SI
• 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
14/34
Yves Caseau – Cours Polytechnique - 2009
Architecture vivante : l’art du compromis
• Evolution permanente
o Contraintes de TTM
o Contraintes « solution » (fournisseurs / clients)
• Architecture cible
o Cible dynamique, à réévaluer en permanence
o Optimisation multi-critère
• Architecture et normalisation
o Pas de progrès sans normes …
o Pas d’efficacité sans adhésion et appropriation
o Pas d’adhésion sans souplesse Première Partie: l’Architecture du SI
Deuxième partie
• 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
16/34
Yves Caseau – Cours Polytechnique - 2009
Propriétés d’une « bonne architecture »
• Modularité
• Lisibilité
• Evolutivité (support à l’agilité)
• Survavibilité
• Standardisation
o L’architecture est un outil de standardisation des interconnexions, en termes de technologies et de paradigme
o Une « bonne architecture » sert à réduire le nombre de techniques, et à favoriser la réutilisation
o Sert à favoriser l’utilisation de standards (LDAP, ETL, BPB, ESB – cf. chapitre 3)
Deuxième Partie: Architecture cible
Modularité
• Modularité = « diviser pour régner »
o Modularité modulo l’organisation : objectif = rendre les départements autonomes
• Minimiser les interactions / les dépendances / les flux
• Déclinaisons
o Architecture de données
o Architecture orientée-services
o Processus
• Art ou science ?:
o Chapitre 4: métriques de modularité
o Multidimensionnel – doit être isomorphe à l’organisation
o Appropriation/pédagogie sont fondamentales Deuxième Partie: Architecture cible
18/34
Yves Caseau – Cours Polytechnique - 2009
Lisibilité
• Méta-modèle compris et partagé
o Que signifient les boites et les flèches ?
o Typologie claire et consistante
• Chercher la continuité – éviter les modes
o Intérêt du standard (UML)
• Séparer les fonds des flux
o Une même nomenclature partagée
o Un schéma par objectif de communication ☺
• Cf. Georges Miller « Magical seven »
o Capacité du « canal » (mémoire immédiate) : 7 +/- 2
o Peut s’utiliser de façon fractale, mais chaque niveau ne contient pas plus de 7 objets ☺
o Construction progressive : animation des schémas ! Deuxième Partie: Architecture cible
Evolutivité
• Ajouts et suppression d’éléments
o Éviter la centralité (degré trop important)
o Dans le cas contraire, normaliser l’interconnexion
• Evolution des flux
o Volume - scalabilité
o Nature
• Une « bonne architecture » doit éviter les situations de blocage en termes d’évolution
o Composant saturé
o Composant irremplaçable Deuxième Partie: Architecture cible
20/34
Yves Caseau – Cours Polytechnique - 2009
« Survavibilité »
• Pas de SPOF
• Redondance (similaire à la scalabilité)
• Back-up / restauration
• Architecture de données
o Privacy & CNIL
o Chiffrement des données sensibles
• Securité
o Intrusion
o Attaque « denial of service » Deuxième Partie: Architecture cible
« Best-of » CEISAR (
courtesy ofJean-René Lyon
)
Deuxième Partie: Architecture cible
Complexité
Agilité Exécution
dans le Monde Réel
Modèle
Eléments Spécifiques Operations
Transformations
Eléments Partageables ou Réutilisables
A Exécution des Opérations
C Exécution de la Transformation
D Modèle de
Transformation B Modèle des Opérations
Opérations Transformatio
n
Acteur Action Produit Vend Gère
Client Produit Contrat
Modèle de donnée Modèle
d’Action Doc.
Logiciel Modèle
d’Acteur Rôle Config.
Modèle de donnée Modèle
d’Action Doc.
Logiciel Modèle
d’Acteur Rôle Config.
Stratégie Projet Planning Acteur
Modèle Global: les « Cartes » Modèle Global: les « Cartes »
Action Spécifie Gère Projet Déploie Maintient
• Cf. présentation en TD
22/34
CEISAR Process Design
ORGANIZATIO N
MODEL
IT MODE
L BUSINES
S MODEL
PROCESS MODEL FUNCTION
MODEL Business
Process
Business Function
Business Entity
Software Service Process Software
Business Class Activity
Organized Process
Organization Function
Organization Entity Actor
Role
1 2 3
4 5 6 7
7
1 4
2 5
3 6
Software lasts 20 years, Organization changes every 3 years: to build Solution which adapts to successive Organizations:
design Business Model before Organization Model
CEISAR: Action Levels for Organized Processes.
“Order”
« Enter Order » « Transport Goods »
« Enter Order » « Accept Order » « Load truck » « Deliver Goods »
« Get Client Info » « Enter Order Lines » « Compute Price »
End to End Process
Independent Event +
Value for Process Client Enterprise
Customer Goods
Client request
Client Back Office Inventory Driver
Client request Enough Goods
Organized Process
Resource Optimization
Activity
Operated by the same Actor et the same time.
Function
(a Function calls Functions)
24/34
Yves Caseau – Cours Polytechnique - 2009
Vision Architecture OCTO
• OCTO est une SSII spécialisée qui publie des livres blancs fort intéressants (téléchargement libre)
o Accent sur les modèles (de processus), l’agilité et le non- dogmatisme ☺
• Importance de l’architecture en couches (cf. chap 3)
• RM-ODP (Reference Model for Open Distributed Processing)
o Vue entreprise – activité métier
o Vue Information
o Vue Traitement – spécification fonctionnelle
o Vue Ingénierie – mécanismes logiciels de distribution
o Vue Technologie
• Importance des « patterns » (patrons)
o Idée clé: favorise la compréhension et la réutilisation
o Royaume – Emissaire (Intermédiation)
o Noyau
o Référentiel (cf. cours 7) Deuxième Partie: Architecture cible
Outils
• Schémas
o Le bon outil est celui qui permet d’être compris ☺
o L’intérêt des outils intégré est la gestion d’un référentiel d’architecture
Nomenclature des composants
Historisation des évolutions
o L’outillage est fonction de la maturité de l’entreprise
• UML
o Le « couteau suisse » du SI – cf. TD
o Use case, Diagramme de classes, Diagrammes d’activité/séquences
o Notation standardisée – sémantique floue => importance de la culture d’entreprise
• Processus
o Différents outils pour visualiser … et pour simuler.
o BPMN, BPEL, etc. -> normalisation technique pour intégration dans des outils d’exécution
26/34
Troisième Partie
• 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
Urbanisation & « Enterprise 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 » ?
o 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
o EA = cible
o Urbanisation = démarche Troisième Partie: Urbanisation du SI
28/34
Yves Caseau – Cours Polytechnique - 2009
Démarche d’urbanisation
• Cartographier
• Définir la cible :
o Architecture d’entreprise
Objets (données)
Processus (et événements)
Services (analyse fonctionnelle)
o Architecture informatique (fonctionnelle & technique)
• Choix technologiques
• Plan de progression par lot
• Conduite du changement
Troisième Partie: Urbanisation du SI
Modèles de déploiement
• Stratégies
• Big bang • avec migration
• Progressif • sans migration
• Leçons de migration
o Le plus dur
o Tester dès le début, attention aux performances !
o Prévoir la sortie (prise de purge)
• Savoir lotir, savoir prendre son temps, savoir respirer COCOMO vs. Notre expérience sur la valorisation
Segmentation
Métier / historique / …
Troisième Partie: Urbanisation du SI
30/34
Yves Caseau – Cours Polytechnique - 2009
Dé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 »
Troisième Partie: Urbanisation du SI
Lotissement
• Faire des lots de taille « raisonnable »
o De 1 à 5 M€ suivant l’entreprise, moins d’un an
o Règle de John Chambers : 3 personnes, 300k$, 3mois
• Utiliser les outils
o Cocomo, Casper-Jones, etc.
o Règles de conduite des projets …
• Eviter le gel « iso-fonctionnel »
o Besoin du support client
• Insister sur la compatibilité ascendante
o Conception
o Format des échanges (XML) Troisième Partie: Urbanisation du SI
32/34
Yves Caseau – Cours Polytechnique - 2009
Migration
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 !.
Troisième Partie: Urbanisation du SI
« 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
comparais on
Environnement de production
Environnement de test
Flux
d’événements
passerelle
passerelle
Composant refondu Composant
original
Troisième Partie: Urbanisation du SI
34/34
Yves Caseau – Cours Polytechnique - 2009
Conduite du changement (I)
Les changements les plus significatifs:
• La relation entre les informaticiens et leurs clients est modifiée par l’ « orientation-processus ». Pour que l’urbanisation puisse apporter ses avantages en terme d’alignement stratégique, il faut que chaque partie s’approprie le concept de processus et soit capable de se comprendre avec l’autre.
• L’urbanisation représente un déplacement du centre de gravité de l’attention portée au système d’information depuis les
composants applicatifs vers l’ensemble.
• L’urbanisation s’accompagne de changements technologiques importants, en terme d’outils, mais surtout en terme de mode de fonctionnement.
• L’exploitation du système d’information est profondément modifiée, que ce soit en mode de supervision ou pour la gestion des incidents.
Troisième Partie: Urbanisation du SI
Conduite du changement (II)
• Il faut un plan de communication qui implique tous les acteurs, depuis la direction générale jusqu’aux architectes en passant par les clients internes..
• Il faut construire un plan de formation très large.
o Il faut faire des pilotes pour acquérir une expérience pratique - hands- on experience -.
o Il faut « sortir de son trou » et voyager : se déplacer pour visiter ses fournisseurs dans leur labs, aller voir des références, assister aux
conventions, etc. Compte tenu de la maturité du sujet aujourd’hui, une démarche de « benchmarking » peut être appropriée.
• Il faut savoir adapter l’organisation aux enjeux de l’urbanisation, pour créer des lignes de forces (Une nouvelle organisation est une façon de mobiliser sur un nouvel objectif).
• Il faut savoir accompagner les collaborateurs, en particulier en ce qui concerne le management et la gestion des ressources humaines.
o Pour cela, il faut créer un climat positif avec le droit à l’erreur, depuis le début (par exemple avec le concept de pépinière) jusqu’à la fin (puisque les phases aval demandent un gros effort d’apprentissage et d’innovation).
• Il faut écrire et documenter, ce que l’on va faire, ce que l’on fait et ce que l’on a fait. C’est la seule façon de résister à la rotation des équipes qui est
naturelle et inévitable compte tenu de la durée d’un programme Troisième Partie: Urbanisation du SI
