Abstract image of blue beams of light

L’architecture évolutive : accompagner une mutation perpétuelle

Ce ne sont pas les plus forts qui survivent, mais ceux qui sont les plus réactifs face au changement. Cela vaut aussi pour le développement d’architectures logicielles. Aujourd’hui, nous vous présentons le concept de l’architecture évolutive et ses principes.

Jusqu’à présent, les gens percevaient leur architecture logicielle comme difficile à faire évoluer. Et si l’on développait des architectures en s’attachant principalement aux notions de changement et d’évolutivité ? Une architecture évolutive permet de soutenir une évolution progressive et dirigée en tant que principe premier sur de multiples dimensions.

 

Quels vecteurs de changement dans l’architecture logicielle ?

Tout finit un jour par changer. Comme le disait Einstein dans une phrase célèbre, c’est la seule constante. Si certaines choses peuvent changer sous l’impulsion de l’entreprise, d’autres choses se verront imposer le changement. Il existe deux types de changement auxquels votre entreprise doit faire face :

  • Le changement lié à l’activité : on peut citer de nouveaux modèles de revenus, des concurrents disruptifs, de nouveaux canaux, l’évolution des besoins du client, la règlementation du marché et l’innovation produit. Ces différents éléments modifient les exigences commerciales et les cas d’utilisation que vous traitez avec votre architecture.
  • Le changement lié à l’écosystème : le domaine technique mue et évolue au fur et à mesure que les langages de programmation, les bibliothèques, les outils de framework et les environnements d’exploitation évoluent. Docker, par exemple, a contribué à diffuser la technologie des conteneurs auprès du grand public. Cela a révolutionné la façon dont nous utilisons les ressources informatiques.

Le changement peut avoir une incidence très forte en raison de la notion d’équilibre dynamique, terme généralement utilisé en chimie et d’autres sciences physiques et qui se vérifie également dans l’architecture logicielle. L’équilibre dynamique signifie que si vous modifiez un état de juste équilibre, vous devrez procéder à des ajustements continus pour maintenir un état stable. Tout comme le Yin et le Yang, l’univers logiciel est dynamique plutôt que statique. Dans un état de flux constant, une image à un instant T de votre architecture logicielle sera différente d’une autre image prise à un autre moment. Alors, comment faire face au changement ?

 

Faire face à l’inconnu

De par sa nature même, l’architecture est l’élément que l’on souhaite le moins changer en raison de son degré de complexité et du coût que cela implique. C’est pourquoi des changements au niveau de l’écosystème peuvent créer de réelles difficultés pour l’architecture logicielle, surtout dans l’entreprise. Plus les choses changent, moins il est possible de faire de planification à long terme. On perd en prévisibilité. Comment prévoir un plan sur cinq ans pour son architecture quand celle-ci peut être facilement balayée par une innovation encore inimaginable ?

Quand on anticipe le changement en tant que early adopter, on peut miser sur le mauvais cheval : pensez simplement à la longue liste de langages de programmation à l’abandon, comme D, Fortress, J# et Wasabi. Et pensez maintenant aux nouveaux langages tels que Scala, Typescript et Swift. Pourront-ils se maintenir ? Ou vont-ils subir le même sort que Ruby, en perte de vitesse depuis que Twitter a annoncé en 2011 qu’il s’en séparait. Il est tout simplement impossible de prévoir quel sera le prochain langage le plus en vogue. Mais quand la transition s’opèrera, il vous faudra toujours planifier l’ensemble de l’écosystème qui doit suivre.

 

L’architecture évolutive par rapport aux architectures antérieures

Le principe directeur d’une architecture évolutive est de soutenir un changement guidé, progressif et sans rupture sur de multiples dimensions. Pour en comprendre les implications, prenons du recul et examinons les architectures antérieures. La première, bien sûr, c’est la grande boule de boue, à savoir un système logiciel dépourvu d’architecture perceptible. C’est un système très dense qui peut être identifié par le niveau de couplage élevé de ses modules. Un simple changement nécessite de nombreuses modifications susceptibles de mettre en péril toute l’application : l’architecture peut s’effondrer.

