Dev
Définir le rôle d’architecte des applications avec les équipes DevOps
Par La rédaction, publié le 28 juin 2018
Les équipes DevOps négligent souvent l’architecture des applications, ce qui conduit à des applications difficiles à gérer, exploiter, intégrer, améliorer et réutiliser. Pour créer des applications durables, les responsables des applications doivent définir un rôle pour l’architecture et les architectes des applications.
Pour être plus efficaces dans le processus d’innovation, les équipes DevOps se sont émancipées de l’architecture des applications, vue comme une discipline de contrôle, non collaborative et axée sur la maîtrise des coûts et des risques aux dépens de l’innovation.
Les contraintes d’architecture sont en effet perçues comme des empêchements de bâtir des applications dans un style incrémental et itératif piloté par le retour d’informations. Et les équipes DevOps, à l’instar des équipes agiles, sur lesquelles elles se basent, sont confortées dans leur positionnement par le Scrum Master qui les « protègent » de « l’hostilité » des pressions externes.
Le risque, dans ce contexte, est toutefois de produire des solutions qui peuvent ignorer des attributs non fonctionnels importants et mal s’intégrer dans le portefeuille des applications de l’entreprise.
Au lieu de personnes externes, de perturbateurs, dont les équipes DevOps vont chercher à se protéger, les architectes d’applications doivent apparaître comme des partenaires. Une façon de procéder est qu’ils soient capables de fournir leurs conseils en mode juste-à-temps, à mesure que la solution évolue, au lieu de peser sur la conception.
Les architectes seront là également pour identifier des synergies entre les équipes DevOps et suggérer, le cas échéant, des compromis dans l’optique de disposer d’un meilleur portefeuille global d’applications. Ils doivent mettre en avant la maximisation de la valeur globale apportée aux clients, versus la valeur directe d’une application individuelle ou la seule perspective d’une finalité immédiate. L’architecte d’applications doit donc être vu comme le défenseur du flux de valeur des produits. C’est une compétence rare qui sera souvent mutualisée entre plusieurs équipes ou projets. Attention toutefois à ne pas en faire une autorité qui spécifie la conception de la solution, mais plutôt un coach qui sera également là pour développer les compétences en architecture des applications au sein des équipes DevOps.
L’architecture des applications fournit les principes et les schémas sur lesquels reposent les solutions, mais ne doit pareillement pas être vue comme l’équivalent de contraintes de conception qui handicaperaient le principe de fonctionnement de DevOps. Comment faire alors pour bénéficier de ses apports en matière de sécurité, d’évolutivité, de fiabilité ou encore de capacité d’intégration avec les autres applications de l’entreprise ? Il faut prévoir que l’architecte intervienne en continu, que les équipes DevOps fassent appel à lui tout au long de la création de l’application, ce qui aura également pour effet de pouvoir faire évoluer l’architecture des applications, le cas échéant, dans un mode incrémental.
De manière pratique, l’architecture des applications doit aussi permettre de maintenir la vue globale du journal des travaux en souffrance des produits. Le travail des équipes DevOps est piloté par leurs journaux des travaux en souffrance. À mesure que les opérations sont effectuées, les journaux s’allongent et deviennent plus difficiles à surveiller. La granularité fine des travaux à réaliser peut ainsi faire passer inaperçus certains conflits entre les travaux individuels de plusieurs équipes, qui ne sont alors détectés qu’en production. De même, certaines synergies peuvent ne pas être détectées.
Ce sera donc l’un des rôles des architectes des applications de maintenir une vue cohérente à la fois globale et détaillée. Le cas échéant avec les responsables de produits, ils pourront être amenés à réorganiser les éléments des journaux des travaux en souffrance pour maximiser l’alignement. Attention dans ce cas aux arbitrages qui pourraient apparaître comme un retardateur sur la fourniture des fonctionnalités les plus précieuses. Là encore, il faudra mettre l’accent sur la valeur globale pour le client, plutôt que sur une fonctionnalité spécifique. Une autre manière de faire est d’enjoindre les équipes agiles à travailler avec les architectes des applications pour coordonner les définitions de « l’achèvement » des travaux.
