Valtech - Architecture Agile des SI

1 364 vues

Publié le

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

Publié dans : Technologie
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 364
Sur SlideShare
0
Issues des intégrations
0
Intégrations
118
Actions
Partages
0
Téléchargements
28
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Valtech - Architecture Agile des SI

  1. 1. ArchitectureAgile 16 juin 2015 – Yann Le Tanou, Directeur Archi&Urba yann.letanou@valtech.fr
  2. 2. PourquoiValtech? STRATEGY CREATIVITY TECHNOLOGY AGILITY Valtech, acteur full-service de votre transformation digitale
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 24. THANK YOU VALTECH.COM

×