Les enjeux stratégiques auxquels les Systèmes d'Information doivent aujourd'hui répondre (mobilité, time-to-market, connaissance et usages client/consommateur, personnalisation, cross-canal) nécessitent de penser autrement la façon de concevoir le SI. Valtech vous proposera un aperçu des pratiques d'architecture qui permettent d'insuffler de l'agilité dans votre SI. Yann Le Tanou, Directeur Architecture & Urbanisme, Valtech yann.letanou@valtech.fr

1. ArchitectureAgile
16 juin 2015 – Yann Le Tanou, Directeur Archi&Urba
yann.letanou@valtech.fr

2. PourquoiValtech?
STRATEGY CREATIVITY TECHNOLOGY AGILITY
Valtech, acteur full-service de votre transformation digitale

3. Desnouvellestendancesetnouveauxbesoins…
Recentrage sur le cœur de métier
Multiplication des partenaires
Cloud
Big Data
NoSql
Transformation
Digitale
Connaissance
accrue
des usages
Mobilité
étendue
Lean
Startup
Devops
Transformation
agile

4. Maislesautresbesoinssonttoujoursd’actualité!
« Lutter contre les résistances au changement… »
« Améliorer la relations MOA-MOE… »
« Limiter les redondances de données, flux, fonctionnalités… »
« Améliorer la qualité des données… »
« Réduire les Coûts récurrents SI dont MCO… »
« Intégrer plus facilement… »
« Améliorer temps de réponse et scalabilité… »
« Déployer plus fréquemment… »
« Réduire les Adhérences fournisseurs… »
« Réduire la dette technique et l’obsolescence… »

5. DesenjeuxmétierstotalementimbriquésauxenjeuxduSI
Évolution permanente des besoins
Mobilisation des parties prenantes
Marchés en transformation continue
Connaissance « intime » des usages des clients et consommateurs
Intégrer au plus tôt les innovations technologiques
Multiplication des canaux de communication
Fiabilité et sécurité du SI
Suivi des processus de bout en bout et de plus en plus fin

6. Unfoisonnementtechnologiquesanséquivalent
Innovation technologique en accélération
Multiplicité et hétérogénéité des sources de données
Traitements de plus en plus scalables et volumineux
Multiplication des canaux de communication et des partenariats

7. « Il devient fondamental d’investir
dans des pratiques d’architecture
d’intégration partagées par tous et
en phase avec les pratiques agiles ! »

8. Système Agile
Capacitésd’unsystèmeagile
C1
Capacité à évoluer en continue avec des déploiements fréquents de
nouveaux services à valeur métier
C2
Capacité à manipuler des données métier multiples, hétérogènes et
volumineuses
C3 Capacité à s’adapter à de fortes variations de charge
C4 Capacité à offrir une très haute disponibilité
C5
Capacité à dialoguer avec des périphériques et des partenaires multiples
tout en offrant une expérience continue et globale aux utilisateurs

9. Quellesméta-exigencesd’architectureagile
Système
Agile
Conduite par le métier,
centrée sur la donnée
Orientée-services Fondée sur une forte
cohésion et un faible
couplage des composants
Événementielle
Communicante via
des médiations
Favorisant le stockage
sans contrainte
Portée par un langage commun
d’échange des données
Construite pour le Cloud
1
2
3
4
567
8

10. L’Entreprise (vue métier)
Le Système d’Information (vue fonctionnelle)
Le Système Informatique (vue applicative)
L’Infrastructure (vue technique)
Conduiteparlemétieretcentréesurladonnée
Clients Fournisseurs
Filiales
Distributeurs
Partenaires
Unicité de la donnée
Référence unique et immuable
Modèle de données pivot
Entités métier
(invariants)
Responsabilité sur la donnée
qualité de la donnée
Format d’échange unifié
Disponibilité de la donnée
Réplication, Archivage
Volumétrie, Sécurité
« entité métier »
Stock
« entité métier »
Produit
« entité métier »
Commande
« entité métier »
Client
C1 C2 C3 C4 C5
capacités
Architecture

11. Orientée-service
L’Entreprise (vue métier)
Le Système d’Information (vue fonctionnelle)
Le Système Informatique (vue applicative)
L’Infrastructure (vue technique)
Services
exposés
Services
exposés
Services
exposés
Services
exposés
Services
consommés
Services
consommés
Services
consommés
Services
consommés
Clients Fournisseurs
Filiales
Distributeurs
Partenaires
support
réalisation
déploiement
support
réalisation
déploiement
C1 C2 C3 C4 C5
capacités
Architecture

12. Un service représente une capacité qu'un fournisseur met à disposition de multiples
consommateurs, aux travers d'interfaces clairement établies et masquant la façon dont la
capacité est réalisée
Une interface spécifie un ensemble d’opérations associé à des structures d’échange de
données que le service met à disposition de ces consommateurs pour accéder à la capacité
La mise en œuvre du service est précisée par la définition de rôles et contraintes à respecter
côté fournisseur et consommateur
Orientée-services
«service»
sStocks
«interface»
iStocks
capacité
rôles
contraintes
«service»
sProduits
«interface»
iProduits
capacité
rôles
contraintes
Fournisseur du
service sStocks ;
consommateur du
service sProduits
Fournisseur du
service sProduits
«fournit»
«requiert»
«fournit»
« entité métier »
Stock
«dérive»
« entité métier »
Produit
«dérive»
«responsabilité» «responsabilité»
C1 C2 C3 C4 C5
capacités
Architecture

