Dans les années 60, les maîtres de l’informatique étaient des développeurs et développeuses. Cela fait longtemps, mais Uncle Bob nous le rappelle dans cette conférence. Il s’agissait souvent de scientifiques curieux, souvent mathématiciens, un peu en avance sur leur temps. Cette origine scientifique nous amène d’ailleurs souvent à réduire l’informatique à sa dimension technique.
Lorsque j’ai découvert l’informatique au début des années 90, on admirait les ingénieurs système et les DBA (DataBase administrators). Leur connaissance du fonctionnement d’un mainframe IBM, d’un Système UNIX, d’une base de données Oracle, alors solidement implantés dans tous les CTI (Centres de Traitement Informatique) faisait d’eux des acteurs incontournables à qui on s’adressait avec un peu d'appréhension quand on était jeune développeur.
Au début des années 2000, les pionniers du downsizing (on appelait alors le passage du mainframe au client/serveur) dopés à l’Internet émergeant se sont proclamés Architectes lorsqu’ils ont commencé à détrôner les ingénieurs système. L’enjeu à ce moment était le passage aux Nouvelle Technologies du Web; une nouvelle forme d’expertise est née, centrée sur les langages Objets, la modélisation UML, les design patterns, les protocoles du web (HTTP, XML), l’univers des frameworks et les rivalités (Java vs VB vs PHP, Apache vs IIS, Oracle vs SQLServer). Puis la course aux technologies de développement a commencé.
Je viens de vous décrire trois cycles d’une durée approximative de 20 ans ayant chacun sa propre conception du "maître" de l’informatique. On peut donc prédire la fin du cycle des architectes (au sens où on l’entend actuellement) autour de 2020, c’est-à-dire demain.
Nous sommes au crépuscule des architectes, on en perçoit déjà les signes.
Une nouvelle génération de développeurs n’entend plus qu’on lui mâche le travail en lui imposant des frameworks assemblés dans une tour d’ivoire par des architectes que le management reconnaît comme exclusivement légitimes des choix techniques. Cette génération assemble des stacks complètes en moins de deux avec Spring Boot, déploie ses applications grâce aux outils Dev-Ops et met en place des techniques de développement évoluées s’inspirant du mouvement Software craftsmanship.
La nouvelle génération de développeurs est autonome, exigeante, dynamique et souvent passionnée. Cela s’explique par le fait que depuis déjà une dizaine d’années, le développement est à nouveau perçu pour ce qu’il est : une discipline intellectuelle complexe et exigeante produisant de la valeur. Mais leurs aînés ont souvent une vision toute autre. Dans les années 2000 encore, il était conseillé de fuir le développement après quelques années d’expérience pour devenir chef de projet, architecte ou expert métier.
Aujourd’hui, les architectes sont en crise. Dans nombre d’organisations ils ont construit leur légitimité sur la base de connaissances techniques avec parfois un sentiment de supériorité hiérarchique. Mais la nouvelle génération de développeurs à laquelle je viens de faire allusion reconnaît de moins en moins cette légitimité; le titre d’architecte n’est plus aussi attractif qu’il y a quelques années.
D’un autre côté, les architectes sont noyés sous les sollicitations techniques. On leur demande de tout connaître, d’être sur tous les fronts, on les confond avec les tech-lead, ils se battent avec la dette technique ; finalement ils n’ont plus le temps de prendre de la hauteur, de se forger une nouvelle vision.
A l’avenir, je pense que la relation architecte/développeur sera amené à évoluer dans le sens d’une collaboration dénuée de toute connotation hiérarchique. On découvrira bientôt que l’architecture et le développement sont deux métiers différents mais complémentaires que l’on choisira en fonction de ses propres aspirations.
Mais pour que les choses évoluent dans ce sens il faut que les architectes se transforment.
Pour quelle raison ?
Dans le livre Building Microservices de Sam Newman, le second chapitre s’intitule The Evolutionary Architect. On peut y lire : "One of the main challenges that microservices introduce is a shift in the role of those who often guide the evolution of our systems: the architects".
L’auteur, Sam Newnam, suggère ici que l’évolution des architectures informatiques doit nécessairement nous pousser à reconsidérer le rôle de ceux que nous nommons les architectes. C’est tout à fait naturel d’un point de vue évolutionniste. D’où le titre judicieux de ce chapitre.
Cette évolution de l’architecture décrite par Sam Newman, c’est le mouvement qui nous fera passer des architectures monolithiques aux microservices. Il s’agit en effet d’une généralisation du concept "d’urbanisation" qui vient bouleverser les gros blocs de code que sont nos ERP les faisant éclater en plus petits morceaux.
Dans ce contexte, les architectes sont plus occupés à penser les interactions entre les morceaux du système, qu’à élaborer les briques permettant de les construire (la stack de développement). Heureusement, les développeurs d’aujourd’hui que l’on qualifie de full stack ont toutes les capacités à maîtriser leur stack de développement d’autant plus qu’ils sont aidés par des outils et générateurs de plus en plus perfectionnés.
L’architecture informatique devient organique. Elle se met à vivre. Les services se déploient progressivement, se branchent sur des streams de données, se mettent à l’échelle en fonction de la charge. Regardez donc cette vidéo et vous saurez pourquoi j’ai employé intentionnellement le terme d’organique.
Il y plein d’autres raisons qui doivent actuellement nous inciter à repenser le rôle des architectes. Je pourrais suggérer par exemple :
-
L’émergence de la fonction de tech-lead au sein de l’équipe.
-
L’hétérogénéité des systèmes et la cohabitation de technologies trans-générations: Les systèmes legacy ne meurent pas. Mais de nouvelles technologies viennent régulièrement les compléter.
-
La diversification des métiers de l’informatique: Du Data Scientist à l’UX Designer en passant par le Scrum Master, l’informatique n’est plus seulement technique.
Le monde de l’informatique devient organique, vivant, subtil. L’informatique est un nouvel écosystème avec son ordre, son désordre et toujours en mouvement.
Qui ?
Il n’y a pas encore de terme pour désigner ceux qui, à partir de 2020, "détrôneront" les architectes. Sam Newman propose l’expression Evolutionnary Architect. Pour ma part, je propose métarchitecte.
Qui sont les futurs métarchitectes ? Deux possibilités.
Tout d’abord des architectes qui regardent méticuleusement l’évolution de leur temps et décident qu’il est temps de remettre à jour leur mode de pensée. Mais cela est difficile. Il faut abandonner ses vieux habits (parfois prestigieux), sortir de sa zone de confort et accepter de côtoyer amicalement la jeune génération de développeurs.
Ensuite, tout simplement les actuels développeurs, du moins ceux qui ont en eux les modes de pensée propices à la pratique de la métarchitecture.
Et nous en venons donc à la question suivante : qu’est-ce qui fera de vous un métarchitecte ?
Qu’est-ce qui caractérise un métarchitecte ?
Pour devenir métarchitecte, un architecte doit effectuer une transformation délicate. De son côté, un jeune développeur qui souhaite devenir métarchitecte doit d’ores et déjà porter les habits d’un rôle qui n’existe pas encore, sans modèle sur lequel s’appuyer.
Il n’est pas un expert technique
L’informatique est une discipline au caractère extrêmement technique; pour cette raison et aussi parce qu’il y a, comme je l’ai évoqué au début de l’article, une continuité entre le rôle de l’ingénieur système et le rôle de l’architecte, ce dernier est souvent perçu comme un expert technique. C’est un piège pour qui veut endosser le rôle de métarchitecte.
Un piège d’autant plus difficile à éviter que le manager autant que le développeur sollicitent constamment l’architecte pour son expertise technique.
À cela s’ajoute évidemment le fait que tout architecte est passionné d’informatique et donc de technique.
Parfois, le désir de maîtrise technique peut trahir l’architecte, l’amenant à mettre en œuvre une technologie sous prétexte de chercher à la maîtriser en oubliant quelque peu de servir le besoin avec le plus de pertinence possible.
Le métarchitecte doit lâcher du lest sur la technique. Mais cela ne signifie pas qu’il faille tomber dans l’approximation ou la vulgarisation. Une connaissance étendue en matière de technologie est indispensable mais la maîtrise l’est moins.
Le métarchitecte se concentrera davantage sur la compréhension et l’interprétation des concepts, l’adéquation d’une technique à un besoin qu’à la façon de la mettre en œuvre avec efficacité. C’est un challenge extrêmement exigeant car il s’avère en réalité que la compréhension des concepts passe inévitablement par l’expérience et donc la mise en œuvre concrète.
Pour y arriver, un métarchitecte doit lire beaucoup, veiller, expérimenter et surtout doit savoir s’entourer des meilleurs experts techniques avec lesquels il doit travailler en étroite collaboration et non déléguer des actions en fermant les yeux.
Il pense urbanisé
En passant beaucoup de temps sur les détails techniques, on passe d’autant moins de temps sur la vision globale. Les journées durent 24 heures pour tout le monde.
Pourtant, les systèmes informatiques devenant de plus en plus complexes, connectés et distribués, un architecte devrait passer de plus en plus de temps à maintenir une vision globale afin d'accompagner au mieux les mouvements incessants de cet organisme mutant qu’est le SI.
Plus question de prévoir tout ce qui va se passer, de planifier toutes les évolutions ni de prêcher la vérité sur la bonne et la mauvaise technologie ; il est quasiment impossible aujourd’hui de savoir ce que sera l’informatique dans 10 ans et quel langage/framework aura pris le dessus. Les paris sur l’avenir sont stériles, ils gênent souvent l'évolution progressive de l’architecture.
Plutôt que de se penser en prescripteur des technologies et des pratiques, le métarchitecte devrait plutôt être une sorte de guide qui s’arme d’une vision d’ensemble pour aider à ce que les techniques émergeant en tout point du SI s’élaborent de façon cohérente en accord avec un schéma directeur bien identifié.
Il code
Dans certains environnements les architectes ne codent plus.
Dans l’ancien monde, ne plus coder était perçu comme un privilège dans la mesure où on en était arrivé à considérer le code comme une tâche à faible valeur ajoutée.
Mais code est en train d’être à nouveau valorisé. Il y a 20 ans, certains gourous nous annonçaient la mort du code mais aujourd’hui on voit émerger de tout "as code", de l’infrastructure à la documentation.
Savoir qui écrit le code de nos jours n’est plus un sujet.
Dans ce contexte, à ne pas coder, on risque de perdre en compréhension technique, ce qui n’est pas acceptable pour un métarchitecte.
Il est Data et Cloud
Si le mainframe était le terrain de jeu de l’ingénieur système, la stack technique celui de l’architecte, l’infrastructure est celui du métarchitecte. Les technologies issues du Cloud et de la mouvance Dev-Ops commencent à dessiner le socle sur lequel on déploiera tout système informatique à l’avenir.
Cela n’est pas sans conséquence sur la façon de penser du métarchitecte. Les cartes sont rebattues rapidement de nos jours. Les développeurs codent leur infra, les Ops monitorent des plateformes vastes comme un continent. Le métarchitecte doit trouver sa place dans ce nouveau paradigme et cela n’est encore clair pour personne.
D’un autre côté, il est entendu maintenant que nous sommes entrés dans l’ère de la Data. Depuis des décennies, on a l’habitude de penser que le sacro-saint modèle de données est l’affaire des experts fonctionnels de l’informatique. Ce raisonnement tenait tant que ce modèle, aussi vaste soit-il, était sous-tendu par une unique technologie avec une complexité technique encore abordable (le SGBDR au hasard).
De nos jours, on met en place des stocks de données multiformes servis par un nombre de technologies incroyablement variées.
Cela provoque un phénomène nouveau qu’il n’est pas facile de bien cerner pour qui a été architecte : le métarchitecte doit reprendre le contrôle sur la donnée.
Il est proche du métier
Ce qui est dit précédemment doit nous amener à une conclusion évidente : le métarchitecte doit se rapprocher du métier.
En effet, comment prendre de la distance avec l’expertise technique, élaborer une vision globale et travailler sur la donnée sans s'investir de plus en plus sur la compréhension fine du fonctionnel ?
Depuis déjà très longtemps, l’expertise technique attribuée à l’architecte a eu tendance à creuser un fossé entre l’architecte et l’expert fonctionnel. À tel point que dans bon nombre de projets, les tensions entre ces deux rôles sont manifestes.
Au passage, si le métarchitecte est incité à se rapprocher du métier, cela sera bénéfique pour l’ensemble des acteurs.
Il est orienté humain
Enfin, comme je l’ai proposé plus haut, le métarchitecte doit être un guide plutôt qu’un prescripteur (voire un censeur).
Il lui est donc indispensable de cultiver assidûment des soft skills.
Il doit savoir expliquer, accompagner, encadrer, convaincre. Il ne doit plus être perçu comme un expert bourru manquant de tact. Il doit au contraire être bienveillant, aider les jeunes développeurs à donner le meilleur d’eux-mêmes sans les juger et surtout participer au maintien d’un climat de confiance au sein d’un environnement technique de plus en plus déroutant.
Conclusion
Pour terminer cet article, je dirais simplement que, selon moi, l’architecture informatique est un vrai métier qui nécessite d’être pensé par ceux qui le pratiquent. Il me semble même que c’est un métier en devenir, même si cela fait des années que beaucoup s’en réclament et que certains vont même jusqu’à en faire une marque de distinction.
Pour désigner ce métier, on utilise le terme d’architecte, par analogie à un métier ancestral qui n’a peut-être pas tant de choses que ça en commun avec celui que nous pratiquons. Alors si le terme a été mal choisi à un moment donné, il faudra peut-être en inventer un nouveau dans quelques années. En attendant, je vous propose d’endosser le rôle de métarchitecte.
