Más contenido relacionado La actualidad más candente (20) Similar a Cours chapitre2 2012 (20) Cours chapitre2 20121. Théorie et Pratique du Système d’Information
Deuxième Chapitre: Architecture du SI
Janvier - Mars 2012
Ecole Polytechnique
Yves Caseau
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
1/26
2. 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
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
2/26
3. Première Partie: l’Architecture du SI
Qu’est-ce qu’une architecture ?
Définition du terme “architecture” ( ANSI/IEEE Std 1471-2000 ):
Pour l’ “Open Group Architecture Forum”, deux sens conjoints:
"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.“
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)
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
3/26
4. Première Partie: l’Architecture du SI
Objectifs d’une architecture
Communiquer au service d’une idée
Favoriser la réutilisation
Réduire les coûts et la complexité
Support de standardisation
Communication entre parties prenantes
Principal outil de transformation
É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
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
4/26
5. Première Partie: l’Architecture du SI
Architecture 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
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
5/26
6. Première Partie: l’Architecture du SI
Architecture de données
Référentiel de données
Architecture 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
Répartition
Formats (ex: XML)
Cycle de vie
Architecture dynamique de donnée (cf. 7e cours)
Distribution / synchronisation
Sauvegarde / restauration
Pilotage des flux
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
6/26
7. Première Partie: l’Architecture du SI
Architecture de services
Service = Fonction + Interface + Contrat
Architecture de Service
SOA « Départemental » = architecture à base de services
Créer une structure (mettre de l’ordre dans le graphe des appels)
Donner du sens (pour favoriser évolution et réutilisation)
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
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
7/26
8. Première Partie: l’Architecture du SI
Analyse fonctionnelle et Architecture objet
L’architecture fonctionnelle est une décomposition
L’architecture fonctionnelle n’est plus isolée (vs. il y a 20 ans)
Fonction / sous-fonction, top-down
Normalisation descriptive: (input, output, transformation, rôles, …)
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
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
8/26
9. Première Partie: l’Architecture du SI
Architecture de processus
Poser une structure sur les interactions temporelles
Décrire la structure « fractale/récursive » des processus
Événements
Enchainements => logique métiers
Finalités => 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
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
9/26
10. Construire une architecture cible
Fonctions
Processus
Données
Terminologie
Métiers
Macro-processus
(ébauche)
Macro-fonctions
Objets (ontologie)
Référence
externe
Cycle de vie objets
Référence
externe
Level 0
Référence
externe
Services
Catalogue
Macro-processus
Echanges – Contenu
Evénements
Processus
Protocole m-a-j
Archi. Services v1
Archi. Processus v1
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
Archi. Données v1
10/26
11. Première Partie: l’Architecture du SI
Modèle Fonctionnel Métier
• 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
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
11/26
12. 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
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
12/26
13. Deuxième Partie: Architecture cible
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)
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
13/26
14. Deuxième Partie: Architecture cible
Modularité
Modularité = « diviser pour régner »
Minimiser les interactions / les dépendances / les flux
Rôle clé des modèles
Déclinaisons
Modularité modulo l’organisation : objectif = rendre les départements
autonomes
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
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
14/26
15. Deuxième Partie: Architecture cible
Lisibilité
Méta-modèle compris et partagé
Chercher la continuité – éviter les modes
Intérêt du standard (UML)
Séparer les fonds des flux
Que signifient les boites et les flèches ?
Typologie claire et consistante
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 !
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
15/26
16. Deuxième Partie: Architecture cible
Evolutivité
Ajouts et suppression d’éléments
«Publish & Suscribe »
Les événements forment une « grammaire » pour l’évolutivité
Très simple avec un middleware asynchrone
Evolution des flux
Éviter la centralité (degré trop important)
Dans le cas contraire, normaliser l’interconnexion
Volume - scalabilité
Nature
Une « bonne architecture » doit éviter les situations de blocage
en termes d’évolution
Composant saturé
Composant irremplaçable
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
16/26
17. Deuxième Partie: Architecture cible
« 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 »
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
17/26
18. 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
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
18/26
19. Troisième Partie: Urbanisation du SI
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 » ?
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
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
19/26
20. Parallèle avec l’urbanisation des villes
Organisation des quartiers
Nomenclature
Structure hiérarchique
Organisation fonctionnelle
Planification de la croissance
Définir les réseaux
Définir les interfaces
Communication / voiries
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
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
20/26
21. Troisième Partie: Urbanisation du SI
Dé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 changement
Diagnostic
Problèmes
informatiques
Définition
« refondation »
Début de la
Gouvernance
du
Métier
démarche
SI
programme
D’urbanisation (modèles,
(planification
d’urbanisation Allocation)
Processus)
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
Réalisation
21/26
22. Troisième Partie: Urbanisation du SI
Modèles de déploiement
Stratégies
• Big bang
• Progressif
Leçons de migration
• avec migration
• sans migration
Segmentation
Métier / historique / …
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
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
22/26
23. Troisième Partie: Urbanisation du SI
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 »
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
23/26
24. Troisième Partie: Urbanisation du SI
Lotissement
Faire des lots de taille « raisonnable »
Utiliser les outils
Cocomo, Casper-Jones, etc.
Règles de conduite des projets …
Eviter le gel « iso-fonctionnel »
De 1 à 5 M€ suivant l’entreprise, moins d’un an
Règle de John Chambers : 3 personnes, 300k$, 3mois
Besoin du support client
Insister sur la compatibilité ascendante
Conception
Format des échanges (XML)
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
24/26
25. 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
comparaison
Composant
original
Composant
refondu
passerelle
passerelle
Environnement de test
Flux d’événements
Environnement de production
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
25/26
26. Troisième Partie: Urbanisation du SI
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 !.
Copyright © Yves Caseau – 2012 - Cours Polytechnique (II)
26/26
Notas del editor L’Architecture est une activité métier stratégique …
Alignement stratégique (SI/métier) est une contrainte !
Si on n’aligne pas le SI sur la stratégie métier, l’inverse se produit
Agilité => Anticiper => Planifier
Enjeux stratégiques
Optimisation -> processus
Segmentation -> flexibilité (orientée client et non système)
Expérience client unifiée
Mutualisation (maîtrise des coûts)
Cf. présentation précédente sur urbanisation (objectifs SI)
L’approche processus est le meilleur outil d’alignement organisation/SI
Goal: minimize impact dispersion for new services
“Definition”: modularity is the correlation
« Distance in the code » and frequency of interaction
« Distance in the code » and « co-evolution »
Good practices :
Layered architecture (define abstraction levels)
Process Architecture (define a composition grammar)
Sharing/reuse & modularity go hand-in-hand : sub-process identification
Event-Oriented Architecture
Pub/sub is still a one of the best modular patterns
Model-Driven Architecture: careful design of « future-proof » data model
Service Architecture reduces unmanaged interactions
Reification of functional architecture
Abstraction/ encapsulation
trends city
- mobile phone
- Electricity
- water
- assainissement
Sofware Production
Info (ESS)
Electricity : Resource (Cloud/grid + tools : code version, repository, auto test, auto config , auto deploy)
water : innovation/ customer focus
assai: code clean up / rex
Les plannings de bascule de flux sont complexes, c’est une des dimensions de l’apprentissage.
Dans le cas d’un développement spécifique, il faut inclure, dans les spécifications, celles d’un export complet en XML. Dans le cas d’un progiciel, la « facilité à vider » le composant doit être un critère de choix. L’expérience prouve que dans l’excitation et la tension qui caractérisent un gros projet de refonte, il est difficile de voir loin et de prévoir la sortie. C’est pourtant un des facteurs clés pour maîtriser les coûts sur le long terme, comme cela a été dit au chapitre 6