La formation

La formation doit être, au même titre que la veille, une tâche récurrente de votre activité d'architecte.

Les sujets possibles sur lesquels vous formez sont innombrables, ils peuvent porter sur un logiciel à propos duquel vous ne vous sentez pas tout à fait à l'aise pour émettre des conseils, un nouvel OS inscrit au catalogue technique de votre entreprise, une technologie que vous voyez poindre de plus en plus régulièrement dans votre veille, etc..

Le point important à retenir est que vous n'êtes pas obligés de devenir LE spécialiste du sujet, la formation doit vous permettre d'acquérir les éléments nécessaires à votre travail d'architecte. Sauf si le sujet vous passionne, ne passez donc pas des semaines sur le sujet.
Prenez le temps de vous abreuver à des sources multiples (surtout s'il s'agit d'un logiciel propriétaire), si vous l'estimez nécessaire mettez en place un Proof-Of-Concept.

Pour un architecte, le POC doit être réservé aux cas où les enjeux et les incertitudes sont forts. Il n'y a pas grand sens à réaliser un énième POC Kubernetes rejouant un tutoriel trouvé sur le net. Oui Kubernetes ça marche, c'est confirmé mais avait-on besoin d'une preuve supplémentaire ? En revanche, il peut y avoir un intérêt à faire un POC Kubernetes pour valider comment cet orchestrateur s'intègre avec les outils et méthodes de travail de votre exploitant. Après, reste à voir si l'architecte est le mieux placé pour faire ce POC.

Le recours à des formations externes est une solution, notamment si votre charge ne vous permet pas de réserver une plage de temps continue et suffisamment longue pour une formation (non on ne se forme pas à coup de 30 minutes entre 2 réunions et en regardant ses mails). Comme c'est souvent fort onéreux pour un résultat très variable, j'aurais tendance à conseiller de les réserver pour approfondir des thématiques, car pour "l'initiation" les informations disponibles en accès libre sont souvent suffisantes. Cela évite aussi de se retrouver dans des sessions avec des débutants complets ou des profils très différents du vôtre qui peuvent faire perdre beaucoup de temps (oui je sais c'est enrichissant de rencontrer des gens de tous horizons mais quand on fait une formation assez dense sur R on goûte moyennement le fait d'être avec des individus qui doivent être accompagnés par le formateur pour faire une recherche Google. Véridique)

Après vous êtes formés. Formez. Vos collègues architectes s'ils sont demandeurs. 99-archives/05-Projet livre architecture/content/Capitalisez ce que vous avez appris.

Tant qu'à parler de formation, mettez en place une formation courte, 1 journée suffira pour présenter les principaux aspects de l'architecture aux nouveaux arrivants du SI (chefs de projets, développeurs etc).

Voici le plan d'une telle formation que j'ai mise en place :

  • Le SI vu d’avion : présentation des différentes strates (datacenter, réseaux, serveurs, virtualisation, etc) du SI. Prenez garde à être vulgarisateur (vos interlocuteurs peuvent n'avoir aucune connaissance informatique) et à centrer chaque expliication sur votre SI, ne faites pas un copier-coller de wikipedia.
  • le Cadre d'architecture : où trouver les règles, les bonnes pratiques, les logiciels à utiliser
  • Exemples d'architecture : les patterns les plus courants dans votre entreprise
  • Le processus d'architecture
    • les entrants
    • les livrables : documentation, schémas
    • instances de validation
    • durées moyennes de chaque étapge
  • Focus sur la cybersécurité (parce que c'est l'affaire de tous)