Cours chapitre2 2012

1,960 views
1,837 views

Published on

Cours sur le système d'information en 9 chapitres

Published in: Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,960
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
97
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • 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
  • Cours chapitre2 2012

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

    ×