Sommaire
- Contexte
- Mon métier
- L'Architecte d'Entreprise
- L'architecte technique
- La théorie
- En pratique
- Bilan
- Résister
Cher journal,
Aujourd'hui je t'écris pour partager mon expérience d'architecte IT dans une grande entreprise française.
Contexte
Je travaille dans une grosse boite avec beaucoup de coeurs de métier différents et donc d'outils informatiques différents. L'informatique de la boutique est gigantesque, avec des portions sur des clouds publics, d'autres sur des clouds privés, d'autres complètement on prem accessibles d'ailleurs, et enfin d'autres complètement on prem et totalement isolés (air gap).
Nous gérons donc un grand nombre de SI différents, de tailles différents, pour des usages différents.
Mon métier
Mon travail, c'est de prendre un problème, ou un besoin métier, ou une évolution réglementaire, et d'y apporter une solution IT répondant au besoin, à la réglementation, avec des coûts et délais maitrisés (à peu près).
Avec si possible une recherche de cohérence technologique entre les différents environnements afin que les pauvres sysadmins et admins réseau ne se retrouvent pas avec 40 technos différents à maitriser pour faire leur job.
Ah oui, et documenter le tout. Rétro-documenter parfois, le plus amusant (lol).
Evidemment dans ma DSI je ne suis pas tout seul, avec les collègues on se parle et on tente d'avancer dans la même direction.
L'Architecte d'Entreprise
Disclaimer : cette section ne sera pas objective.
Dans toute grande boite comme ça, il y a (à Paris si possible, dans un grand building vitré, au 24ème étage), des gens "en central" qui sont Architectes d'Entreprise. Leur métier consiste à réfléchir à long terme, et à orienter les grandes tendances et patterns d'architecture de l'IT de la boutique dans son ensemble. C'est donc un travail nécessitant un haut niveau d'abstraction et une fine connaissance du marché et des technos. Qu'est-ce qui est intéressant mais qui dans 2 ans n'existera plus ? Comment faire en sorte que les jeunes dev ne fuient pas au bout de 2 semaines devant l'IT de dev ? Etc… C'est un travail important.
Ce genre de personne est donc très souvent assez loin des problématiques de terrain et produit majoritairement des slides et des réunions Teams.
L'architecte technique
L'architecte technique est une personne experte dans un domaine IT ou une techno donnée. Dans les grosses boites, on les trouve souvent en équipe : les experts stockage, les experts virtu, Windows, annuaire, etc… Ces gens produisent des briques de base IT parfaitement maitrisées que les archis solution utilisent pour concevoir… ben des solutions IT quoi.
La théorie
En théorie, les architectes d'entreprise fixent donc les grandes cibles des évolutions du SI. Les architectes solution (moi) conçoivent une solution IT permettant d'atteindre cette cible, avec les briques de bases d'IT standard de la boutique. Ensuite, les admins, assistés des experts, installent tout ce bazar, et en assurent ensuite l'exploitation. Il arrive parfois que les équipes de "build" et de "run" soient séparées, parfois avec un niveau de sous-traitance en plus.
Dans un monde merveilleux, tout va bien.
En pratique
Voici comment ça se passe en pratique :
1) Un grand chef se réveille un matin et dit : nous devons mover vers le cloud car tout le monde le fait.
2) le CTO et ses architectes d'entreprise font plein de slides jolies.
3) La sécurité passe par la et explique que non, tout va pas aller chez les GAFAM, et que faut ségréguer, hybrider, on premiser, segmenter, etc…
4) On prend un cabinet externe pour concevoir une solution déclinable dans tous les cas : 1 gros building block, qu'on sait instancier chez GAFAM, chez nous, autant de fois qu'on a de SI. Evidemment, ça accouche d'une usine à gaz monstrueuse avec tous les trucs hypes du moment, très cher tant qu'à faire.
5) Le corp déploie la version centrale de la boutique. Des équipes d'experts sont créés sur le sujet, une équipe maitrise bien. Ca va.
6) Le corp, pour rentabiliser son investissement humain, demande aux sous-DSI (nous), de déployer la même chose dans ses SI.
7) Le temps de trouver les sous, d'adapter l'archi aux contraintes locales, d'acheter le matériel, 2 ans passent.
8) Entre-temps, le corp a changé de cible, a pondu une autre usine à gaz, démantelé les équipes pour les faire bosser sur la nouvelle solution vachement plus mieux.
9) Quand nous on commence à déployer Solution A, on a plus de support dessus car le corp est passé sur la B.
10) Retour étape 1.
Bilan
Avant, on avait sur chaque SI 2 grosses solutions un peu old school mais qui marchent, et la super solution devait tout réunir sur une seule plateforme trop bien qui est la même dans toute la boutique.
Maintenant, on a 3 grosses solutions un peu old school. Et on a pas le temps de migrer les 2 premières sur la troisième car faut installer la quatrième.
Résister
Je suis un fervent partisan des solutions simples. On est pas un cloud provider. On fournit pas 200 VM par jour. Pour de l’isolé du net, un bon trois tiers virtu/SAN/stockage, c’est très bien. C’est pas cher. C’est rock solid. Les admins maitrisent. Mais c’est pas moderne. Je suis pas moderne. Et je l’assume.
# Retour à la ligne
Posté par Dafyd . Évalué à 3 (+2/-0).
Arf, je viens de voir que mes retours à la ligne dans vi ont été interprétés et que ça produit des retours à la ligne dans le texte. Je pensais que comme en markdown, ça n’aurait pas été interprété, sorry.
[^] # Re: Retour à la ligne
Posté par Benoît Sibaud (site web personnel) . Évalué à 4 (+1/-0).
Corrigé, merci.
[^] # Re: Retour à la ligne
Posté par Dafyd . Évalué à 1 (+0/-0).
Merci beaucoup, c'est nettement plus lisible !
[^] # Re: Retour à la ligne
Posté par ChocolatineFlying . Évalué à 10 (+12/-0).
on ta reconnu Cédric !
# Bienvenue au club
Posté par BenTpe . Évalué à 9 (+9/-0).
Malheureusement il n’y a pas que les services IT qui fonctionnent comme ça ;)
Je lisais récemment que chaque échelon de management en plus rajoute 10x le temps d’exécution. Je crois que vous êtes dans ce cas de figure…
# ça me rappelle des souvenirs
Posté par Bruno (Mastodon) . Évalué à 4 (+3/-0).
Difficile de lutter contre cet état de faits, surtout quand en plus il n'y avait pratiquement pas de contrainte budgétaire.
Et je faisais partie des décideurs..
Courage..
# Not all archi
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 4 (+2/-0).
"Ce genre de personne est donc très souvent assez loin des problématiques de terrain et produit majoritairement des slides et des réunions Teams."
C'est triste ton avis sur les architectes
. Que devraient ils produire selon toi ?
[^] # Re: Not all archi
Posté par Nicolas Boulay (site web personnel) . Évalué à -3 (+0/-6).
Linus Thorvald et Jean-Baptiste Kempf produisent quoi ?
"La première sécurité est la liberté"
[^] # Re: Not all archi
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 8 (+6/-0).
Linus Torvalds et Jean-Baptiste Kempf ne sont pas architectes d'entreprise rattachés à un CTO d'une grosse boite (genre Paprika ou Compagnie Géniale par exemple).
[^] # Re: Not all archi
Posté par Dring . Évalué à 10 (+9/-0).
Ils doivent faire ce qu'on leur demande, et c'est ce qu'ils font.
Mais ça n'empêche qu'ils sont loin du terrain, et que certaines décisions peuvent s'avérer difficiles voire impossibles à mettre en oeuvre. Que bien souvent, quand l'info remonte du terrain, c'est trop tard, on a déjà signé pour aller vers cette option, et donc maintenant c'est à marche forcée pour ne pas perdre l'argent investi.
Difficile de donner des exemples sans lâcher des informations confidentielles, mais j'observe souvent ce décalage. Je suis moi aussi architecte solution, et la plupart du temps je comprends pourquoi l'architecte d'entreprise a pris telle ou telle direction. Mais ça n'empêche pas que quand j'essaye de l'appliquer, je me heurte à des murs.
Pour rester vague :
- on a pris la solution TopMoumoute 3.0, du fournisseur BrilleTrèsFort. Elle sera installée on-prem. Elle fait tout ce dont on a besoin.
- on négocie un gros contrat, et on obtient un bon prix à condition de migrer au moins 1000 applications dans les 3 ans ; ça a l'air jouable
- mais le produit implique que le fournisseur sera en charge du maintien en condition opérationnelle, donc son staff aura accès direct à l'infrastructure
- ah ben du coup, OK c'est du on-prem, mais comme y'a des agents externes qui y ont accès, on vous interdit d'y mettre des données sensibles
Et pouf : tu as une cible "universelle", et rapidement tu te rends compte que l'essentiel des équipes ne peut pas s'en servir. Mais ce "petit sujet" de limitation en terme de confidentialité n'est pas au centre de la comm', donc plusieurs équipes vont joyeusement vers la solution pour découvrir en cours de route que "ah ben oui mais non, faut migrer maintenant".
Accessoirement, l'objectif de migration n'est pas atteint, et donc le prix pas si intéressant. Donc ceux qui ont réussi à faire la migration doivent payer plus que prévu.
Le temps que tout ça soit identifié et remonté à l'architecture centrale, pris en compte et corrigé… on parle en années. Même remonté rapidement, revoir les contrats… c'est encore des années.
On peut toujours dire "c'est parce que les études initiales ont été bâclées", mais c'est un peu facile. On sait bien que c'est compliqué.
[^] # Re: Not all archi
Posté par Dafyd . Évalué à 2 (+1/-0).
Oui je suis d'accord c'es pas aussi binaire que ce que j'ai écrit. Mais j'avais mis le disclaimer ! Je ne suis pas objectif :D
# 2 ans... ou plus ?
Posté par Paul POULAIN (site web personnel, Mastodon) . Évalué à 9 (+7/-0).
Dans "architecte d'entreprise" tu écris : "Leur métier consiste à réfléchir à long terme, et à orienter les grandes tendances et patterns d'architecture de l'IT de la boutique dans son ensemble […] Qu'est-ce qui est intéressant, mais qui dans 2 ans n'existera plus ?"
Puis "en pratique" : "Le temps de trouver les sous, d'adapter l'archi aux contraintes locales, d'acheter le matériel, 2 ans passent. Entre-temps, le corp a changé de cible".
Du coup, ça se contredit. Est-ce que le souci ne serait pas là : le corp a mal fait son travail et a choisi une solution avec une vision court terme ? Le PDG / le conseil d'administration a changé => la vision a radicalement changé => aucun respect de la décision d'il y a 2 ans ?
Bref, il me semblerait, vu d'ici, que la responsabilité vient du changement de vision plus que de la "grosse structure".
Exemple (non vécu) : on passe d'un "nous devons maîtriser toute la chaîne de production" (= internaliser un maximum) à "nous devons nous recentrer sur notre cœur de métier" (= externaliser un maximum). Forcément, si on change de vision tous les 2 ou 3 ans, difficile de suivre…
[^] # Re: 2 ans... ou plus ?
Posté par Dring . Évalué à 10 (+11/-0).
Tous les 2 ans (à peu près) il y a une nouvelle mode et il faut la suivre.
Il faut la suivre non pas parce qu'on y croit, mais parce que si on ne le fait pas, on sera "sanctionné par le marché".
Parce que c'est bien connu, le marché sait. Le marché a compris, il a tout compris. Le marché a bien vu que l'offshoring c'était l'avenir pour réduire les coûts IT. Que la blockchain réglait de nombreux problèmes. Que passer en agile "at scale", c'était la garantie de pouvoir enfin réagir au quart de tour. Qu'avec ITIL, les incidents allaient disparaître d'eux même. Qu'avec ServiceNow, gérer son patrimoine informatique et ses évolutions serait désormais à la portée d'un nouveau né. Qu'avec MongoDB, on n'était plus limité dans les données stockables. Qu'avec Java, on faisait du "write once, run everywhere". Etc…
C'est navrant parce que pas mal de fois, je me suis pris à y croire moi aussi. Puis la réalité m'a rattrapé.
Même le meilleur architecte d'entreprise n'est pas à l'abri de ce phénomène.
[^] # Re: 2 ans... ou plus ?
Posté par Dafyd . Évalué à 10 (+10/-0).
Oui en fait ce qui me fatigue, c'est qu'au lieu de capitaliser sur les technos, de densifier, etc… Ben on s'éparpille dans toutes les technos à la mode qui sont sensées résoudre tous nos problèmes. Alors que remplacer une VM qui fait serveur Web pour 20 personnes par du kube parce que ça "scale", etc etc… Ben.. on a pas besoin que ça scale.
Au final on a encore plus de problèmes qu'avant, mais des problèmes modernes.
C'est cette démarche que je critique.
[^] # Re: 2 ans... ou plus ?
Posté par Christophe B. (site web personnel) . Évalué à 5 (+3/-0).
Et encore tu as oublié "l'IA qui va améliorer la productivité"
La com et le marketing c'est que du bonheur
Au temps de la pré histoire (avant internet) les prédictions étaient du style
Mais qui a besoin de plus 640K de RAM ?
Dans 5 ans il n'y a plus de papier crayon …
Un peu plus tard
Dans les années 2000+ avec la virtualisation plus besoins de ces e……. de sysadmin
Le NoSQL qui devait remplacer les bases relationnelles
Bref si on devait écouter les commerciaux, la GAFAMs il faudrait changer tout les 6 mois de technos, de téléphone, d'applications etc …
Alors que dans la vie réelle … exemple d'un client que l'on a installé en 2001 la machine disposait 1 Go de RAM et de 2 Disques de 9 Go (en RAID1) pour gérer une petite compta utilisée par 3 utilisateurs. Cette machine a dispensée de bon et loyaux services jusqu'en 2018 soit 17 ans
La machine : un IBM 44 P (RS/6000) et l'OS AIX 4.3
pourquoi : du bon sens, un client qui connait ses besoins réels, pas de réve juste du concret
Si on arrêtait de vendre du réve, et on batissait du concret avec des choses faites pour être utilisé et durable comme l'open source cela marcherait certainement mieux
Mais cela necessite d'apprendre, de lire de tester alors que on vous propose un beau produit dans un beau papier cadeau … avec le sticker qui avec :)
Le bonheur se trouve dans l'IPHONE 16 … 17 … 18 … ou dans le dernier Windows … 11 .. 12 .. 13 c'est évident non ?
C'était l'avis d'un vieux c..
[^] # Re: 2 ans... ou plus ?
Posté par Pol' uX (site web personnel) . Évalué à 4 (+2/-0).
Et c'est sans compter sur l'essor de l'informatique qui va simplifier l'administratif. :) 40 années de retex nous le prouve chaque jour.
Adhérer à l'April, ça vous tente ?
[^] # Re: 2 ans... ou plus ?
Posté par Christophe B. (site web personnel) . Évalué à 4 (+2/-0).
Ces 40 ans de retex prouve que la connerie naturelle cela ne fonctionne pas
alors
plan B => l'intelligence artificielle
Dans 2 ans je suis à la retraite … bon courage les gars ;)
[^] # Re: 2 ans... ou plus ?
Posté par Ysabeau 🧶 (courriel, site web personnel, Mastodon) . Évalué à 4 (+1/-0).
Ça sent le type qui compte les jours et ne jouera pas les prolongations.
Je n’ai aucun avis sur systemd
[^] # Re: 2 ans... ou plus ?
Posté par Christophe B. (site web personnel) . Évalué à 3 (+1/-0).
Normalement non, de plus j'ai déjà commencé à travailler 3 jours sur 5 en retraite progressive (faut avoir plus de 60 ans et le nombre de trimestre necessaire)
Et cela va bien comme transition, cela suffit amplement en attendant le 0/5 :)
Et puis la vie offre tellement de choses a faire en dehors du travail …
De plus je continuerai certainement a donner mon avis sur LinuxFr :)
[^] # Re: 2 ans... ou plus ?
Posté par Dafyd . Évalué à 4 (+3/-0).
Non ça se contredit pas ! Dans mon cas "le corp" ce sont les archi d'entreprise en central.
Ce sont eux qui changent de techno, de gouvernance, etc… tous les 2 ans. Ce qui est, effectivement, incompatible avec une vision à long terme. C'est justement la défaillance que je pointe.
# L'herbe est plus verte ailleurs...
Posté par arnaudus . Évalué à 10 (+11/-0).
Ce qui me fait un peu marrer, c'est à quel point cette situation qui te semble ridicule ressemble à une île paradisiaque quand tu compares avec ce que je connais (la fonction publique).
Dis-toi que tu as un budget IT, que certains des décideurs savent ce qu'est un ordinateur, des gens qui sont compétents et payés pour concevoir, acheter, maintenir le matériel et le logiciel, qu'il y a une stratégie IT avec des gens qui discutent de ça, que les employés n'ont pas besoin d'acheter leur matériel informatique eux-mêmes, qu'il existe des consignes de sécurité, que les pratiques au quotidien ne consistent pas à travailler sur Google docs et ChatGPT avec son adresse gmail perso, que tu peux créer un ticket quand tu as un problème IT (et que quelqu'un lit les tickets de temps en temps), etc.
Sur le fond, j'ai peur que tu ne décrives juste les dérives inévitables des très grosses organisations.
[^] # Re: L'herbe est plus verte ailleurs...
Posté par Liorel . Évalué à 10 (+9/-0).
Tu as le pire et le meilleur dans la fonction publique.
Un jour, j'étais au CHU de Montpellier, j'ai reçu un mail manifestement de phishing d'une adresse en @chu-rouen.fr (ou peut-être Caen, je ne sais plus). Mail forwardé dans la foulée à mon RSSI, et après quelques recherches, au RSSI du CHU normand. Une demi-heure plus tard, je reçois un mail du RSSI normand, qui me demande des précisions et m'indique une marche à suivre précise pour les obtenir, et m'indique que dans l'intervalle, ils ont bloqué le compte de la personne. Donc plutôt propre.
Là, je suis en ARS, et j'ai pu demander à installer KeePass sur ma machine : non seulement ça n'a fait aucune difficulté, mais en plus on a une page de promotion de KeePass sur l'intranet avec une vidéo de formation. On a régulièrement des campagnes sur la sécurité informatique, la confidentialité des données, la sécurisation du poste de travail et on a un chiffrement des mails (en réalité un service qui envoie un lien au destinataire et lui sert du HTTPS).
Bon après c'est pas parfait, notre DSI veut mettre de l'IA partout et on n'a pas eu de réflexion en amont sur comment organiser nos données, notre gestion documentaire est archaïque et on a des tas de Word dans tous les sens là où un wiki ferait environ 20 mieux fois le taf, mais là on est plus dans ce que décrit le journal que dans ce que décrit ton commentaire.
Après je pense que par rapport au reste du secteur public, je suis privilégié du fait d'être dans la santé : on a des obligations très fortes, de l'ordre du pénal et à l'échelle individuelle1, en termes de fiabilité et de confidentialité, donc forcément, les moyens humains et financiers suivent. Quand je vois ce qu'il en est dans l'école de mon fils, c'est plus inquiétant et plus proche de ce que tu décris.
un médecin, même hospitalier, peut tout à fait aller en prison pour une erreur médicale, et la non-tenue du dossier médical est une erreur médicale. Si un agent du fisc se plante, il se fera peut-être virer, mais c'est le maximum qui puisse lui arriver. ↩
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: L'herbe est plus verte ailleurs...
Posté par passke (site web personnel) . Évalué à 6 (+5/-0).
Personnellement, je vois de plus en plus de meilleur et de moins en moins de pire… même si la machine est énorme, elle progresse et j'ai l'impression que le mouvement accélère. Par ailleurs les logiciels libres ont de plus en plus leur place tant dans la bureautique que dans l'infra.
[^] # Re: L'herbe est plus verte ailleurs...
Posté par Dafyd . Évalué à 6 (+5/-0).
Oui je suis d'accord. Il y a du progrès. Je ne veux pas jeter bébé avec l'eau du bain comme on dit. C'est juste assez rageant quand tu bosses dans une boite avec un budget IT conséquent, le fric colossal dépensé en trucs à la mode, pour une valeur ajoutée discutable.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.