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

1. Théorie et Pratique du Système d’Information
Troisième Chapitre: Composants du SI
Janvier-Mars 2012
Ecole Polytechnique
Yves Caseau
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
1/26

2. Plan du Cours – Composants du SI
Première partie:
Le « Système Technique »
 Deuxième partie:
Infrastructure d’intégration
 Troisième partie:
Make/buy/rent : software ecosystem

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
2/26

3. Première Partie: le Système Technique
Sous-Systèmes du SI

Le SI est « fractal », ses composants sont des SI

Qualifiés de « macro-ST » à Bouygues Telecom
Une « brique » (sous-système) est un ensemble d’applicatifs
associés à un ensemble de ressources
 Schéma inspiré/extrait de « Architecture Logicielle » de J.
Printz

Système
applicatif
applicatio
n
exécutable
exécutable
bibliothèques
threads
process
scripts
DLLs, …
threads
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
3/26

4. Première Partie: le Système Technique
Système Technique
Chaque système technique dispose de ses ressources, allant du
PC à un ensemble de serveur spécialisés
 Les ressources peuvent être distribuées



Les ressources peuvent être mutualisées


Ex: GRID computing
Partage entre plusieurs systèmes applicatifs
Les ressources peuvent être virtualisées


Découpage logique d’une ressource en plusieurs « machines virtuelles »
Classique pour le stockage, tendance de fond pour les serveurs
Postes
de
travail
Postes
dePostes
de
travail
travail
Serveurs
Serveurs
Serveurs
de calcul
Ressource de
stockage
Ressource de
stockage
Back-up
Intfrastructure : réseau / servitudes
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
4/26

5. Première Partie: le Système Technique
Cycles de développement et Intégration

Le cycle classique de développement est souvent représenté
par un V
Expression Besoin
Mise en Service
Tests exploitabilité
Spécification
Spécifications
fonctionnelles
Intégration
Architecture système
Conception
Architecture
logicielle
Tests unitaires
Tests unitaires
techniques
code
Développement
Tests fonctionnels
Tests
Intégration logicielle
Zone spécifique
au métier / à
l’entreprise
On parle également de cycle en W pour représenter
l’intégration de plusieurs composants/projets dans un même SI
 Cf. Meinadier
Intégration
Ingénierie

système
système
Coordination
Réalisation des composants
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
5/26

6. Première Partie: le Système Technique
Composants

Principe d’un composant (Printz/Spyzerski)




Propriétés clés





Réutilisable
Scalable (sans état) => gestion du contexte en paramètre
Définition « unité de déploiement indépendante, utilisable via des
tiers via ses interfaces, dont l’état interne n’est pas observable »
Intégration tardive
Test modulaire (indépendants)
Standardisation (écosystème interne/externe)
Contrats
La notion de composant est transverse dans le SI (multi-échelle)




Composant logiciel
Serveur d’application – SOA local
Services métiers SOA global
Mais aussi: requêtes BD (services Tuxedo – moniteur transactionnel)
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
6/26

7. Première Partie: le Système Technique
Architecture Client-Serveur

L’architecture client-serveur est le classique des années 80-90,
apparue avec l’informatique départementale



Mainframe : batch + terminal
PC + serveur
Une typologie qui évolue au cours des années (avec
balancier)




Client lourd
Client léger
Client riche (ex: Ajax)
Avantages/inconvénients: déploiement / performance / ergonomie
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
7/26

8. Première Partie: le Système Technique
Architecture en Couches

L’architecture en couche est aussi ancienne que la
programmation




Ex: Dijkstra, 1968
Base des architectures de protocole de communication
Exemple : 7 couches du modèle OSI
Outil de modularité



Correspond à une structure d’arbre orienté (hiérarchique)
Impacts en O(log N)
Cf. DSM
(dependency structure matrix
chapitres suivants)

Plusieurs « patterns » orientés


Vertical
 Par niveau d’abstraction (chaque couche ignore les détails de l’autre)
Horizontal
 Par étape de processus/ transformation (irréversibilité du temps)
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
8/26

9. Première Partie: le Système Technique
Architecture 3-tiers

Evolution naturelle du modèle client-serveur:



Découplage traitement - données
Orientée-scalabilité : capacité à démultiplier les ressources de
traitement
Solution technique: Serveur d’application
IHM
Services Métiers
Présentation
Traitements
Visualisation IHM
Services
Présentation

Accès aux
données
Logique Métier
Services
élémentaires
Objet Métiers
Accès
S’étend naturellement au N-tiers en décomposant le traitement
selon une architecture en couche:


Serveurs d’applications Web (frontal de clients légers)
Serveurs d’intégration (entre traitement et données)
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
9/26

10. Deuxième partie
Le « Système Technique »
 Infrastructure d’intégration
 Make/buy/rent : software ecosystem

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
10/26

11. Deuxième Partie:Infrastructure d’intégration
Web Services

