Presentation cesames mars2012

1,936
-1

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,936
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
45
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Complexity: key challenge for management + key challenge for CIO
  • Complicated -> Taylor -> B&S Complex -> collaboration
  • Anecdotal evidence: Japan arm robot -> speed beats brains in complex situations Key thought: Need for agility comex from complexity When the world is complicated, you can be slow & smart, when the world is complex, you must be fast
  • Les processus formalisent la coopération
  • Companies absorbe complexity from their environment
  • Cf. Kelly
  • Complexity: key challenge for management + key challenge for CIO
  • Distance dans le code: lié à l’organisation physique : fichier / module (repository) / sous-système
  • s’exprime comme «  le développement qui répond aux besoins du présent sans compromettre la capacité des générations futures à répondre aux leurs ". Extreme IT ! Extreme programming at IS level
  • Abstraction: définir les bons niveaux d’abstraction Trop haut = trop d’effort d’adaptation Trop bas = trop spécifique pas de réutilisation Modularité des service = question du bon découpage, en services indépendant - aussi peu de co-évolution que possible S’appuper sur les process et les events ! Composabilité Faite du LISP : apprendre le parametrage fonctionnel 
  • Complexity: key challenge for management + key challenge for CIO
  • 10 Things Agile Executives Need To Do Differently by  Kelly Waters , 12 March 2012 |  Agile Adoption ,  Agile Leadership Agile adoption is sometimes driven from the top by courageous executives boldly declaring “We’re going agile!”.  They see a vision of a better, happier place, where development is better, faster, cheaper, and they want it.  That’s understandable, of course.  But some don’t realise the implications.  When moving to agile methods, it’s not just teams that need to change.  Executives need to change too. Here are 10 things agile executives need to do differently: 1.  Do Less  - limit work in progress at portfolio level, eliminate waste, create focus, do less in parallel, keep things simple. 2.  Explore & Adapt  - rather than follow a plan. 3.  Learn Fast  - short feedback loops, tolerate mistakes, value learning and continuous improvement. 4.  One Team, One Goal  - avoid silos by setting up product oriented, co-located, multi-disciplined teams with shared purpose; squash politics. 5.  Focus On Value  - focus on value over cost, deliver value earlier/incrementally, concentrate on building the right product. 6.  Empower Teams  - inspire and engage, provide opportunity for intrinsic motivators: autonomy, mastery and purpose. 7.  Accept Hard Truths  - be open, accept difficult messages, support the team in resolving them; agile doesn’t solve your problems, it highlights them. 8.  Think Big, Start Small -  have the big vision, but deliver it in small bite-sized pieces. 9.  Collaborate  - play nicely, be supportive, give your people’s time, actively participate in projects. 10.  Lead By Example  - be agile yourself, use agile techniques, exhibit agile principles, adopt a servant leadership style.
  • Presentation cesames mars2012

    1. 1. Comment concevoir efficacement des systèmes d’information ? Complexité, Architecture et Lean Software Development CESAMES 20 Mars 2012 (v0.2) Yves Caseau Bouygues Télécom – Académie des TechnologiesYves Caseau - présentation CESAMES – Mars 2012 1/26
    2. 2. Outlinel Gouvernance et Complexité Le défi des entreprises du 21e siècle et de leurs systèmes d’informationl Architecture d’Entreprise, SOA and durabilité L’anticipation dans un monde complexe n’est pas de la prévision, mais la construction d’un “potentiel de situation”l Lean Software Factory L’adaptation des méthodes de développement aux nouveaux défis, dont celui de la complexité Yves Caseau - présentation CESAMES – Mars 2012 2/26
    3. 3. Les entreprises face à un monde complexe1ère Partie : Complexité et Gouvernance Un monde complexe:  Hyper-competition, mondialisation, le temps se “racourcit”  La puissance passe du coté du consommateur (F. Dupuy)  T. Friedman : « All that is easy has been done, what’s left is the hard stuff » Les problèmes compliqués requièrent des spécialistes, les problèmes complexes font appel à tous  Diversité des compétences et des points de vues …  … organisés en équipe Les problèmes complexes se traitent “sur le terrain” (gemba) un à la fois, là où ils se trouvent  Les abstractions cachent trop de choses, la décomposition ne marche pas!  “les conditions reproductibles” … ne le sont pas (isolation impossible)  La communication est difficile (ex: spécifier plus difficile que réaliser) Yves Caseau - présentation CESAMES – Mars 2012 3/26
    4. 4. Les entreprise du 21e siècle doivent être agiles1ère Partie : Complexité et Gouvernance ourt-terme (satisfaire ses clients)  Vitesse (lead time)  Zéro défauts (juste du premier coup)  Orienté-client oyen-terme (suivre ses clients)  Flexibilité (s’adapter aux nouveaux besoins)  Réactivité (le faire rapidement) ong-terme (apprendre à évoluer) Systemic Challenge :  Apprentissage (nouvelles compétences) continuous  Travail d’équipe adaptation to  Développement des collaborateurs environment Yves Caseau - présentation CESAMES – Mars 2012 4/26
    5. 5. L’entreprise en réseau: S’adapter à la complexité selon la biologie1ère Partie : Complexité et Gouvernance rganisation et Management doivent évoluer:  Control & command → recognition & response (L. Morris)  Organisation dynamique sur des thèmes, auto-organisation (C. Shirky) trength of Weak Ties (M. Granovetter)  Pour innover / réagir à une crise, il faut s’appuyer sur ses relations distantes (liens faibles: les personnes que l’on voit rarement)  Homophilie : “tendance à s’associer à des personnes qui vous ressemblent” raison pour ne pas s’appuyer uniquement sur ses « liens forts »  évelopper son « potentiel de situation » (« Stratégie Chinoise » )  Passer d’une planification détaillée à une réaction opportuniste  Bénéfice des exercices, travaux pratiques et “serious games”  Construire des “reflexes” (A.N. Whitehead, N. Taleb) Yves Caseau - présentation CESAMES – Mars 2012 5/26
    6. 6. Collaboration & Coopération : « Nouveau Management Scientifique »1ère Partie : Complexité et Gouvernance ’approche de F. Taylor a atteint ses limites :  Projection de l’œuvre collective sur les individus (décomposition & spécialisation)  Il s’agit maintenant de travailler autrement, en équipe  Passe du compliqué au complexe … n travail complexe requière une forme d’orchestration  Multiple flux d’information (il faut dire ce que l’on fait)  Plus on décompose/spécialise, plus il faut parler ! ollaboration vs. Coopération: les deux sont nécessaires  Collaboration: résultat commun, objectif partagé, responsabilité indistincte  Coopération: résultat commun, mais les buts et les responsabilités sont distinctes (… d’ou les “processus métiers ) Yves Caseau - présentation CESAMES – Mars 2012 6/26
    7. 7. L’enterprise est un “système complexe”1ère Partie : Complexité et Gouvernance  Complexité numérique (nombre de choses)  Multi-échelle  Complexité temporelle  Richesse des interactions avec l’environnement  Exemples de symptômes:  Coûts (Systèmes d’information)  Exemple: évolution non-linéaire des coûts projets vs. leur taille  Taux d’erreurs et de pannes  Difficulté à « garantir » la robustesse et la résistance aux pannes  Ross Ashby « la régulation d’un système (complexe) requière un système de contrôle qui est aussi complexe que le système lui-même »  Time-to-market  La première manifestation de la complexité interne  Le temps pour intégrer un nouveau composant dépend de la taille de l’hôte : – Complexité humaine (organisation) – Absence de modularité (impacts inattendus & interaction entre composants)  Loi des “conséquences inattendues”– Feature Interaction Problem Yves Caseau - présentation CESAMES – Mars 2012 7/26
    8. 8. Conséquences d’une “vision systémique”1ère Partie : Complexité et Gouvernance  “Emergence” de propriétés et caractéristiques  Des « systèmes obtenus par design et agencement » …  .. à la « culture de systèmes » (K. Kelly)  Humilité and Amélioration continue  Expliciter les « politiques/règles »  SLA, contrats de services, règles gouvernance OM, …  “Enterprise Architecture” comme discipline d’entreprise  Alignement des parties prenantes  Importance de l’environnement externe  Gouvernance de la complexité Complexité  Reconnaitre le problème !  S’y attaquer avec méthode / Exécution dans le persévérance  Monde Réel Agilité  Cf. le cube du CEISAR’s Modèle Eléments Partageables ou Réutilisables Eléments Spécifiques Operations Transformations Synergie Yves Caseau - présentation CESAMES – Mars 2012 8/26
    9. 9. Gouvernance de la complexité1ère Partie : Complexité et Gouvernance  Réfléchir en « potentiel de situation » vs « schéma directeur »  Scénarios  Jeux (serious games)  … si nous étions … un de nos compétiteurs ?  … si nous « out-sourcions » cette activité ?  … si nous offrions ce service à une autre entreprise (SaaS)  Développement durable de l’entreprise et de son SI  Cf. 2e partie – éviter le « mur » de l’obésité  Rythme durable de l’effort continu de réorganisation (urbanisation)  Subsidiarité  Autonomie, Encapsulation et Gouvernance déclarative  « Thing globally, act locally »  Management visuel (éducation systémique) Yves Caseau - présentation CESAMES – Mars 2012 9/26
    10. 10. 2ème Partie2e Partie: Architecture d’Entreprise l Gouvernance et Complexité Le défi des entreprises du 21e siècle et de leurs systèmes d’information l Architecture d’Entreprise, SOA and durabilité L’anticipation dans un monde complexe n’est pas de la prévision, mais la construction d’un “potentiel de situation” l Lean Software Factory L’adaptation des méthodes de développement aux nouveaux défis, dont celui de la complexité Yves Caseau - présentation CESAMES – Mars 2012 10/26
    11. 11. Enterprise Architecture2e Partie: Architecture d’Entreprise Architecture: Pourquoi ? Architecture: Comment ?  Communiquer une vision  Outil de transformation  « Enterprise Architecture »  Mise en cohérence de trois niveaux  Maitriser la complexité  Stratégie: objectifs  Simplicité et modularité  opérations: processus and données  Promouvoir la standardisation  Systèmes d’information:  Favoriser la réutilisation applications et services  Aligner les parties prenantes  Réduire la complexité (toolbox)  Éviter les outils complexes et  Approche composants formalismes obscurs  Orientation processus  Dépend de la maturité propre (extraction de la logique métier)  Découplage temporel de chaque entreprise (messages asynchrones)  Asynchronie / Diachronie  Découplage fonctionnel  Sert de mémoire d’entreprise (intermédiation)  Management visuel du changement Yves Caseau - présentation CESAMES – Mars 2012 11/26
    12. 12. Données et Fonctions2e Partie: Architecture d’Entreprise Architecture de données Architecture fonctionnelle  Modèle de données  Décomposition  Sémantique  Fonctions et sous-fonctions,  Modèle conceptuel approche « top-down »  Ontologies: hiérarchies de  Normalisation descriptive: (entrées, sorties, classes (UML) invariants, pre/post-conditions, …)  Architecture de données  L’architecture fonctionnelle n’est pas  Distribution isolée (une leçon des 20 dernière années)  Formats (ex: XML)  Un focus étroit sur l’architecture fonctionnelle conduit à prendre en compte  Cycle de vie trop tard les données et les processus.  Gestion dynamique des  Une architecture fonctionnelle trop poussée objets métiers conduit à des silos  Distribution /  L’approche fonctionnelle « top-down » est synchronisation mal adaptée à l’utilisation de progiciels  Sauvegarde / restauration  Design orienté-objet au niveau du SI :  Flux de données mélanger fonctionnel et données Yves Caseau - présentation CESAMES – Mars 2012 12/26
    13. 13. Processus et Services2e Partie: Architecture d’Entreprise Architecture de Processus Architecture de Services  Structure temporelle:  Service = Chaînage et dépendances ⇒  Evénements Fonction + Interface + Contrat   Service Architecture logique métier  Structure (organiser le graphe d’appels)  Réifier les buts en processus  Fournir du sens (simplifier la gestion du changement et la réutilisation)  Récursif (“fractal”)  SOA local = service-based architecture  Processus/sous-processus  Souvent lié à une technologie,  Familles de processus  L’objectif est le système (et son  Partagent des ressources: architecture), les services sont un données, IHM, … moyen)  Rôles (alignement organisationnel)  SOA global = architecture-based list  description-> services, fonctions,  Indépendant des technologies  Normaliser / Standardiser  Le but est d’obtenir un catalogue de services durables, l’architecture  Partager / réutiliser / BPO (l’organisation) est un moyen (qui varie  Meilleure approche pour au cours du temps) l’intégration de progiciels Yves Caseau - présentation CESAMES – Mars 2012 13/26
    14. 14. Construire une architecture modulaire2e Partie: Architecture d’Entreprise  Objectif: minimiser la dispersion des impacts (nouveau service)  “Définition”: la modularité est une corrélation:  « Distance dans le code » & fréquence des interactions  « Distance dans code » & « coévolution »  Bonnes pratiques:  Architectures en couches (définir des niveaux d’abstraction)  Architecture de processus (définir une grammaire de composition)  Même objectif pour partage/réutilisation et modularité: identifier les sous-processus communs  Event-Oriented Architecture  « Pub/sub » reste un des meilleurs motif modulaire  Model-Driven Architecture: design d’un modèle de données « future-proof »  L’architecture de services réduit les interactions non-pilotées  Réification de l’architecture fonctionnelle  Abstraction/ encapsulation Yves Caseau - présentation CESAMES – Mars 2012 14/26
    15. 15. Systèmes d’information durables2e Partie: Architecture d’Entreprise  « développer les services du SI correspondant aux besoins d’aujourd’hui sans diminuer la capacité future de développer ceux de demain, à travers une sur-utilisation de ressources ou la production d’une complexité non gérable ».  Librement inspiré de la définition de la commission Brundtland   (global) SOA est la seule méthode pour un développement durable  Pas la seule façon de faire de l’architecture d’entreprise (d’autres méthodes sont efficace pour réduire la complexité)  Mais la meilleure façon pour le faire de façon continue, avec l’ensemble des parties prenante, dans une démarche de long terme qui génère ses propres récompenses (cercle vertueux)  Nettoyage : apprendre à supprimer et alléger (classique )  Cf. Extreme programming (Agile Manifesto – 3e Partie) :  Lisser l’effort, intégration continue, privilégier la simplicité  Simplification en continu, pas un effort héroïque de dernier ressort Yves Caseau - présentation CESAMES – Mars 2012 15/26
    16. 16. SOA & Gouvernance :2e Partie: Architecture d’Entreprise Trois étapes du « SOA global »:  Service Definition: construire la liste des services métiers. Commence comme une analyse fonctionnelle (à partir des processus) – mais la « réusabilité » et la « composabilité » sont construites au travers d’un dialogue entre la vision métier et la vision SI.  Architecture de Service: Transformer une liste en structure hiérarchisée et modulaire. Difficultés et solutions classiques (ex: refactoring) … pour éviter les « Web Services spaghetti».  Intégration de Services : l’étape technique – (SOI vs SOA). La technologie est mure aujourd’hui  - ce n’est pas le plus complexe SOA commence à la périphérie (aux interfaces) du système et termine par le cœur – En revanche, l’architecture de donnée est critique.  Attention au “proof of concept” plus difficile à intégrer qu’à construire   Gouvernance SOA  Fondée en premier lieu sur des “artefacts” partagés (schémas d’architecture, catalogue de services, roadmaps) et les différents rôles associés (droits et devoir des parties prenantes)  « Something you do, not something you buy » - David Linthicum Yves Caseau - présentation CESAMES – Mars 2012 16/26
    17. 17. SOA comme discipline: Services “orientés-architecture”2e Partie: Architecture d’Entreprise  Comment obtenir la réusabilité, à travers l’entreprise (partage) et au cours du temps ?  Abstraction  Un compromis entre la spécificité et la généricité  Réification des rôles et de (certaines) relations  Modularité  S’appuyer sur les processus et sur les graphes d’événements  Penser “ontologie” plus que “description”  Composabilité  Horizontale (Processus) : Modèle Objet Commun (Pivot)  Verticale (Fonctionnelle) : Polymorphisme Paramétrique   Discipline: gérer des modèles d’API  Gérer les versions !  Méta modèle des API: mérite quelques efforts !  Chaque DSI doit penser en tant qu’éditeur de logiciel  Plus un art qu’une science  Yves Caseau - présentation CESAMES – Mars 2012 17/26
    18. 18. 3ème Partie3e Partie: Lean Software Factory l Gouvernance et Complexité Le défi des entreprises du 21e siècle et de leurs systèmes d’information l Architecture d’Entreprise, SOA and durabilité L’anticipation dans un monde complexe n’est pas de la prévision, mais la construction d’un “potentiel de situation” l Lean Software Factory L’adaptation des méthodes de développement aux nouveaux défis, dont celui de la complexité Yves Caseau - présentation CESAMES – Mars 2012 18/26
    19. 19. Software Factory3e Partie: Lean Software Factory  Intégration continue  Automatisation des tests et des configurations  Le travail des développeurs est intégrée et testé chaque nuit  Automatisation de la qualimétrie  Vers un déploiement continu … complètement automatisé  Structure plateau projet (« one Roof »)  Cohabitation des différents rôles: développement / intégration / test / architecture /  Devops : une nouvelle culture pour une nouvelle organisation  Opérations pilotées par programme  Adapté au Cloud Computing  Fusion des cultures développement / production  Production adaptée au développement agile  Inspiré des approches lean → petits lots Source: Wikipedia Yves Caseau - présentation CESAMES – Mars 2012 19/26
    20. 20. Développement Agile - SCRUM3e Partie: Lean Software Factory  La spécification du produit est remplacé par un « backlog » des attentes  Utilisation de « story boards » Pourquoi des « petits lots » ?  Travail en lots courts (sprints) Complexité + évolution rapide ⇒  Time-boxing Avancer par petits pas & réévaluer  Voir ce que l’on construit / éviter le tunnel  Participation active du client/utilisateur sur le lieu de développement.  Besoin/ architecture / design / code  Spécification / conception se font en continu / collectif  Réunion d’équipe quotidienne, management visuel (murs) Yves Caseau - présentation CESAMES – Mars 2012 20/26
    21. 21. Extreme Programming3e Partie: Lean Software Factory  Remettre le code à l’honneur  « the innovation is the code »  Un code élégant, maitrisé et revu fréquemment  Rôle central du test pour développer du code de qualité Source: Wikipedia  Penser test en premier – savoir ce que l’on veut  Application du « lean thinking » - pull vs. Push – et ça marche !  Valeurs (cf. Wikipedia)  Communication  Simplicité – seules les architectures simples sont durables  Feedback – cf. méthodes agiles + test en continu  Courage & respect  Pratiques  Agile: itératif, « user stories », petits lots, espace ouvert et dédié à l’équipe, …  Travailler avec un rythme durable (« set a sustainable pace »)  Pair programming Yves Caseau - présentation CESAMES – Mars 2012 21/26
    22. 22. Lean Startup / Pretotyping / Google Values all else will follow3e Partie: Lean Software Factory Innovator s beat idea s Focus on the user and Build It’s best t in g be o do one t ats t hing reall alkin y, reall g y well committees Commitment beats Fast is better than slow nion ea ts opi Rough Consensus Data b and Working Cod e The Lean Startup : le best-seller mondial d’Eric Ries  Validated learning  Innovation : machine à produire des “idées qui marchent”  Minimum viable product  Collecter et analyser des faits, le plus tôt possible  Synchronicité  L’efficacité d’une équipe calée sur un takt time commun Yves Caseau - présentation CESAMES – Mars 2012 22/26
    23. 23. Lean Schematic Vision  Skills Learning3e Partie: Lean Software Factory Lean « Work Philisophy » How ? • Go and see the gemba Problem Solving • Search for deep causes Continous Improvement • Continuous improvement « Lean Engine » (3) Pull – flux tendus • Teamwork (4) Heijunka Lean Engine (2) Streamline (fluidifier) Juste-à-temps (lissage) Fractionner processu (réduire la taille des lots) s (1) Éliminer muda Focus sur valeur (2) Streamline Single Piece Flow, Just-in-Time Lean Engine Small batches (4) Heijunka (leveling) (3) Pull – process (1) Eliminate muda Focus on value Subtle Customer focus: interaction  Why ? • value analysis between all (meaning) factors • done right on the first time • reduce lead time • increase flexibility Yves Caseau - présentation CESAMES – Mars 2012 23/26
    24. 24. Lean Software Development (I) « Faire juste du premier coup »  Mise en valeur du code, focus sur la qualimétrie  Mode agile : faire moins, pas « moins bien » Client « sur place » - au cœur du processus de développement  Cf. SCRUM/XP – « le client est toujours disponible » Tester dès que possible  Tests unitaires – cf. extreme programming  Tests clients – cf. Lean Startup « Time-boxing » : Utiliser le levier du « lead time »  Pour la satisfaction client (agilité / pertinence)  Pour augmenter la qualité (défi permanent) Kaizen  Culture de l’amélioration continue (cf. SCRUM – retour d’expérience)  Outil d’apprentissage du travail en équipeYves Caseau - présentation CESAMES – Mars 2012 24/26
    25. 25. Lean Software Development (II) Pas d’attentes  Minimiser les ruptures (action / responsabilité) Synchronicité  « Talk time » : temps commun Priorité à laval (pull)  Production > Intégration > Développement > Architecture > Conception  Ne faire que ce qui est utile, au bon moment – « just in time » Management visuel  Utiliser les murs : planning, liste des problèmes, architecture, ….  Outil de pilotage systémique (cf. Kanban pour le JIT) Simplicité  KISS ( paradoxe → cf. Ashby)  moins de code  Éliminer le « muda »Yves Caseau - présentation CESAMES – Mars 2012 25/26
    26. 26. Conclusion Les modèles et l’architecture sont la clé pour :  Agilité  Potentiel de situation (saisir les opportunités)  Maitriser / optimiser ses coûts L’innovation dans le monde numérique se produit dans le code source  Fin du modèle de Taylor  Développement agile (utilisateur / designer / développeur)  Lean IT: participation du client, livraison fréquente de petits lots, qualité du code, moins de code, pas d’attente, équipe Il faut se préparer au monde “massivement parallèle”  Cloud, multi-processeur, multi-coeurs, …  … même pour des fonctions de back-office  Fin du modèle de Von Neuman  Yves Caseau - présentation CESAMES – Mars 2012 26/26
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×