Apriori contradictoires dans un contexte de pérennité pour l’un et de flexibilité pour l’autre, architecture d’entreprise et développements agiles semblent peu à peu trouver leur équilibre commun. Une certaine maturité sur ces deux notions permet en effet d’en tirer la quintessence respective.

STRATÉGIE AGILE : L’HEURE DE LA MATURITÉ

Après des débuts balbutiants mais des résultats prometteurs sur les périmètres qui lui étaient assignés, l’agilité s’est soudainement trouvée sous les feux de la rampe il y a cinq ans. C’est à cette époque que le concept s’est mis à séduire tous azimuts le top management de nombre d’entreprises.
Il n’en fallait pas plus : l’organisation se devait de devenir agile, pour survivre dans un environnement qui l’était de plus en plus. Au point d’en devenir parfois plus dogmatique que pragmatique.

Car cette transformation à marche forcée a non seulement pu être mal ressentie en interne, mais elle a aussi pu produire certains effets indésirables, réduisant de fait l’intérêt d’une agilité réfléchie et mesurée au sein de l’organisation.
C’est ainsi qu’en ne considérant que le seul périmètre IT, certaines entreprises ont pu constater, par l’emploi excessif des principes de l’agilité, la dégradation d’une partie de leur patrimoine applicatif, une mauvaise organisation de leurs data, ou encore des applications mal ou pas du tout référencées.

AGILITÉ ET PÉRENNITÉ : L’ÉQUILIBRE DÉLICAT DE L’ARCHITECTURE D’ENTREPRISE

Bien que plus mesurée aujourd’hui, l’agilité reste un véritable défi pour l’architecte d’entreprise. Car c’est sur ses épaules que reposent à la fois la nécessité de construire un socle IT solide et pérenne, et une architecture agile capable d’évoluer en fonction des besoins du marché.

Dès lors, cela signifie qu’il doit être en mesure de procéder aux bons arbitrages entre ces chemins souvent opposés. Qu’il ne doit d’ailleurs pas considérer comme tels, mais plutôt comme complémentaires. En acceptant un ratio raisonnable entre une architecture intentionnelle, correspondant à la stratégie et à la politique de l’entreprise, et le design émergent des équipes agiles pour répondre aux besoins immédiats, l’architecte d’entreprise se doit de garder la dette technique sous contrôle tout en optimisant les ressources IT de l’entreprise afin de produire le maximum de valeur pour les métiers.

Concrètement, charge à l’architecte d’entreprise de trouver le juste équilibre entre l’approche topdown de la stratégie IT, et celle, orientée bottom-up, de l’agilité.
L’idée est de ne pas se focaliser uniquement sur le court terme, mais aussi de penser les développements dans une démarche de long terme, en conformité avec la stratégie, les bonnes pratiques définies ou encore, par exemple, les réglementations qui s’imposent au système d’information.
La dimension du passage à l’échelle des développements agiles permettant d’adresser ce long terme est un sujet souvent difficile dans les entreprises. L’architecte d’entreprise doit y prendre part afin de tirer les démarches vers le long terme. Et surtout de ne pas opposer agilité et temps long d’un développement ou d’un projet industriel. Car, même à l’échelle de plusieurs années, l’agilité dans un développement d’applications, par exemple, est susceptible de faire gagner du temps, d’apporter de la valeur et ainsi de gagner en compétitivité sur l’ensemble du projet.

COLLABORATION ET ÉCOUTE, AUXILIAIRES D’UNE DOUBLE CULTURE

Au même titre que la maîtrise d’ouvrage est coincée entre le marteau des métiers et l’enclume de la DSI (ou l’inverse !), l’architecte d’entreprise se trouve donc souvent à la croisée du « design émergent » et de l’architecture intentionnelle. Toute sa difficulté repose ainsi, sans tomber dans « l’effet gendarme », sur l’association des équipes agiles dans une vision de long terme, tout en leur laissant une certaine marge de liberté au quotidien. Marge de liberté qui sera d’autant plus gagnante que cette culture d’architecture se diffusera et que la valeur associée sera comprise et adoptée par les équipes agiles.

En pratique, c’est donc sur la confiance mutuelle entre architectes d’entreprise et équipes agiles que s’appuie cet équilibre. Mais également sur une certaine ouverture d’esprit de part et d’autre : les développeurs agiles doivent prendre conscience et accepter les contraintes d’une vision à long terme du système d’information, et les architectes d’entreprise doivent aussi accepter d’intégrer dans l’architecture intentionnelle certaines fonctionnalités ou concepts issus du design émergent.

C’est donc sur une collaboration étroite entre équipes agiles et les architectes d’entreprise que doit se construire le système d’information de demain, capable de répondre à leurs enjeux de flexibilité, de souplesse et de time-to-market réduit, tout en reposant sur des fondations réfléchies et solides à long terme.
En d’autres termes, la capacité d’écoute et de communication de l’architecte d’entreprise auprès des équipes de développement ‒ comme de tous les collaborateurs de l’organisation qui utilisent le système d’information quotidiennement ‒ est loin d’être accessoire : c’est même l’un des murs porteurs de la stratégie IT dont il a la charge.


Par Antoine Mouttapa, Directeur de comptes et architecte principal de Cesames Institut
et Gabriel Gomane, Senior product marketing manager, Mega International