Théorie et Pratique du Système d’Information Troisième Chapitre: Composants du SI

(1)

Théorie et Pratique du Système d’Information Troisième Chapitre: Composants du SI

Janvier 2009

(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

(3)

Sous-Systèmes du SI

• Le SI est « fractal », ses composants sont des SI

o 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 application

exécutable exécutable scripts

Première Partie: le Système Technique

(4)

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

o Ex: GRID computing

• Les ressources peuvent être mutualisées

o Partage entre plusieurs systèmes applicatifs

• Les ressources peuvent être virtualisées

o Découpage logique d’une ressource en plusieurs « machines virtuelles »

o Classique pour le stockage, tendance de fond pour les serveurs

Ressource de stockage Serveurs

Postes de travail

Back-up Ressource de

Serveurs Postes

de Postes

de travail

(5)

Déploiement d’une application

• Le déploiement d’un système applicatif est une opération complexe

o Couplage entre une hiérarchie d’exécutables et une hiérarchie de ressources

o Paramétrage & contraintes d’exécution

o Cf. Prinz (fig 2.8)

Scripts paramétrage &

config

Application À installer

config Machine M2

config Machine Mn Machine M1

Paramétrage pour installation sur M1

Paramétrage pour adaptation au contexte client

infrastructure

(6)

Système d’information et sous-systèmes

• La notion de système d’information est fractale

o Un SI est un ensemble de SI/composants qui interagissent

• Vision pyramidale de Wieringa

• L’architecture logicielle et l’architecture de SI ont des points communs …

o Modèle fonctionnel/ approche composant / bus logiciel / données /…

responsabilités services transaction

fonctions mission

(7)

Cycles de développement et Intégration

• Le cycle classique de développement est souvent représenté par un V

• On parle également de cycle en W pour représenter l’intégration de plusieurs composants/projets dans un même SI

• Cf. Meinadier

Expression Besoin

Spécifications fonctionnelles

code Architecture logicielle

Tests unitaires techniques

Mise en Service Tests exploitabilité

Tests fonctionnels Intégration

Tests unitaires

Conception

Spécification

Développement Intégration logicielle Architecture système

Tests

Zone spécifique au métier / à l’entreprise

(8)

Composants

• Principe d’un composant (Printz/Spyzerski)

o Réutilisable

o Scalable (sans état) => gestion du contexte en paramètre

o Définition « unité de déploiement indépendante, utilisable via des tiers via ses interfaces, dont l’état interne n’est pas observable »

• Propriétés clés

o Intégration tardive

o Test modulaire (indépendants)

o Standardisation (écosystème interne/externe)

o Contrats

• La notion de composant est transverse dans le SI (multi-échelle)

o Composant logiciel

o Serveur d’application – SOA local

o Services métiers SOA global

o Mais aussi: requêtes BD (services Tuxedo – moniteur transactionnel) Première Partie: le Système Technique

(9)

Architecture Client-Serveur

• L’architecture client-serveur est le classique des années 80-90, apparue avec l’informatique départementale

o Mainframe : batch + terminal

o PC + serveur

• Une typologie qui évolue au cours des années (avec balancier)

o Client lourd

o Client léger

o Client riche (ex: Ajax)

o Avantages/inconvénients: déploiement / performance / ergonomie Première Partie: le Système Technique

(10)

Architecture en Couches

• L’architecture en couche est aussi ancienne que la programmation

o Ex: Dijkstra, 1968

o Base des architectures de protocole de communication

o Exemple : 7 couches du modèle OSI

• Outil de modularité

o Correspond à une structure d’arbre orienté (hiérarchique)

o Impacts en O(log N)

o Cf. DSM

(dependency structure matrix chapitres suivants)

• Plusieurs « patterns » orientés

o Vertical

 Par niveau d’abstraction (chaque couche ignore les détails de l’autre)

o Horizontal

 Par étape de processus/ transformation (irréversibilité du temps)

(11)

Architecture 3-tiers

• Evolution naturelle du modèle client-serveur:

o Découplage traitement - données

o Orientée-scalabilité : capacité à démultiplier les ressources de traitement

o Solution technique: Serveur d’application

• S’étend naturellement au N-tiers en décomposant le traitement selon une architecture en couche:

o Serveurs d’applications Web (frontal de clients légers)

o Serveurs d’intégration (entre traitement et données)

IHM

Présentation

Services Métiers

Traitements Accès aux

données

Visualisation IHM Services

Présentation

Logique Métier

Objet Métiers

Services élémentaires Accès

(12)

Architectures de Machines de Transformation

• Machine de transformation (Printz)

o Modèle de SI composant générique

• Pattern MVC

(Model-View-Controler)

• Moniteur de contrôle

o Distribution de charge et contrôle de cohérence

o Assure une qualité de service (planification)

o (ex: Moniteur transactionnel) cf. chapitre 7

EV

ER

demandes

moniteur

ressources

État/disponibilité

(13)

Deuxième partie

• Le « Système Technique »

• Infrastructure d’intégration

• Make/buy/rent : software ecosystem

(14)

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

o RPC (pattern principal) remote procedural call

o SOA (message-based)

o REST (http emulation)

• WS-* (from WS-I)

o WS-security

o WS-reliability

o WS-transaction

• RPC: RMI (Java), Corba, DCOM (MS), XMP-RPC

Deuxième Partie:Infrastructure d’intégration

(15)

Bus d’intégration

• Bus logiciel

o pattern tiré du hardware

o Intermédiation, standardisation (interface) et mutualisation du transport

• Bus d’intégration = bus logiciel au niveau du SI

• Synchrone/ Asynchrone

• Exemples:

o EAI (Enterprise Application Infrastructure) architecture « Publish & Subscribe »

o ESB (Enterprise Service Bus)

bus compo sant

Schéma iconique de l’urbanisation

(16)

Architecture SOA

Applications interactives (ex: portail)

Processus

événements

Batchs

service

Propriété clés:

• Stateless

• Gestion explicite du contexte

• Contrat de service

Applicatio Ressourc Infrastructure (ex: ESB asynchrone)

Infrastructure (ex: ESB synchrone)

service

Mash-ups

Annuaire UDDI

(17)

Services et Événements

• La notion d’adaptateur, propre aux EAI, disparaît dans la vision SOA

• « Services métiers » vs. « Services logiciels »

• Services métiers (plus générique, plus réutilisables) : investissement pour le futur

• Service vs. Événements: ne pas connaître son consommateur

Bus Adaptateur Composant

Interface I2

Interface I1

Responsabilité Composant (vision EAI)

Responsabilité Infrastructure (vision SOA) Responsabilité Composant Responsabilité Infrastructure

Processflow

Référentiel

transforme services

Changement du

« poids du corps »

local – global

(18)

Orchestration BPM

• Moteur d’orchestration

o

Workflow

o

Processflow

• Standardisation

o

BPEL4WS / XW-BPEL et les autres

 Cf chapitre 6

o

Intégration avec serveur d’applications

 WebSphere (IBM), WebLogic (Bea/Oracle),

• Questions à se poser/ réponse possible

…

o

Performance / distribution

o

Flexibilité / moteur de règles

o

Intégrité (Transactions)

Moteur Processus

BPEL

(19)

ETL (Extract / Transform / Load)

• Exemple d’architecture en couche (cf. Printz)

• Infrastructure d’intégration des SI décisionnels

o

Orienté traitement de masse

o

Intégration d’outils XML volumiques (filtrages, transformation)

• Evolution vers une solution complète

o

EII : Enterprise Information Integration

ETL DWH

Data- marts

Extract Transform Load

Appli- cation Appli-

cation

Référen ciels

(20)

Echanges XML et format pivot

• XML: la « lingua franca » de l’intégration

o Ingénierie XML = savoir utiliser les outils !

• Format Pivot: le format associé au noyau des échanges

• Pourquoi le FP est important

o Multiples représentations XML possibles

DWH

Modèle « métier »

local Modèle des échanges

Internes ST

(21)

Compatibilité ascendante et versions

• XML est auto-décrit et extensible …

o Cela n’assure pas la compatibilité ascendante dans la lecture des messages

• La gestion des versions est indispensable pour gérer la complexité

o La gestion de version introduit un « découplage temporel »

o En l’absence de versions, le système doit évoluer par bloc (malgré l’EAI

• Règles pour obtenir une compatibilité ascendante (classique)

o Marquer les composant des messages avec des numéros de version

o Format ouvert permettant d’accepter des informations non interprétées (le minimum … rarement implémenté)

o Pilotage dynamique (quelle version de X utilise quelle version de Y) Deuxième Partie:Infrastructure d’intégration

(22)

Intégration par le « front office » - Portail applicatif

• L’intégration applicative peut aussi venir du front-office

o Vision unifiée des applications

o Scripts de partage d’information/ automatisation de saisie

o 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

o Une part importante d’open-source

Portail applicatif Serveur Web Progiciel moderne

Legacy Web

Inter- Services

Présentation Services métiers

Interface Services

(23)

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) ?

o Analyse de scénarios (avec et sans) Deuxième Partie:Infrastructure d’intégration

(24)

Cycle de vie du SI

développement

Exploitation maintenance

Exploitation Maintenance

(vétuste)

Développement (suivant)

migration

nettoyage

Durée de vie réelle en exploitation Durée de vie perçue

MEF: renouvellement partiel

temps Intensité

activité

La phase de développement n’est que la « partie émergée de l’iceberg » Deuxième Partie:Infrastructure d’intégration

(25)

Analyse par phase

Etude Impact-

Spécification +20% -30% -: changement orientation processus +: simplification des impacts

Développement 0% -20% +: Objet Métiers Mutualisés & Externalisation de la logique (processus)

Développement (Intégration)

-30% -70% -: apprendre la technique « adaptateurs » +: un seul adaptateur à réaliser, réutilisation Intégration – UAT-

VABE 10% -30% +: conduite du changement

- : capacité à automatiser les tests + modularité (test isolé d’un composant)

Exploitation 20% -20% +: orientation processus

-: découplage des systèmes, flexibilité de l’hébergement

Nettoyage 0% -80% +: un seul fil à débrancher

(26)

Troisième partie

• Le « Système Technique »

• Infrastructure d’intégration

• Make/buy/rent : « software ecosystem »

(27)

Progiciels et Logiciels Métiers

• Il existe plusieurs types de « mode de fabrication » pour des applications logicielles

o Spécifique

o Framework

o Progiciel

• Critères dimensionnants

o nombres de clients

o taux de couverture (générique / spécifique pour intégration)

o généricité du besoin (intersection / union)

o Taux d’évolution fonctionnel

o Contraintes de performance

• Jeu à « deux acteurs »

o client : make/buy (avec intégration)

o Vendeur: maximiser rentabilité (pas revenu) Troisième Partie: Ecosystème Logiciel

(28)

Comprendre les coûts de fabrication

• Coûts sont fonction du volume du logiciel (cf. Chapitre 5)

o O(n ^1.2) construction

o 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)

