Pourquoi changer notre façon d’architecturer nos solutions ?

Depuis une dizaine d’années, de nombreuses nouvelles pratiques d’ingénierie logicielle ont vu le jour, principalement dans le but de livrer plus rapidement nos produits à nos utilisateurs finaux. Parmi celles-ci : le lean management, l’agilité, la transformation DevOps, l’intégration continue et la livraison continue… Pourquoi une telle tendance ? Parce que la valeur n’est produite que lorsque le produit est déployé et utilisé. Tout ce qui n’est pas encore déployé n’est que de l’inventaire dans votre base de code source. Mais un domaine clé manquait encore dans cette transformation massive de nos pratiques d’ingénierie. Et si vous vous trouvez actuellement sur notre site web consacré à la Continuous Architecture, vous avez probablement déjà deviné de quoi il s’agit. Comme le dit l’adage : “Rome ne s’est pas faite en un jour.” On comprend donc qu’il est impossible de transformer toutes les disciplines en même temps. Mais pour achever cette transformation, il faut désormais s’attaquer à l’Architecture. Notre conviction : les méthodes et processus d’architecture d’hier ne permettront pas de livrer les solutions de demain. Si l’on prend un peu de recul, on peut dire qu’aujourd’hui, nous construisons le logiciel de manière continue. Il est donc temps d’adapter notre modèle opérationnel d’architecture à cette réalité !

Pour complexifier les choses, l’environnement dans lequel nous évoluons est souvent qualifié par l’acronyme VUCA : Volatilité, Incertitude, Complexité et Ambiguïté. Dans un tel contexte, la seule chose à faire est de construire un système d’information résilient, flexible, réactif et ouvert. On ne peut pas prédire ce que nous réserve l’avenir proche, alors concevons un SI capable d’évoluer quelle que soit la direction que prennent les changements. Il ne suffit donc pas de modifier notre modèle opérationnel pour gérer le flux de livraison continue, il faut aussi maintenir l’intégrité de notre système à grande échelle. Que cela nous plaise ou non, nous venons d’un monde où les décisions d’architecture étaient prises de manière centralisée, et très en amont dans les projets. Cela devient aujourd’hui un goulot d’étranglement intenable — une contrainte que nous ne pouvons plus nous permettre dans un monde en flux continu. Certaines décisions devront bien entendu rester centralisées (notamment celles qualifiées de “stratégiques”), mais il est essentiel de donner du pouvoir à nos équipes. Non seulement cela permettra d’accélérer la livraison, mais les décisions seront prises au plus près de là où les choses se passent : au sein des équipes produit. Mais l’autonomisation est un processus plus complexe que le simple fait de déléguer de l’autorité. En d’autres termes : ALIGNEMENT + AUTONOMIE > CONTRÔLE.