Quand le changement est constant, l’architecture devient une discipline essentielle

le 24/05/2023 par Wassel Alazhar, Damien Hecquet

Durant le printemps, nos experts OCTO vous proposent un cycle de contenus autour du Cloud. Le sujet vous intéresse ? Pour découvrir le programme et ne rien rater, inscrivez-vous sur notre page Cloud, DevOps & Plateformes.

A l'heure où les géants du Cloud proposent une quantité grandissante de ressources d'Architecture optimisées pour leurs plateformes (au sein de la documentation Azure ou AWS ou via un outil chez Google), on peut se dire que la vie des architectes est grandement simplifiée. Mais est-ce vraiment le cas ?

L’architecture à l’épreuve du changement

Traditionnellement, les architectes d’entreprise ont pour mission de valider les choix technologiques, en début de projet, en expliquant en quoi ces choix répondent aux besoins métier. Pour cela, il faut considérer une multitude de contraintes d’ordre technique, organisationnel ou politique. Les solutions à l’équation sont souvent la déclinaison des besoins en périmètres applicatifs, les choix technologiques (build vs buy) et d’infrastructure (quel DataCenter, quel socle d’infra), voire le choix d’un intégrateur pour couvrir tous ces besoins (le fameux “Nobody ever gets fired for buying IBM”).

Mais, dans les dernières années, les facteurs de complexité ont bien augmenté.

Agile, Cloud, conteneurisation, architectures micro-services, Serverless, nouveaux paradigmes de données, Intelligence Artificielle... de nombreuses nouvelles méthodes, solutions, technologies et motifs d’architecture sont apparus.

Si le Cloud apporte un certain nombre de promesses (élasticité, innovation, services managés…), il ne vient pas sans son lot de complexité.

La coexistence des systèmes d’information historiques (“Legacy”) et des nouvelles capacités apportées par les hyperscalers introduit une complexité d’hybridation des architectures. Il convient alors de trouver la meilleure façon de modulariser les applications, dont certaines vont avoir un pied dans le SI traditionnel et utiliser une partie des fonctionnalités Cloud, avec un besoin d’interfaçage des deux mondes.

Gregor Hohpe est peut-être celui qui a le mieux illustré ce changement de contexte qui s’impose aujourd’hui aux organisations, dans son ouvrage “Cloud Strategy”. D’un côté, il y a les organisations qui cherchent à passer d’un mode nominal à un autre, avec, entre les deux, la perturbation du projet et sa conduite de changement. De l’autre côté, les organisations qui acceptent que le changement est constant.

~Du « mode projet » (à gauche) au changement constant (à droite). Source : <a href="https://leanpub.com/cloudstrategy">Cloud Strategy</a>, de Gregor Hohpe~

Quand on combine les facteurs de complexité mentionnés plus tôt avec l’accélération des besoins d’évolution, on se rend compte à quel point l’architecture est une discipline essentielle. Mais il est indispensable que le regard porté sur l’architecture - comme discipline - change de façon radicale : une approche pragmatique qui nous offre des options face aux différentes incertitudes, plutôt qu’une série de contraintes qui nous infligent des solutions figées et complexes.

L’architecture pour sécuriser les nouveaux investissements : s’offrir des options pour retarder les décisions engageantes

Plusieurs architectes considèrent que leur rôle est de prendre les décisions structurantes, difficiles à changer, voire “irréversibles”. Et parfois, c’est ce qu’on attend d’eux.

Le dossier d’architecture détaillé (DAT) est souvent un pré-requis pour démarrer tout développement. C’est parfois même un entrant nécessaire pour valider le budget d’un nouveau projet.

Or, faire des choix engageants au tout début d’un projet, c’est-à-dire au moment où l’on en sait le moins, est la pire chose que l’on pourrait s’infliger et infliger aux équipes de développement.

Ce que les équipes cherchent avant tout, c'est de maximiser les apprentissages sur le terrain dès que possible. Au lieu de cela, elles se retrouvent à lutter avec des contraintes qui leur ont été imposées sur la base d'hypothèses non vérifiées.

Il faut dire que, lorsqu’on se lance dans une nouvelle aventure, on prend des hypothèses, avec un grand nombre d’incertitudes qui les entourent. Des incertitudes sur les plans métier, technologique, organisationnel ou tout en même temps (quelques exemples : est-ce que les comportements des utilisateurs seront conformes à ce que l’on a projeté ou “espéré” ? Notre partenaire historique saura-t-il gérer nos nouveaux cas d'usages ? Est-ce que l’on va continuer avec Stripe ou on ferait mieux de passer sur Stancer ? Est-ce que la nouvelle plateforme d’observabilité sera prête à temps ? Est-ce qu’on continue de faire comme si notre Keycloak fonctionnait bien ou serait-il temps de passer sur autre chose ? Combien de temps faudra-t-il à nos équipes pour maîtriser ces nouveaux paradigmes ? Comment la réglementation va évoluer ? ...).

Face à ces incertitudes, le piège est de tomber dans les extrêmes : partir bille en tête dans le solutioning technique sans se poser de questions ou essayer de fournir des solutions “intelligentes”, avec des plans visionnaires qui, dans les faits, deviendront très vite obsolètes.

Pour couvrir les risques liés à ces incertitudes, le rôle des architectes est de concevoir et préconiser des options permettant de retarder les décisions les plus engageantes. Ces options d’architecture permettent aux organisations d’acheter de la flexibilité pour sécuriser leurs investissements (Gregor Hohpe, encore lui, a bien exploré la métaphore comparant l’architecture aux options en finance, dans son ouvrage “The Software Architect Elevator” et dans cet article).

Plus il y a de l’incertitude, plus ces options ont de la valeur.

Plus ces options réduisent la surface d’exposition au risque, plus elles ont de la valeur.

Benjamin Bayart nous explique dans son article "les légendes du cloud" (et ici) que les contraintes réglementaires font partie des aspects les plus importants à prendre en considération en début de projet. Ces contraintes peuvent avoir des impacts à tous les niveaux, jusqu’au choix du cloud provider. Et en plus, elles sont en évolution permanente. Au plus haut niveau d'ignorance concernant le comportement futur de notre produit (c'est-à-dire en début de projet), il serait rassurant d'avoir des options pour éviter de tout jeter à la poubelle si nos hypothèses initiales changent.

