Quand je me présente en tant qu’architecte de SI aux nouveaux arrivants à OCTO, j’obtiens régulièrement deux types de réponses :
Cela m’a donné l’idée d’écrire cet article où je vais tenter d’expliquer pourquoi ce n’est pas le cas, ou au moins pas le cas dans toutes les situations.
L’architecture de SI consiste à définir des stratégies globales à des organisations, gérer des transformations de système, ou piloter des systèmes complexes. Depuis le début des années 2000, elle a profondément changé.Mais, si les prérequis ont évolué, la finalité reste la même.
Il y a quinze ans, l’architecture de SI était très contrainte par ce que les outils étaient capables de faire, une vraie expertise de ces briques était donc nécessaire pour faire les bons choix et guider leur mise en œuvre. De même, la capacité d’intégrer des systèmes dépendait des technologies disponibles, et des solutions exotiques pouvaient être nécessaires pour des besoins pointus, ce qui à nouveau demandait des connaissances spécifiques.
De nos jours, pour une application standard, les outils et les protocoles sont beaucoup plus matures.
Mettre en place une grappe de serveurs applicatifs associés à une base de données répliquée, ce qui répond aux besoins de beaucoup de projets - est désormais devenu accessible, alors qu’il y a pas si longtemps les efforts à investir pour cela étaient encore significatifs.
Avec le cloud, beaucoup de ces logiciels sont disponibles en quelques clics. Dans beaucoup de cas, certaines compétences ne sont donc plus utiles.
Mais cela ne veut pas dire que l’architecture de SI a disparu, c’est seulement que le temps à passer sur les sujets d’architecture est plus faible et que certaines compétences ne sont plus nécessaires pour faire de l’architecture de SI.
Les vendeurs fournissent de plus en plus de solutions et de patterns clés en main. Ils peuvent répondre à des "comment" et simplifient la mise en œuvre, mais ne remplacent pas la définition d’une stratégie de SI ni la capacité à accompagner les personnes qui la réalisent.
Oui, il est possible de construire des systèmes qui fonctionnent en se passant de ce type de questions, mais procéder ainsi augmente vos chances de ne pas y parvenir, ou de construire un système fragile et difficile à faire vivre.
Lorsqu’on travaille en cycle en V, l’architecture cible est souvent définie de manière très complète dès le lancement. En agile, l’objectif est de le faire "au dernier moment", c’est-à-dire de prendre les décisions seulement au moment où cela est nécessaire.
Il n’y a donc plus forcément de phase en début de projet uniquement consacrée à la définition de l’architecture : on fait un cadrage 360° où l’architecture émerge en même temps que les besoins et la vision produit. Mais cela ne signifie pas que les questions d’architecture ont disparu : seulement qu’on les traite au fur et à mesure.
Pour qu’un développement s’intègre dans un SI, il faut répondre à des questions d’architecture de SI : quels sont les échanges à faire, sous quels formats, comment seront gérées les évolutions…
Ces sujets sont transverses au SI et donner de la cohérence à cette échelle permet de garder la complexité sous contrôle et donc d’augmenter vos chances de construire un système pérenne. Le pilotage de SI doit être pensé comme un investissement à moyen et long terme.
Il s’agit également de faire le lien avec le métier pour l’éclairer sur les conséquences de ses choix.
Ici encore, on peut s’en passer et tout décider en point à point de manière opportuniste, mais c’est risquer de développer un système trop hétérogène difficile à faire évoluer. D’autant plus que le développement en cycles courts peut créer une sorte de myopie qui fait oublier le temps long et que l’architecture a une mauvaise image pour une partie des agilistes.
La plupart des personnes qui développent ont un vernis sur l’architecture de SI : ce sont des extensions des questions d’architecture logicielle, et elles concernent tout le monde sur les projets.
Ce vernis est très utile pour pouvoir comprendre les enjeux, et faire en sorte que ce qui est fait dans le projet soit cohérent avec les décisions d’architecture au niveau du SI, même si l’on n’est pas directement partie prenante des décisions.
Ce vernis peut même être suffisant pour mener des projets. Ainsi tant qu’un projet n’a aucun besoin "exotique" c’est à dire aucune contrainte inhabituelle en terme de volume, performance, intégration avec les autres systèmes … une expertise limitée peut suffire.
Mais dans d’autres cas ce vernis n’est pas suffisant. Prendre certaines décisions nécessite de connaître les conséquences à long terme des différentes options, ou les prérequis pas forcément évidents d’une idée qui semble couler de source. Par exemple tout ce qui tourne autour de la gestion du changement comme les montées de versions avec gestion de la compatibilité, ou la capacité de mettre à jour le système sans interrompre le service. Cela demande de l’expertise, qui repose sur de l’expérience.
Dans des organisations de grande taille, en plus de prendre les décisions il faut faire le lien entre toutes les personnes impliquées sur le sujet, comme les équipes en charge de l’infrastructure ou de la sécurité. L’expertise technique doit alors s’accompagner d’autres compétences.
La question n’est donc pas le fait de porter ou pas le titre d’architecte, mais d’avoir des personnes qui auront les compétences adaptées à votre ou à vos niveaux de besoin : si sur des sujets transverses un·e architecte "classique" est souvent nécessaire, l’expérience OCTO prouve qu’au niveau d’un projet un·e tech lead expérimenté·e peut être le bon choix.
Les équipes d’architectes "tour d’ivoire" des années 2000 nous ont montré les risques de faire de l’architecture de SI loin des projets et de penser que l’architecture devait tout aux architectes. Cette vision est révolue. Pas d’architecture qui fonctionne sans participation du reste de l’IT, voire des métiers.
Notre préconisation est que la (ou les) personnes en charge de l’architecture d’un projet en fasse(nt) partie : cela permet de mieux comprendre les enjeux et ce qui s’y passe. Cela permet de prendre de meilleures décisions tout en impliquant mieux les autres membres de l’équipe.
Avoir un·e architecte "à demeure" est un bon choix, mais souvent un projet n’a pas de quoi occuper un poste à plein temps. L’architecte risque alors de chercher à se rendre utile et à aider le projet malgré lui.
Une des solutions est qu’il ait d’autres cordes à son arc et fasse du développement, de l’ops ou d’autre tâches le reste du temps. La cohésion des projets s’en trouve renforcée mais nécessite d’avoir des moutons à cinq pattes.
Autre option, faire du "consulting" sur d’autres projets dans lesquels le besoin en architecture est plus ponctuel. Cela est bien pratique pour les projets, même si cela rend la gestion du temps plus compliquée.
Les projets qui ont de faibles besoins en architecture n’auront pas besoin de l’aide d’un architecte mais seulement de personnes avec un vernis sur le domaine afin de pouvoir faire le relai avec le reste du SI, et d’en savoir assez pour déterminer à quel moment il devient nécessaire de faire appel à une expertise extérieure.
Ce modèle donne de meilleurs résultats que celui où des équipes d’architectes intervenaient pour les cadrages des projets puis disparaissaient, mais il demande une organisation plus fluide.
Avec les progrès techniques et organisationnels, le temps à passer sur les questions d’architecture a diminué. On a donc de moins en moins besoin d’achitectes.
Cela signifie que les architectes - entre autres - ont bien fait leur travail, et ont su faire progresser leur discipline.
Dans beaucoup de projets, une expertise limitée en architecture est désormais suffisante, tant qu’on sait ce qu’on ne sait pas.
À l’inverse, sur des projets plus complexes ou pour les sujets d’architectures transverses, des architectes SI expérimenté·e·s restent souvent nécessaires. En effet si la capacité à faire a beaucoup progressé, les question de stratégie de SI sont toujours là.