Le SI peut-il être lui-même rendu agile ? Oui, grâce au DevOps. Mais à la condition que l’on applique de nouveaux principes d’architecture, car il y a une contradiction profonde entre les grands principes de l’agilité et le SI tel qu’il est conçu et géré aujourd’hui.
Un SI pleinement automatisable
La mise en œuvre du DevOps permet d’assurer l’alignement entre tous les acteurs autour d’objectifs business en s’appuyant sur des cycles de vie produit fortement automatisés. Pour s’intégrer dans cette démarche, le SI devra être pleinement automatisable, aussi bien dans son build (investissement) que dans son run (exploitation et maintien en condition opérationnelle). Or si l’on décide d’automatiser un SI via des principes DevOps, il faut respecter des exigences dans le design des solutions, afin qu’elles puissent s’intégrer dans un parcours d’automatisation, du développement jusqu’à la production.
C’est là que réside un des grands dilemmes de l’architecture agile. En effet, la réponse proposée par le Manifeste agile sur l’architecture dans son onzième principe(1), à savoir « les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées », est erronée dès lors qu’on souhaite l’appliquer à un SI géré par une organisation, plutôt qu’à un produit unique géré par une équipe. Comment sortir de l’impasse ?
Etablir de nouveaux principes d’architecture
La réussite de l’implémentation du DevOps repose sur l’établissement de nouveaux principes d’architecture nécessaires à la bonne intégration dans une orchestration globale des tâches automatisées de build et de run du SI. Quelques réponses existent.
> Rationnaliser
L’organisation de l’automatisation, particulièrement à grande échelle, nécessite une démarche d’architecture au même titre que les développements applicatifs. L’organisation des outils, la réutilisabilité des développements d’automatisation et les règles d’automatisation, ainsi que leur impact sur les principes d’architectures régissant les études et la production doivent être rationnalisés pour garantir leur efficience.
> Construire un modèle de données adapté et évolutif
La construction du modèle de données, son implémentation et les règles et principes d’évolution de ce modèle sont prioritaires. Cela doit permettre de créer des applicatifs capables non seulement d’évoluer techniquement mais aussi sur le plan des métiers.
> Construire des architectures modulaires
Des architectures telles que les micro-services, l’utilisation d’API ou la gestion d’évènement permettent de construire des solutions adaptées à une forte évolutivité grâce à leur modularité.
> Séparer la mise en production de la mise en service
L’utilisation de pattern de déploiement permet de déclencher des mises en service de nouvelles fonctionnalités pour l’utilisateur, indépendamment de la mise en production. Certain de ces patterns permettent également l’ouverture du service pour une population ciblée d’utilisateurs, permettant de collecter des retours terrain tout en conservant une capacité de retour arrière rapide.
Bien maîtriser et coordonner les évolutions du DevOps
Le risque, c’est que grâce au DevOps, l’architecture des différents produits composant le système d’information puisse évoluer très rapidement. Il reste essentiel de maitriser et de coordonner ces évolutions. Les activités transverses (gouvernance, planification et positionnement de l’architecte) nécessitent donc une proximité avec les équipes opérationnelles afin de garder connaissance et maitrise de son SI. Les modèles d’organisation d’agilité à l’échelle permettent cette proximité
Finalement, on le voit bien dans le cas de l’architecture, agilité et DevOps sont les deux faces d’une même pièce, ne pouvant pleinement exister l’une sans l’autre, tant au niveau d’une équipe que de l’entreprise.
(1) Le Manifeste pour le développement agile de logiciels, ou Agile manifesto, rédigé en 2001 par des experts du développement d'applications informatiques, comprend 12 grands principes et 4 valeurs.