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 Technologies
Yves Caseau - présentation CESAMES – Mars 2012 1/26

2. Outline
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 2/26

3. Les entreprises face à un monde complexe
1è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. Les entreprise du 21e siècle doivent être agiles
1è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. L’entreprise en réseau:
S’adapter à la complexité selon la biologie
1è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. 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. 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. 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. 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. 2ème Partie
2e 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. Enterprise Architecture
2e 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. Données et Fonctions
2e 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. Processus et Services
2e 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. Construire une architecture modulaire
2e 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. Systèmes d’information durables
2e 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. 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. 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. 3ème Partie
3e 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. Software Factory
3e 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. Développement Agile - SCRUM
3e 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. Extreme Programming
3e 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. Lean Startup / Pretotyping / Google Values
all else will follow
3e 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. Lean Schematic Vision  Skills
Learning
3e 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. 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 équipe
Yves Caseau - présentation CESAMES – Mars 2012 24/26

25. Lean Software Development (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 25/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