Une option qui isole certains facteurs de risque par rapport au reste du système nous permet de réduire notre exposition à ce risque (exemple : ne pas propager des données sensibles dans tout le système).

~Les architectes à la quête du graal : Forte ~ _{cohésion} ~ et ~ _{couplage} ~ faible. Source : <a href="https://en.wikipedia.org/wiki/Cohesion(computer_science)#/media/File:CouplingVsCohesion.svg" target="blank" rel="noreferrer noopener">Wikipedia</a>~

De même, en décomposant le problème et en regroupant les éléments qui changent au même rythme, nous gagnons la souplesse de remplacer une partie du système sans affecter les autres si nos besoins ou nos hypothèses changent. On pourrait aussi décider d’introduire des abstractions qui nous offrent la possibilité de porter tout ou une partie de la solution d’un cloud à l’autre si l’on en est contraint.

Ce sont des options qui pourraient avoir de la valeur mais qui ont certainement un coût. Si l’on prend le dernier exemple concernant la portabilité, il faudra supporter le coût des abstractions supplémentaires tout au long du projet, et en même temps accepter de renoncer à certains services du cloud provider et qu’il y aura toujours un coût de migration (réduit, certes, mais pas nul).

En prenant conscience des incertitudes et des axes de changements auxquels on fait face en début de projet, on comprend facilement quelles devraient être nos attentes vis-à-vis de l’architecture. On ne s’attend plus à prendre des décisions irréversibles mais plutôt à en réduire le nombre.

N.B. : Quand on veut retarder des décisions importantes, il est primordial de bien comprendre le problème que l’on souhaite résoudre et l'écosystème dans lequel on évolue. Il est également nécessaire de rendre explicite les visions et les hypothèses. Les outils du Domain-Driven Design sont des atouts incontournables aux architectes.

L’architecture évolutive pour dé-risquer en continu

L’autre moyen, nécessaire pour sécuriser tout investissement logiciel, est de livrer en continu (comme expliqué par Celine Gilet dans cet article).

Et ce serait tellement confortable si toutes les bonnes décisions étaient prises dès le départ. Ce serait tellement rassurant, pour tout le monde, si les esprits les plus éclairés de l’organisation avaient pensé à tout et qu’il n’y avait plus qu’à implémenter des architectures brique par brique.

Une fois encore, les réalités d’hier ne sont pas celles d’aujourd’hui et l’architecture optimale est celle qui évolue au fur et à mesure de l’évolution de nos besoins et de nos apprentissages et découvertes.

L'architecture évolutive, en tant qu’approche, permet aux équipes de faire évoluer progressivement l’architecture de leur système au fur et à mesure qu’ils font leurs livraisons. Cette approche permet, d’un côté, de moins subir dans le temps le coût d’une option d’architecture, puisqu’on essaiera de l’introduire uniquement au moment où l’on pourrait en tirer des bénéfices. D’un autre côté, l’architecture évolutive permet d’incorporer de nouvelles décisions qui émergent des patterns qu’on observe.

Loin d’être devenue une réelle tendance, on constate tout de même un intérêt grandissant pour cette discipline, surtout avec les simplifications de mise en œuvre qu’apporte l’infra as code et les services managés des clouds providers.

Néanmoins, elle nécessite un certain nombre de pré-requis à la fois techniques (développements pilotés par les tests, refactoring continu, documentation des décisions d’architecture via des ADR, livraison continue, intégration continue, test data management …), mais surtout organisationnels en raccourcissant les circuits de décisions ainsi qu’en permettant aux équipes de choisir leur propres outils.

L’architecture comme levier d’apprentissage

En conclusion, nous sommes convaincus que l’architecture qui résoudra vos problèmes et qui aura le plus de valeur pour vous n’est pas une architecture que vous pouvez copier/coller depuis le catalogue d’un cloud provider.

L’approche qu’on vous propose pourrait effrayer certains, puisqu’elle soulève plus de questions qu’elle n’apporte de réponses. Au lieu de faire rapidement des choix déterminants, on les diffère ; au lieu de prendre toutes les décisions en amont pour les équipes de développement, on leur demande aussi de décider et de communiquer leurs décisions en continu. Et c’est normal, car c’est une approche qui permet d’apprendre rapidement ; et pour apprendre, on se pose des questions. Apprendre rapidement c’est le meilleur moyen de faire face à toutes les complexités qui s'imposent à nous et de pouvoir évoluer rapidement et atteindre les objectifs business.

Pour aller plus loin :

Pour tout savoir sur les enjeux Cloud, DevOps et Plateformes, cliquez ici.

Nos articles sur le blog OCTO :

Nos formations OCTO Academy:

Références externes :