Disic mars2014

Yves Caseau - présentation DISIC – Mars 2014 1/31

Comment concevoir efficacement Comment concevoir efficacement des systèmes d’information dans un des systèmes d’information dans un

monde complexe ?monde complexe ?

Architecture, Jardinage et Architecture, Jardinage et Lean Software DevelopmentLean Software Development

DISIC6 Mars 2014 (v0.1)

Yves CaseauAcadé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. Complexité et OrganisationCe que la science des systèmes complexes nous propose

3. 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”

4. 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)

11ère

ère P

art

ie :

Gou

vern

an

ce e

t C

om

ple

xit

é P

art

ie :

Gou

vern

an

ce e

t C

om

ple

xit

é


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

11ère

ère P

art

ie :

Gou

vern

an

ce e

t C

om

ple

xit

é P

art

ie :

Gou

vern

an

ce e

t C

om

ple

xit

é


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)11

ère

ère P

art

ie :

Gou

vern

an

ce e

t C

om

ple

xit

é P

art

ie :

Gou

vern

an

ce e

t C

om

ple

xit

é


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 )11ère

ère P

art

ie :

Gou

vern

an

ce e

t C

om

ple

xit

é P

art

ie :

Gou

vern

an

ce e

t C

om

ple

xit

é


La révolution de la motivationLa révolution de la motivation

La motivation extrinsèque ne fonctionne plus au 21e siècle« There is a gap between what science knows and business does »

Du « simple » & répétitif au complexe & créatif

De l’algorithme à l’heuristique

La motivation extrinsèque s’appuie surAutonomy: choisir ses actions

Mastery: le plaisir de se sentir progresser

Purpose: replacer son action dans un ensemble plus large qui donne le sens

Le lean (façon Toyota) est une philosophie qui intègre ces idées

Autonomie: rôle des équipes, SCRUM (petits lots)

Maîtrise : Kaizen, 5S, Kanban

Finalité : Orientation client, amour du produit

11ère

ère P

art

ie :

Gou

vern

an

ce e

t C

om

ple

xit

é P

art

ie :

Gou

vern

an

ce e

t C

om

ple

xit

é

Signature de la complexité


22èmeème Partie Partie






Que nous dit la science des systèmes complexes ?Que nous dit la science des systèmes complexes ?22

èm

eèm

e P

art

ie :

Com

ple

xit

é e

t O

rgan

isati

on

P

art

ie :

Com

ple

xit

é e

t O

rgan

isati

on


Sept principes Sept principes qui gouvernent les systèmes complexes (1)qui gouvernent les systèmes complexes (1)

1. La complexité rend la prévision illusoire, voire impossible Nassim Taleb: attention à la « narrative fallacy »

2. Le défi d’un système complexe est en premier lieu son adaptation continue à son environnement

Homéostasie et Loi de la variété requise

3. La loi des grands nombres, et les statiques classiques (courbes de Gauss) ne s’appliquent plus

On observe des « power laws » qui sont les signatures de la complexité (interaction et apprentissage)

22èm

eèm

e P

art

ie :

Com

ple

xit

é e

t O

rgan

isati

on

P

art

ie :

Com

ple

xit

é e

t O

rgan

isati

on


Sept principes Sept principes qui gouvernent les systèmes complexes (2)qui gouvernent les systèmes complexes (2)

4. Pour rendre un système complexe robuste, il faut distribuer la finalité

Chaque composant possède une représentation des objectifs du système dans son ensemble (holomorphisme)

5. Le fonctionnement d’un système complexe se traduit par des flux importants d’information qui conduisent à des structures de réseau multi-échelle

La richesse des interactions est la signature de la complexité (par opposition à la complication : nombre de parties)

6. La complexité se développe dans le temps Nous (humains) avons beaucoup de mal à apprécier les différentes

échelles de temps et les boucles de rétroactions avec délais.

7. Le contrôle d’un système complexe est une propriété émergente Kevin Kelly : control is grown, not designed

22èm

eèm