“Web services are frequently just Web APIs that can be
accessed over a network, such as the Internet, and
executed on a remote system hosting the requested
services”.
SOAP / WSDL
 Styles

RPC (pattern principal)
remote procedural call
 SOA (message-based)
 REST (http emulation)


WS-* (from WS-I)

WS-security
WS-reliability
 WS-transaction


RPC: RMI (Java), Corba, DCOM (MS), XMP-RPC
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
11/26

12. Deuxième Partie:Infrastructure d’intégration
Bus d’intégration

Bus logiciel
pattern tiré du hardware
 Intermédiation, standardisation (interface) et
mutualisation du transport

comp
osant
Schéma iconique
de l’urbanisation
bus
Bus d’intégration = bus logiciel au niveau du SI
 Synchrone/ Asynchrone
 Exemples:

EAI (Enterprise Application Infrastructure)
architecture « Publish & Subscribe »
 ESB (Enterprise Service Bus)
 Corba

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
12/26

13. Deuxième Partie:Infrastructure d’intégration
Architecture SOA
événements
Applications
interactives
(ex: portail)
Processus
Batchs
Infrastructure (ex: ESB synchrone)
Annuaire
UDDI
service
service
Infrastructure (ex: ESB asynchrone)
Applicatio
ns
« Cloud »
(Internet)
Mash-ups
Propriété clés:
• Stateless
•Gestion explicite
du contexte
•Contrat de
service
Ressources
Référentiels
(données)
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
13/26

14. Deuxième Partie:Infrastructure d’intégration
Orchestration BPM

Moteur d’orchestration
Workflow
 Processflow
BPEL
Moteur
Processus


Standardisation

BPEL4WS / XW-BPEL et les autres


Cf chapitre 6
Intégration avec serveur d’applications
– WebSphere (IBM), WebLogic (Bea/Oracle),
…

Questions à se poser/ réponse possible
Performance / distribution
 Flexibilité / moteur de règles
 Intégrité (Transactions)

Cf. chapitre 6

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
14/26

15. Deuxième Partie:Infrastructure d’intégration
ETL (Extract / Transform / Load)

Exemple d’architecture en couche (cf. Printz)
Application
ETL
Extract
Transform
DWH
Load
Référe
nciels

Datamarts
Application
Infrastructure d’intégration des SI décisionnels
Orienté traitement de masse
 Intégration d’outils XML volumiques (filtrages,
transformation)


Evolution vers une solution complète
EII : Enterprise Information Integration
 Intégration d’un processflow / interfaces SOA

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
Vraie
compétence
technique
15/26

16. Compatibilité ascendante et versions

XML est auto-décrit et extensible …


La gestion des versions est indispensable pour gérer la
complexité



