Architecture et Agilité : Chapitre 2 : Détournement de valeur(s) en cours

Architecture et Agilité : Chapitre 2 : Détournement de valeur(s) en cours.

10 avril 2018

– 6 min de lecture

Architecture d’entreprise

Olivier Constant

Senior Manager Architecture

L’agilité défend 4 valeurs principales. Dans certains cas, on constate des équipes dites agiles mais qui ne sont plus en phase avec les valeurs. Pourquoi ?

En quoi les valeurs de l’agilité et de l’architecture devraient-elles se rejoindre ?

Les 4 valeurs de l’agilité

L’agilité se base sur 4 grandes valeurs qui sont tirées du Manifeste Agile, complétées par 12 principes.

Des valeurs et pas des dogmes

Pour commencer, rappelons que ce sont des valeurs et non des règles. Cela signifie qu’il s’agit d’une vision partagée, chacun ayant la liberté de décider des mécanismes à mettre en place pour y arriver.

Ces valeurs présentent une nouvelle façon de faire, par opposition à l’ancienne.

En effet, quand la valeur prône « la collaboration avec les clients plutôt que la négociation contractuelle », cela ne veut pas dire la mort de tous les contrats. La contractualisation à outrance a eu tendance à éloigner les gens, à les faire se retrancher derrière des clauses comme derrière des barrières infranchissables. La nouvelle façon de faire met en avant la collaboration, le partage d’information, la confiance comme des moyens d’avancer plus efficacement. Les contrats existent toujours mais sont faits différemment, sur d’autres bases.

A l’identique de ces valeurs, pour l’Architecture d’Entreprise, un Framework comme TOGAF pose les bases et bons principes de comment faire de l’Architecture d’Entreprise. Chaque entreprise doit s’approprier ces principes, les décliner dans son contexte et les appliquer suivant sa culture et sa maturité. Il ne s’agit pas d’appliquer l’intégralité du Framework sans une réflexion préalable.

Pour illustrer à quel point les valeurs de l’Agilité peuvent être détournées par les projets ou sont mal comprises par des collaborateurs, j’ai choisi 2 phrases. Elles reviennent régulièrement dans la bouche de collaborateurs et elles nous montrent le chemin restant à parcourir pour la compréhension des bénéfices de l’agilité.

En agile, on ne fait pas de documentation !

Nous allons essayer quelque chose appelée

« Développement Agile »

Ce qui signifie qu’il n’y a plus de plannings et plus de documentation. On commence directement à programmer et à se plaindre

– Je suis content que cela ait un nom.

– C’était votre formation.

La valeur prônée par l’agilité est « des logiciels opérationnels plutôt qu’une documentation exhaustive ». Historiquement, les logiciels disposaient d’une documentation abondante (Spécifications générales, détaillées, etc.) qui n’était pas lue, peu utilisée, pas adéquate et très peu maintenue.

Le but principal d’un projet informatique est bien d’avoir un logiciel opérationnel qui répond aux besoins des utilisateurs. La documentation est un sous-produit du logiciel. Elle doit servir aux utilisateurs, aux personnes qui vont en faire la maintenance, etc. mais elle n’est pas un but en soi.

Beaucoup de projets « classiques » semblaient avoir oublié ce but et donnaient l’impression de livrer plus de documentation que de code à la fin des projets, un comble !

Qu’en est-il pour les projets en Agile ? Etant donné la proximité des participants, il n’est pas nécessaire de formaliser tous les échanges par de la documentation in extenso. Les échanges ayant lieu en direct, et verbalement, ils ont moins besoin d’être complètement décrits. Seul le résultat est conservé, les principales décisions, les règles métier et les choix faits. La documentation est réduite au juste nécessaire et une partie est parfois même stockée dans le code directement. Certains projets agiles en ont-ils profité pour ne pas faire de documentation du tout ? Possible. Les responsables des maintenances ont-ils été surpris de ne pas avoir autant de documentation qu’avant ? Fort probable. Que certains développeurs n’aiment pas faire de la documentation in extenso ? On les comprendrait presque. Mais la documentation ne s’adresse pas qu’aux développeurs. La documentation sur les choix métiers, les données et certaines règles de gestion peut avoir son utilité.

La bonne documentation est bien celle qui va servir par la suite et qui sera maintenue…

L’architecture ne fait que de la documentation ?

A l’inverse, les architectes ont souvent été « accusés » de ne produire que de la documentation. De ne produire que des règles et des normes, pas toujours facilement applicables, que le projet doit ensuite se justifier d’utiliser, ou pas.

