Depuis quelques années, je travaille sur l’architecture de SI, j’ai même organisé une conférence sur ce sujet.
Mais jusqu’à présent, je n’ai pas de définition précise de ce que cela signifie.
Mais, pour changer de l’article précédent, je vais essayer d’en parler plus sérieusement cette fois-ci.
Travailler sur l’architecture d’un système d’information, c’est prendre des décisions sur un système informatique d’une certaine taille.
Il peut s’agit de choisir des outils, de définir leur utilisation, de définir des stratégies d’entreprise côté IT, ou d’accompagner des projets…
Ces décisions mélangent du développement, de la gestion projet, de l’organisation, de la technique, et d’autres choses…
Il s’agit d’un réseau de sujets liés entre eux, et qui définissent un domaine. Certains sont plutôt centraux, d’autres plus en périphéries.
L’archi de SI commence là où sont les compromis
En simplifiant, un bon critère pour savoir si une question fait partie de l’archi du SI, c’est de savoir s’il existe une solution simple qui répond parfaitement à tous les besoins.
En effet, une caractéristique, pour moi, de ce sujet, est que les réponses posées en archi de SI sont presque toujours des compromis : elle répondront bien à certains cas, et moins bien à d’autre.
Car un système informatique complexe obéit à tout un cas de contraintes souvent incohérentes, et les questions posées doivent souvent répondre à des besoins qui le sont tout autant.
Cela ne veut pas dire que les solutions choisies sont toujours compliquées : parfois la meilleure solution est la plus simple, mais elle viendra presque toujours avec des limitations.
Le travail d’une personne qui travaille sur ces sujets consiste à comprendre les enjeux de chaque problème, et à savoir prendre une décision qui s’insérera au mieux dans le système.
Réaliser “vraiment” que les solutions magiques n’existent pas, et apprendre à vivre en faisant des choix presque jamais complètement satisfaisants est une étape important dans la carrière d’un ou d’une architecte. Si vous demandez pourquoi les architectes ont la réputation de beaucoup se plaindre, je pense qu’une partie de la réponse vient de là.
Expertise & polyvalence
Si les problèmes posés brassent autant de sujet, l’architecte doit-il ou elle tout savoir sur tout pour pouvoir travailler ?
Idéalement oui, mais dans la réalité ça n’est pas le cas : un système informatique d’une certaine taille, c’est-à-dire son code, ses outils, et les pratiques qui les accompagnent, sont trop complexes pour qu’une personne seule puisse les maîtriser.
Comment faire alors ?
C’est simple : ne pas faire seul, mais savoir faire à plusieurs, avec les bonnes personnes.
Face à une question trop compliquée pour lui, la compétence de l’architecte consiste à
-
savoir identifier quels sont les pans du système qui seront touchés ;
-
pour chacun des pans, parvenir à savoir si il ou elle en sait assez ou si de l’aide est nécessaire ;
-
si de l’aide est nécessaire, savoir travailler avec les autres.
Par exemple : identifier qu’un nouvel outil n’est peut-être pas compatible avec des règles de sécurité, et qu’il faudra aller parler avec le ou la RSSI, ou qu’un POC qu’on voudrait déployer remet en cause le fonctionnement d’un autre projet.
L’apprentissage d’un ou d’une architecte est donc un mélange de deux types de connaissance :
-
construire une expertise forte sur certains domaines au cœur de son métier, comme les questions d’intégrations de données, permettant d’être autonome ;
-
obtenir un niveau de compétence faible sur plein d’autres sujets, permettant à la fois de détecter qu’un sujet est à prendre en compte, et de travailler avec les personnes expertes de ce sujet.
L’architecte est ainsi quelqu’un qui veille qu’il n’y ait pas d’externalités dans les décisions prises. C’est à dire d’agents sur lequel une décision influe et qu’on n’aurait pas pris en compte.
Encore une fois cela ne signifie pas que tout le monde obtiendra satisfaction, car en général c’est impossible, mais seulement que les décisions sont prises en connaissance de cause.
Légitimité
Le deuxième axe d’apprentissage est celui de la légitimité.
En effet, un ou une architecte doit parvenir à répondre à des enjeux complexes, tout en ne possèdent parfois qu’une faible partie des expertises nécessaires.
Comme faire, surtout quand en plus il faudra dire non à des personnes qui en savent plus que vous dans leur domaine, car encore une fois on ne peut pas dire oui à tout le monde ?
Il faut pour cela se sentir légitime : avoir une certitude suffisante qu’on a bien entendu toutes les bonnes personnes, et que la décision prise est celle qui répond aux mieux à l’ensemble du système. Qu’une décision qui ne satisfait pas tout le monde n’est pas le résultat de l’incompétence, mais une conséquence de la complexité.
La tentation d’y répondre par une forme d’arrogance, qui serait une manière de se protéger, et souvent là, mais si on fait ça on fait du mauvais boulot : en se plaçant au dessus on perdra la capacité d’écoute qui fait les bonnes décisions.
Autant que l’apprentissage des contenus, maîtriser cette posture est un travail de longue haleine. Si l’organisation dans laquelle on s’inscrit peut faire beaucoup, par exemple par un appui hiérarchique fort, elle demande dans tous les cas un travail sur soi.
Tout est bon pour l’archi de SI
En dehors des aspects techniques, la multiplicité des domaines touchés par l’architecture est ce qui m’attire dans ce métier.
En effet cela signifie qu’il y a un tas de domaines à explorer, et que dans beaucoup d’entre eux même une connaissance faible peut déjà être utile.
Par exemple lire un livre sur le réseau pourra améliorer votre capacité à travailler avec des spécialistes de ce domaine de manière déterminante. De même sur le sécurité, le mobile, l’organisation…
Bref : un ou une architecte de SI a toujours une bonne raison de s’intéresser à un nouveau sujet.
Tant qu’il ou elle garde en tête qu’un vernis ne remplace pas l’expertise, et qu’en savoir un peu sur tout fait de vous un spécialiste en tout.
Les modes
La partie la plus désagréable en tant qu’architecte est de voir arriver de nouvelles modes en IT.
Par exemple le DevOps, le REST, les microservices…
Dans son travail, les architectes ont pour mission d’identifier là où ça va coincer, de piloter par le risques, de peser le pour et le contre.
Et lorsqu’une nouvelle mode arrive, la nouvelle révolution qui prétend tout changer en mieux et sans contrepartie, un ou une architecte ne pourra s’empêcher de chercher et de trouver ce qui ne fonctionnera pas, ce qui ne peut pas se passer aussi bien qu’on le dit, le cas pénible qu’on préfèrerait oublier.
On peut garder une forme d’enthousiasme, car souvent les modes ont tout de même des effets positifs dont on va profiter. Mais un enthousiasme toujours limité par le fait de savoir ou de penser savoir que ça va quand même finir par échouer, ou du moins que ça peut pas fonctionner aussi bien que ça, et que dans 3 ans ça va recommencer.
Et on se fait traiter de grincheux ou de grincheuses.