Pour cette dernière partie, je vous propose de nous concentrer sur les changements profonds qui traversent l’architecture aujourd’hui.
Bien que l’informatique soit un secteur qui par nature évolue beaucoup au gré des innovations technologiques, on voit ces dernières années une vraie accélération des transformations. L’arrivée des méthodes agiles-devops, du cloud, des conteneurs, du stockage flash et l’emphase mise sur le digital raccourcissent les cycles projet et précipitent l’arrivée de nouvelles approches. Quels sont leur impacts sur l’architecture aujourd’hui ? Comment se tenir au courant ?
En complément des réponses à ces questions, nous zoomerons sur la place prépondérante qu’ont pris le réseau et la sécurité par rapport aux autres problématiques.
Hier, un rôle d'architecte limité
La plupart du temps, les architectures prévues prenaient la forme de documents longs, complexes, et en général assez peu utiles car très rapidement dépassés par la réalité de la technique et de sa mise en œuvre. C’est l’image de l’architecte dans sa tour d’Ivoire loin des préoccupations du terrain, mais ravi d’appliquer sa méthode et de produire de beaux schémas.
Souvent, ce mode d’intervention est perçu dans l’entreprise comme un écueil à éviter car augmentant les délais, les coûts et freinant l’innovation. Cependant, dans ces organisations, le « tampon de l’architecture » est souvent obligatoire avant tout passage en production.
Aujourd'hui, des responsabilités étendues
Développez une vision long terme de l'architecture
Dans de plus en plus de contextes, on attend aujourd’hui une implication très différente des architectes :
Un accompagnement dans la durée, en assumant les choix faits jusqu’à la production ;
Une capacité à guider les choix technologiques ET à les remettre en question à tout moment.
Ils doivent désormais prouver leur valeur dans des organisations aux cycles très raccourcis, qui n’autorisent plus des phases d’études longues dont elles ne voient pas la valeur ajoutée directe (à tort comme à raison!).
Concrètement, il va falloir montrer à vos interlocuteurs que l’application de la méthode, loin de leur faire perdre du temps, va leur permettre au contraire d’aller plus vite en évitant des errements liés à une mauvaise compréhension des différents enjeux. On est là dans la composante posture que je vous décrivais en première partie.
Assurez-vous de comprendre toutes les couches de votre architecture
Anecdote récente, j’accompagne un jeune architecte sur ses premiers travaux autour d’une application. Au bout de quelques ateliers avec les développeurs, où on travaillait principalement sur des schémas logiques, il vient me voir en me disant « Jonathan, tu vas pas le croire, mais je me suis rendu compte aujourd’hui que je n’avais pas du tout compris ce que faisait l’application, je pensais qu’elle permettait à des utilisateurs de récupérer des données, alors qu’en fait, le seul consommateur est une autre application ».
Cette prise de conscience lui a permis d’adapter l’architecture proposée par les développeurs pour la rendre bien plus simple et plus efficace en éliminant notamment toute une partie exposition vers internet.
Ce cas simple montre toutefois bien l’importance cruciale du rôle : c’est à vous de vous assurer que toutes les couches sont bien comprises et partagées par tous. Et de grâce, évitez la validation par épuisement, celle où vos interlocuteurs sont prêts à tout vous accorder à cause d’une présentation trop longue et trop touffue. Ça se paie toujours un peu plus tard !
Adaptez-vous aux changements technologiques
Si on reprend la terminologie Agile et DevOps, votre intervention devra se faire à chaque sprint (qui doit inclure une phase de conception) et durant tout le cycle de vie de l’application ou du système.
Les architectures Cloud en particulier imposent ce mode de fonctionnement : en effet, les services souscrits sont à la main des fournisseurs qui les font évoluer à leur gré (j’y reviendrai dans le prochain chapitre). Il faut donc être en mesure de faire évoluer ses choix en fonction des nouveautés et des changements de stratégie, à tout moment.
Afin de prendre en compte cette exigence, idéalement, il faudrait prévoir comme pour une centrale nucléaire : estimer dès le départ le coût du retour en arrière. Malheureusement, c’est quasi-impossible à faire en réalité, et imaginer l’avenir en informatique est un exercice très périlleux :)
De même, gardez à l’esprit que les solutions changent très vite. Restez humbles dans vos designs, les principes d’architecture d’aujourd’hui ne seront pas nécessairement ceux de demain et tout peut être remis en question.
En résumé
Dans ce chapitre, nous avons vu ensemble le changement profond que vivent les architectes aujourd’hui, en passant d’une situation où ils sont incontournables à un monde où ils ont besoin de prouver leur valeur ajoutée. Cette transformation creuse un fossé profond en particulier là où les nouvelles architectures sont déployées, en utilisant par exemple les services PaaS, IaaS, serverless, Flash et Containers.
Nous aborderons dans le prochain chapitre comment prendre en compte ces nouveautés et comment s’adapter efficacement aux changements.