coût

Nombre de clients Coût total

Progiciel Coût unitaire

Troisième Partie: Ecosystème Logiciel

(29)

Comprendre les coûts de maintenance

• Cycle de vie des coûts de maintenance

o Le logiciel est un produit « vivant » -> génération successive de versions fonctionnelles

o Chaque version génère un coût de maintenance

 technique

 correction des anomalies

• Réduire les coûts

o Le coût de maintenance dépend de:

 Nombre de versions en activité

 Nombre de clients (taux de découverte des anomalies)

o Conduit à la notion de cycle: garantie/maintenance/maintenance étendue/maintenance spécifique (sur demande)

 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

(30)

ASP et SaaS

• ASP (Application Service Provider)

o Hébergement applicatif

o 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 »

o Multiplicité des fournisseurs

coût

framework

spécifique

Capacité à

évoluer Synchroniser les besoins

Effet complexité

framework

spécifique Nombre de clients

(31)

Sélection de progiciels et Architecture Orientée-Service

• Sélection de progiciel

o Choix d’un modèle métier compatible (coût traduction)

 choix MOA

o Choix d ’un partenaire (adoption des cycles de vie / version)

 Choix long-terme!

o Attention au coût d’intégration spécifique (loi O(n x m 0.5))

o L’intégration ne change pas les performances ni la qualité de service

 Cf. Chapitres 8 & 9

