annuler
Affichage des résultats de 
Afficher  uniquement  | Rechercher plutôt 
Vouliez-vous dire : 

Opposer Architecture d’entreprise et Agilité, c’est nouille

Architecture-entreprise-agilité
90050
2

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.

Metaphore Spaghetti IT C’est un fait que l’on se soucie peu de son informatique quand elle fonctionne. On ne s’en préoccupe qu’à l’occasion d’un incident ou d’une évolution, c'est-à-dire d’un projet. La métaphore du « plat de spaghetti » prend alors tout son sens car dès qu’on plante une fourchette dedans …

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

Architecture entreprise lasagneL’architecture d’entreprise est souvent représentée suivant différentes couches qui s’empilent les unes sur les autres. Cette approche pédagogique rassure tout le monde car chacun reconnait sa place dans l’organisation et son périmètre de responsabilité.

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 !

metaphore ravioli projet agileVous l’avez déjà compris, le ravioli permet de procéder à des itérations rapides sur un élément sans impliquer l’ensemble qui est dans votre assiette.

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.

 

90050
2
Comment
AGuercio
MEGA

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.

Metaphore Spaghetti IT C’est un fait que l’on se soucie peu de son informatique quand elle fonctionne. On ne s’en préoccupe qu’à l’occasion d’un incident ou d’une évolution, c'est-à-dire d’un projet. La métaphore du « plat de spaghetti » prend alors tout son sens car dès qu’on plante une fourchette dedans …

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

Architecture entreprise lasagneL’architecture d’entreprise est souvent représentée suivant différentes couches qui s’empilent les unes sur les autres. Cette approche pédagogique rassure tout le monde car chacun reconnait sa place dans l’organisation et son périmètre de responsabilité.

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 !

metaphore ravioli projet agileVous l’avez déjà compris, le ravioli permet de procéder à des itérations rapides sur un élément sans impliquer l’ensemble qui est dans votre assiette.

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