J’échangeais récemment avec un CTO qui me demandait comment il pourrait utiliser l’approche Lean IT pour améliorer l’architecture de la suite logicielle qu’il livrait à ses clients. En toute franchise j’ai un peu trébuché sur sa question.

J’ai réalisé un peu plus tard que sa question était mal posée. Si vous aussi vous réfléchissez à cette question, voici quelques éléments de réponse.

Architecture et ingénierie : quel but ?

La première question à se poser c’est dans quel but nous faisons de l’architecture et de l’ingénierie. Quelques éclairages remarquables :

1.  John Allspaw (SVP Infra chez Etsy.com) : building resilience in Web Developments : une conférence essentielle en ce qu’elle dévoile les principes clefs de l’architecture et de l’infra dans les entreprises numériques
2. Lean Architecture at Soundcloud : un retour d’expérience sur l’utilisation de l’approche Lean pour améliorer l’architecture selon la perspective du client.
3. Lean en Ingénierie par Cécile Roche – la perspective passionnante de la directrice du Lean chez Thalès sur ce sujet. Sujet un peu plus large mais on peut avancer que l’architecture est une discipline de l’ingénierie IT.

Le point important qui relie ces trois présentations : l’architecture et l’ingénierie sont COMPLÈTEMENT au service de la valeur créée pour le client. Et pour aligner l’architecture sur les demandes du client, on mesure sans cesse l’impact de ses apports en fonction d’indicateurs qui sont importants pour le client.

Lean et architecture 

Si l’on considère cette perspective, on réalise alors que la question n’est pas posée dans le bon sens : ce n’est pas « Comment le lean IT peut-il aider l’architecture ? » mais « Comment l’architecture peut aider à mieux servir le client ? ».

Cela sous entend livrer de la valeur au client final grâce à des technologies qui lui simplifient la vie. Mais cela implique aussi aider les clients internes (designers, concepteurs, développeurs, testeurs, opérations, support) à supprimer les gaspillages dans leur travail au quotidien. A ce titre, l’exemple de Soundcloud ci-dessus est particulièrement éloquent. La réflexion Lean aide ainsi à sortir d’une vision purement technologique ; ce que les CTO ont parfois tendance à oublier c’est que ce qui importe à leur CEO ce n’est pas de livrer de l’architecture ou de la technologie mais de produire des solutions pour ravir le client.

Démarrer par la fin du processus

J’ai personnellement mis beaucoup du temps à voir ce point qui semble contre-intuitif :  pour répondre à cette nouvelle question (comment l’architecture peut aider à mieux servir le client ?), l’activité de Support (c’est à dire le point le plus en aval dans le processus) est celle par laquelle on doit commencer.

Dans le Lean on commence toujours par « le cul du camion », le processus le plus en aval pour comprendre la perspective client sur le produit/service qui est livré. On peut faire autrement mais alors on ne fait pas du Lean, on fait autre chose.

Architecture, Technologie et Innovation

On veut étoffer notre offre en avançant sur un des nouveaux domaines technologiques (social, cloud, mobile, big data, iot …) ? On recherche dans les tickets de support pour comprendre les problèmes que rencontre le client (ce que le client essaye de nous apprendre dirait Michael Ballé) et comment l’utilisation de ces technologies dans des cas précis pourrait aider à identifier de nouveaux services pour lesquels le client serait prêt à payer.

Ce qu’on me rétorque alors souvent c’est « oui mais comment faisons-nous pour innover et produire de nouveaux services auxquels le client n’a pas pensé ? ».  Là, il est très important de rappeler la différence entre l’invention et l’innovation selon Schumpeter :

“L’invention signifie la conception d’une nouveauté. Alors que l’innovation se définit par l’introduction d’une invention dans l’environnement social. Le marché est une forme spécifique de l’organisation sociale.”

Il n’y a pas de corrélation directe entre l’invention technologique et l’innovation. L’idée selon laquelle l’invention va pousser l’innovation a, ces dernières années, été largement invalidée, en particulier par l’approche Lean Startup. L’innovation dans l’IT démarre par la validation d’une hypothèse business (Minimal Viable Product) : c’est elle qui tire ensuite, par nécessité, l’invention technologique.

Problème Lean d’architecture

L’exemple de Soundcloud est remarquable car il ne s’agit pas d’une simple évolution technologique. La mise en œuvre de micro-services sert dans ce cas spécifique à régler un problème business : livrer plus rapidement de la valeur en divisant par 4 le délai de livraison de nouvelles fonctionnalités (de 66 à 16 jours).

Que l’on ait pour cela utilisé telle ou telle technologie est anecdotique pour le dirigeant et pour le client : l’innovation technologique a été tirée par le besoin client.

Lean et équipe d’architecture 

Au-delà de ce problème spécifique, d’une manière générale, plutôt que réfléchir à comment utiliser le Lean pour améliorer l’Architecture (en tant que livrable), nous suggérons plutôt de faire d’appliquer la pratique Lean à l’activité architecture, à savoir l’équipe en charge de ce sujet. Cela impliquera d’essayer de comprendre dans cette entreprise, soumise à son business spécifique pour cette équipe d’architecture :

• qui sont les clients ?
• quelles sont leurs attentes ?
• leurs attentes sont-elles satisfaites ?
• quelle est la valeur que livre l’équipe ?
• sur quels composants de la solution ?
• quelle est la performance opérationnelle de l’équipe aujourd’hui ? (coûts, qualité délais, satisfaction client)
• cette performance s’améliore-t-elle ? Comment le savons-nous ?
• quels sont les critères de réussite (objectifs opérationnels) ?
• quels sont les obstacles majeurs (gaspillages) qui empêchent l’équipe de réussir ?
• quels sont les potentiels d’amélioration ?

Une fois que l’on aura avancé sur les réponses à ces questions, on pourra alors commencer la pratique Lean. Plutôt qu’imposer des « bonnes pratiques » ou la toute nouvelle technologie super trendy, qui pourraient ne pas être optimales pour ce contexte donné, on va privilégier la réalité du processus existant, dans le contexte existant pour se concentrer sur la Roadmap Lean IT pour cette équipe :

1. Protéger le client (Qualité)
2. Maîtriser puis réduire les délais
3. Améliorer la productivité
4. Accroître la valeur livrée

Comment appliquez-vous l’approche Lean IT à vos problématiques d’architecture ?