RTFAD : S'il vous plaît, veuiler lire le document d'architecture

Quelques pensées sur les domaines d'architecture logicielle et technologique

C’est quoi une vision d’affaire et technologique pour un projet ?

Non ce ne sont pas des licornes qui utilisent la magie pour créer de l’harmonie.

C’est un ensemble de principes, entre 3 et 5 phrases simples sur lesquels on se base pour prendre des décisions et prioriser. Pour qu’elles soient bien comprises et utilisées dans un projet, elles doivent être communiquées par du leadership.

Celles-ci sont extrêmement importantes dans toutes les étapes du projet, conception, analyse, développement, assurances qualité et support / maintenance.

Dans des projets complexes, pour ne pas succomber à l’inaction, on doit toujours se ramener à ces principes. Pourquoi nous faisons ce projet ? Quels sont les objectifs les plus importants ? Comment mesure-t-on leur succès ?

Toutefois, comme les licornes magiques, elles vont contribuer à l’harmonie et protéger de la discorde ☺

L'architecte en relation avec l'équipe dont il fait partie

Le plus important pour un architecte de solutions et de mettre en valeur et consolider le travail des spécialistes avec lesquels il travaille, le tout à l’intérieur de la vision d’affaire des projets et de son équipe.

Un architecte ne peut évidemment pas être spécialiste dans tous les domaines. C’est à la base un généraliste. Il doit par contre savoir parler techniquement et au niveau affaire autant avec les développeurs, les analystes, le marketing, les artistes, les DBA, les clients, les parties prenantes, etc.

Il découpe les besoins d’affaire pour en faire une vision technologique du projet.

Dans un modèle agile, il ne porte plus le nom d’architecte (c’est trop hiérarchique), mais il oriente et aide l’équipe à communiquer. Il est l’allié du scrumaster pour débloquer des récits.

Il écoute, consolide et représente.

Parce que je m'en rappelle jamais : lister les modules PHP en command line

php -me

Quand est-ce que des humains scalent plus que des processus et vice-versa ?

Même si ce n'est pas nécessairement mieux pour le SEO, je considère que d'écrire tout le HTML est plus zen que d'utiliser un CMS.

Je me pose parfois la question si d'utiliser un CMS n'amène pas automatiquement une architecture dégueue.

La vision d'architecture ne se trouve pas dans le code (en fait pas de façon super lisible)

En même temps que nous ne sommes pas toujours assez habitués de faire des tests unitaires complets, je crois qu'on ne pense pas à bien définir et communiquer la vision technologique d'un projet. C'est à ce quoi sert un architecte dans une équipe de développement ! S'assurer que tout au long du projet, les choix technologiques s'enlignent avec ce qui avait été décidé au départ, et que si l'orientation change (ça se peut, personne n'est parfait), l'ensemble de la solution en prenne compte. L'architecture, fait partie de la définition du "done" en agile et l'architecte supporte l'équipe en ce sens.