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

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

0
2
Architecture-entreprise-agilité

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.

 

0
Comment
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
LE BRIS
Non applicable

 

Bravo pour ces métaphores.

 

Je me permets une petite contribution.

 

L'article dit "L’architecture d’entreprise vise elle à définir un découpage suivant plusieurs dimensions : stratégique, organisationnelle, fonctionnelle, applicative, logique, technique …"

 

Je pense que la division en couches est l'un des moyens pour appréhender la complexité mais pas forcément la cible pleine hauteur. La cible pleine hauteur est pour moi "la complexité de l'IS/IT". Nous sommes bien loin du gros mainframe monolithique.

 

Je pense que l'architecture d'entreprise a été créée pour tenter de gérer la complexité de IS/IT afin d'être en capacité de

a) mieux exploiter l'existant (par exemple, comment faire une analyse de dysfonctionnement efficace si on ne sait pas qu'elles sont les briques/couches présentes ?)

b) faire évoluer IS/IT afin répondre aux besoins de la stratégie de l'entreprise (aptitude au changement via le fameux alignement business/IS+IT);

c) faire évoluer la stratégie d'entreprise en tirant profit des opportunités que proposent l'IS+IT (alignement du business sur l'IS+IT, opposé de b).

 

Tout n'est pas blanc ou noir, le monde est majoritairement gris.

 

Il ne faut pas oublier que l'éclatement en couches et en composants par du couplage lâche s'il apporte une capacité d'évolution par touche successive (flexibilité) contribue à créer de la complexité et des sources supplémentaires de pannes et de points de réglage.

 

Je n'ai rien contre la conduite de projets agiles maintenant elle n'a pas que des avantages. Le fait que le périmètre ne soit pas fixe implique que le coût et le temps ne le sont  pas non plus. Ce qui est un souci pour le management senior qui n'aime pas que ces deux dernières variables fluctuent à la hausse. Le risque est qu'une qualité revue à la baisse devienne la contrepartie de la variabilisation des trois varaibles principales (périmètre, coût, temps). Une brique de faible qualité détériore et complexifie votre IS/IT. Que dire si cela devient une mode.

 

Bref, comme toujours, attention aux effets de bord de certains choix.

 

Fr de Joux
Non applicable

Excellent! Je me sers de la metaphore du spaghetti  depuis lomgtemps: elle est tellement vraie!

La critique que je ferai : vous prenez les chefs pour ce qu'ils devraient etre, non pas ce qu'ils sont.

Entre les operationnels qui veulent foncer, et le DSI qui dit qu' on va à la cata, il faut des nerfs (je reste poli), que la direction n'a pas...

La vraie solution: agir sous les radars, en quick-win, et mettre "tout le monde" devant le fait accompli. C'est risqué, mais ca peut reussir.

Cordialement

fj