Devops for Growth

Dans la majorité des DSI où nous intervenons, nous faisons souvent le même constat depuis plusieurs années ; il reste difficile de produire des applications évolutives et pérennes. C’est d’autant plus vrai aujourd’hui alors que la révolution numérique (ne dites surtout pas digitale) bat son plein, entrainant des nouveautés incessantes en termes de technologies, d’outillage, etc. Ainsi, il est assez courant d’entendre que la durée de vie d’une application ne dépasse pas 4-5 ans et toute ou partie de la connaissance métier se perd après chaque redémarrage à zéro, malgré toute la bonne volonté du monde.

Plus précisément, nous observons chez nos clients :

• Des choix techniques précipités. Ces derniers sont la majorité du temps faits au début du projet, alors que la connaissance est à son niveau le plus faible (volume d’utilisateurs, pics de charge, adéquation aux contraintes métier). C’est un pari sur le futur qui s’avère souvent désastreux et se fait au détriment de la connaissance métier, qui elle aussi est à son niveau le plus bas.

• Un immobilisme technique. Une fois ces choix techniques faits, il est souvent difficile voire impossible de s’en défaire. Cela nécessite la plupart du temps de re-tester le périmètre complet de l’application et induit un très fort risque de régressions. Plus le temps passe, plus l’application grossit et plus l’immobilisme grandit jusqu’à atteindre un point de non-retour. Ce problème trouve son origine dans l’incapacité des équipes à séparer la logique métier des technologies, frameworks et outils utilisés.

• Une faible testabilité de la logique métier. Ne pas séparer la logique métier de l’infrastructure n’a pas que des impacts techniques. Dans bien des équipes, les tests fonctionnels font intervenir un grand nombre de couches techniques (bases de données, middlewares). De ce fait, ils sont souvent longs à s’exécuter, le sont rarement (au mieux une fois par jour) et sont friables. Au final, ils sont souvent rares voire même abandonnés car la boucle de feedback est trop longue et trop difficile à mettre en place. En conséquence, les testeurs (ou QA) perdent la majorité de leur temps à répéter manuellement des tests qui pourraient être automatisés, réduisant ainsi la part exploratoire de leur travail. Ceci n’est évidemment pas sans conséquence sur la qualité finale de l’application.

Pour faire face à ces problèmes, il convient de faire usage d’une approche isolant logique métier et couches techniques.
Chez Xebia, nous pensons que c’est essentiel afin :

• d’assurer la pérennité du métier de son application (les technologies doivent pouvoir changer sans risque de régression) ;
• de renforcer l’appétence des équipes au métier, voie royale vers une plus grande qualité et une plus grande adéquation des livrables aux besoins clients.

Dans cet article, nous vous proposons de découvrir l’une de ces approches : l’architecture hexagonale.