• SOA: utilisation d’un « progiciel à la carte »

o L’approche SOA permet de multiplier la valeur qu’on retire d’un progiciel

o Mutualisation/ Réutilisation passe par une SOA métier, long-terme

& partagée Troisième Partie: Ecosystème Logiciel

(32)

Open Source

• Qu’est-ce l’open-source ? 

o 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)

o QoS : fonction de la taille de la communauté (généricité du logiciel) et de l’implication (généricité de la demande)

• Avantages

o Coûts (même avec les coûts cachés)

o Réactivité

• Contraintes d’utilisation

o Culturel: les développeurs parlent aux développeurs

o 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-openso urce-and-vrm/

)

o Général => open source

(33)

Grid Computing and Cloud Computing

• Grid: utiliser une « ferme » d’ordinateurs en tant que super-ordinateur parallèle

• Cloud Computing: Outsourcing du Grid (Amazon, Google, etc.)

• Trois avantages majeurs:

o

Fault-tolerance à travers la redondance implicite.

o

Très haute performance à travers le parallélisme massif

 Ex: data mining, traitement d’événements en temps réel

 Cf. architecture « MapReduce » de Google

o

TCO réduit par l’utilisation de « Commodity computing » (PC) – Ex: coût hébergement email de Google

 + Économie d’échelle implicite

o

(1 & 2) suppose une architecture logicielle adaptée !

• Le SaaS se prête très bien (souvent, architecture moderne) au

(34)

Limites du Cloud Computing

• Le « cloud computing » est dans une phase naissance =>

beaucoup de « hype »

• Trois limites:

1. Maitrise des données et de la « privacy ».

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

3. 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 »



(35)

Conclusion: Make / Buy / Rent ?

• Le plus important est de se poser la question 

• Il faut raisonner en coût complet (cf. Chap. 5)

• Il faut raisonner en termes de partenariat

• Il faut se mettre à la place du fournisseur et faire un pari (conservateur) sur l’avenir de son marché

• C’est un choix métier qui implique la MOA

o Progiciel : choix d’une vision du métier

o SaaS: choix de la simplicité

• Il faut favoriser les choix « cloud-compatible » (déployable sur un GRID) car elles permettent:

o Une réduction du TCO à travers le « commodity computing »

o Une informatique plus verte: Réduction des GES Troisième Partie: Ecosystème Logiciel