Explication

On a tous griffonné sur un tableau, une feuille blanche ou un cahier un schéma représentant notre application.

On appelle cela un diagramme d’architecture et on rajoute souvent la notion d’architecture technique, physique, réseau, logicielle, de déploiement, etc. (en fait tous les trucs qu’on a appris en cours d’UML ou de conception) – wiki.

Toutes ces “architectures” ne sont finalement que des vues de notre système. L’une va être utile à l’équipe IT, l’autre aux développeurs, une autre pour le client ou pour illustrer la documentation.

Pour simplifier, j’en impose un seul : la Big Picture, le diagramme qui permet de discuter autour d’annoter, de débattre, de débuguer mais surtout de comprendre la solution.
C’est même presque la seule documentation imposée.

L’objectif de ce diagramme n’est pas l’exhaustivité (pas forcément besoin de préciser les DMZ, les IP, les protocoles, les technos utilisées) mais juste de voir les gros blocs du système et leurs interactions principales.

Ex :

• Le Service Windows appelle la base de données,
• un Job SQL appelle l’Active Directory,
• un Service Web est exposé à l’extérieur,
• une Application Console lit dans un jeu de répertoires,
• etc.

L’objectif est de se repérer.

Il servira à gribouiller dessus, à valider qu’on a rien oublié lors de la mise en production, qu’il n’y a pas une incohérence globale et tout un tas de choses auxquelles on pense dans la réalisation d’un projet (et que je serai incapable de ressortir de façon exhaustive à chaud).

Evidemment, de ce schéma, de nombreux en découlent : celui qui focalise sur les machines ou sur les instances SQL, celui qui détaille les namespaces ou le découpage des projets dans Visual Studio, celui qui montre les permissions à donner, etc.

Quel outil ? :

En général, quand je demande le schéma, on me répond qu’il faut installer Visio. Que nenni ! Moi, j’utilise PowerPoint.

On peut mettre des formes basiques (les patates), mettre du texte dans tous les sens, avoir des flèches “libres” (ou pas), jouer avec les couleurs, mettre des images ou des cliparts, etc. Et ça tient sur un slide.
En un mot comme en cent, c’est souple et joli (et vos clients-utilisateurs-patrons) pourront le lire sans problème.

(toutefois, un certain Christopher m’a fait un super Visio récemment)

Quelques exemples :

Je n’ai pas écumé mes archives pour vous en sortir 450, j’en ai pris quelques uns à la va-vite sur mes récents projets.

Vous noterez qu’au départ, rien ne vaut le tableau blanc (ici, le résultat des journées de cogitation au MTC lors d’Architecture Design Session que je donne).

Chez Bewise, la méthodologie a aussi une place importante. Un domaine métier y est même dédié : AMI. De nombreux débats ont lieu au sein de nos projets (mais aussi à la machine à café. )

Pour montrer son attachement aux méthodologies agiles, Bewise, via l’un de nos consultants (Ionut Mihalcea), animera un séminaire pour l’association SigmaT qui promeut l’agilité dans le sud-ouest.

Ce sera le 11 décembre à l’université Paul Sabatier et le sujet est : Pratiques Agiles avec Team Foundation Server 2010

Le programme complet se trouve ici :
http://www.sigmat.fr/dotclear/index.php?post/2009/11/24/Programme-du-SigmaT12

Pour vous inscrire : http://www.sigmat.fr/dotclear/index.php?form/inscription