13. FondéesuruneFortecohésionetunfaiblecoupagedescomposants
«composant»
Gestion des Stocks
Ports d’entrée Ports de sortie
(…)
«composant»
Gestion des
Achats
«composant»
Suivi des
Commandes
«composant»
Catalogue
Produits
Les composants sont indépendants les uns des autres
Chaque composant encapsule un ensemble de fonctions cohérentes entre elles
Les composants communiquent uniquement via leurs ports
Les ports définissent des protocoles d’échanges indépendamment de la façon dont les
composants sont implémentés
connecteur
données échangées
sous-
compo-
sant
Architecture interne du composant
(sous-composants)
données échangées
responsabilités ; données stockées
C1 C2 C3 C4 C5
capacités
Architecture

14. L’Entreprise « composant »
Unité
Organisationnelle
Descomposantsdeservicesàtouslesniveaux
Le Système d’Information
Le Système Informatique
L’Infrastructure
Services
exposés
Services
exposés
Services
exposés
Services
exposés
Services
consommés
Services
consommés
Services
consommés
Services
consommés
« composant »
Unité
Organisationnelle
« composant »
Unité
Organisationnelle
« composant »
Bloc
Fonctionnel
« composant »
Bloc Applicatif
« Composant »
Ressource
d’Exécution
Clients Fournisseurs
Filiales
Distributeurs
Partenaires
support
réalisation
déploiement
C1 C2 C3 C4 C5
capacités

15. «composant applicatif»
Gestion des Stocks
Composantapplicatifdeservice
«service»
sStocks
iStocks
capacité
rôles
contraintes
port1:sStocks
«consomme»
«service»
sProduits
iProduits
capacité
rôles
contraintes
port2~:iProduits«produit»
Stock
«donnée stockée »
« ref »
Produit
«composant applicatif»
Catalogue Produits
Produit
«donnée stockée »
port1:sProduits
« entité métier »
Stock
« entité métier »
Produit
«dérive»
«dérive»«produit»
C1 C2 C3 C4 C5
capacités

16. «événement»
evCommande
Un événement véhicule un changement d’état à un instant t d’un élément significatif
Tout composant peut produire des événements consommés par d’autres composants et
réciproquement, dans la limite des fonctions qu’il encapsule
Un composant produisant un événement ignore toujours ce qu’il adviendra de celui-ci
Les événements sont véhiculés via des composants techniques équivalent à des « boites
aux lettres », dans lesquels les producteurs postent leurs événements tandis que les
consommateurs retirent ces événements
Événementielle
«composant»
Gestion des Stocks
port1:sStocks
Définition
Cycle de vie
Contraintes
«consomme»
port2~:evCommande
« boites aux lettres »«composant»
Gestion des Commandes
port1:evCommande
«produit»
Stock
«donnée stockée »
Commande
«donnée stockée »
C1 C2 C3 C4 C5
capacités
Architecture

17. Communicanteviadesmédiations
producteurs d’événements
Logique de routage
événements vers
orchestration de
services
producteurs de services
« médiation »
Routage Ev
Événement (Asynchrone)  Service (synchrone)
C1 C2 C3 C4 C5
capacités
Architecture

18. Portéeparunlangagecommund’échangededonnées
L’Entreprise
Le Système d’Information
Le Système Informatique
L’Infrastructure
Clients Fournisseurs
Filiales
Distributeurs
Partenaires
« entité métier »
Stock
« entité métier »
Produit
« entité métier »
Commande
« entité métier »
Client
« document »
eClient
« document »
eCommande
« document »
eProduit
« document »
eStock
« format »
eClient.json
« format »
eClient.xml
« format »
eClient.html
Protocoles : http,
amqp, ftp, smtp, etc.
ETL Message Queue ESB API Gateway
C1 C2 C3 C4 C5
capacités
Architecture

19. Node n
Node 2
Favorisantlestockagesanscontrainte
Node 1
Stocks Produits
Clients
Stocks Produits
Commandes
Stocks Produits
Clients Commandes
DATA CLUSTER
Catalogue Produits
Produit
«donnée stockée »
Gestion Client
Client
«donnée stockée »
Prise de Commandes
Commandes
«donnée stockée »
Gestion des Stocks
Stock
«donnée stockée »
Serviced’Infrastructure
Serviced’Infrastructure
«consomme» «consomme»
C1 C2 C3 C4 C5
capacités
Architecture

20. ConstruitepourleCloud(IaaSetPaaS)
IaaS/PaaSComposant de
Service
IaaS/PaaS
Composant de
Service
Composant de
Service
Médiation
«déploiement»
«déploiement»
«déploiement»
«déploiement»
«déploiement»
Élasticité
Facturation à la consommation
Montée en charge
Disponibilité
VM
VM
VM
VM
VM
VM
C1 C2 C3 C4 C5
capacités
Architecture

21. ConstruitepourleCloud(SaaSetiPaaS)
Les Systèmes de demain seront avant tout une intégration de services SaaS publiques et
de services développés en interne et eux même déployés en cloud privé et/ou publique, à
travers la mise en place de composants de médiations
C1 C2 C3 C4 C5
capacités
Architecture
SI externalisé SaaS Service API
SI Internalisé
MédiationMédiation
Médiation
MédiationMédiation
(iPaaS)
Service API
Service API
Service API
Service API
Service API
Service API
Service API

22. La complexité de la réalité est souvent sous-estimée
La transformation vers une architecture agile doit se faire par palier
La vision n’est pas la cible, elle définie les orientations à prendre
Vision/Réalité/Futur

23. « Des architectures agiles pour des
transformations plus rapides, plus
nombreuses, plus radicales, en tirant
pleinement parti des opportunités
technologiques au fur et à mesure de
leur découverte ! »

24. THANK YOU
VALTECH.COM