Presentation cesames mars2012

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


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é


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


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


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


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


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


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


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


22èmeème Partie Partie



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


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


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


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


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


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


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


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


33èmeème Partie Partie



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


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


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


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


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


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


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


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 »


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

Documents

Presentation cesames mars2012