Les projets penseraient même que l’architecture les contraint à remplir des dossiers et à passer par des comités qui ralentissent leur bonne marche. Que ces étapes coutent chers et n’apportent rien (ou presque).

Ce n’est bien sûr pas comme ça que nous concevons l’Architecture d’Entreprise. Elle se doit d’être au service et en accompagnement des projets. Leur fournir une aide et non être un frein.

Comme pour les projets, l’architecture doit être documentée utilement et sans excès. Elle apporte la vision d’ensemble du SI dont chaque projet a besoin. Il est essentiel de connaître les règles de construction, pourquoi elles ont été définies et pourquoi certaines dérogations ont été accordées… car la règle est la conséquence d’un besoin et la remise en cause de ce besoin doit remettre en cause la règle.

La bonne architecture est bien celle qui est opérationnelle et donc proche des projets…

Le problème avec l’agilité c’est qu’il n’y a pas de planning

Avant de de faire notre business plan pour l’année prochaine, regardons comment nous avons réalisé celui de l’année passée.

Finalement, nous n’avons rien fait de ce qui était prévu. Comme les autres années

– Pourquoi fait-on l’exercice alors ?

– Cela n’aurait aucun sens de de ne pas avoir de plan

La valeur prônée par l’agilité est « l’adaptation au changement plutôt que le suivi d’un plan ». Avant, le plan était roi et devait être suivi, parfois jusqu’à l’absurde. La planification « à la soviétique » (détaillée sur 5 ans et sans changement possible) en était la parfaite illustration.

Maintenant et dans un monde qui change si vite, les projets doivent s’adapter à l’évolution des besoins et des exigences. Plus question de faire des projets avec des « tunnels » de plusieurs années. Plus question de s’entendre dire, les spécifications sont validées, plus rien ne peut changer avant la prochaine version, l’année prochaine au mieux.

Pour autant et pour des besoins de cohérence et de synchronisation entre les livraisons des produits, il est essentiel d’avoir une certaine visibilité sur les projets. Une vision détaillée à court terme et une vision plus globale à moyen / long terme (les notions de court et moyen terme restent à adapter à chaque situation) sont nécessaires. Des outils agiles existent pour réussir à se projeter sur ces échelles de temps, comme le Burn-Up Chart par exemple. Ils utilisent les données issues des itérations complétées pour alimenter des éléments de pilotage permettant de prendre des décisions.

Car les plannings doivent servir à dégager des trajectoires et des orientations sur le long terme. Ils rendent possible la synchronisation entre les différentes évolutions en cours dans le SI.

Les architectes font des plannings sur 5 ans qui sont irréalisables

Les architectes d’entreprise, garants de la vision d’ensemble du SI, se doivent de dégager une trajectoire globale, long terme, du SI. Ce faisant, ils donnent parfois l’impression de figer les évolutions à plus court terme. Tout semble déjà prévu d’avance et sur 5 ans ! Il semble ne plus y avoir de place pour de nouvelles initiatives ou pour des changements. Les projets ont alors l’impression d’être mis devant le fait accompli et de devoir respecter des échéances qui leur sont imposées sans concertation.

C’est une vision de l’architecte que nous ne partageons pas du tout.

Oui, l’architecture d’entreprise doit bien dégager une vue d’ensemble sur le long terme et essayer de « mettre en musique » les différentes évolutions du SI. Pour autant, il n’est pas question de figer cette trajectoire et de ne pas être en capacité de réagir à court et moyen terme aux événements qui ne manqueront pas de survenir.

La cible du SI ainsi que sa trajectoire sont nécessaires pour consolider les évolutions, donner de la visibilité et apporter de la transversalité. Mais ils doivent être adaptés dès le départ aux contraintes projets et être revus régulièrement en fonction des avancées des projets et de tout ce qui peut avoir un impact (stratégie de l’entreprise, concurrence, avancement / retard des projets, technologies etc.).

La trajectoire du SI constitue un outil d’aide à la décision, d’une part en démontrant que l’évolution du SI répond aux enjeux métiers et d’autre part en mettant en évidence les dépendances entre les différents projets.

Le détournement des valeurs de l’Agilité, nous ramène aux reproches qui sont faits aux architectes : trop ou pas assez de documentation et de normes, trop ou pas assez de planification.

Certains sont trop loin des réalités et d’autres trop proches ?

La convergence de l’architecture et de l’Agile vers un (juste) milieu de documentation et de planification semble donc la solution permettant à chacun d’avoir les outils nécessaires.

Parlons-en et travaillons ensemble seront les maîtres mots des prochains chapitres.

Suite de la série : les solutions arrivent

Les autres articles qui peuvent vous intéresser