La seconde architecture à mettre en comparaison est l’architecture en couches ou architecture multiniveaux, qui sépare la présentation des fonctions, les traitements applicatifs, la logique métier et la gestion des données. Elle offre une évolutivité monodimensionnelle dans le sens structurel du fait qu’on aborde la dimension des couches séparément. Mais dans la pratique, les changements apportés aux interfaces de niveau inférieur ont tendance à migrer vers les niveaux supérieurs. Le déploiement de nouvelles fonctionnalités sur une couche peut aussi entraîner des changements dans les autres couches. En outre, si on considère le principe de la conception pilotée par le domaine (DDD), qui est centrée sur les secteurs d’activité des utilisateurs, on constate qu’un même domaine est susceptible d’être éclaté sur plusieurs couches. Un changement dans le domaine affectera toutes les couches : ce n’est pas un modèle évolutif.

Maintenant, examinons une architecture évolutive telle que les microservices. Il existe un contexte délimité qui est fonctionnellement distinct. Les services sont découplés et orientés domaine, ce qui signifie que le fait de modifier un service existant n’a pas d’incidence sur les autres services. C’est comme remplacer une brique de Lego.

 

Les principes de l’architecture évolutive

La grande idée est que les éléments architecturaux peuvent être modifiés plus tard. Si vous intégrez le changement évolutif dans votre architecture, les changements seront moins chers et plus faciles. Il existe plusieurs concepts autour de l’architecture évolutive :

  • API : si vous utilisez des API comme framework pour interagir avec les applications, les données et les fonctionnalités sont facilement accessibles à d’autres applications.
  • Cloud : en particulier, lorsque vous mettez vos microservices dans le cloud, votre architecture peut bénéficier pleinement des avantages types du cloud comme l’évolutivité, la résilience et la haute disponibilité.
  • Le commerce « headless » : lorsque vous utilisez des microservices pour faire du e-commerce, vous pouvez découpler le CMS de la couche de présentation, dans un commerce dit headless (sans tête)
  • L’architecture orientée évènements (EDA) : cette approche est axée sur les évènements commerciaux auxquels l’entreprise doit impérativement réagir. Une architecture orientée évènements offre à ses clients un service en temps réel et permet de définir la logique métier en tant que logique globale.

Si l’ensemble de ces avancées et approches procurent l’agilité commerciale que les entreprises recherchent aujourd’hui, c’est le concept d’architecture évolutive qui fournit le principe directeur. Il s’agit avant tout d’adaptabilité face au changement.

 

5 aspects clés à prendre en compte pour créer votre architecture évolutive

  1. Fonctions de qualité. Elles permettent d’indiquer à quoi ressemble l’architecture cible et à ce titre, elles varient considérablement d’une entreprise à l’autre. Certains systèmes nécessitent un très haut niveau de sécurité, d’autres une disponibilité élevée quand d’autres requièrent des temps de service donnés. Penser dès le départ aux fonctions de qualité permet de guider le processus décisionnel et le calendrier et vous aide à préserver les exigences clés au fur et à mesure que le système évolue.
  2. Dernier moment responsable. Traditionnellement, les décisions architecturales se prennent avant d’écrire un quelconque code. Dans une architecture évolutive, on attend le dernier moment responsable pour prendre des décisions. Pourquoi ? Parce qu’il existe probablement des informations plus détaillées à prendre en compte. La difficulté, toutefois, est de déterminer quelles sont les décisions que l’on peut reporter. Ici, ce sont les fonctions de qualité qui doivent passer au premier plan.
  3. Mettre le doigt sur les problèmes. Certaines choses sont plus difficiles à faire et peuvent poser de nombreux problèmes. Plus vous les faites tôt et souvent, plus vous identifierez rapidement les problèmes qui en sont la cause. Et plus vous les résoudrez, plus vous serez encouragé·e à continuer.
  4. La livraison continue. Elle vous permet de soutenir la pratique d’architecture évolutive dans son ensemble, en introduisant deux nouveaux attributs architecturaux : la testabilité et la déployabilité. Dans une architecture testable, la plupart des défauts se décèlent à l’aide de tests automatisés. Dans une architecture déployable, vous pouvez déployer tel ou tel service sans orchestration ni temps d’indisponibilité conséquents. Cela permet également l’expérimentation et les tests A/B, comme faire fonctionner plusieurs versions d’une même version en même temps.
  5. S’organiser autour des capacités commerciales. La conception pilotée par le domaine permet de générer de la modularité au niveau du domaine plutôt qu’au niveau des couches techniques. Cela nécessite la mise en place d’équipes plurifonctionnelles par secteur professionnel et place les projets permanents et non plus les projets ponctuels au centre du processus. C’est vous qui bâtissez cette modularité, et c’est vous qui la gérez. Ainsi, il vous sera plus simple d’opérer des changements sans rupture suivant des limites clairement définies.