e P

art

ie :

Com

ple

xit

é e

t O

rgan

isati

on

P

art

ie :

Com

ple

xit

é e

t O

rgan

isati

on


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

22èm

eèm

e P

art

ie :

Com

ple

xit

é e

t O

rgan

isati

on

P

art

ie :

Com

ple

xit

é e

t O

rgan

isati

on


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

22èm

eèm

e P

art

ie :

Com

ple

xit

é e

t O

rgan

isati

on

P

art

ie :

Com

ple

xit

é e

t O

rgan

isati

on


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. 3e 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)

22èm

eèm

e P

art

ie :

Com

ple

xit

é e

t O

rgan

isati

on

P

art

ie :

Com

ple

xit

é e

t O

rgan

isati

on


Manager l’émergence = JardinageManager l’émergence = Jardinage

La transformation ne se décrète pas, elle se favorise …. Bottom-up, même s’il existe une confiance top-down Comme le jardinage, agir sur les facteurs favorables

Le SI « idéalement adapté à son environnement » n’est pas (seulement) le résultat d’une conception, mais d’un processus de « croissance »

Cf. Tom Kelly : « grown, not designed » Culture de l’essai rapide (MVP) Apprentissage, donc mesure !

Conditions favorables Outillage irréprochable (industrialisation du code) Devops: liberté de mise en production continue Compétences techniques

22èm

eèm

e P

art

ie :

Com

ple

xit

é e

t O

rgan

isati

on

P

art

ie :

Com

ple

xit

é e

t O

rgan

isati

on








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 et 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)

33ee P

art

ie:

Arc

hit

ectu

re d

’En

trep

rise

Part

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

33ee P

art

ie:

Arc

hit

ectu

re d

’En

trep

rise

Part

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 catalog

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

33ee P

art

ie:

Arc

hit

ectu

re d

’En

trep

rise

Part

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

33ee P

art

ie:

Arc

hit

ectu

re d

’En

trep

rise

Part

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 – 4e Partie) :

Lisser l’effort, intégration continue, privilégier la simplicité Simplification en continu, pas un effort héroïque de dernier ressort

33ee P

art

ie:

Arc

hit

ectu

re d

’En

trep

rise

Part

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

33ee P

art

ie:

Arc

hit

ectu

re d

’En

trep

rise

Part

ie:

Arc

hit

ectu

re d

’En

trep

rise







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

Source: Wikipedia

44ee P

art

ie:

Part

ie:

Lean

Soft

ware

Facto

ryLean

Soft

ware

Facto

ry


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)

Pourquoi des « petits lots » ?Complexité + évolution rapide ⇒Avancer par petits pas & réévaluer

44ee P

art

ie:

Part

ie:

Lean

Soft

ware

Facto

ryLean

Soft

ware

Facto

ry


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

44ee P

art

ie:

Part

ie:

Lean

Soft

ware

Facto

ryLean

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

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

44ee P

art

ie:

Part

ie:

Lean

Soft

ware

Facto

ryLean

Soft

ware

Facto

ry


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

44ee P

art

ie:

Part

ie:

Lean

Soft

ware

Facto

ryLean

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

44ee P

art

ie:

Part

ie:

Lean

Soft

ware

Facto

ryLean

Soft

ware

Facto

ry


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 »

44ee P

art

ie:

Part

ie:

Lean

Soft

ware

Facto

ryLean

Soft

ware

Facto

ry


ConclusionConclusion

Les modèles et l’architecture sont la clé pour : Agilité Potentiel de situation (saisir les opportunités) Conduire une transformation en maîtrisant les coûts

La science de la complexité donne des pistes pour évoluer: Besoin d’une vision globale et partagée (« True North ») … … mais distribuée en laissant de l’autonomie locale l’évolution se construit comme un apprentissage,

dans une démarche de progrès

Il faut adopter les méthodes et les outils des « géants du Web » Agile & lean software development Devops et mise en production continue Big Data, Web programming, open source tools …

Technology

Disic mars2014