Cela n’assure pas la compatibilité ascendante dans la lecture des
messages
La gestion de version introduit un « découplage temporel »
En l’absence de versions, le système doit évoluer par bloc (malgré
l’EAI
Règles pour obtenir une compatibilité ascendante (classique)



Marquer les composant des messages avec des numéros de version
Format ouvert permettant d’accepter des informations non
interprétées (le minimum … rarement implémenté)
Pilotage dynamique (quelle version de X utilise quelle version de Y)
 Déploiement facilité
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
16/26

17. Deuxième Partie:Infrastructure d’intégration
Intégration par le « front office » - Portail applicatif

L’intégration applicative peut aussi venir du front-office



Vision unifiée des applications
Scripts de partage d’information/ automatisation de saisie
Méthode légère d’urbanisation qui peut évoluer vers SOA
Une méthode légère et efficace d’intégration
 Architecture Web qui s’appuie de multiples outils


Une part importante d’open-source
Portail applicatif
Serveur Web
Services
Présentation
Services
métiers
Automatisation
Workflow
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
Progiciel moderne
Interface
Services
Web
Interface
Legacy
17/26

18. Deuxième Partie:Infrastructure d’intégration
Quel est le retour sur investissement ?
Le ROI de l’infrastructure d’intégration n’est pas simple :





L’infrastructure coûte cher
La conception est difficile -> alourdit les spécifications + essais/erreurs
Les adaptateurs sont coûteux (de 20 à 40% du développement)
Tests complexes
Exploitation et mise au point difficiles
Facteurs clés:


Age moyen (taux de refonte) -> nettoyage
Taux de renouvellement -> évolutions
Le ROI se juge avec du recul


Cycle complet de vie
Quelle est la valeur de l’agilité (cf. chapitre 5) ?
 Analyse de scénarios (avec et sans)
I.2 : Urbanisation - Questions
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
18/26

19. Troisième partie
Le « Système Technique »
 Infrastructure d’intégration
 Make/buy/rent : « software ecosystem »

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
19/26

20. Troisième Partie: Ecosystème Logiciel
Progiciels et Logiciels Métiers

Il existe plusieurs types de « mode de fabrication » pour des
applications logicielles

Spécifique

Framework
Progiciel


Critères dimensionnants

nombres de clients
taux de couverture (générique / spécifique pour intégration)
 généricité du besoin (intersection / union)
 Taux d’évolution fonctionnel
 Contraintes de performance


Jeu à « deux acteurs »


client : make/buy (avec intégration)
Vendeur: maximiser rentabilité (pas revenu)
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
20/26

21. Troisième Partie: Ecosystème Logiciel
Comprendre les coûts de fabrication

Coûts sont fonction du volume du logiciel (cf. Chapitre 5)


O(n 1.2) construction
O(n x m 0.5) incrément
Le volume est un compromis entre « intersection » et
«union » des besoins
 Le fournisseur gère différentes versions techniques
 Le fournisseur optimise nb_clients * (prix – cout unitaire)

Progiciel
Coût unitaire
coût
Nombre de clients
Coût total
Différentiation (l’inverse de la généricité)
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
« le mieux est
l’ennemi du bien »
Trop de fonctions
coûte: intégration,
ressources,
complexité
21/26

22. Troisième Partie: Ecosystème Logiciel
Comprendre les coûts de maintenance

Cycle de vie des coûts de maintenance


Le logiciel est un produit « vivant » -> génération successive de
versions fonctionnelles
Chaque version génère un coût de maintenance



technique
correction des anomalies
Réduire les coûts

Le coût de maintenance dépend de:



Conduit à la notion de cycle: garantie/maintenance/maintenance
étendue/maintenance spécifique (sur demande)


Nombre de versions en activité
Nombre de clients (taux de découverte des anomalies)
Pression sur les clients pour faire « migrer » de façon ascendante
La maintenance est une composante du prix qui est moins bien
comprise par les clients

d’où l’idée de « louer le logiciel » en tant que service
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
22/26

23. Troisième Partie: Ecosystème Logiciel
ASP et SaaS

ASP (Application Service Provider)



Hébergement applicatif
Le service correspond à la « location par appartement » d’une
plateforme
 Ex: CRM, SFA (Salesforce)
SaaS (Software as a Service) : nouveau nom / concept marqué
par le « cloud computing »

Multiplicité des fournisseurs
coût
Capacité
à
évoluer
Effet complexité
Synchroniser les besoins
Nombre de clients
spécifique
framework
framework
ASP
spécifique
COTS
COTS
ASP
Différentiation (l’inverse de la généricité)
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
Complexité du besoin
23/26

24. Troisième Partie: Ecosystème Logiciel
Open Source

Qu’est-ce l’open-source  ?



Avantages



Coûts  (même avec les coûts cachés)
Réactivité
Contraintes d’utilisation



Développement et maintenance confiée à une communauté d’intérêt
bénévole (même si des services rémunérés existent – cf. UNIX)
QoS : fonction de la taille de la communauté (généricité du logiciel) et de
l’implication (généricité de la demande)
Culturel: les développeurs parlent aux développeurs
Généricité : la QoS dépend de la mutualisation du besoin
Critères de JP Rangaswami (
http://confusedofcalcutta.com/2008/07/19/thinking-about-opensource
)



Général => open source
Industrie => progiciel
Entreprise-spécifique (différenciant) => développement
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
24/26

25. Troisième Partie: Ecosystème Logiciel
Grid Computing and Cloud Computing

Grid: utiliser une « ferme » d’ordinateurs en tant que superordinateur parallèle
Cloud Computing: Outsourcing du Grid (Amazon, Google,
etc.)
 Trois avantages majeurs:

Fault-tolerance à travers la redondance implicite.
 Très haute performance à travers le parallélisme massif




TCO réduit par l’utilisation de « Commodity computing »
(PC) – Ex: coût hébergement email de Google



Ex: data mining, traitement d’événements en temps réel
Cf. architecture « MapReduce » de Google
+ Économie d’échelle implicite
(1 & 2) suppose une architecture logicielle adaptée !
Le SaaS se prête très bien (souvent, architecture
moderne) au Cloud Computing
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
25/26

26. Limites du Cloud Computing
Le « cloud computing » est dans une phase naissance =>
beaucoup de « hype »
 Trois limites:

1.
2.
3.
Maitrise des données et de la « privacy ».
Temps de latence: Un aller-retour n’est pas gratuit (10 ms pour
3000km) => les applications transactionnelles à fort de gré
d’interaction ne sont indiquées
Surcoût d’une approche SOA externalisée
1.
Les services sont forcément à faible granularité, (s’ils était
spécialisés et complexes il n’y aurait pas la taille critique de
marché)
2.
Un RPC à travers un WS a un surcoût important
3.
On ne peut pas transformer (aujourd’hui) toutes les appels
fonctionnels en invocation de WS
–
–
« SOA is not scale-free »
C’est même vrai à l’intérieur de l’entreprise !
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)
26/26