Comment concilier durabilité et agilité au sein d'une architecture informatique ?

Nous nous sommes entretenu avec Dietmar Hafner, un expert de longue date et formateur pour Digicomp afin de savoir s’il est possible et judicieux de fournir un travail sérieux d’architecture logicielle dans le cadre de projets agiles. Ou bien si la contradiction avec les principes d’agilité est trop grande.

Dietmar Hafner travaille dans le domaine de l’informatique depuis plus de 10 ans. Il possède un profil de conseiller très diversifié, du développement et l’architecture de logiciels jusqu’au conseil en technologie, gestion de produit et méthode de développement agile de logiciels. L’industrie des télécoms, la finance ainsi que les concepts de fidélisation de la clientèle s’ajoutent à son expertise du secteur. En plus d’une formation technique dans la gestion informatique, il est diplômé d’études juridiques dans le domaine du droit de l’informatique.

Monsieur Hagner, de nos jours les méthodes agiles sont considérées comme un facteur de succès pour les projets particulièrement innovants et critiques grâce à leur capacité à réagir à des modifications. Comment concilier durabilité et agilité ?

L’application de principes agiles permet à l’architecture de n’être à tout moment définie que de telle sorte à ce que seules les décisions obligatoirement nécessaires soient prises. Les décisions qui peuvent encore être en suspens sont laissées comme telles aussi longtemps que possible. La décision n’est prise que plus tard sur la base des enseignements tirés.

Dans l’architecture logicielle classique, les erreurs et lacunes au niveau des exigences sont identifiées et éliminées avant les phases de conception et de développement puis l’architecture logicielle est définie et optimisée. Les professionnels en architecture et documentation élaborent des modèles et processus détaillés afin d’éliminer le risque de mauvaise surprises. Le codage n’intervient qu’ultérieurement. Est-ce une procédure encore appliquée ou pas ?

Cette approche est parfaitement adaptée pour des système plus complexes. Il s’agit de systèmes qui comportent de nombreuses variables, conditions et fonctions mais qui disposent d’une spécification parfaite. Les exigences sont et restent plus ou moins les mêmes, du début à la fin. Cela ne fonctionne plus aussi bien dans des systèmes complexes pour lesquels les exigences ne restent pas identiques dans le temps et qui varient de manière plus ou moins importante. Une architecture prédéfinie ne convient plus très rapidement. Dans ce cas, il vaudrait mieux adopter une approche agile et se laisser ainsi de nombreuses options ouvertes. La plupart des grands projets logiciels sont complexes et non compliqués. Il y a souvent de nombreuses modifications et inconnues. Il s’agit par exemple de nouvelles technologies, interfaces, tendances ou exigences.

Vous pensez donc que le meilleur moyen de venir à bout de projets véritablement exigeants est une approche agile.

Non, ce n’est pas si simple. La procédure classique et éprouvée part du principe que les systèmes sont compliqués mais pas complexes. Cela signifie que les exigences et conditions-cadres sont stables et suffisamment bien connues. Cela conduit souvent à faire cette erreur de raisonnement :

1. Les erreurs sont décelées pendant la mise en oeuvre. Il n’est plus possible d’en tirer des enseignements car les concepts sont déjà définis depuis longtemps et sont en partie mis en oeuvre. L’architecture est “gravée dans le marbre” et n’est plus modifiable.
2. Un niveau de détail trop élevé n’est pas obligatoirement un gage de qualité supérieure, il est même préjudiciable et génère une charge importante inutile.
3. On pense souvent à tort qu’une globalisation cohérente permet d’anticiper les exigences ce qui conduit souvent à des architectures et concepts trop compliqués et faux.

De plus, les aspects suivants sont perdus de vue :

1. Tous les membres d’une équipe agile sont intelligents et disposent de connaissances. Utiliser la collaboration entre ces intelligences recèle un potentiel exponentiel par rapport à un seul architecte de génie.
2. Les erreurs et fausses pistes sont une bonne chose lorsqu’elles sont détectées à temps. Lorsque l’on identifie les erreurs, il est possible de réagir et d’y remédier. Lorsqu’elles sont ignorées et que l’on repousse leur traitement, elles deviennent de plus en plus complexes.

Comment bien appliquer le développement agile ?

Agile ne signifie pas sans structure, mais avec une structure agile. Les rôles sont clairement définis. Le Product Owner (propriétaire du produit) est responsable du Business Scope (champ d’activité) spécialisé et du budget. L’équipe est responsable du Product Increment (incrément du produit), autrement dit la solution élaborée et la gère elle-même. Le Scrum Master coache tout le monde quant à la méthode et anime les réunions. Il doit également veiller à ce que les obstacles puissent être surmontés.

A-t-on encore besoin d’un architecte en tant que tel ?

Les projets agiles ont besoin d’une architecture donc d’un architecte. Il fait partie de l’équipe de développement. L’architecte contribue à la mise en oeuvre et vérifie régulièrement la pertinence des approches de solution. Les décisions concernant l’architecture sont en permanence contrôlés et confirmées par des prototypes ou percées. Les mauvaises décisions peuvent se produire mais elles sont immédiatement identifiées et corrigées par l’équipe. La participation de l’équipe au travail d’architecture permet de constituer une grande expérience et l’acceptation est assurée en permanence.

Selon quels principes le travail d’architecture doit-il être effectué ?

La définition de l’architecture selon le principe du “autant que nécessaire” permet de laisser des options ouvertes, les approches comme “Last Responsible Moment” (dernier moment responsable) dictent la prise de décision. Elle permet de tenir compte d’exigences changeantes. Le produit est créé de manière incrémentielle. La documentation de l’architecture est poursuivie en continu et gérée au sein de l’équipe. Le processus rétroactif continu ainsi implémenté du développement de l’architecture logicielle permet de faire largement participer également les développeurs à l’architecture. Cela ne présente manifestement que des avantages

Vous affirmez que l’architecture est créée en équipe. Quel rôle joue le travail d’architecture et quelles sont les tâches de l’architecte dans ce cadre ?

Aujourd’hui, la plupart des projets informatiques sont développés de manière agile. L’expérience montre que c’est précisément dans l’architecture informatique qu’il y a souvent des points d’interrogation et des lacunes. Le travail sur une architecture informatique doit également évoluer pour qu’elle puisse fournir les meilleurs résultats au sein de projets agiles, marqué par de nombreuses options ouvertes et par la flexibilité.

Il convient donc d’arriver à concilier l’intégration de l’équipe avec les objectifs et tâches à long terme de l’architecture. L’équipe dispose souvent d’une grande expérience et de connaissances. Il faut savoir en profiter. L’architecture logicielle n’est toutefois pas un processus démocratique, mais applique strictement les exigences fonctionnelles et non-fonctionnelles du client ainsi que les objectifs économiques de l’entreprise. En cas d’avis divergents au sein de l’équipe de développement, c’est l’architecte qui doit trancher.