Une démarche « agile » se caractérise par la prise en compte des évolutions des besoins en cours de projet, par l’importance donnée aux relations interpersonnelles par rapport à l’écriture de documents ainsi que par un mode de fonctionnement par itérations successives. L’architecture d’entreprise vise elle à définir un découpage suivant plusieurs dimensions : stratégique, organisationnelle, fonctionnelle, applicative, logique, technique … Cette structuration s’effectue de manière à ce que chaque partie élémentaire présente une cohérence interne forte et un couplage faible avec son environnement, c'est-à-dire le reste du système. L’objectif est de doter l’organisation d’une capacité à faire évoluer une des parties – et notamment ses applications informatiques – sans bouleverser les autres.
Dans nombre d’entreprises on tend à opposer ces deux approches, comment en est-on arrivé là ?
Au commencement était le spaghetti
Au début de l’informatique, les applications couvraient un périmètre fonctionnel cohérent (les clients, la paie, la comptabilité, …). Les managers se sont vite aperçu que ces domaines devaient s’échanger régulièrement des informations et que ces données dupliquées devaient être mises à jour par des interfaces qui s’établissaient de point à point entre les applications.
Avec le temps, l’intégration des modes de gestion et l’accumulation des technologies, le système informatique s’est largement vu attribuer le joli nom de « plat de spaghetti ». En régime stable, il est difficile de comprendre pourquoi cette métaphore remporte tant de succès chez les utilisateurs et les informaticiens. Car en général, au bout d’un spaghetti, il n’y a rien.
Les méthodes classiques de gestion de projet recommandent de bien réfléchir avant de tourner la fourchette dans le plat de spaghetti, surtout si les pâtes sont trop cuites, gluantes et cassantes, et s’il y a des risques importants de projection de sauce tomate.
Les méthodes de gestion de projet agiles ne s’embarrassent pas de telles considérations. En s’appuyant sur des équipes compétentes, disponibles, motivées, elles préconisent des actions itératives et intenses dans un délai court.
En filant la métaphore du plat de spaghetti, certains émettent des doutes : si on n’attrape que deux ou trois spaghettis, les bouchées sont peu nourrissantes et le repas risque d’être interminable. Par contre si l’on attrape trop de spaghettis d’un coup, on risque d’abandonner ou de mourir étouffé. Que faire ?
Les lasagnes, une architecture multicouche
Malheureusement, elle tend à faire croire que la cohérence est forte au sein d’une même couche et que les couplages sont faibles entre les couches, ce qui n’est que rarement la réalité. N’hésitez pas à faire cette expérience très simple et peu risquée, enfin bien moins risquée que celle des spaghettis … Quand vous plantez franchement votre fourchette dans un plat de lasagnes, vous pouvez tourner comme vous voulez : c’est toute votre assiette qui tourne ! Les plus aventureux tenteront de ne faire bouger qu’une couche sans faire bouger les autres …
On déduit que cette architecture en couches successives contribuera peu à la réussite d’un projet, et particulièrement d’un projet agile. Il faut effectivement donc aller encore plus loin.
Aujourd’hui, c’est ravioli !
On en conclut qu’il est impératif de procéder à un découpage fin du système en sous-systèmes avant de pouvoir lancer un projet, et particulièrement un projet « agile ».
Bien sûr, la fabrication des raviolis est un peu plus compliquée que celles des lasagnes ou des spaghettis. Il faut prendre en considération leur couplage faible qui est assuré par l’emporte-pièce et la fermeture du ravioli, et la cohérence interne du ravioli qui se révèle être lui-même un système composite et multicouche.
Dans la recette, une donnée importante est la composition de la farce, car elle est au cœur du ravioli et peut représenter un axe de différenciation majeur. Dans un système d’information, on ne rigole pas avec la farce, car elle est constituée d’informations, un des actifs les plus stratégiques pour les organisations.
Une architecture d’entreprise agile, c’est épatant !
Même si je vous accorde que cette métaphore culinaire est un peu osée, merci de ne pas en faire un fromage, d’autant plus que si le sujet est chaud, le problème se révèle gratiné. Pour l’heure, on se contentera de conclure que l’architecture d’entreprise identifie des sous-systèmes. La règle première en architecture impose que chaque sous-système doit présenter une cohérence interne forte et un couplage faible avec les autres sous-systèmes. C’est ce couplage faible qui permet au ravioli de bouger sans impliquer les autres dans son mouvement.
L’architecture d’entreprise sait alors définir le périmètre optimal à chacun des projets ainsi que leurs interactions avec le reste du système. Une fois le niveau d’intégration connu, il est alors possible de décider de lancer un projet en mode « agile » en toute connaissance de cause. C'est-à-dire en allant vite et bien, avec un risque maîtrisé.
Mais pourquoi doit-on se contenter d’un seul projet agile ? A l’heure du numérique, les organisations ont besoin de lancer une multitude de projets agiles. Vous comprenez que si vous faites tourner plusieurs fourchettes dans un même plat de spaghetti, il est certain que le repas va mal se terminer.
Opposer l’architecture d’entreprise aux méthodes agiles n’a pas de sens. L’agilité de l’entreprise est la finalité première de ces deux approches. Quand l’une dit « Think Global », l’autre dit « Act Local ». L’architecture d’entreprise est la condition indispensable à la multiplication à grande échelle des projets agiles et donc de la transformation digitale maîtrisée des organisations.
2 Commentaires
