Professional Documents
Culture Documents
1/34
2/34
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. En premier lieu, un outil de communication
3/34
Favoriser la rutilisation
viter les outils et les formalismes complexes (dpend du niveau de maturit de lentreprise) Rle de mmoire Simplifie les volutions
4/34
Architecture du SI
Dcomposition en composants/ sous-composants Approches objets/ services / modules Vision macroscopique Top-down (ex: cartographie fonctionnelle) et bottom-up (des objets mtiers aux services) Architecture logique et physique Architecture logique
Architecture mtier (processus / objets mtiers) Architecture fonctionnelle / service
Architecture physique
Architecture applicative Architecture systme
5/34
Architecture de donnes
Rfrentiel de donnes
o o o o o o o o o o
Architecture de donnes
Rpartition Formats (ex: XML) Cycle de vie
Rfrentiel smantique: quest-ce quun client, etc? Modle conceptuel de donnes: quest-ce qui constitue un client Ontologie: modle de classes (UML) Outil fondamental de partage dans lentreprise
6/34
Architecture de services
Service = Fonction + Interface + Contrat Architecture de Service
o o o o o
Crer une structure (mettre de lordre dans le graphe des appels) Donner du sens (pour favoriser volution et rutilisation) Souvent associ lutilisation de technologies Web Services Formalise une bonne pratique ancienne Le service est un moyen, ce qui est dcrit par larchitecture est lobjectif
Indpendant de la technologie (Tuxedo, procdures, ) Une application des thories de la rutilisation des composants logiciel au niveau du systme dinformation Le catalogue de services rutilisables est lobjectif, larchitecture (lorganisation) est un moyen
7/34
Fonction / sous-fonction, top-down Normalisation descriptive: (input, output, transformation, rles, ) Une architecture fonctionnelle isole conduit se proccuper trop tard des aspects processus, distribution de donnes, etc. Une analyse trop pousse conduit une informatique en silos Lapproche fonctionnelle top-down est mal adapte lutilisation de progiciels Cartographie mtier : analyse description des fonctions/mtiers de lentreprise Dfinition des services au sein de la SOA Enrichissement de larchitecture de donne et du modle mtier
8/34
Architecture de processus
Poser une structure sur les interactions temporelles
o o o o o o
Normaliser/ Standardiser
o o
9/34
SOA
EAI
les flux dchanges de donnes doivent tre harmoniss avec les flux de contrle
10/34
Rfrence externe
Rfrence externe
Level 0
Rfrence externe
Optimisation -> processus Segmentation -> flexibilit (oriente client et non systme) Exprience client unifie Mutualisation (matrise des cots) Cf. prsentation prcdente sur urbanisation (objectifs SI)
12/34
13/34
Architecture cible
Contraintes de TTM Contraintes solution (fournisseurs / clients) Cible dynamique, rvaluer en permanence Optimisation multi-critre Pas de progrs sans normes Pas defficacit sans adhsion et appropriation Pas dadhsion sans souplesse
Architecture et normalisation
14/34
Deuxime partie
Premire partie: Quest-ce que larchitecture ? Deuxime partie: Etablir une architecture cible Troisime partie: Urbanisation du Systme dInformation
15/34
Larchitecture est un outil de standardisation des interconnexions, en termes de technologies et de paradigme Une bonne architecture sert rduire le nombre de techniques, et favoriser la rutilisation Sert favoriser lutilisation de standards (LDAP, ETL, BPB, ESB cf. chapitre 3)
16/34
Modularit
Modularit = diviser pour rgner
o
Art ou science ?:
Architecture de donnes Architecture oriente-services Processus Chapitre 4: mtriques de modularit Multidimensionnel doit tre isomorphe lorganisation Appropriation/pdagogie sont fondamentales
17/34
Lisibilit
Mta-modle compris et partag
o o o o o o o o
Chercher la continuit viter les modes Sparer les fonds des flux
Intrt du standard (UML) Une mme nomenclature partage Un schma par objectif de communication Capacit du canal (mmoire immdiate) : 7 +/- 2 Peut sutiliser de faon fractale, mais chaque niveau ne contient pas plus de 7 objets Construction progressive : animation des schmas !
18/34
Evolutivit
Ajouts et suppression dlments
o o o o
viter la centralit (degr trop important) Dans le cas contraire, normaliser linterconnexion Volume - scalabilit Nature
Une bonne architecture doit viter les situations de blocage en termes dvolution
o o
19/34
Survavibilit
Pas de SPOF Redondance (similaire la scalabilit) Back-up / restauration Architecture de donnes
o o o o
Securit
Privacy & CNIL Chiffrement des donnes sensibles Intrusion Attaque denial of service
20/34
C Excution de la Transformation A Excution des Oprations Acteur Action Acteur Action Spcifie Stratgie Gre Projet Projet Planning Dploie Maintient D Modle de Transformation Modle Modle dActeur dAction Produit Vend Gre Client Produit Contrat
B Modle des Oprations Modle dActeur Modle de donne Rle Config. Modle dAction Doc. Modle de donne
Complexit
Rle Config.
Doc.
Agilit
Elments Partageables ou Rutilisables
Elments Spcifiques
Transformations Synergie
21/34
BUSINES S MODEL
Business 3Process
Software lasts 20 years, Organization changes every 3 years: to build Solution which adapts to successive Organizations: design Business Model before Organization Model
IT MODE L
Process 3Software 6
Activity
Actor 7 Role PROCESS MODEL FUNCTION MODEL Business 2 Function Business 1 Entity
Order
Enough Goods
Organized Process
Resource Optimization
Enter Order
Transport Goods
Activity
Operated by the same Actor et the same time.
Enter Order
Accept Order
Load truck
Deliver Goods
Client
Back Office
Inventory
Driver
Function
(a Function calls Functions) Organization Function
Compute Price
Find available Actor in Back Office 23/34
Importance de larchitecture en couches (cf. chap 3) RM-ODP (Reference Model for Open Distributed Processing)
o o o o o o o o o
Vue entreprise activit mtier Vue Information Vue Traitement spcification fonctionnelle Vue Ingnierie mcanismes logiciels de distribution Vue Technologie Ide cl: favorise la comprhension et la rutilisation Royaume Emissaire (Intermdiation) Noyau Rfrentiel (cf. cours 7)
24/34
Outils
Schmas
o o
o o o o
UML
Le bon outil est celui qui permet dtre compris Lintrt des outils intgr est la gestion dun rfrentiel darchitecture Nomenclature des composants Historisation des volutions Loutillage est fonction de la maturit de lentreprise Le couteau suisse du SI cf. TD Use case, Diagramme de classes, Diagrammes dactivit/squences Notation standardise smantique floue => importance de la culture dentreprise Diffrents outils pour visualiser et pour simuler. BPMN, BPEL, etc. -> normalisation technique pour intgration dans des outils dexcution
Processus
o o
25/34
Troisime Partie
Premire partie: Quest-ce que larchitecture ? Deuxime partie: Etablir une architecture cible Troisime partie: Urbanisation du Systme dInformation
26/34
Mise en cohrence de 3 plans : Stratgie : objectifs Oprationnel : processus et objets Systme dinformation: applications et services EA = cible Urbanisation = dmarche
27/34
Dmarche durbanisation
Architecture dentreprise Objets (donnes) Processus (et vnements) Services (analyse fonctionnelle) Architecture informatique (fonctionnelle & technique)
28/34
Modles de dploiement
Stratgies
Big bang avec migration Progressif sans migration
Segmentation Mtier / historique /
Leons de migration
o o o
Le plus dur Tester ds le dbut, attention aux performances ! Prvoir la sortie (prise de purge)
Savoir lotir, savoir prendre son temps, savoir respirer COCOMO vs. Notre exprience sur la valorisation
29/34
Dploiement Progressif
Lapproche big bang ne fonctionne que pour des SI de taille moyenne Nous avons adopt une approche progressive Bouygues Telecom
Cest un compromis: plus sr mais plus cher (en fonction du nombre dtapes) Cette stratgie se compose avec une approche fractale
30/34
Lotissement
De 1 5 M suivant lentreprise, moins dun an Rgle de John Chambers : 3 personnes, 300k$, 3mois Cocomo, Casper-Jones, etc. Rgles de conduite des projets Besoin du support client
31/34
Migration
Quelques recommandations : Il faut penser aux plannings dexploitation et loptimisation des performances ds le dbut du projet. La migration est une activit qui aura lieu plusieurs fois, il faut donc lindustrialiser. En particulier, il faut sappuyer sur XML et les outils XML. Il faut inclure des contrles de cohrence et faire du nettoyage pendant la migration des donnes. Il est souhaitable dutiliser le plus possible linfrastructure pour faire les migrations, en particulier le flux incrmental. Enfin, il faut anticiper le problme de la migration qui se posera dans quelques annes avec la gnration suivante !.
32/34
Parallel Run
Les composants doivent subir des tests de non-rgression sur donnes relles Dans certains cas, il est trop complexe de produire un jeu de test complet -> on compare
passerelle
Environnement de test
33/34
Les changements les plus significatifs: La relation entre les informaticiens et leurs clients est modifie par l orientation-processus . Pour que lurbanisation puisse apporter ses avantages en terme dalignement stratgique, il faut que chaque partie sapproprie le concept de processus et soit capable de se comprendre avec lautre. Lurbanisation reprsente un dplacement du centre de gravit de lattention porte au systme dinformation depuis les composants applicatifs vers lensemble. Lurbanisation saccompagne de changements technologiques importants, en terme doutils, mais surtout en terme de mode de fonctionnement. Lexploitation du systme dinformation est profondment modifie, que ce soit en mode de supervision ou pour la gestion des incidents.
34/34
Il faut savoir adapter lorganisation aux enjeux de lurbanisation, pour crer des lignes de forces (Une nouvelle organisation est une faon 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
Il faut faire des pilotes pour acqurir une exprience pratique - handson experience -. Il faut sortir de son trou et voyager : se dplacer pour visiter ses fournisseurs dans leur labs, aller voir des rfrences, assister aux conventions, etc. Compte tenu de la maturit du sujet aujourdhui, une dmarche de benchmarking peut tre approprie.
Il faut crire et documenter, ce que lon va faire, ce que lon fait et ce que lon a fait. Cest la seule faon de rsister la rotation des quipes qui est naturelle et invitable compte tenu de la dure dun programme 35/34 durbanisation. Yves Caseau Cours Polytechnique - 2009
Pour cela, il faut crer un climat positif avec le droit lerreur, depuis le dbut (par exemple avec le concept de ppinire) jusqu la fin (puisque les phases aval demandent un gros effort dapprentissage et dinnovation).