L’architecture évolutive : accompagner une mutation continue

Cela vaut également pour les architectures logicielles, car ce sont elles qui contiennent les bonnes décisions que vous souhaitez pouvoir prendre dès le début d’un projet. Jusqu’à présent, les architectures logicielles sont perçues comme difficile à faire évoluer. Et si nous construisions des architectures en nous attachant principalement aux notions de changement et d’évolutivité ? Une architecture évolutive permet de soutenir une évolution progressive et dirigée en tant que premier principe dans de multiples dimensions.  

Quel est le moteur du changement ?

Tout finit un jour par changer ; comme le disait Einstein, c’est la seule constante. Certaines choses peuvent changer si l’initiative est prise au niveau de l’entreprise, d’autres devront changer de façon involontaire. Il existe deux types de changement auxquels votre entreprise doit faire face :

• Le changement lié à l’activité : on peut citer les nouveaux modèles de revenus, des concurrents disruptifs, les nouveaux canaux, l’évolution des besoins du client, les règlementations 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 frameworks et les environnements d’exploitation évoluent. Docker, par exemple, a contribué à diffuser la technologie des conteneurs auprès du grand public et a révolutionné la façon dont nous utilisons les ressources informatiques.

Le changement peut avoir une très forte incidence en raison de la notion d’équilibre dynamique, terme emprunté à la chimie et d’autres sciences physiques, 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. 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 aux inconnues « non connues »

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.

Comment prévoir un plan sur cinq ans pour son architecture quand celle-ci peut être facilement balayée par une innovation encore inimaginable ? A l’inverse, si vous investissez tête baissée dans une toute nouvelle technologie, vous risquez d’essuyer les plâtres en ayant misé sur le mauvais cheval. Regardez les langages de programmation qui n’ont pas percé, comme D, Fortress, J# et Wasabi… et pensez maintenant aux nouveaux langages tels que Scala, Typescript et Swift. Pourront-ils durer ? Ou vont-ils subir le même sort que Ruby, en recul depuis que Twitter a annoncé en 2011 qu’il s’en séparait ?

Il est impossible de prévoir quel sera le prochain langage le plus en vogue, mais quand la transition s’opèrera, il faudra toujours planifier l’ensemble de l’écosystème qui doit suivre. La seule solution consiste à bâtir une architecture capable d’anticiper les changements et l’évolution de manière économiquement rationnelle. Thoughtworks a donné à cette idée le nom « d’architecture évolutive ». Avec cette architecture, vous pouvez vous adapter rapidement au changement sans avoir besoin de prédire l’avenir pour réaliser des investissements incertains. La prévisibilité ouvre la voie à l’évolutivité.  

L’architecture évolutive vs. les 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, c’est la grande boule de boue : un système logiciel dépourvu d’architecture perceptible. Il est très dense et 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 se rompre.

La seconde architecture est l’architecture en couches ou architecture multi-niveaux, 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. Et quand on introduit de nouvelles caractéristiques sur une couche, cela peut imprimer des changements au niveau d’une couche sur deux. En outre, si on considère le principe de la conception pilotée par le domaine (Domain-Driven Design, 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 seul changement dans le secteur d’activité va affecter toutes les couches : pas d’évolution. 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

L’idée clé 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 coûteux et plus faciles. Il existe plusieurs concepts autour de l’architecture évolutive :

• API :si vous utilisez des API comme cadre de référence 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é.
• Commerce headless :lorsque vous utilisez des microservices pour faire de l’e-commerce, vous pouvez découpler le CMS de la couche de présentation dans un commerce dit « headless ».
• 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 un service en temps réel et la possibilité de définir la logique métier en tant que logique globale.

Si l’ensemble de ces développements et approches apportent l’agilité commerciale que les entreprises recherchent aujourd’hui, c’est le concept d’architecture évolutive qui fournit le principe par excellence. Il s’agit avant tout d’adaptabilité face au changement. Les cinq caractéristiques suivantes sont fondamentales pour la conception d’une architecture évolutive :

1. Fonctions de qualité.Elles permettent d’indiquer à quoi ressemble l’architecture cible. A 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é est toutefois de déterminer 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. Si vous les faites tôt et plus souvent, vous identifierez plus rapidement les problèmes qui en sont la cause. Plus vous les résoudrez, plus vous serez encouragé(e) à supprimer automatiquement ces problèmes.
4. La livraison continue.Elle permet de soutenir une pratique plus large de l’architecture évolutive, 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 le test 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.

 

Tout est question de temps

L’architecture évolutive améliore considérablement le temps nécessaire à la mise en production d’un seul changement, de manière répétée et fiable. Elle le fait en supprimant les cycles lents de retour d’informations, les couplages et la cohésion : les principaux obstacles lorsqu’il s’agit de s’adapter aux changements. Chaque composante de l’architecture peut évoluer au fil du temps, indépendamment de son environnement. La forte réduction des délais de mise sur le marché et la nouvelle adaptabilité apporteront à votre entreprise une manœuvrabilité et une agilité commerciale réelles. Vous pourrez ainsi vous adapter efficacement aux changements, introduire de nouvelles caractéristiques au bon moment et dépasser vos concurrents. Avec une architecture évolutive, vous serez à même d’avancer à votre propre rythme.