Comment les architectes peuvent interagir avec l’agilité ?

14 avril 2018

– 5 min de lecture

Olivier Constant

Senior Manager Architecture

Architecture d’entreprise et agilité – chap 4 : comment les architectes d’entreprise peuvent interagir avec l’agilité ?

En tant qu’architecte, quelle posture adopter face à un projet Agile ? Et dans le cadre plus global d’une entreprise Agile, comment est intégrée la notion d’architecture ? Quel rôle est dévolu à la fonction Architecture ?

Les architectes, de leur côté, ont défini la « Continuous Architecture » (conférence OpenGroup en 2016) pour édicter les principes de l’Architecture d’entreprise dans le cadre des projets Agile.

Les principaux frameworks d’agilité à l’échelle intègrent l’architecture d’entreprise : DAD – Disciplined Agile Delivery-, SAFe – Scaled Agile Framework- et LeSS – Large Scaled Scrum.

Que nous manque-t-il alors pour vraiment travailler ensemble ?

Les architectes et l’agilité se connaissent !

D’un côté, les architectes ont travaillé à l’évolution de leurs pratiques et regardent l’agilité avec intérêt depuis plusieurs années déjà : article de 2008, article de 2010, conférence de l’Agile Tour en 2011, etc… Ils ont inventé la « Continuous Architecture »

La « Continuous Architecture » énonce des principes facilitant l’interaction avec les projets en agilité. Ces principes mettent en avant l’adaptation et l’intelligence qui doivent guider les travaux des architectes pour convenir au rythme et au fonctionnement des projets Agiles.

Voici quelques principes de « Continuous Architecture » qu’il est intéressant de noter : partager les décisions, partager l’information, être collaboratif, etc …

D’un autre côté, les framework d’agilité à l’échelle les plus connus (DAD, LeSS ou SAFe par exemple) ont pris en compte les architectes dans leurs modes opératoires. Des définitions de l’architecture sont proposées. Les livrables et interactions des architectes avec les projets / programmes agiles sont définis.

Quelles questions restent donc à traiter pour que les 2 travaillent en symbiose ?

Une bonne définition de l’architecture d’entreprise dans l’agilité

Les définitions proposées par les frameworks d’agilité à l’échelle reprennent les éléments essentiels de l’Architecture d’Entreprise :

Vision long terme et à haut niveau de la transformation de l’entreprise,
Réutilisation,
Interaction avec les projets,
etc…

Des exemples concrets mettent en avant les apports de l’architecture dans le cycle de vie d’un produit Agile. DAD a un chapitre « Pourquoi l’Architecture d’Entreprise » qui décrit les apports essentiels de l’architecture d’Entreprise pour les projets comme de pouvoir se concentrer sur la valeur ajoutée et une plus grande cohérence dans les solutions.

L’architecture devient agile – forcément

Les frameworks mettent en avant des principes d’agilité que les architectes se doivent de respecter. Ainsi SAFe recommande aux architectes de bien rester en contact avec les activités journalières de développement et les équipes projets. De ce rapprochement, un gain mutuel de confiance est espéré : les architectes auront plus confiance dans les équipes projet pour suivre les cadres d’architecture, les équipes projet auront plus confiance dans les solutions proposées par les architectes.

Pour être en conformité avec les principes agiles, on remarquera que dans DAD, tous les livrables de l’Architecture sont sujets à des feedbacks (retours d’expérience). Il n’y a pas de décision unilatérale. L’architecture est dans un processus permanent de discussion et d’évolution.

Continous architecture – l’architecture agile

Pour se mettre en accord avec les concepts de l’agilité, l’architecture d’entreprise a énoncé un certain nombre de recommandations. L’une d’elles est justement de donner des principes d’architecture et non des règles !

Une autre de ces recommandations consiste à prendre les décisions le plus tard possible, laissant aux projets la possibilité d’étudier plusieurs solutions avant de trancher quand vraiment il le faut.

Une autre recommandation consiste à dire « il faut partager de l’information et non de la documentation », nous rappelle la discussion du chapitre 2 de cette série d’article. En d’autres termes et pour citer le manifeste Agile : les individus et leurs interactions plutôt que les processus et les outils.

Mais parfois l’Architecture semble quand même trop éloignée des préoccupations des projets…

Less et les architectes powerpoint vs les master programmers

Le framework LeSS, dans son chapitre sur Architecture & design, consacre son introduction à préciser que l’architecture de l’informatique est dans le code : ceux qui font sont ceux qui savent. Les architectes qui ne font plus du code mais font de l’architecture pour les managers ou de l’architecture pour de l’architecture finissent par se couper du monde et ne plus être entendus par les projets. Ils deviennent des « Architectes PowerPoint dans leur tour d’ivoire ».

Même si tous les architectes, qui plus est dans les grandes entreprises, ne peuvent pas rester au contact du code (qui plus en est quand la politique d’entreprise est centrée sur l’intégration de progiciels plutôt que la conception d’applications), il est de leur devoir d’interagir avec les architectes plus opérationnels et de veiller à ce que leurs travaux restent compréhensibles par tous. Et bien sûr applicables !

LeSS rappelle que le principal intérêt d’un modèle est la discussion que l’on a en faisant ce modèle. Le modèle n’est pas la solution et ne doit pas rester figé dans le temps.

Ces images illustrent la différence entre ce qui a été proposé (chemin goudronné) et les usages (chemin tracé par le passage des piétons)

Coaching et agilité ?

La transformation vers l’entreprise agile se fait beaucoup à partir de coaching des équipes et des managers. Ils sont accompagnés dans une réelle évolution de leurs pratiques afin de développer des modes de travail plus collaboratifs et les conditions d’une meilleure coopération.

En général, des coachs agiles interviennent pour faire évoluer ces pratiques et accélérer la transformation. Il faut alors qu’un mode de fonctionnement soit établi et les parties prenantes (comme les architectes) impliquées dans ces transformations.

Les architectes doivent donc être inclus dans ces transformations afin de bien mettre en place les modes de fonctionnement adaptés à chaque entreprise.

Les architectes doivent-ils être certifiés SCRUM Master ou Product Owner ? Doivent-ils être formés aux frameworks d’agilité à l’échelle comme DAD, LeSS ou SAFe ? Doivent-ils être accompagnés de coachs agiles ?

Suivant la transformation en cours, chaque entreprise devra apporter sa réponse. Que cela soit pour les architectes ou d’autres fonctions d’ailleurs !

Pour que l’architecture d’entreprise et l’agilité puissent travailler ensemble, il faut que l’entreprise s’approprie l’un et l’autre et pense bien à les faire travailler ensemble. La communication est un élément clé de cette réussite.

L’architecture d’Entreprise doit être un facteur facilitateur de l’agilité car elle apporte une vision partagée de la stratégie d’évolution du SI et doit donc servir à guider l’ensemble des travaux de l’entreprise sur son SI.

Dans le chapitre suivant, nous parlerons de l’évolution d’un des travaux majeurs des Architectes, le Schéma Directeur du SI.