Yves Caseau - présentation CESAMES – Mars 2012 1/26
Comment concevoir efficacement Comment concevoir efficacement des systèmes d’information ?des systèmes d’information ?
Complexité, Architecture et Complexité, Architecture et Lean Software DevelopmentLean Software Development
CESAMES20 Mars 2012 (v0.2)
Yves CaseauBouygues Télécom – Académie des
Technologies
Yves Caseau - présentation CESAMES – Mars 2012 2/26
OutlineOutline
1. Gouvernance et Complexité Le défi des entreprises du 21e siècle et de leurs systèmes d’information
2. 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”
3. Lean Software FactoryL’adaptation des méthodes de développement aux nouveaux défis, dont celui de la complexité
Yves Caseau - présentation CESAMES – Mars 2012 3/26
Les entreprises face à un monde complexeLes entreprises face à un monde complexe
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)
1ère P
art
ie :
Com
ple
xit
é e
t G
ou
vern
an
ce
Yves Caseau - présentation CESAMES – Mars 2012 4/26
Les entreprise du 21Les entreprise du 21ee siècle doivent être agiles siècle doivent être agiles
Court-terme (satisfaire ses clients) Vitesse (lead time) Zéro défauts (juste du premier coup) Orienté-client
Moyen-terme (suivre ses clients) Flexibilité (s’adapter aux nouveaux besoins) Réactivité (le faire rapidement)
Long-terme (apprendre à évoluer) Apprentissage (nouvelles compétences) Travail d’équipe Développement des collaborateurs
Systemic Challenge : continuous adaptation
to environme
nt
1ère P
art
ie :
Com
ple
xit
é e
t G
ou
vern
an
ce
Yves Caseau - présentation CESAMES – Mars 2012 5/26
L’entreprise en réseau:L’entreprise en réseau:S’adapter à la complexité selon la biologieS’adapter à la complexité selon la biologie
Organisation et Management doivent évoluer: Control & command → recognition & response (L. Morris) Organisation dynamique sur des thèmes, auto-organisation (C. Shirky)
Strength 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 »
Dé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)1
ère P
art
ie :
Com
ple
xit
é e
t G
ou
vern
an
ce
Yves Caseau - présentation CESAMES – Mars 2012 6/26
Collaboration & Coopération :Collaboration & Coopération : « Nouveau Management Scientifique » « Nouveau Management Scientifique »
L’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 …
Un 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 !
Collaboration 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 )1ère P
art
ie :
Com
ple
xit
é e
t G
ou
vern
an
ce
Yves Caseau - présentation CESAMES – Mars 2012 7/26
L’enterprise est un “système complexe”L’enterprise est un “système complexe”
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
1ère P
art
ie :
Com
ple
xit
é e
t G
ou
vern
an
ce
Yves Caseau - présentation CESAMES – Mars 2012 8/26
Conséquences d’une “vision systémique”Conséquences d’une “vision systémique”
“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é Reconnaitre le problème ! S’y attaquer avec méthode /
persévérance Cf. le cube du CEISAR’s
Complexité
Agilité
Synergie
Exécution dans le
Monde Réel
Modèle
Eléments SpécifiquesOperations
Transformations
Eléments Partageables
ou Réutilisables
1ère P
art
ie :
Com
ple
xit
é e
t G
ou
vern
an
ce
Yves Caseau - présentation CESAMES – Mars 2012 9/26
Gouvernance de la complexitéGouvernance de la complexité
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)
1ère P
art
ie :
Com
ple
xit
é e
t G
ou
vern
an
ce
Yves Caseau - présentation CESAMES – Mars 2012 10/26
22èmeème Partie Partie
1. Gouvernance et Complexité Le défi des entreprises du 21e siècle et de leurs systèmes d’information
2. 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”
3. Lean Software FactoryL’adaptation des méthodes de développement aux nouveaux défis, dont celui de la complexité
2e P
art
ie:
Arc
hit
ectu
re d
’En
trep
rise
Yves Caseau - présentation CESAMES – Mars 2012 11/26
Enterprise ArchitectureEnterprise Architecture
Architecture: Pourquoi ?Architecture: Pourquoi ? Architecture: Comment ?Architecture: Comment ?
Communiquer une vision Outil de transformation
Maitriser la complexité Simplicité et modularité Promouvoir la standardisation Favoriser la réutilisation
Aligner les parties prenantes Éviter les outils complexes et
formalismes obscurs Dépend de la maturité propre
de chaque entreprise Asynchronie / Diachronie
Sert de mémoire d’entreprise Management visuel du
changement
« Enterprise Architecture » Mise en cohérence de trois niveaux
Stratégie: objectifs opérations: processus and données Systèmes d’information:
applications et services Réduire la complexité (toolbox)
Approche composants Orientation processus
(extraction de la logique métier) Découplage temporel
(messages asynchrones) Découplage fonctionnel
(intermédiation)
2e P
art
ie:
Arc
hit
ectu
re d
’En
trep
rise
Yves Caseau - présentation CESAMES – Mars 2012 12/26
Données et FonctionsDonnées et Fonctions
Modèle de données Sémantique Modèle conceptuel Ontologies: hiérarchies de
classes (UML) Architecture de données
Distribution Formats (ex: XML) Cycle de vie
Gestion dynamique des objets métiers
Distribution / synchronisation
Sauvegarde / restauration Flux de données
Architecture de donnéesArchitecture de données Architecture fonctionnelleArchitecture fonctionnelle
Décomposition Fonctions et sous-fonctions,
approche « top-down » Normalisation descriptive: (entrées, sorties,
invariants, pre/post-conditions, …) L’architecture fonctionnelle n’est pas
isolée (une leçon des 20 dernière années) Un focus étroit sur l’architecture
fonctionnelle conduit à prendre en compte trop tard les données et les processus.
Une architecture fonctionnelle trop poussée conduit à des silos
L’approche fonctionnelle « top-down » est mal adaptée à l’utilisation de progiciels
Design orienté-objet au niveau du SI : mélanger fonctionnel et données
2e P
art
ie:
Arc
hit
ectu
re d
’En
trep
rise
Yves Caseau - présentation CESAMES – Mars 2012 13/26
Processus et ServicesProcessus et Services
Service = Fonction + Interface + Contrat
Service Architecture Structure (organiser le graphe d’appels) Fournir du sens (simplifier la gestion du
changement et la réutilisation) SOA local = service-based architecture
Souvent lié à une technologie, L’objectif est le système (et son
architecture), les services sont un moyen)
SOA global = architecture-based list Indépendant des technologies Le but est d’obtenir un catalogue de
services durables, l’architecture (l’organisation) est un moyen (qui varie au cours du temps)
Architecture de ProcessusArchitecture de Processus Architecture de ServicesArchitecture de Services
Structure temporelle: Evénements Chaînage et dépendances ⇒
logique métier Réifier les buts en processus
Récursif (“fractal”) Processus/sous-processus Familles de processus
Partagent des ressources: données, IHM, …
Rôles (alignement organisationnel) description-> services, fonctions,
Normaliser / Standardiser Partager / réutiliser / BPO Meilleure approche pour
l’intégration de progiciels
2e P
art
ie:
Arc
hit
ectu
re d
’En
trep
rise
Yves Caseau - présentation CESAMES – Mars 2012 14/26
Construire une architecture modulaireConstruire une architecture modulaire
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
2e P
art
ie:
Arc
hit
ectu
re d
’En
trep
rise
Yves Caseau - présentation CESAMES – Mars 2012 15/26
Systèmes d’information durablesSystèmes d’information durables
« 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
2e P
art
ie:
Arc
hit
ectu
re d
’En
trep
rise
Yves Caseau - présentation CESAMES – Mars 2012 16/26
SOA & Gouvernance : SOA & Gouvernance :
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
2e P
art
ie:
Arc
hit
ectu
re d
’En
trep
rise
Yves Caseau - présentation CESAMES – Mars 2012 17/26
SOA comme discipline: Services “orientés-architecture”SOA comme discipline: Services “orientés-architecture”
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
2e P
art
ie:
Arc
hit
ectu
re d
’En
trep
rise
Yves Caseau - présentation CESAMES – Mars 2012 18/26
33èmeème Partie Partie
1. Gouvernance et Complexité Le défi des entreprises du 21e siècle et de leurs systèmes d’information
2. 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”
3. Lean Software FactoryL’adaptation des méthodes de développement aux nouveaux défis, dont celui de la complexité3
e P
art
ie:
Lean
Soft
ware
Facto
ry
Yves Caseau - présentation CESAMES – Mars 2012 19/26
Software FactorySoftware 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
3e P
art
ie:
Lean
Soft
ware
Facto
ry
Source: Wikipedia
Yves Caseau - présentation CESAMES – Mars 2012 20/26
Développement Agile - SCRUMDéveloppement Agile - SCRUM
La spécification du produit est remplacé par un « backlog » des attentes
Utilisation de « story boards » Travail en lots courts (sprints)
Time-boxing 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)
3e P
art
ie:
Lean
Soft
ware
Facto
ry
Pourquoi des « petits lots » ?Complexité + évolution rapide ⇒Avancer par petits pas & réévaluer
Yves Caseau - présentation CESAMES – Mars 2012 21/26
Extreme ProgrammingExtreme Programming
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é 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
Source: Wikipedia
3e P
art
ie:
Lean
Soft
ware
Facto
ry
Yves Caseau - présentation CESAMES – Mars 2012 22/26
Lean Startup / Pretotyping / Google ValuesLean Startup / Pretotyping / Google Values
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
Building beats talking
3e P
art
ie:
Lean
Soft
ware
Facto
ry
Innovators beat ideas
Commitment beats committees
Fast is better than slow
It’s best to do one thing really, really well
Data beats opinion
Focus on the user and all else will
follow
Rough Consensus and Working Code
Yves Caseau - présentation CESAMES – Mars 2012 23/26
Lean Schematic Vision Lean Schematic Vision
Customer focus:• value analysis• done right on the first time• reduce lead time• increase flexibility
Lean « Work Philisophy »• Go and see the gemba• Search for deep causes• Continuous improvement • Teamwork
process
(1) Eliminate mudaFocus on value
(2) Streamline Single Piece Flow,Small batches
(4)
Heiju
nka
(levelin
g)
(3)
Pu
ll –
Just-
in-
Tim
e
Lean
En
gin
e
How ?
Why ?(meaning)
Subtle interaction between all factors
SkillsLearning
« Lean Engine »
processus
(1) Éliminer mudaFocus sur valeur
(2) Streamline (fluidifier)Fractionner (réduire la taille des lots)
(4)
Heijunka
(lis
sag
e)
(3)
Pull –
flux t
end
us
Juste
-à-t
em
ps
Lean E
ng
ine
Problem SolvingContinous Improvement
3e P
art
ie:
Lean
Soft
ware
Facto
ry
Yves Caseau - présentation CESAMES – Mars 2012 24/26
Lean Software Development Lean Software Development (I)(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 équipe
Yves Caseau - présentation CESAMES – Mars 2012 25/26
Lean Software Development Lean Software Development (II)(II)
Pas d’attentes Minimiser les ruptures (action / responsabilité)
Synchronicité « Talk time » : temps commun
Priorité à l'aval (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 26/26
ConclusionConclusion
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